What is a custom virtual tour?

A custom virtual tour is an interactive digital experience built around a real or imagined place and a specific user decision. It may combine high-resolution 360° photography, conventional photography, video, 3D, maps, text, data and calls to action. Unlike a fixed-template tour, its journeys, interface, content, integrations, analytics and governance are designed for the organisation and its audiences.

The important word is not virtual. It is custom.

A useful custom tour does more than let someone look around. It helps that person answer a question: Is this the right accommodation? Will this venue work for our event? How does this facility operate? Where do I need to go? What should I understand before I arrive?

Not every organisation needs one. If the task is simply to show a small space quickly, a self-service platform, Google Street View, a video or a conventional web page may be the better investment. Custom becomes rational when the experience must support a complex decision, reflect a distinctive brand, connect to other systems, work across multiple sites or remain adaptable over time.

Start here: which decision are you making?

Use the route that matches your current question.

• “We need to choose a format.” Read the solution comparison and decision tree.
• “We know we need a tailored experience.” Go to requirements, process and procurement.
• “We need a budget.” Start with cost drivers and total cost of ownership; do not compare proposals on production price alone.
• “We need to prove business value.” Begin with the measurement plan before production starts.
• “We want to appoint a supplier.” Use the RFP checklist and require vendors to distinguish standard capability from project-specific commitments.

First, separate the formats

“Virtual tour” is used for several different products. They can overlap, but they are not interchangeable.

Linked 360° photography

The user moves between panoramic viewpoints and looks in every direction from each point. This approach can deliver excellent visual fidelity and works well for hospitality, culture, tourism, campuses, venues and other spaces where appearance and orientation matter. Its spatial accuracy depends on how it is captured and built; a panorama is not automatically a survey-grade model.

3D scan or spatial digital twin

A scan-based platform records imagery together with spatial data. Depending on the capture hardware, processing and selected outputs, it can support measurement, floor plans, point clouds, BIM or operational workflows. Matterport, for example, describes its product as a digital-twin platform and offers features such as measurement, tags, floor plans and technical-file options on particular plans. Verify the exact outputs, accuracy, export rights and ongoing access required for your use case rather than assuming that all “digital twins” are equivalent. Matterport’s current feature and plan descriptions are the appropriate source for its present capabilities.

CGI or a real-time 3D environment

Computer-generated imagery can visualise a place that does not yet exist, show alternatives or create interactions that physical capture cannot provide. It can be photorealistic or stylised. It is useful for development, simulation and storytelling, but requires a different production pipeline and asset strategy from photographic capture.

360° video

The viewer can look around while a scene unfolds over time. This makes 360° video useful when movement, people, atmosphere or a guided sequence is essential. It is less suitable when the viewer must inspect details at their own pace, compare many options or take multiple branching routes.

Virtual reality and WebXR

VR is a mode of access, not a synonym for every virtual tour. Many tours are used primarily in an ordinary web browser. WebXR provides browser interfaces for compatible VR and AR devices, but support, comfort, privacy and device testing require their own decisions. The W3C WebXR specification remains the technical reference and should be treated according to its current standards status.

Custom immersive web platform

This is an application layer that can combine several of the above. It controls navigation, content structure, search and filtering, interfaces, languages, calls to action, integrations and analytics. Its value is not that it uses more media; its value is that the media and functionality are organised around a useful decision.

What “custom” should actually change

Customisation is not a logo placed on a standard viewer. A genuinely custom tour can change seven things.

1. Purpose. The experience begins with an audience and an outcome, such as choosing an accommodation, qualifying a venue, preparing a site visit or understanding a public story.
2. Information architecture. Scenes, maps, filters and content are organised around user questions rather than around the capture sequence.
3. Experience design. Navigation, controls, mobile behaviour, accessibility and calls to action are designed for the task.
4. Content logic. Different audiences can be guided to relevant spaces, languages, stories or product options without seeing everything.
5. Integration. The tour can connect with a booking engine, CRM, product database, learning environment, ticketing flow or analytics setup when the business case and technical access justify it.
6. Governance. Roles, permissions, translations, publishing, updates, hosting, support and approval flows are defined.
7. Ownership and exit. Contracts specify who owns or may reuse the source images, processed panoramas, design files, code, content and data, and what happens if the relationship or hosting arrangement ends.

