Seven reasons enterprise XR safety rollouts stall after the pilot, and what to fix before you buy a single headset.
The demo always goes well. That is the problem.
The site director puts on the headset. She walks a scaffold at height, misses a tie-off, and the world tells her about it in a way no toolbox talk ever has. She takes the headset off grinning. Everyone in the room agrees this is the future of safety training. The pilot gets approved that week.
Six months later the headsets are in a cupboard in the site office, and nobody can remember the login for the dashboard.
We build VR safety training for construction and infrastructure teams. [FILL: your real number, e.g. “Across 100+ game and XR builds” or “Across N enterprise deployments”] we have seen pilots turn into programmes that train several hundred workers a year, and we have seen pilots that never left the room they were demoed in.
The difference almost never came down to the quality of the VR. It came down to seven things that happen outside the headset.
1. IT said no, and nobody asked IT until week six
This is the number one killer, and it is boring, which is why it keeps happening.
Standalone headsets are unmanaged devices asking to join a corporate network. Your IT and security team has a policy about that. They will want mobile device management, a plan for enrolment, a position on the vendor account, an answer on where the data sits, and often a security review of the app itself. None of that is unreasonable. All of it takes weeks.
If the first time IT hears about the project is when 30 devices arrive at reception, you have just added six to twelve weeks to your timeline, and you have spent it on the part of the budget that was supposed to be showing results.
What it costs: the pilot window closes before a single worker is trained. Momentum dies. The budget holder starts asking what happened.
The fix: bring IT into the room in week one, not week six. Ask your vendor which MDM platforms they have actually deployed under, whether the build runs in kiosk mode, and what network access the app needs at runtime. If a vendor cannot answer that in one sentence, they have not done a real enterprise rollout.
2. It did not talk to your LMS, so it did not count
A worker completes a 20 minute VR module on confined space entry. They perform well. That result lives inside the VR vendor’s dashboard.
Your training record, the one the auditor asks for, the one that proves competency, lives in your LMS. If those two systems never speak, then as far as your organisation is concerned, the training did not happen. Someone in EHS is now manually re-keying completions into a spreadsheet, which lasts about three weeks before it quietly stops.
What it costs: VR becomes an extra task on top of the compliance training, instead of a replacement for part of it. Nobody adopts a tool that adds work.
The fix: decide on day one whether completions need to reach your LMS, and if they do, make SCORM or xAPI integration part of the scope and the acceptance criteria. Not a phase two. Phase two rarely gets funded.
3. You measured excitement instead of competency
Most pilots are evaluated on the wrong thing. Did people enjoy it. Did it feel realistic. Would they recommend it. These are satisfaction scores, and satisfaction scores are always high for VR, because putting on a headset at work is genuinely fun.
Then the finance conversation arrives, and enthusiasm is not a number anyone can defend. The question is not whether workers liked it. It is whether it made them safer, faster, or cheaper to train than what you were doing before.
What it costs: you cannot build a business case for rollout, so the pilot stays a pilot forever.
The fix: pick your comparison and your metric before you start. Time to competency against the classroom baseline. Error rate on the critical steps, first attempt versus third. Assessor hours saved. Number of workers who can be trained on a high risk procedure without shutting down a live area. Instrument the build to capture it, then measure the same thing on a control group doing it the old way. That is the slide that unlocks the second budget.
4. You had a champion, not an owner
Almost every pilot starts with one enthusiastic person. A safety manager who saw XR at a conference, or an L&D lead who wants to modernise. They push it through. It works because of their energy.
Then they get promoted, move site, or move company. The project had a champion but no owner, no line in anyone’s budget, and no place in the annual training calendar. It stops within a quarter.
What it costs: the entire investment, plus the internal credibility of the next person who proposes XR.
The fix: before the pilot ends, get three things written down. Who owns this next year. Which budget line it sits in. Which mandatory training it replaces or supplements in the calendar. If you cannot answer all three, you do not have a programme, you have an experiment.
5. Nobody owned the headsets on Monday morning
Twelve headsets across four sites sounds trivial until you run it. Who charges them. Who cleans the facial interfaces between shifts. Who updates the build. Who notices that four of them have not been switched on in a month. Who replaces the one that got dropped off a mezzanine.
At pilot scale, one motivated person absorbs all of this invisibly. At rollout scale, that person burns out or leaves, and the whole thing degrades quietly until a headset with a dead battery becomes the reason a session gets cancelled.
What it costs: slow decay rather than sudden failure, which is worse, because nobody can point at the moment it died.
The fix: treat headsets like PPE, not like laptops. Name the owner per site. Build the charge and clean routine into an existing shift handover, not a new process. Budget for a hardware refresh and a spare ratio from the start. And ask your vendor whether content updates push over the air or need a person with a cable.
6. The content froze the day it shipped
Your procedures change. A method statement gets revised, a new regulation lands, an incident triggers a control change, a client mandates a different permit flow.
If your VR module was built as a one off bespoke piece of software, every one of those changes is a change request, a quote, and a wait. Within eighteen months the VR is teaching a procedure you no longer follow, which is worse than no VR at all, because now it is a liability.
What it costs: the module goes stale, and stale safety content is a risk, not an asset.
The fix: ask how the module is built before you ask what it costs. Content that lives in configurable data, on a reusable training framework, can be updated in days. Content hard coded into a bespoke build cannot. Ask specifically: if a step in this procedure changes next year, what does it take to update, and can our team do any of it ourselves. The answer tells you what you are really buying.
7. It was built to impress a room, not to run a rollout
Pilot builds are often designed to win the internal sell. Maximum visual polish, one perfect scenario, one language, one site, one headset model, and a facilitator standing next to the user the whole time.
None of that survives contact with 400 workers across six sites in three languages, half of whom have never held a controller. The scenario that dazzled the steering committee turns out to be twenty minutes long, which does not fit the shift pattern. There is no onboarding for first time users, so the first two minutes of every session are spent teaching someone how to point.
What it costs: you have to rebuild for rollout, so the pilot spend becomes sunk cost rather than phase one.
The fix: scope the pilot as the first slice of the real thing. Insist on a built in tutorial for first time users. Ask for module length that fits an actual shift or induction slot. Confirm multi language and multi site support are in the architecture even if you only enable one at first. Make the pilot a small rollout, not a showcase.
The pattern
Look at all seven and the shape is obvious. Every one of them is an operations problem, a data problem, or a procurement problem. Not one of them is a graphics problem.
The XR industry has spent a decade getting very good at the twenty minutes inside the headset, and much less good at the eighteen months around it. If you are buying VR safety training, most of your diligence should go on the eighteen months.
Take this into your next vendor meeting
Ten questions. The answers will separate the vendors who have run a rollout from the vendors who have run a demo.
- Which MDM platforms have you deployed under, and can you name a deployment?
- Does the build support SCORM or xAPI, and is LMS integration in scope or an extra?
- What data does the module capture per user, and can we export it?
- Can we see the assessment logic, and can we change the pass criteria ourselves?
- If our procedure changes next year, what does an update cost and how long does it take?
- Can our team edit any of the content, or does every change come back to you?
- Do content updates push over the air?
- Is there a first time user tutorial in the build?
- What is the plan for multi language and multi site, and what does enabling it cost?
- What does the pilot need to prove, in numbers, for you to consider it a success?
If a vendor gets uncomfortable around questions five, six, and seven, you have learned the most important thing in the meeting.
Where we land on this
We build on a reusable training framework rather than starting from zero each time, precisely because of point six. It means a module can be updated as procedures change instead of aging out, and it means the second module costs less than the first. It also means we talk about MDM, LMS, and update paths in the first call, which is a less exciting first call than a demo, and a much better second year.
If you are scoping a VR safety training programme and you want a blunt conversation about whether it will survive its own pilot, we are happy to have that conversation whether or not you build it with us.
Get in touch at Contact
