What is cost per outcome?
Cost per outcome is the total spend attributable to a Digital FTE in a closed period divided by the number of outcomes that were approved in that period. On ftes.ai the numerator comes from the token ledger, which records every debit with its job and its timestamp, and the denominator comes from the Approvals record, which records every human decision. Both are records of events that happened rather than estimates, which is what makes the ratio worth computing at all.
The metric answers one management question: what did each unit of accepted work cost this period. It does not answer what that work was worth.
Defining the outcome is the hard part
An outcome is one unit of work a manager approved: a published article, a reconciled statement, a resolved ticket, a shipped listing correction. It must be a unit the role produces repeatedly, or the denominator changes meaning between periods. It must be counted at approval rather than at production, because work that was produced and sent back is cost without an outcome. And its definition must be written down once and left alone, since redefining the unit is the easiest way to make the metric improve without anything improving.
Where a role produces two genuinely different units, compute two ratios rather than averaging them into one that describes neither.
The arithmetic: one division, with the inputs left blank
For period [start] to [end], take total user tokens debited to the role from the ledger as [T]. Convert to currency at the organisation's own rate for the plan it is on, giving spend [S]. From the Approvals record take the count of approved units of the defined outcome as [N]. Cost per outcome is [S] divided by [N]. Record [T], [S], [N] and the outcome definition alongside the result, because a ratio without its inputs cannot be checked or compared later.
Every bracket is filled from a record the organisation already holds. If a bracket cannot be filled, the number should not be computed, and the absence is itself the finding.
Four ways the number is computed wrong
The first is counting produced work rather than approved work, which credits the role for drafts nobody accepted. The second is removing the cost of rejected attempts from the numerator, which prices a perfect run that did not happen. The third is comparing an open period against a closed one, where approvals lag production and the ratio looks worse than it is. The fourth is changing the outcome definition between periods, which makes the series incomparable while looking continuous.
All four move the number in the flattering direction, which is why they are worth naming explicitly rather than trusting a reviewer to catch.
- Counting produced work instead of approved work
- Removing rejected attempts from the cost
- Comparing an open period against a closed one
- Redefining the outcome between periods
What should the result be compared against?
Against the same role's prior periods, and against the fully-loaded cost of producing the same unit the way the organisation produced it before. Both comparisons use the organisation's own numbers, which is what makes them defensible. A comparison against a figure published by a vendor, including ftes.ai, would compare two different outcome definitions on two different cost bases and would mean nothing.
ftes.ai therefore publishes the model and refuses to publish a benchmark. A benchmark would be the more persuasive artefact and the less honest one.
What cost per outcome cannot tell you
It cannot tell you whether the outcome was worth having. A falling cost per outcome on work nobody needed is a cheaper way to waste money, and the metric will report it as an improvement. It also says nothing about quality beyond the approval decision itself, which is why it is read next to the approval rate and the send-back reasons rather than alone. A role whose cost per outcome falls while its send-backs rise is producing cheaper work that needs more of the manager's time.
The metric is one input to a review, and the review is where the judgement happens.
How often should it be computed?
Once per closed period, at the monthly review, with the inputs recorded in the review note. Computing it more often invites the open-period mistake; computing it less often loses the connection between a change the manager made and its effect. A role in its first two periods will produce a volatile number because volumes are small and the definition is still settling, and that volatility should be reported rather than smoothed.
A stable ratio over three closed periods is the point at which it starts supporting decisions about budget and autonomy.