The test is simple: if changing the supplier’s logo and colours would produce substantially the same product, you are probably buying a configured template rather than a custom platform. That may still be the right choice—provided the proposal says so clearly.

When a custom virtual tour is worth considering

A custom solution is most defensible when several of these conditions apply:

• People must understand a complex physical environment before deciding, visiting or working there.
• Different audiences need different routes through the same place.
• The experience must express a distinctive brand rather than a platform brand.
• Users need to compare locations, room types, facilities, layouts or scenarios.
• Calls to action must connect naturally to booking, enquiry, product, ticketing or training flows.
• Several properties or sites need a common structure with controlled local variation.
• Content, languages or imagery will need governed updates over several years.
• Accessibility, privacy, security, uptime or data requirements exceed what a simple public viewer can offer.
• The organisation needs event-level analytics and CRM or transaction outcomes, not only aggregate view counts.
• The project combines captured reality with video, 3D, maps, live data or bespoke interaction.

When custom is probably overkill

Choose a simpler option when most of the following are true:

• You need to publish one small, stable location quickly.
• Standard navigation and branding are acceptable.
• A public map listing is the main distribution channel.
• There is no meaningful integration, segmentation or measurement requirement.
• The content will have a short useful life.
• Internal ownership for content, approvals and optimisation does not exist.
• The expected decision value is too low to justify research, design, development and maintenance.

A good supplier should be willing to say this. Over-engineering is not evidence of ambition; it is often evidence that the business question was never made precise.

Solution comparison

No format wins every criterion. The right answer depends on the job, risk and life of the asset.

Option	Best fit	Main strengths	Main constraints to test	Typical control and integration	Relative effort
Custom immersive web platform	Complex choices, distinctive brand, multi-site programmes, integrations or long-term evolution	Tailored journeys, interface, content logic, measurement and system connections	Requires discovery, governance, QA, maintenance and a clear product owner	Potentially high, but only where specified in scope and contract	Higher initial effort; variable ongoing cost
Matterport or comparable scan platform	Fast capture, spatial documentation, measurement, property viewing or standardised roll-outs	Established capture-to-cloud workflow; spatial model and platform features	Platform plan, hosting, export, branding, accessibility and integration limits must be verified	Configurable within current platform and API/plan boundaries	Often faster to deploy; subscription and add-on costs may continue
Google Street View	Map discovery, local presence and public orientation	Familiar distribution inside Google Maps; broad reach	Limited ownership of the surrounding experience, interface and journey; public-context considerations	Low custom control; designed for the Google Maps ecosystem	Usually lower production complexity
Template or DIY tour software	Small sites, simple needs, internal production and rapid publishing	Lower entry barrier, reusable templates and direct authoring	Quality, scale, support, accessibility, analytics and portability vary widely	Low to medium, depending on the product and plan	Low to medium if internal time is available
Conventional video	Emotion, atmosphere, people, movement and a controlled story	Familiar format; strong narrative pacing; easy distribution	Viewer cannot freely inspect or branch through a place; updates may require re-editing	Calls to action and analytics usually sit around the player	Medium; depends heavily on production ambition
Conventional web page, gallery or floor plan	Clear factual explanation, fast comparison or an uncomplicated space	Accessible, searchable, fast and easy to maintain when built well	Limited sense of presence or self-directed spatial exploration	High web and analytics control	Often the lowest effort and should remain part of the experience

Procurement note: features, prices and rights change. Treat product websites as current vendor claims, then make the exact plan, service level, exports, permitted uses and exit provisions contractual. Do not infer legal ownership from the ability to download a file.

Decision tree: do you need custom?

Follow the questions in order.

1. Is understanding a place materially important to a sale, booking, visit, operational decision, learning outcome or public-service goal?
   • No → use a normal web page, photos, a floor plan or video.
   • Yes → continue.
2. Is the primary need spatial documentation or measurement rather than a branded customer journey?
   • Yes → evaluate a scan-based digital-twin platform first.
   • No → continue.
