Define what the application must contain
Begin with the product configuration, approved models and the visitor task. A guided view of a prepared product differs from an interactive assembly with selectable internal components. List the exact actions, explanations and reset flow instead of requesting “full VR” without a boundary.
Document what the experience will not assess. A sales presentation is not automatically a validated training simulator, a digital twin or a safety assessment. Such outcomes require separate scope and evidence.
Ask for five distinct work packages
| Package | What to identify | Common unresolved assumption |
|---|---|---|
| Product content | Models, configurations, textures and approved explanations | Production CAD is assumed to be ready for real-time use. |
| Interaction | Selection, navigation, reset and any guided sequence | Every visible component is assumed to be interactive. |
| Application delivery | Target device, installable build and installation method | A desktop preview is assumed to prove headset readiness. |
| Equipment | Device quantity, accessories, ownership and maintenance | Hardware is assumed to be included in the software price. |
| Event operation | Setup, operator instructions, support dates and fallback | Remote handover is assumed to include on-site staffing. |
Ask for assumptions to be visible beside each package. If the hardware has not been selected, quote the decision and validation work separately from a commitment to a specific device. If the customer supplies equipment, define when it becomes available for testing.
Use one visitor task to define the first release
List optional interactions individually so their value can be considered against development and testing effort. Keep a clear starting state and recovery path in the base scope. An impressive feature that cannot be reset by the booth team can interrupt the entire presentation.
One station or several?
Treat acceptance testing as a deliverable
Ask how the agreed visitor actions, startup, reset and recovery will be tested on the target device. State whether testing at the booth is included and what happens if the chosen network is unavailable. A desktop recording alone cannot prove headset behaviour or event readiness.
Confirm ownership and permitted use of the delivered application, model assets and source files. Record maintenance, update and post-event support boundaries. Request commercial terms for equipment and on-site work separately from content production.
Before requesting an interactive exhibition quotation, complete the visitor and operator checklist. If the device is undecided, compare AR, VR and screen-based 3D.
Budget for ownership after the first event
Clarify where the delivered build is kept, who can install it and which versions of the content and device it supports. Ask whether future product changes, operating-system changes, additional devices and repeat-event support are included or separately quoted. Record third-party licensing requirements where they apply.
The event budget may also need equipment transport, suitable power, spare accessories and an operator. These are planning categories, not a claim that every project needs the same kit. Before approving the estimate, have the event owner check what is already available at the booth and what someone still needs to supply. The planning checklist helps connect software scope to that practical handover.