Outcome-based pricing ties part of what you pay to a measured result: less scrap, fewer escaped defects, fewer hours of unplanned downtime. It sounds like the vendor finally has skin in the game, and it can be exactly that. But it only works when three conditions hold. There must be a measured baseline both sides accept, a metric neither side can move without moving the real outcome, and a result the vendor can actually influence. Without all three, a shared-savings contract turns into a monthly argument, and a plain subscription or capital purchase serves everyone better.
Three ways to pay for industrial AI
Most industrial AI systems are bought in one of three ways. They differ mainly in who carries which risk.
| Model | What you pay for | Who carries performance risk | Fits best when |
|---|---|---|---|
| Capital purchase | Hardware, integration and software up front; support optional | You | You want to own the asset, have capital budget and in-house support |
| Subscription | A monthly fee per station, asset or building, usually with hardware replacement and support included | Shared: the vendor carries hardware and support risk, you carry results risk | You want predictable operating cost and no hardware exposure |
| Outcome-based (shared savings) | A base fee plus a variable portion tied to a measured improvement | Shared, with more of the results risk moved to the vendor | A clean baseline exists and the outcome is frequent and measurable |
For reference, our own prices are published. A typical single-station inspection system costs $48,000–$140,000 installed as a capital purchase, while Inspection-as-a-Service starts at $2,950 per station per month on a 36-month term. Outcome-based pricing is a layer on top of those structures, not a replacement for them. Someone still has to pay for the hardware.
Why a measured baseline comes first
There are no savings without a “before”. The baseline has to be measured, not estimated from memory, from last year’s budget or from a quality report that defined scrap differently. A usable baseline has four properties:
- Same method before and after. The same system of record, the same definitions, the same people doing the counting.
- Long enough to capture normal variation. Several shifts, the usual product mix, and ideally a full production cycle. A baseline measured during an unusually good fortnight will make any later result look bad.
- Normalized. Expressed per unit produced, per million units shipped or per scheduled operating hour, so that changes in volume don’t masquerade as improvement.
- Documented conditions. Line speeds, products, suppliers and staffing during the baseline period, so later changes can be recognized.
This is why outcome-based pricing usually follows a pilot rather than replacing one. The pilot is where the baseline gets measured and both sides learn whether the metric behaves. We covered how to set one up properly in from pilot to fleet.
Designing the metric
The metric is the contract. If it is vague, the contract is vague.
Scrap
Scrap is the easiest outcome to measure, because it is counted or weighed every shift. Normalize it per unit or per kilogram produced. The trap is that an inspection system can reduce recorded scrap simply by rejecting less, which sends the defects to the customer. So scrap should always be paired with an escape metric.
Escapes
Escapes, meaning defects that reach a customer, are what quality managers care about most. They are also hard to contract on. They are lagging, because complaints can arrive weeks after shipment, and they are often rare. If the baseline is four customer escapes a quarter, a quarter with two is not proof of anything. Use longer measurement windows, or an agreed internal audit sample as the primary measure, with customer complaints as a check.
Downtime
Unplanned downtime on monitored assets suits condition monitoring. Normalize it per scheduled operating hour, and define precisely what counts. Planned maintenance, utility outages and stops caused by starved or blocked conditions are usually excluded. The trap here is relabeling: a stop that becomes “planned” disappears from the metric without anything getting better.
| Metric | Normalize by | Usual exclusions | Pair it with |
|---|---|---|---|
| Scrap rate | Units or kg produced | Trial runs, documented incoming-material nonconformances | Escape rate |
| Escape rate | Units shipped (per million) | Defects outside the agreed inspection specification | False-reject rate |
| Unplanned downtime | Scheduled operating hours on monitored assets | Planned maintenance, utility outages, starved and blocked time | Planned downtime hours |
Guardrails against gaming, on both sides
Gaming is rarely deliberate. More often, a well-meaning person optimizes the number in front of them. Contracts should assume that both sides will do so.
Vendor-side temptations
- Over-rejecting to drive escapes toward zero, which inflates scrap and false rejects.
- Under-rejecting to cut recorded scrap, which pushes defects downstream.
- Alerting on everything, so that every failure was technically “predicted”.
The answer is paired metrics, a cap on the false-reject rate, and measuring alert precision as well as alert coverage.
Client-side temptations
- Moving unplanned stops into planned categories, or reclassifying scrap as rework.
- Not acting on alerts, then counting the resulting failure against the vendor.
- Crediting improvements to a parallel lean project, or crediting the parallel project’s improvements to the AI system.
- Changing the product mix toward items that are easier or harder to make.
The answer is definitions written into the contract, data from a system of record both parties can audit, a response obligation for alerts, and an attribution rule for overlapping projects agreed in advance.
Structural guardrails
- A base fee that covers hardware, software and support whatever the result.
- A cap and a floor on the variable portion, so neither side faces an open-ended number.
- Rebaseline triggers, such as a new product, a line rebuild or a volume change beyond an agreed band.
- A monthly joint review of the measurement, with a named owner on each side.
- A dispute rule decided before the first invoice, not after.
A worked example
The numbers below are hypothetical and illustrate the mechanics, not any actual Perflens terms.
A line makes 1,000,000 units a month. The baseline, measured over six weeks, shows scrap at 2.0% of output, or 20,000 units. Each scrapped unit costs $1.50 in material and processing. After deployment, scrap runs at 1.4%, or 14,000 units, while the escape rate and false-reject rate stay inside their agreed limits.
- Measured reduction: 0.6 percentage points, or 6,000 units.
- Monthly saving: 6,000 × $1.50 = $9,000.
- If the agreement shares 30% of measured savings, the variable fee that month is $2,700, on top of the base fee.
The following month, volume drops to 800,000 units and scrap holds at 1.4%. Because the metric is normalized, the saving is 0.6% × 800,000 × $1.50 = $7,200, and the variable fee is $2,160. Nobody has to argue about whether the lower absolute scrap count reflects the system or the slower month.
When outcome-based pricing doesn’t fit
It is a poor fit more often than vendors admit:
- There is no baseline, and no time to measure one. Estimated baselines lead to disputes.
- The outcome is rare. With a handful of events a year, random variation swamps any real effect.
- The vendor can’t control the result. In predictive maintenance, the plant’s crew decides whether and when to act on an alert. That can still work with a response obligation, but the contract gets complicated.
- The process is about to change. A new product launch or line move will reset the baseline anyway.
- Your finance team wants predictable costs. A variable fee is harder to budget and accrue than a flat one.
- You want to own everything outright. A capital purchase with optional support is simpler.
- The deployment is small. The effort of measurement and monthly review can cost more than the risk it shifts.
How our shared-savings option works
At Perflens, shared savings is an option on top of our standard pricing, and it is only available after a Proof of Value has established a measured baseline. From there, part of the fee can be tied to measured scrap, escape or downtime reduction against that baseline. Because the Proof of Value already requires success criteria agreed in writing, the measurement definitions exist before the commercial terms do.
If you are still estimating what an improvement is worth, start with the inspection ROI calculator or the downtime cost calculator. If the numbers are large, frequent and measurable, outcome-based pricing may be worth discussing. If they aren’t, a flat price you can plan around is usually the honest answer.