3. Is discovery inside Google Maps the main objective?
   • Yes → evaluate Street View or an approved publishing workflow first.
   • No → continue.
4. Can a fixed template handle the required navigation, branding, languages, content and analytics?
   • Yes → compare template platforms and the internal time needed to operate them.
   • No → continue.
5. Do the expected commercial, operational or public-value outcomes justify discovery, design, development, QA and maintenance?
   • No → simplify the scope or use a lower-cost format.
   • Yes → a custom virtual tour is a credible candidate.
6. Is there an accountable owner for content, systems, measurement and future updates?
   • No → appoint one before procurement.
   • Yes → create a requirements brief and assess vendors.

If several branches remain plausible, commission a short solution-discovery phase rather than asking suppliers to price undefined outputs. A small amount of paid clarity is usually cheaper than competing proposals built on different assumptions.

Define the business problem before the shots

The production brief should begin with a decision, not a list of viewpoints.

Choosing or booking

Users need to understand differences between options and move from exploration to a relevant booking or enquiry. The tour should expose the details that reduce uncertainty, not every detail that happens to have been captured. Useful requirements may include accommodation filters, capacity information, location context, comparison cues, direct links and consistent campaign attribution.

Complex sales and qualification

A sales team may need prospects to understand a venue, factory, showroom, development or infrastructure site before a meeting or visit. The experience can answer repeated questions, qualify interest and create a shared visual reference. Define whether the aim is lead generation, meeting quality, faster qualification, fewer unnecessary visits or stakeholder alignment; each requires different evidence.

Onboarding, training and preparation

A spatial experience can introduce layouts, procedures, zones or equipment. But a tour is not automatically a learning product, a risk assessment or proof that someone is competent. Learning objectives, assessment, version control and access restrictions must be specified separately.

Access and wayfinding

Visitors may want to know what the route, entrance, parking, room or facility will be like. In this context, accurate practical content, accessible alternatives and reliable updates matter more than spectacle.

Culture, heritage and public interpretation

A tour can connect a place with archive material, expert stories, objects, audio and multilingual interpretation. Rights, provenance, captions, transcripts and an editorial model should be part of the product design from the start.

Requirements that belong in an enterprise brief

Audience and journeys

Name the priority audiences and the decision each must complete. Do not use “everyone” as a target audience. List the starting points, expected routes, required content and successful exits for each audience. Decide whether the tour should encourage free exploration, guided navigation or both.

Content and editorial governance

Specify content types, languages, approval roles, version history, publishing rights, review intervals and expiry rules. Distinguish updates that editors can make in a CMS from changes requiring design, development or new photography.

Image and capture quality

Request a capture plan, not a camera-brand promise. It should cover viewpoint logic, light and weather dependencies, staging, permissions, people and personal data, drone or restricted-area requirements, image processing, retouching boundaries, colour review, nadir/zenith treatment and reshoot conditions. Ask for deliverable resolution and viewing performance rather than relying on one headline pixel number.

Responsive performance

The experience should remain useful on real mobile networks and devices. Require progressive loading, appropriately sized image tiles, fallbacks and performance testing. Google’s current “good” Core Web Vitals guidance is LCP within 2.5 seconds, INP below 200 milliseconds and CLS below 0.1; measure field performance at the 75th percentile rather than relying only on a fast office connection. See Google Search Central’s Core Web Vitals guidance.

These thresholds are a useful web baseline, not proof that an immersive application is effective. Also test time to a useful first scene, failed asset requests, memory use, heat and battery impact, recovery from a poor connection and the speed of the next meaningful action.

Accessibility

Accessibility cannot be added by writing alt text for a launch image. The entire task must be perceivable, operable, understandable and robust. Use WCAG 2.2 as the reference and set the required conformance level—commonly AA—contractually, subject to applicable law and organisational policy.

For an immersive tour, acceptance criteria should include:

