Chapter 2 of 15

Define the Unit Economics Before Optimising

I do not want to optimise tokens before I know what economic unit matters. A ten-pence request can be expensive if the customer pays five pence for it, while a five-pound workflow can be excellent economics if it replaces an hour of valuable work and is priced accordingly.

  • Cost per request versus cost per outcome
  • Contribution margin
  • Cost-to-value ratio
  • Success-rate-adjusted cost
  • Internal versus customer-funded usage

The situation

Teams often see an expensive model call and immediately try to make it cheaper. That can be the wrong optimisation. The right question is whether the cost is appropriate for the value and revenue attached to the workflow.

The naive solution

Choose the cheapest model everywhere and celebrate the reduced token bill.

The hidden constraint

A cheaper call that lowers answer quality, increases retry rate, causes more human correction, or reduces conversion can increase the cost of a successful outcome. Model price and workflow economics are not the same thing.

The decision

Define the business metric first. For a SaaS feature I may care about variable cost per active customer and gross margin. For an agency workflow I may care about cost per qualified lead, redesign, audit, or delivered project. For internal automation I may care about cost per hour of human work avoided.

The implementation

For each important workflow I would track at least: revenue or value proxy, successful completions, AI variable cost, failure rate, retry rate, and human intervention. From that I can calculate cost per successful completion and contribution margin. I would also keep a value estimate where possible, because a cost number without a value number encourages indiscriminate cutting.

The tradeoff

Value is sometimes harder to measure than spend. I would rather use an imperfect but explicit value proxy than optimise solely against the easiest number in the system, which is usually token cost.

The evidence I would look for

A useful cost model should explain why an apparently expensive workflow is still worth running, or why a cheap high-volume feature is quietly destroying margin. If the model cannot do that, it is not yet connected to the business.

The reusable lesson

Optimise contribution, not consumption. The cheapest AI system is not automatically the best business, and the most expensive workflow is not automatically the one to cut.

The consultant's questions

  • What is the unit of value for this AI workflow?
  • What is the cost per successful outcome after retries and failures?
  • Does a cheaper model increase downstream correction or abandonment?
  • Which AI features create measurable revenue, retention, time savings, or sales leverage?