.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
How Should You Price Your Recurring VR and AR Experience Services
A recurring VR or AR experience is not a headset sale with a support contract attached. It is an operating service. The customer expects the experience to remain available, secure, current, measurable, and useful after launch. That obligation can include device administration, content releases, learner or worker support, analytics, integrations, and periodic redesign.
The pricing stakes are rising because the underlying stack now has several meters. Meta Horizon managed services became free on February 20, 2026, while XR device-management vendors such as ArborXR and ManageXR continue to charge by managed device. Training platforms can charge by learner and credit pool, while development platforms often charge by creator seat or a custom enterprise agreement. A provider that simply passes through one of those meters risks charging for its own costs rather than for the service the customer is buying.
Monetizely's position is clear: price recurring VR and AR experience services around an annual active production deployment. Define that deployment as one agreed use case in one operating environment, then use device, learner, or user bands to scale the commitment. Charge launch work and custom experience production separately.
The logic follows Monetizely's 5-Step Pricing Framework, developed in Monetizing Agentic AI.[^1] The sequence begins with business goals and customer segments, moves to packages that fit those segments, selects the pricing metric, sets the price points, and finally makes billing and delivery work in practice. The order matters. A provider that starts with “price per headset” may discover too late that its real cost sits in content refreshes and support, or that its buyer values a trained workforce rather than a device fleet.
The buyer is renewing an operating service, not a piece of immersive content
A single VR safety simulation or AR work instruction can be sold as a project. The commercial problem changes once the provider promises that the experience will stay live across multiple quarters.
Consider the layers a customer may buy from the same provider:
Each layer has a different cost driver. Yet the customer does not want five invoices and cannot reasonably manage five separate renewal decisions. The provider therefore needs one commercial center that captures the continuing responsibility.
Public XR software pricing makes the point. ArborXR and ManageXR both charge primarily per managed device because each vendor operates a device-management layer. Virti packages immersive learning around learner capacity and credits. Unity charges its development software by creator seat or enterprise contract, while PTC's Vuforia Engine reserves production-scale capabilities for paid plans and custom pricing.
Exhibit 1: The XR stack contains several legitimate meters, each tied to a different product layer
| Vendor and product | Public pricing approach, accessed September 7, 2026 | What the meter reflects |
|---|---|---|
| ArborXR | Starter at $7 and Essential at $10 per device per month, billed annually | Managed device fleet, configuration, security, and remote support (arborxr.com) |
| ManageXR | Essential at $7 and Premium at $10 per device per month, billed annually | Device administration, content deployment, and fleet analytics (managexr.com) |
| Virti | Teams at $359 per month, billed annually at $4,308, including up to 25 learners and 60 monthly credits | Learner capacity plus AI and content consumption (virti.com) |
| Unity Industry | Starts at $4,950; seat and floating-license options are available through sales | Creator access, development tools, support, and enterprise administration (unity.com) |
| PTC Vuforia Engine | Production plans for Model Targets and Area Targets require paid Premium or Enterprise plans; high-scale options are quote-based | AR recognition and production deployment capability (ptc.com) |
The implication is not that providers should copy any one of these models. It is that a managed experience service must price the responsibility it owns, rather than inherit the meter of a software supplier.
A 5,000-person manufacturer can be a simple XR customer if it wants one standardized safety program at one plant. A 300-person field-services company can be demanding if it needs AR instructions across six equipment types, three countries, and a changing technician base.
Goals and segmentation come first because the same experience can mean different things to different buyers. A learning leader may want completed training and audit evidence. An operations leader may want fewer errors on a repair workflow. An innovation team may want a controlled pilot that proves adoption before a larger rollout. Those are different jobs, buying processes, and willingness to pay.
The useful distinction is the operating model, not a generic small, medium, and enterprise label.
Exhibit 2: Four XR operating models call for one primary unit with different scaling bands
| Customer operating model | What the customer is buying | Primary commercial unit | Scaling band |
|---|---|---|---|
| Shared VR training at one site | A repeatable training program that stays ready for each cohort | Active production deployment | Number of managed headsets |
| AR work instructions in a facility | A maintained operational workflow | Active production deployment | Frontline-worker or device band |
| Distributed soft-skills simulation | A learning program with broad access and reporting | Active production deployment | Enrolled-learner band and credits |
| Retail, showroom, or venue experience | A live guest experience that remains current | Active production deployment | Venue and device band |
An active production deployment gives the provider and buyer a stable object for the annual agreement: a defined use case, operating environment, service level, and capacity band.
A recurring service package should answer a simple buyer question: “What will remain true every month after launch?” A project statement of work should answer a different one: “What must be built or changed before the program can run?”
Mixing these two questions creates weak ARR. A provider may win a large custom-content project, call the full contract subscription revenue, and then face a renewal that contains little continuing value. The customer sees a finished asset; the provider sees an unfunded support burden.
Our view is that an XR provider should create a standard annual deployment subscription, then make recurring service modules visible. The package needs enough structure to be easy to buy, while preserving room for real operational differences across segments.
Exhibit 3: A durable offer separates launch work from the annual operating commitment
| Commercial component | Include in annual recurring price? | Typical contents |
|---|---|---|
| Active production deployment subscription | Yes | Experience hosting, administration, standard reporting, standard support, release management |
| Capacity band | Yes | Agreed ceiling for managed devices, learners, or frontline users |
| Recurring service module | Yes | Content-refresh allowance, premium support, facilitator tools, analytics, integration maintenance |
| Discovery and solution design | No | Workflow mapping, requirements, success measures, technical design |
| Device staging and initial configuration | No | Enrollment, physical preparation, initial deployment |
| Custom 3D production or major experience build | No | New simulations, complex models, bespoke interactions, major redesigns |
The package should make the annual subscription easy to compare at renewal while keeping finite production work from being mistaken for a permanent operating obligation.
The primary meter should meet four tests. It must track customer value, give the buyer budget predictability, expand fairly as use grows, and be practical to measure and invoice. Monetizely's pricing guidance places those customer and business constraints at the center of metric selection. A meter that is analytically elegant but impossible to explain or administer will not survive procurement or renewal.
Seats fail as the default XR meter because many VR programs use shared devices. A plant may train 500 workers with 20 headsets. Charging 500 seats can make the service look expensive relative to its delivery cost and usage pattern.
Device pricing also fails as the universal answer. It works well for device-management software because every enrolled device creates direct management work. A managed AR workflow, however, may create most of its value through updated instructions, integration upkeep, and service-level commitments. A mobile AR deployment may have no dedicated hardware fleet at all.
Exhibit 4: The annual active deployment outperforms common primary meters for recurring experience services
| Candidate meter | Buyer predictability | Fit with managed-service value | Fit across VR and AR | Billing practicality | Monetizely assessment |
|---|---|---|---|---|---|
| Named seat | High | Low for shared-device programs | Medium | High | Use only when the experience is personal and access is the main value |
| Managed device | Medium | Medium | Low to medium | High | Use as a scaling band, not the commercial center |
| Session, minute, or launch | Low | Low | Medium | Medium | Avoid as a primary meter because invoices become unpredictable |
| Completed training or task outcome | Medium | High in narrow cases | Medium | Low | Use as a bonus metric only when definitions are controlled |
| Active production deployment | High | High | High | High | Use as the primary meter |
The annual deployment commitment wins because it prices the service that must remain in place whether a headset is used heavily in a given week or a field workflow is needed only during an equipment shutdown.
An annual commitment does not mean a flat fee with no growth path. The deployment should include a clear capacity band, followed by transparent overages or an upgrade to the next band.
For shared VR training, the capacity measure will often be managed devices. For distributed learning, it may be enrolled learners. For AR field work, a provider can use active frontline users where individual access and support materially increase delivery effort. The choice changes by operating model, but the primary commitment remains the production deployment.
Rate setting comes after the package and meter are settled. Market comparisons can help establish a starting range, but they do not decide the price. ArborXR's $7 to $10 monthly device prices, for example, inform the software cost of an XR fleet. They do not determine the value of a managed safety program or an AR maintenance workflow.
Set the annual price within a corridor bounded by three checks:
- Economic floor: Cover the fully loaded cost of technology, customer success, support, content releases, and account management at the target gross margin.
- Customer value ceiling: Estimate the financial value of reduced training time, fewer errors, lower travel, faster onboarding, or lower safety risk.
- Market reference point: Compare the offer with credible alternatives, including internal delivery, point software, and incumbent training or workflow tools.
The first check protects the provider. The second protects value capture. The third keeps the quote legible to the buyer.
Exhibit 5: A sample three-year quote makes the commercial logic visible
The buyer can now see what it will actually pay over three years, while the provider can show which costs are launch-specific and which fund the ongoing service.
The final step is operationalization. Pricing only works when the provider can measure the chosen capacity, invoice it reliably, and explain changes without a manual debate. Monetizely's guidance is direct: making a pricing model work in systems and customer processes often takes more effort than designing the model itself.
Every agreement should establish the following rules before launch:
- Define when a deployment becomes active and when it can be paused or retired.
- Set the method and cadence for measuring device, learner, or user capacity.
- State the overage rule, including whether the customer upgrades immediately or at the next renewal.
- Specify the content-refresh allowance and the threshold that turns a request into paid custom work.
- Assign responsibility for device loss, replacement, connectivity, and local support.
A customer should never learn at renewal that “support” did not include a content update that the account team assumed was standard. Clear boundaries turn renewal from a negotiation over old expectations into a decision about future scope.
Providers should resist the temptation to price recurring VR and AR services as a bundle of headset licenses, content hours, and professional-services days. That approach reflects internal cost categories. It does not reflect the buyer's operating decision.
The annual active production deployment should be the commercial center because it captures the continuing promise: the experience will work in production for a defined use case and environment. Capacity bands make growth measurable. Separate project fees protect the economics of custom build work. Recurring modules let customers pay for deeper support, integrations, and content change without forcing every account into the same plan.
Operators should act on that position now:
Choose the business model before the rate card. Decide whether the company aims to be a repeatable managed-program provider or a custom immersive studio. A rate card cannot repair a conflict between those two businesses.
Design sales compensation around annual deployment ARR. Reward sellers for recurring commitments, expansion within capacity bands, and strong renewals rather than for maximizing one-time production revenue.
Build a buyer-facing three-year cost view for every quote. Procurement teams should see implementation, annual subscription, capacity, and optional modules separately from the first commercial conversation.
Use renewal data to standardize the service catalog. Review which custom requests recur across accounts, then turn the common ones into priced recurring modules or product features.
Require executive approval for exceptions that change the meter. Discounting a rate is reversible. Creating a special seat, session, or outcome metric for one account can permanently complicate billing and future renewals.
Assumptions: The three-year quote in Exhibit 5 is a modeled example for one active production deployment with a defined device-capacity band and recurring support scope. Actual rates should be tested against delivery cost, customer value, competitive alternatives, contract length, and the provider's target gross margin.
Footnotes
- Monetizing Agentic AI. https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
- ArborXR, “XR Device Management Pricing,” accessed September 7, 2026. (arborxr.com)
- ManageXR, “Pricing That Fits Your Deployment,” accessed September 7, 2026. (managexr.com)
- Virti, “AI Roleplay and Coaching Plans,” accessed September 7, 2026. (virti.com)
- Unity, “Unity Industry” and “Unity Pricing Changes”; PTC, “Vuforia Engine Pricing,” accessed September 7, 2026. (unity.com)