• complete keyboard operation with visible, logical focus and no keyboard trap;
• labelled controls with programmatically available names, roles and values;
• sufficient contrast and controls that do not depend on colour alone;
• a way to pause, stop or reduce motion and auto-rotation;
• captions and transcripts for time-based media, with audio description or equivalent where required;
• text alternatives and a non-immersive route to the same essential information and call to action;
• touch targets, zoom, reflow and orientation behaviour tested on mobile;
• error messages and forms that can be understood and corrected;
• testing with assistive technology and people, not only automated scanners.

Do not claim “WCAG compliant” because the surrounding website passed an automated test. Define scope, test complete user flows and keep a record of known limitations and remediation.

Privacy and data protection

Treat privacy as both a capture issue and a usage-data issue.

During capture, identify faces, number plates, screens, documents, access controls, personal belongings and restricted areas. Agree what must be removed, blurred, staged or excluded, who approves the result and how source material is secured.

During use, document every analytics, personalisation, CRM, form, embedded-media and third-party service. Under the GDPR principles, personal data should be adequate, relevant and limited to what is necessary; retention periods should be defined; and protection should be designed in from the start. See the European Commission’s explanation of GDPR principles. Obtain legal or data-protection review for the actual deployment; a buyer’s guide is not legal advice.

Never place names, email addresses, free-text form content or other personal data in analytics event parameters. Define consent behaviour, controller/processor roles, sub-processors, hosting regions, retention, deletion, access requests and breach responsibilities before launch.

Security

A public tour and a restricted operational environment are different risk classes. Specify authentication, authorisation, role management, audit logs, dependency management, patching, vulnerability handling, backup, recovery, encryption, secrets management, penetration testing and incident response in proportion to the risk.

For web-application procurement, the OWASP Application Security Verification Standard provides a structured basis for technical security requirements and testing. It does not replace a threat model or sector-specific obligations.

Hosting, availability and support

Ask where application and media assets are hosted, how content is delivered across target markets, how traffic spikes are handled and which third parties are critical. Define uptime measurement, planned maintenance, support hours, severity levels, response targets, recovery objectives, backups, monitoring, security notifications and service credits if relevant.

An “uptime guarantee” without a measurement point, exclusions and remedy is marketing copy, not a service level.

CMS and permissions

List exactly which fields local and central teams can edit. Define roles, approval, preview, publishing, rollback, audit history, translation workflow and training. A CMS does not solve governance; it exposes whether governance exists.

Languages and localisation

Translation covers words. Localisation also covers terminology, units, imagery, offers, routes, cultural expectations and legal information. Decide which content is global, which is local, who approves each language and what happens when a source-language item changes.

Integrations

For each connection, document the system owner, use case, API or link method, authentication, data direction, source of truth, error state, latency, test environment and support responsibility. A reliable deep link with campaign parameters may create more value than a brittle real-time integration. Choose the simplest architecture that meets the decision need.

Ownership, licences, portability and end of life

Separate these assets in the contract:

• raw source photographs and video;
• stitched and edited panoramas;
• conventional images and derivatives;
• 3D models, meshes, point clouds and floor plans;
• design files and component systems;
• application source code and third-party libraries;
• written, audio and translated content;
• domains, URLs, analytics properties and tag-manager containers;
• CMS data and user accounts;
• usage data, reports and consent records.

For each, state ownership, licence scope, permitted reuse, access method, export format, retention, deletion and transfer on termination. If custom code is not transferred, specify the continued-use licence and exit path. If third-party components cannot be transferred, make that dependency visible before signing.

A realistic delivery process

1. Discovery and success definition

Interview business, user, content, IT, privacy, security and operational stakeholders. Agree the priority audience, decision, baseline and measurable outcome. Record non-goals so the tour does not become a container for every idea.

2. Requirements and solution choice

Compare custom, platform and simpler options. Define functional, content, accessibility, performance, integration, governance and service requirements. Resolve rights and capture constraints early.

3. Information architecture and prototype

Map the place around user decisions. Prototype menus, maps, filters, content points and calls to action before committing to full production. Test the concept with representative users, including mobile and accessibility scenarios.

4. Capture planning and production

Create a shot list and location schedule; manage light, weather, access, staging, safety and permissions. Capture only what the product needs. Document conditions that could require a reshoot.

5. Post-production and content

Stitch, edit and review the imagery. Write and structure information for the interface, not as a brochure pasted into hotspots. Prepare translations, captions, transcripts and alternative content.

