Define the result before comparing totals
A quote for a touchscreen is not automatically a quote for a functioning kiosk. The screen may need a computer, an enclosure, an application, prepared content and someone responsible for opening and recovering it. Start with what a visitor should accomplish, then ask each supplier to price the same journey.
Distinguish a display running an existing approved application from a new branded experience. Reusing a working application can reduce new design work, but compatibility, content preparation and event testing still need an owner. A web page that works on an office laptop may need changes for public touch use.
Separate the budget into deliverables
| Budget area | Typical scope question | Evidence to request |
|---|---|---|
| Hardware and installation | Which display, computer, mount, cables and enclosure are included? | A complete station list and installation plan |
| Interface and application | Existing software adaptation or new design and development? | Visitor flow, prototype and agreed functions |
| Content | Who prepares products, images, language versions and video? | Content list, formats and approval owner |
| Integrations | Does data connect to registration, CRM or another service? | Test access, field mapping and success/failure behaviour |
| Testing and operation | Who verifies the real station and supports the event? | Acceptance checks, hours and recovery responsibilities |
| Future use | What can be edited or reused at the next event? | Agreed files, rights, licences and support scope |
Ask suppliers to mark included work, optional work and client-supplied inputs. A blank line can conceal a dependency that arrives as a late task. Name the owner even when the work does not appear on the AV supplier's invoice.
Worked example: the same hardware, three different projects
Imagine a hypothetical exhibitor requesting two identical kiosk stations for a two-day event. Option A presents twenty approved product pages from an existing application. Option B adds a new branded interface, two languages and a comparison tool. Option C adds contact capture, a CRM connection and locally queued requests during a network interruption.
The hardware count stays at two in every option. The software and acceptance work grows because the visitor journey changes. For C, “the form opens” is not enough: the correct fields must arrive in the receiving system, failed submissions need handling and the next visitor must start with a clean session.
Compare A, B and C against the event goal. If staff already record enquiries during a conversation, C may duplicate that process. If independent visitor requests are essential, its integration and recovery work belong in the base scope. Removing them would change the result, not simply lower the price of an equivalent kiosk.
Understand the work hidden behind small requests
“Add a confirmation” includes deciding what has actually succeeded. W3C's form guidance explains the need for clear submission feedback and understandable errors. For a kiosk, the project team must also agree which system confirms the action and what a visitor should do when it fails.
“Make it offline” also needs a defined scope. MDN describes preparing application resources for offline use; that is deliberate application work. Offline contact storage and later reconciliation add different requirements from showing local product images. Ask for functions and test cases rather than a single unchecked feature label.
Content volume matters too. Twenty complete, approved product records are a different input from twenty inconsistent PDFs and a folder of unlabelled photos. Specify whether the supplier organises, edits, translates and loads the content or receives finished material.
Compare the first event and the next one
Separate initial design and development from recurring hardware, logistics, licences and operation. Reuse can change the balance, but only if the next event can use the agreed application and materials. Different screen orientation, new products, a new language or a changed integration may require additional preparation.
Ask who receives editable files, who can publish changes and what happens when the underlying platform changes. Do not assume that commissioning a project transfers every third-party licence or includes indefinite maintenance. Record the intended reuse in the actual agreement.
Send a brief that makes quotes comparable
Describe the visitor task, number of stations, event hours and expected peak demand.
Provide the application reference, real content sample, languages and update needs.
List integrations, data fields, connectivity assumptions and required fallback.
Confirm the enclosure, power, installation access and support responsibilities.
Agree the prototype review, final-device rehearsal and handover package.
Common mistakes are comparing only screen rental, leaving content ownership open and assuming development includes event operation. Discuss the full journey through interactive installations or event applications, with the touchscreen equipment scope attached.