Two quotations can both say “architectural virtual tour” and describe very different work. One may start with a clean approved model; another may require reconstruction from drawings and photographs. A useful proposal makes those differences visible, so you can choose a scope that fits the project rather than guessing what is included.
Define the outcome and the audience
Start with the purpose of the presentation. Is the audience reviewing a design, discovering a development or exploring a representative interior? Name the decision the tour should support and the action that follows. This gives the production team a basis for recommending a format and helps you judge whether an added feature contributes something meaningful.
State where the experience will be used. An embedded website tour, a meeting presentation and a downloadable film have different delivery needs. Include languages, target devices and any access restrictions. If several stakeholders must approve the result, identify the person who combines their feedback. A clear outcome and review owner make the scope easier to manage than a broad request for something impressive.
Make the starting information explicit
Describe the available drawings, model formats, software versions and design revision. IFC supports open BIM exchange, but an exchange model still needs review before it becomes a browser presentation. Three.js similarly describes a delivery workflow and recommends glTF where possible; this does not eliminate cleanup, conversion or material work.
A proposal should say what happens when source information is missing or inconsistent. For example, an approved exterior model may still need interior modeling, while a polished render may not include reusable geometry. Ask whether the estimate assumes ready-to-use files or includes reconstruction and interpretation. A small compatibility test can resolve that question before the full schedule and price are fixed.
List included spaces, controls and outputs
Define the physical extent: buildings, levels, rooms, surrounding context and any exclusions. Then describe the viewing functions. Selected panoramas, free camera movement, unit selection and material choices are different tasks. Specify which are required and which are optional. Counting square metres alone cannot explain the complexity of navigation, modeling or interface design.
Name each delivery output separately. These could include a hosted viewer, an embeddable experience, panorama images, selected stills or a film. Agree the languages, resolution or quality expectations and intended platforms. If a vendor-hosted service is involved, clarify ongoing fees and what remains usable when the subscription ends. Ask who controls the hosting account and who can authorize future changes.
Agree reviews, design changes and acceptance
A review round should have a purpose and a clear approval owner. An early check can resolve scale, camera positions and included geometry before detailed materials are finalized. A later review can focus on finishes, labels and usability. Ask how comments are consolidated and what constitutes approval to proceed to the next stage.
Distinguish corrections against the approved brief from a change in the underlying design. Moving an entrance after approval can affect geometry, routes, labels and multiple outputs. A change log should identify that impact before work continues. Agree acceptance tasks too: for example, opening the overview on a phone, reaching a named interior view, resetting orientation and completing the inquiry path.
Compare three hypothetical scopes fairly
The following example concerns a fictional house presentation. It shows why the starting files and deliverable definition matter. The options are not advertised packages and do not imply a fixed price, deadline or production method for your project. Their purpose is to make assumptions visible before comparing proposals.
When reading real quotations, add a column for unanswered questions. If one includes modeling from drawings and another assumes a finished model, the headline totals are not yet comparable. Ask for clarification rather than assuming either provider is expensive or incomplete. The right comparison is the same useful outcome, with responsibilities and exclusions understood.
| Example scope | Starting assumption | Questions to resolve |
|---|---|---|
| A: linked panoramas | Approved model is usable; five selected positions | Who supplies finishes and hosts the result? |
| B: exterior plus three interactive spaces | Model needs preparation and browser optimization | Which controls, devices and languages are included? |
| C: model and presentation from drawings | Geometry must be reconstructed from current plans | Which dimensions are missing and who approves assumptions? |
| Optional later update | A named design revision changes after delivery | What files are retained and how is new work scoped? |
Move from inquiry to an agreed scope
- Describe the outcome
- Review available files
- Define spaces and outputs
- Agree review milestones
- Confirm handover and upkeep
- Approve a tailored quotation
Clarify rights, handover and the next conversation
Agree which files you receive and how you may use them. A public viewer, exported images and native authoring files are different deliverables. Architectural drawings, project design and third-party content can carry separate rights. The U.S. Copyright Office distinguishes architectural works from technical drawings in its jurisdiction; a real agreement should address the relevant owners and local requirements rather than assume every right transfers together.
Finally, describe maintenance and communication. Who responds to a broken embed, requests an update or removes an outdated presentation? What information is needed to request the next phase? A well-labeled inquiry form can gather these requirements without asking you to solve the technical pipeline yourself. Provide what you know, mark what is undecided and use the compatibility review to turn that information into a realistic written scope.
Ideas to take from this guide
- State the viewing outcome, audience and next action.
- Identify source files, revisions and modeling assumptions.
- List included spaces, controls, languages and outputs.
- Agree review rounds, approval ownership and design-change handling.
- Confirm hosting fees, handover files, rights and maintenance.
- Compare equivalent scopes and resolve unanswered questions.
A good quotation explains how the project will become a usable presentation. Compare clear responsibilities and a defined outcome before comparing a single total.
Sources & further reading
- Three.js — Loading 3D Models ↗
- buildingSMART International — Industry Foundation Classes ↗
- U.S. Copyright Office — Circular 41, Architectural Works ↗
- W3C WAI — Labeling Controls ↗
Original editorial guidance with hypothetical examples. Product documentation and the project’s approved source files define actual capabilities and scope.
