A VR training simulator RFP is the document you send to suppliers to get comparable offers for a custom VR training app. A good one describes what the trainee must be able to do after the training, where and on what hardware it will run, which results it must record, who owns the result and how it will be maintained. It says little about technology and a lot about the job being trained.
Most weak RFPs fail the other way round. They list a headset model, a game engine and "realistic graphics", then leave the scenario to the supplier's imagination. Below is what to put in instead, section by section, written from the side of a team that answers these requests.
Start with the outcome, not the headset
The core of the RFP is a description of the task: what the trainee does, in what order, which mistakes the scenario must provoke and how a pass is decided. Suppliers can price a task. They cannot price "an immersive experience", so they guess, and you get bids you cannot compare.
Write it the way you would brief a new instructor:
- the procedure step by step, with the steps that people get wrong today;
- the mistakes the simulation must allow, and what should happen when someone makes them;
- what counts as passing (all critical steps correct, a time limit, a score threshold);
- the documents, photos, drawings or CAD files you can share so the virtual site matches the real one.
If the procedure is the same in every company (using a fire extinguisher, CPR, basic hazard spotting), stop here and check the VR course catalog first. Commissioning a scenario that already exists is the most expensive way to get it. Our post on custom VR training development or a ready-made course helps with that call.
Describe requirements, not brands
An RFP should state what the hardware must do (standalone or PC-based, hand tracking or controllers, offline use) and leave room for equivalent products. That keeps competition open and protects you when a product line changes.
For public buyers in the EU this is the law. Article 42 of Directive 2014/24/EU (European Parliament and Council, 2014) says technical specifications must give suppliers equal access and may refer to a specific make or trade mark only as an exception, "accompanied by the words 'or equivalent'". Private companies are not bound by it, but the logic holds.
The market gave a practical reason in 2026. Meta stopped selling commercial Quest SKUs and Horizon managed services on 20 February 2026, while existing customers keep support until 4 January 2030 (Meta, 2026). An RFP written around one vendor's enterprise bundle had to be rewritten. Asking for an app built on OpenXR, the royalty-free open standard for XR apps (Khronos Group), is one way to keep your options open across devices. More on the hardware side in enterprise VR headsets after Meta's exit and standalone vs tethered VR headsets for training.
Say where it will run
Training rarely happens in a quiet office. State the real conditions: a canteen with no Wi-Fi, a training room shared by three shifts, a site where trainees stand or sit, the number of headsets running at once.
These details change the price. Offline operation, kiosk mode that locks the headset to the training, and remote installation on a fleet all need to be built or provided by a platform. If you already own headsets, list the models so the supplier builds for them.
Specify the data, not just the app
The simulator should record more than "started" and "finished". Ask for per-step results, number of attempts, time on task and the mistakes made, stored per employee. Then say where that data must end up: a report you download, your LMS, an HR system or a certificate.
This is the part that turns a demo into evidence for an audit, and the part most RFPs forget. Be specific about the format you need (CSV or XLSX export, an API your systems can read) and who will own the data. If you have no system to receive it, the supplier's management layer matters as much as the scenario. Our checklist on how to choose a VR LMS lists what to compare, and the VR LMS page shows what ours records.
Ownership, licence and support after launch
Decide before you write: do you need the app exclusively, with source code handed over, or is a licence enough? Article 42 of the same directive allows a public buyer to state whether intellectual property rights must be transferred, so this is a legitimate line in any RFP.
Full ownership costs the most. A licence where the supplier shares the production cost, and may also offer the app to others, costs less. Extending an existing app is cheaper still. Ask bidders to price the model you want, and ask what happens after launch: who fixes bugs, who ports the app to the next headset generation, and how a changed procedure gets into the scenario.
Accessibility and languages
If staff will use the app, plan for people who cannot stand for long, wear glasses, or do not read the training language well. The directive asks public buyers to take accessibility criteria into account for anything used by natural persons, staff included, except in duly justified cases.
List the languages you need now and the ones you expect within two years. Voice-over, on-screen text and the results panel all count.
How to compare the bids
Price alone is a poor criterion for a training app. Score the bids on how well the proposed scenario matches your task, the supplier's process (workshop, script approval before 3D work, testing with real users), the data and support terms, and only then the cost.
Ask every bidder for a recording from an app they actually built, not concept renders. Ask for a realistic timeline too. At EHS VR a single, well-defined scenario usually takes around 8 to 16 weeks from the first workshop to a working app on your headsets (EHS VR, custom VR and AR app development). A bid that promises a complex simulator in three weeks is either reusing an existing app (fine, if they say so) or underestimating the work.
Budget follows volume. PwC found that VR training reached cost parity with classroom training at around 375 learners in its model (PwC, 2020). Put your own headcount and refresher cycle into the VR training ROI calculator before you fix a budget line.
A one-page checklist
- 1The task: steps, critical mistakes, pass criteria, source documents.
- 2Ready-made check: does a catalogue course already cover it?
- 3Hardware: requirements plus "or equivalent", models you own, offline needs.
- 4Data: what is recorded, export format, target system, data owner.
- 5Ownership: exclusive app with code, or licence with updates.
- 6Support: bug fixes, new headset generations, procedure changes.
- 7Accessibility and languages.
- 8Evaluation criteria and their weights, stated in the RFP.
If you want a second opinion on a draft, send it to us. Our team in Poland handles custom VR and AR app development end to end, from the first workshop to the panel that records the results, and we will tell you honestly if a catalogue course would do the job.