6. Design and development

Build the responsive interface, CMS behaviour, integrations and analytics. Reuse tested components where that improves reliability; “custom” does not mean rebuilding commodity infrastructure without reason.

7. Quality assurance

Test content, links, devices, browsers, loading, keyboard use, assistive technology, contrast, motion, privacy, security and analytics. Test failed integrations and missing assets, not only the ideal journey.

8. Launch and validation

Release with monitoring and a rollback plan. Verify analytics in real time and debug tools, indexable supporting content where relevant, consent states, cross-domain journeys and final calls to action.

9. Optimisation and maintenance

Review search behaviour, content use, drop-off, exits, conversion and feedback. Update the experience when spaces, offers or systems change. Agree who owns the quarterly review and what triggers a reshoot or redevelopment.

What determines cost?

There is no responsible universal price for a custom virtual tour. Two projects with the same number of panoramas can require very different research, travel, access, retouching, interfaces, integrations and support.

Ask suppliers to separate these cost drivers:

• discovery, research and user testing;
• number, size, complexity and geographic spread of locations;
• capture methods, crew, access, staging, weather and travel;
• number of viewpoints and post-production complexity;
• 360° video, conventional video, audio, animation, CGI or 3D;
• information architecture, UX/UI and visual identity;
• custom development and reusable platform components;
• CMS roles and editorial workflow;
• booking, CRM, product, identity or analytics integrations;
• languages, translation and localisation;
• accessibility work and independent testing;
• privacy, security, procurement and legal requirements;
• hosting, traffic, storage, licences and service levels;
• support, training and reporting;
• future content changes, renovations and recapture;
• migration, export and decommissioning.

Compare total cost of ownership, not only launch price

Calculate over a period that matches the expected life of the experience—often three to five years for procurement comparison, but shorter or longer where the environment demands it.

Total cost of ownership = initial discovery and production + implementation and integration + licences and hosting + support and governance + localisation and updates + recapture and redevelopment + exit or migration costs.

A lower initial quote can become more expensive if every text change requires the supplier, source assets cannot be reused, hosting scales unpredictably or the product cannot move. A higher initial quote can still be wasteful if no one owns the content or the project has no credible route to value.

Request assumptions and exclusions beside every price. A comparable proposal states what the supplier will deliver, what the buyer must provide and what changes the price.

How to measure value without inventing ROI

Measurement design starts before launch. If tracking is added after production, the team will know that people visited but may not know whether the tour changed a decision.

Step 1: write the causal question

Examples:

• Does using the tour increase the proportion of qualified visitors who start a booking?
• Does it improve the quality or conversion rate of meeting-space enquiries?
• Does pre-visit exploration reduce repetitive questions or avoid unnecessary site visits?
• Does a guided onboarding route improve knowledge or task completion?

One project can have several benefits, but each needs its own baseline, population and evidence.

Step 2: define the metric hierarchy

Level	What it answers	Example measures
Business outcome	Did the organisation gain value?	Confirmed bookings, qualified opportunities, completed applications, avoided visits, completion or assessed learning
Decision action	Did the user take the intended next step?	begin_checkout, generate_lead, meeting enquiry, route completion, document request
Product behaviour	How was the tour used?	tour start, meaningful scene views, filter use, map use, information-panel opens, comparison actions, CTA clicks
Experience health	Did the product work?	load failures, time to first useful scene, API errors, device/browser issues, Core Web Vitals

Engagement is diagnostic. It is not automatically value. Longer time can mean interest, confusion or slow loading; more scenes can mean discovery or failure to find an answer.

Step 3: implement an event model

Google Analytics 4 distinguishes automatically collected, enhanced-measurement, recommended and custom events. Google advises using recommended events when they match, and custom events when no existing event fits. Important actions can be marked as key events. See Google Analytics’ event guidance and recommended events.

Suggested event design:

