Designing the Unit of Value: What Exactly Are You Selling Now?

The unit of value is the thing a client actually buys and the thing an invoice counts. In a time-and-materials contract it is a person-month. Once that unit stops making sense, choosing its replacement becomes the hardest commercial decision a services firm makes, because every other term in the contract is derived from it.

Why the choice determines everything downstream

Two firms can agree on the same strategy and reach entirely different outcomes because they picked different units. Cognizant reports roughly 45% of BPO contracts on outcome-based models. Coforge puts outcome-based work at 6–7% of total revenue. Both are moving the same way. Much of the distance between them sits in how tractable a unit they chose and whether their delivery model could carry it.

A well-chosen unit makes pricing, measurement, dispute resolution and capacity planning follow naturally. A poorly chosen one turns every month-end into a negotiation.

The candidates

The last row is where most first-time outcome contracts go wrong, and the reason is understandable. A business KPI is the easiest unit to sell, because it is the thing the client cares about. It is also the unit most contaminated by decisions the provider does not make.

Four tests for any candidate unit

Before a unit reaches a proposal, run it against four questions. A unit that fails any one of them will cause trouble; a unit that fails two should not be offered.

1. Does the client recognise it as value?

If the buyer has to be persuaded that the unit matters, the unit is wrong. Credits and tokens fail here more often than their designers expect. Grid Dynamics' GAIN framework and Globant's AI Pods both work as pricing constructs precisely because the vendor invested in making the unit legible to a buyer.

2. Can it be measured without argument?

The measurement has to come from an instrument both parties can read, on a cadence both parties accept. If the number arrives in a monthly provider report that the client cannot independently verify, the unit will eventually be disputed.

3. Can either side game it?

A ticket-based unit rewards ticket creation. A resolution-based unit rewards closing cases fast rather than well. Every unit creates an incentive; the question is whether that incentive points in a direction both parties can live with. Pairing a volume unit with a quality gate usually resolves this.

4. Do you know your cost of delivering one?

This is the test most firms skip and the one that decides profitability. If a provider cannot state the cost of resolving one case or deploying one model, it cannot know whether a price is generous or ruinous, and it will discover which only after the contract is signed.

The baseline problem

Most outcome contracts are lost at signature rather than in delivery, and the usual cause is a missing baseline.

If the pre-engagement position was never measured, every subsequent improvement becomes contested. The provider says ticket volume fell 40%; the client says volume was already falling, or that the definition changed, or that seasonality explains it. Neither party is acting in bad faith. They simply have no shared starting number.

The discipline that avoids this is unglamorous:

• Instrument the account before proposing, not after signing.
• Agree the measurement method, the data source and the reporting cadence in writing, separately from the commercial terms.
• Write the dispute mechanism while both sides are still optimistic. It is the only time it can be written fairly.
• Record the baseline as a joint artefact, signed by both parties, with the definitions attached.

Tech Mahindra's healthcare engagement, priced against 40% fewer tickets, 20% lower resolution time and a 30–35% reduction in technical debt, only functions because each of those measures has a defined starting point. Without the baseline, the same contract is unenforceable in either direction.

A note on vendor productivity claims

Firms designing their first unit often anchor on published productivity figures. A 30% uplift here, six-times-faster adaptation there, three-times-less production time elsewhere. These numbers come from companies selling the frameworks that produce them.

Treat them as positioning, not as planning inputs. A pricing model built on someone else's marketing claim will price the work at a cost the firm cannot actually achieve.

The alternative is slower and more reliable: run two or three engagements with the new delivery model, measure the real cost of a unit in your own environment, and price from that. The first contracts should be priced to learn rather than to win.

Start narrow

The instinct when redesigning a commercial model is to find one elegant unit that covers the portfolio. It rarely exists.

A more workable approach is to choose one service line where volume is high, definitions are stable and measurement already exists, and convert only that. Application support and infrastructure operations usually qualify. Complex transformation work usually does not, and can stay on its existing model for another year without embarrassment.

The firm that converts one service line well learns more than the firm that announces a portfolio-wide shift and quietly reverts.