Cost per outcome, not cost per token
“We spent 40 million tokens on the support bot last month” is a true sentence that answers nobody's real question. Tokens are a unit of provider billing, not a unit of business value. Your board isn't going to ask how many tokens the support bot consumed. They're going to ask whether the money it costs is worth what it produces — and token count, on its own, cannot answer that.
The metric that actually answers it is cost per outcome: total spend on a feature divided by the number of real business results it produced — tickets resolved, contracts drafted, leads qualified, documents processed. Same spend, framed against what it bought instead of what it consumed.
Why per-token and per-feature metrics fall short on their own
Attribution by feature or department — “Customer Support spent $2,450 this month” — is a real improvement over one lump invoice line, and it's necessary groundwork. But it still doesn't answer whether that spend was worth it. $2,450 is expensive if it resolved 200 tickets and cheap if it resolved 12,000. The dollar figure alone carries no information about value produced; it only tells you where the money went, not what it bought.
Cost per token has the opposite problem: it's precise about consumption and silent about value entirely. A feature that uses fewer tokens per call isn't automatically cheaper per result — if it also produces fewer usable outcomes per call, the efficient- looking token metric can be hiding a worse cost-per-result than a “wasteful”- looking feature that gets more real results per dollar spent.
There's a third failure mode, and it's the one that actually stops teams from ever getting to outcome tracking at all: waiting for a complete, perfectly-designed outcome taxonomy before tagging a single call. It feels responsible — why tag “ticket resolved” before you've agreed on every outcome category the business will ever need? In practice that wait never ends, because the taxonomy only ever gets refined against real tagged data, and there isn't any yet. Teams that hold out for the complete version end up with no outcome data a year later. Teams that tag one crude, obviously-imperfect outcome on day one have a trend line by week two — and can refine the taxonomy against real evidence instead of a whiteboard guess.
How outcome tracking actually works
Add one header — X-Cost-Outcome: ticket-resolved — to the calls that produce a result worth counting, and Cognocient aggregates spend against outcome count automatically: total cost for the tag, divided by how many times it fired, tracked over time and compared against the prior period so a cost-per-outcome trend is visible, not just a snapshot.
Outcomes can also be correlated after the fact — a call tagged at request time and an outcome confirmed later (a ticket actually closed, a document actually approved) get linked by a correlation key, so the metric reflects results that were confirmed to happen, not just calls that were made with the intent of producing one.
What this looks like in practice
Consider a hypothetical support-bot feature that's been tagged with X-Cost-Feature: support-bot for months, giving the team a clean per-feature spend number — but no sense of whether that spend is trending better or worse. Rather than waiting to design a full outcome taxonomy, the team adds one tag to the single call that fires when a ticket is marked resolved: X-Cost-Outcome: ticket-resolved.
Within days, the same total spend that used to be one flat number now divides by outcome count automatically, producing a cost-per-ticket figure that moves week to week. If a model change or a prompt tweak makes the bot more efficient, that shows up as a falling cost-per- outcome trend — not just a falling total-spend number that could just as easily mean fewer tickets came in. This is illustrative of how the mechanism behaves, not a specific customer's reported result.
What this changes about the conversation
“Cost per ticket resolved is $0.42, down 12% from last month” is a sentence a CFO can act on immediately — compare it to what a human agent costs per ticket, decide whether the trend is going the right direction, and know whether the AI feature is getting more or less efficient over time, all without needing to understand tokens, models, or prompt structure at all.
That's the actual purpose of outcome tracking: not a more precise cost metric, but a translation layer between what engineering instruments and what finance and the board can actually reason about — spend framed against results, not consumption.