Event	Trigger	Essential non-personal parameters	Role
tour_start	User deliberately opens or starts the experience	tour_id, entry_context, language, device_class	Product diagnostic
scene_view	A scene becomes meaningfully visible, with repeat rules defined	tour_id, scene_id, scene_category, position_index	Product diagnostic
content_open	User opens a substantial information panel	tour_id, content_id, content_type, scene_id	Product diagnostic
filter_apply	User applies a decision-relevant filter	tour_id, filter_type, result_count_band	Decision diagnostic
map_use	User uses the map to navigate	tour_id, map_action	UX diagnostic
select_item	User selects an accommodation, venue or product represented in the tour	GA4-recommended name where ecommerce semantics fit; use documented item parameters	Decision action
cta_click	User follows a defined next-step link	tour_id, cta_type, destination_type, scene_id	Decision action
begin_checkout	A booking or commerce flow begins	GA4-recommended event and relevant commerce parameters	Business funnel
generate_lead	A valid lead action completes	GA4-recommended event; do not send personal form data	Business outcome
tour_error	A material application, media or integration error occurs	tour_id, error_type, component, recoverable	Experience health

Use stable IDs rather than scene titles that change with translation. Publish an event dictionary defining trigger, parameters, deduplication, consent behaviour, owner and QA test for every event.

Step 4: preserve attribution across domains

If the tour, marketing site and booking or lead flow use different domains, configure and validate cross-domain measurement where technically and legally appropriate. Google provides a specific GA4 cross-domain measurement guide. Preserve campaign parameters, prevent self-referrals and test the full journey after consent choices.

Do not mix unrelated public-tour traffic with the supplier’s marketing-site lead measurement. At minimum, separate reporting by hostname, organisation, tour ID and purpose; for materially different data owners or use cases, use an appropriately separated property or data architecture. Access controls, contracts and controller responsibilities should drive the design—not reporting convenience.

Step 5: choose an evaluation design

From strongest to weakest causal evidence:

1. Randomised experiment: eligible users are assigned to an experience with or without the tour, with a pre-defined primary outcome and sample plan.
2. Phased or holdout roll-out: comparable locations, audiences or periods provide a control while deployment expands.
3. Matched comparison: compare similar users or sites and adjust for known differences.
4. Interrupted time series: examine a sufficiently long pre/post trend and account for seasonality and other changes.
5. Simple before/after: useful as an early signal, but highly vulnerable to campaigns, demand, pricing, availability and market changes.

Do not call an uplift causal unless the design supports it. Record launches, media campaigns, pricing changes, inventory, renovations and tracking changes alongside the data.

Step 6: connect behaviour to qualified outcomes

Where consent, systems and governance permit, pass a non-personal interaction or session reference into the downstream booking or CRM process, then return outcome stages in a privacy-safe way. Compare tour users and non-users on qualification, proposal, booking or completion—not just clicks.

Step 7: calculate ROI transparently

Use buyer-owned inputs and ranges.

Incremental gross benefit = incremental completed outcomes × contribution per outcome + validated operating savings.

ROI = (incremental gross benefit − total cost of ownership) ÷ total cost of ownership.

Payback period = total cost of ownership ÷ average incremental gross benefit per period.

Show low, expected and high cases. Exclude benefits that cannot be measured or defend them separately as strategic value. Do not multiply an engagement percentage by revenue and call the result incremental income.

Vendor evaluation and RFP checklist

Use this checklist to make proposals comparable. Require the supplier to answer “included”, “optional”, “not available” or “buyer responsibility”, with assumptions and evidence.

Business fit

• Priority audiences, decisions and non-goals are stated.
• The supplier explains why custom is appropriate and which simpler option was rejected.
• Success measures and baseline requirements are defined before production.
• The proposal distinguishes reusable platform capability from new project-specific work.

Relevant experience and evidence

• Examples resemble the decision, scale or constraints of this project—not only the sector label.
• Live examples are available on target devices.
• Performance claims include metric definition, period, sample, comparison method and limitations.
• Client references or permissions are genuine and current.
• No supplier superlative is accepted without independent proof.

User experience and content

• Information architecture and prototype testing are included.
• Mobile, keyboard, touch and low-bandwidth behaviour are specified.
• Maps, filters, content points and calls to action have defined purposes.
• The CMS fields, roles, workflow, preview, rollback and training are listed.
• Language and localisation responsibilities are explicit.

