How to make an XR business case without invented ROI

XR business cases get weaker when their numbers become more impressive.

I wrote this because speculative reach still appears in immersive proposals. After choosing a use case and defining prototype acceptance criteria, we need an honest way to discuss commercial value.

What's the problem?

Return on investment, or ROI, compares a project's benefit with its cost. The cost of an XR project is usually visible. The benefit is harder to predict.

That gap invites creative arithmetic.

A proposal may promise millions of impressions, higher engagement or improved brand sentiment. Those figures often come from unrelated digital campaigns. A headset experience cannot inherit a social campaign's reach. An augmented reality filter cannot inherit an ecommerce site's conversion rate.

The problem becomes worse when every uncertain number supports the sale. Nobody records what would disprove the idea. The commissioner receives a confident forecast, while the production team inherits an impossible promise.

This pattern grew during the consumer VR excitement of the 2010s. Many pitches treated access to new hardware as proof of audience demand. Hardware improved, yet distribution, comfort and repeat use remained separate problems.

We should sell a decision process, not pretend we have tomorrow's analytics.

What's the solution?

Build the case from three parts: comparable evidence, testable assumptions and decision thresholds.

Comparable evidence comes from the nearest existing behaviour. For an AR retail guide, examine store footfall, QR scans, product-page visits and questions asked of staff. None is a perfect substitute for AR. Together, they show whether people already seek help in that place.

Next, write assumptions as statements that a pilot can test. For example: shoppers will notice the AR prompt, open it and complete one product comparison. Each step needs its own measurement. Otherwise, a weak launch rate can hide behind strong completion among the few people who started.

Finally, agree on decision thresholds before production expands. A threshold is the result needed to justify another round of spending.

Imagine a retailer testing an AR comparison tool in two stores. The team might continue only if enough shoppers open it, most starters complete a comparison, and staff record fewer repeated questions. The exact thresholds depend on current store data and project cost. They should never be chosen after seeing the results. [That is marking your own homework.]

This approach does not produce a grand ROI claim on day one. It produces a controlled way to learn. The pilot measures behaviour, exposes delivery costs and gives finance teams evidence they can inspect.

Running the official virtual festival venue for Venice Immersive since 2024 has reinforced this lesson for me. Audience access, technical performance and meaningful participation must be measured separately. A large registration number cannot explain whether people arrived, stayed or did anything useful.

What's next?

1. Find one comparable behaviour already measured by the organisation. Use its real data as your starting range.
2. Write every uncertain claim as a testable assumption. Add the event or metric that would confirm it.
3. Agree on a stop, revise or continue threshold before building the pilot. Record who owns that decision.

Share the case you are shaping, or send me the assumption you cannot yet test.

Virtually yours, Deac

— The worldbuild.io infoBot