Cost-per-Outcome

Definition. Cost-per-Outcome is the total cost of a process in a period divided by the number of usable business results it completed in that period.

The price of a model request says little about whether a process became cheaper. People may spend time reviewing the answer, customers may have to contact support again, or an error may need expensive repair. Cost-per-Outcome brings those parts of the work into the same calculation.

Define the result first

Choose an outcome the process exists to deliver. For customer support, “ticket closed” may be too loose: a request resolved without a repeat contact may better reflect the customer's experience. For an internal workflow, the result might be a complete, accepted record rather than a draft generated by the system.

Write down what qualifies, how it is counted and when it is counted. Use the same definition before and after a change. If the team changes the definition, recalculate earlier periods where possible or show a break in the series. Do not join unlike measures in one trend line.

Count the full cost

For the same period and scope, add:

• People and operating costs: time spent doing, checking, correcting and managing the work, plus relevant tools and services.
• AI and infrastructure costs: model usage, hosting, integration and maintenance of data or context.
• Transition costs: design, training and implementation. Choose and disclose a consistent way to allocate these costs across periods; also show actual cash outlay when discussing payback.
• Error costs: rework, repeat contacts, refunds or other consequences that can be measured credibly.

Then calculate:

Cost-per-Outcome = total process cost ÷ completed outcomes.

Use estimates where records are missing, label them and replace them with observed data as the process runs. A precise-looking answer based on omitted work is less useful than an honest range.

Read it with a quality measure

Suppose a system closes more requests with less staff time. The unit cost may fall while customers return because their problems were not resolved. Pair cost with a measure such as repeat-contact rate, accepted-work rate or customer satisfaction, depending on the process. Segment the results when one customer group or exception type behaves differently from the average.

Total spending and unit cost answer different questions. A team can spend more overall while completing more work at a lower unit cost. That may be valuable if demand exists, but it is not a cash saving. State which outcome the business expects: lower spending, more capacity, faster service, better quality or some combination.

Establish a comparison

Capture the baseline before changing the process if the data is available. Record the outcome definition, volume, cost categories and quality measure. Then repeat the calculation over comparable periods. Adjust for meaningful changes in case mix: a month with mostly routine requests should not be compared uncritically with a month of difficult ones.

If the baseline is missing, reconstruct what you can from records and say where the estimate is weak. Do not claim a return on investment from a model bill alone. A pilot review can use the cost, quality and implementation evidence to decide whether to expand, redesign or stop the work.