Capture and media

• Locations, viewpoints, methods and deliverable resolutions are defined.
• Site access, safety, weather, staging, people and privacy are planned.
• Post-production, retouching, review rounds and acceptance criteria are stated.
• Rights and permitted reuse are defined for every source and derivative asset.
• Reshoot triggers and rates are clear.

Accessibility

• Required WCAG version, conformance level and scope are contractual.
• Essential tasks work by keyboard and assistive technology.
• Reduced-motion, captions, transcripts and equivalent non-immersive content are included.
• Manual and user testing supplement automated checks.
• Defects, exceptions, remediation and evidence are documented.

Technical architecture and performance

• Supported browsers, devices and minimum network assumptions are stated.
• Progressive loading, caching, image tiling and fallbacks are described.
• Performance budgets and field-monitoring responsibilities are defined.
• APIs, environments, authentication, errors and integration ownership are mapped.
• Monitoring, backups, recovery and deployment/rollback are documented.

Privacy and security

• Data flow, purpose, lawful basis/consent needs and retention are reviewed.
• Controller, processor and sub-processor roles are specified.
• Personal data is excluded from analytics parameters.
• Authentication, authorisation, logging, encryption and patching match the risk.
• Vulnerability disclosure, incident notification and testing are included.

Hosting, service and scale

• Hosting locations, critical providers and data-transfer implications are disclosed.
• Traffic, storage and bandwidth assumptions are visible.
• Uptime method, exclusions, support hours, severity and response targets are defined.
• Multi-site responsibilities, local variation and bulk updates are supported where needed.
• Price changes at scale can be modelled.

Analytics and optimisation

• Event dictionary and data layer are deliverables.
• Recommended analytics events are used where suitable; custom events are documented.
• Consent and cross-domain journeys are tested.
• Buyer access and data ownership are explicit.
• Reporting separates engagement, decision actions, business outcomes and errors.
• An experiment or comparison design is agreed where ROI claims matter.

Commercial, ownership and exit

• Initial and recurring costs are separated.
• Assumptions, exclusions, change process and payment milestones are clear.
• Ownership and licences are stated asset by asset.
• Source, exports, documentation and account transfer are defined.
• Termination, data return/deletion, continued operation and migration assistance are priced.
• Third-party features that cannot be transferred are identified.

Common failure modes

Starting with “How many panoramas?”

This turns a decision product into a photography inventory. Start with user questions, then determine the scenes required to answer them.

Treating more engagement as proof of more value

An immersive format may attract attention, but attention can be positive, neutral or frustrating. Connect behaviour to a decision and an outcome.

Designing desktop spectacle and shrinking it for mobile

Mobile is often the dominant access context. Design navigation, copy, touch, loading and calls to action for a small screen from the beginning.

Hiding essential information inside the experience

Provide crawlable and accessible text outside or alongside the immersive layer. A user should not have to rotate a panorama to discover opening hours, accessibility information or the next step.

Confusing visual accuracy with measurement accuracy

High-resolution imagery can look precise without providing calibrated spatial measurement. State which outputs are visual, indicative, measured or survey-grade.

Ignoring the operating model

A tour becomes stale when no one owns updates, language changes, broken links, renovated spaces and reporting. Governance is part of the product.

Leaving ownership until contract negotiation

Portability affects architecture and price. Define it in the brief, not after the supplier has been selected.

Adding VR because it sounds innovative

VR can be valuable for a defined audience and environment. It also adds device, input, comfort, privacy and testing requirements. Make it a justified mode, not a ceremonial feature.

Questions to ask during supplier interviews

1. What would make you recommend that we do not build a custom tour?
2. Which part of your proposal is standard product, configuration and bespoke development?
3. Show how your information architecture follows our users’ decisions.
4. Demonstrate the same live project on a mid-range phone and a constrained connection.
5. How do keyboard and screen-reader users complete the essential journey?
6. Which analytics events and business outcomes will you implement and validate?
7. What changes can our team make without you?
8. What will still work if an API, media asset or third-party service fails?
9. What exactly do we own, license, export and lose at termination?
10. Which project risk do you think we are underestimating?

