Three pricing models, chosen by the customer's data maturity

The same deployment can be priced three ways, and for a given customer only one of them survives contact with reality. Choosing by preference — "I like outcome pricing, it feels like a partnership" — is how a small team ends up funding the customer's measurement problem for a year and calling it investment.

Three models, three billing units

Per seat. Billed by people, accounts, or person-days. It is the easiest to explain and the easiest for a buyer to compare against a salary. It is also the fastest route to being treated as cheap outsourcing: when the unit is a person, every adjacent task looks free, and the customer has no reason to stop adding them.

Per stage. A fixed price per phase, with payment attached to verifiable artefacts. The billing unit is a milestone, not a day. A twenty-thousand-yuan engagement can be split eight thousand at scope confirmation, eight thousand when the agreed sample table runs and reconciles with the manual total, and four thousand after a one-week trial and handover. Each payment follows an event both sides can see.

Per outcome. Billed per resolved unit: a closed case, a recovered payment, a completed onboarding. Four rungs move the unit closer to value and further from easy attribution — usage, then task, then result, then a share of the value created. The clause underneath needs five parts: metric definition, baseline and measurement window, judge and data source, dispute arbiter, and an abortion clause. The last is the one most often omitted and the most damaging when a result never arrives.

Model	Choose it when	What must exist on the customer side	Failure mode	Switch trigger
Per seat	Scope is still moving, or the customer has no process owner	A manager who can define tasks and stop adding them	You sell hours, the ceiling is 24 a day, and the buyer compares you to a temp	The same task appears a third time and can be scoped
Per stage	Scope can be listed and acceptance can run in weeks	A signed metric table, an approver, a written out-of-scope list	Scope creep absorbed as unpaid overtime; the stage never closes	The same stage repeats across customers and becomes a template
Per outcome	The customer's own systems can measure the result	A baseline, clean attribution, an arbiter, and cheap monthly measurement	You fund the measurement gap and every bad month	The measurement is argued monthly rather than once

Data maturity has three levels

The deciding variable is not the industry and not the size of the account. It is whether the customer can produce the number without you.

Level one. Numbers exist only as a story — "reports eat our week" — and no export can be pulled. Sell per stage, or per seat if the work itself is unstable. Never sell outcome pricing here: there is nothing to measure against, so the baseline becomes your opinion.

Level two. An export exists, but no agreed definition and no named owner for the number. Sell per stage, with the metric table signed before the build starts. Outcome pricing becomes available after the first measurement window, not before.

Level three. A live system, a historical baseline, and a finance owner who will sign the figure. Outcome pricing is now possible, because the proof that a case was resolved already exists as infrastructure rather than as an argument.

This is also why vendors that charge per resolved case can do it at all. One vendor-reported example bills per resolved conversation, with an annual floor around one hundred and fifty thousand dollars and a per-resolution price of one to two dollars; that is only defensible because an evaluation system can show the customer what "resolved" means. Without that system, outcome pricing is a discount wearing a partnership's clothes.

Bad debt is part of the price

One practitioner's observation, from his own pipeline: final payments are hard to collect at the three-hundred-thousand level, orders above two hundred thousand tend to enter formal procurement, and fifty to two hundred thousand is the range a small team can actually carry. Those are one person's numbers, not an industry rate, and they should be read as structure rather than statistic. A fixed price paid at the end is an interest-free loan, and the FDE is the party who cannot absorb it.

Three consequences follow. First, milestones are not a sign of distrust; they are how a small team survives the risk it is being paid to take. Second, a deposit that is not refundable is not greed, it is the cost of reserving a month. Third, when a customer insists on payment at the end, the answer is to shrink the first deliverable until it is separately deliverable and separately billable, not to accept the whole risk.

Outcome pricing is bought with volatility

Moving to per-outcome shifts usage risk from the customer to the vendor. Revenue swings, collection slows, and cash forecasting gets worse. The extra pricing room is paid for in that volatility, so the first question is not "can I charge more" but "can I survive the worst month". If the worst month would end the company, per stage is the honest answer, whatever the pitch deck says.

The second question is whether the baseline is stable enough to bill on. A metric that the customer redefines each quarter turns every invoice into a negotiation, and a metric the customer cannot see turns every invoice into a favour.

Three questions before any quote goes out

1. Can the customer produce this number today, from their own system, without asking me for it?
2. Who signs that number, and what happens on the day we disagree?
3. Which model will be wrong in six months, and what event triggers the switch?

Write the answers into the quote itself. The scoping work decides whether a quote may be sent at all; this choice decides whether the project is still profitable after the first change request. And because the switch trigger usually appears as a new metric, keep the metric table as the single place where a renegotiation starts — that is what makes a change of model a business decision rather than an argument at the end of a stage.