Frequently asked questions

How is a custom virtual tour different from Matterport?

Matterport is a specific digital-twin platform with a defined capture, cloud and feature ecosystem. A custom virtual tour is a project and product approach: its interface, journeys, content, integrations and governance can be designed around the buyer. Matterport may be the better choice when rapid spatial capture, measurement or standardised documentation is central. Custom may be better when brand, complex decisions, integrations or long-term product control dominate. A project can also use scan-derived assets inside a broader custom experience; the rights and technical path must be verified.

Is a custom tour better than Google Street View?

Not universally. Street View is strong when discovery and orientation inside Google Maps are the main objectives. A custom tour offers more control over the surrounding interface, story, calls to action, integrations and analytics. Many organisations can use both for different jobs.

How much does a custom virtual tour cost?

Cost depends on discovery, number and spread of locations, capture and post-production, UX/UI, development, integrations, languages, accessibility, hosting, support and updates. Ask for a transparent scope and three-to-five-year total cost of ownership instead of comparing one launch figure.

How long does production take?

The schedule depends on access, weather, stakeholder approvals, capture scope, content readiness, integrations, languages and testing. A supplier should provide a dependency-based plan with approval windows and reshoot conditions. A precise duration quoted before these inputs are known is an assumption, not a commitment.

Can our team update the tour?

It can if the CMS and governance are designed for that purpose. Specify editable fields, roles, approvals, previews, rollback and training. New or renovated spaces will normally require new capture and image processing even when text changes are self-service.

Can a virtual tour connect to our booking engine or CRM?

Often, yes—but “integration” can mean anything from a stable link with campaign parameters to real-time API exchange. Define the business need, system owner, available API, authentication, data flow, errors and support responsibility before choosing the architecture.

Can it be measured in Google Analytics?

Yes. Implement recommended GA4 events where their semantics fit and documented custom events for tour-specific behaviour. Validate cross-domain measurement, consent behaviour and downstream outcomes. Do not confuse scene views with commercial impact.

Is a virtual tour accessible?

It can be designed to be substantially more accessible, but immersive interaction creates real challenges. Set a WCAG 2.2 target, test essential flows with keyboard and assistive technology, support reduced motion and media alternatives, and provide equivalent text or conventional navigation for essential information and actions.

Do we own the photography, data and code?

Only the contract can answer that. Ownership, licence, reuse, download access, export formats, hosting and termination rights may differ by asset and supplier. List each asset separately and agree the exit path before production.

Will a custom virtual tour improve conversion?

It may, if it resolves meaningful uncertainty and connects users to an appropriate next step. It can also fail to create value. Establish a baseline and use an experiment, holdout, phased rollout or careful comparison. Do not treat a vendor case result as a guaranteed forecast for a different organisation.

Should we create a pilot first?

A pilot is useful when it tests a real uncertainty: audience adoption, content model, technical integration, operating ownership or measurable impact. It is wasteful when it is merely a smaller production with no success threshold or scale decision. Define in advance what the pilot must prove and what happens next.

How often will it need updating?

That depends on how often the place, offers and supporting systems change. Separate frequent editorial updates from periodic imagery replacement and occasional platform redevelopment. Assign owners and review dates at launch.

The decision in one page

A custom virtual tour is a strong candidate when a physical environment materially affects a high-value decision, standard products cannot support the required journey, and the organisation can own measurement and maintenance. It is a weak candidate when the need is simply to show a small stable space, the expected value is low or no one will operate the result.

Before buying, settle five questions:

1. Which audience decision must the experience improve?
2. Why is custom better than a scan platform, Street View, template, video or conventional page?
3. Which requirements are contractually essential—especially accessibility, privacy, security, analytics, ownership and exit?
4. What is the full cost over the useful life of the asset?
5. Which evidence would persuade you that the project worked?

If those answers are clear, suppliers can propose comparable solutions. If they are not, buy discovery before buying production.

A proportionate next step

If your requirements point to a tailored platform, Poppr can help turn the business question into an experience, production and measurement brief. Explore Poppr’s custom virtual-tour approach or use the checklist above to brief any qualified supplier.

---