Unit Economics Teardown: What a Customer-Support Agent Actually Costs at Scale

Table of Contents

• The Setup: One Agent, One Price, A Lot of Hidden Plumbing
• The Revenue Side: What "Per Resolution" Actually Means
• The Cost Stack, Line by Line
• Inference: The Obvious Cost That Isn't the Biggest
• Retrieval and Tool Calls: The Quiet Multiplier
• Retries and Escalations: Where Margin Goes to Die
• Human Review: The Cost Everyone Pretends Is Temporary
• Putting It Together: A Worked P&L Per 1,000 Tickets
• The Three Variables That Decide Everything
• Insights Most People Overlook
• References

The Setup: One Agent, One Price, A Lot of Hidden Plumbing

Let's build a concrete example and stick with it, because vague economics is how vendors hide bad businesses.

Imagine "Resolve," a fictional but representative Agentic AI-as-a-Service product. It plugs into a mid-market SaaS company's Zendesk, reads incoming tickets, searches the customer's help center and internal docs, drafts a reply, and, when confident, sends it and closes the ticket. When it isn't confident, it hands off to a human with a summary. Resolve charges the customer $1.50 per resolved ticket. No seats, no platform fee. You pay when a ticket gets closed by the agent.

That pricing model is the whole story. It sounds clean to the buyer: I only pay for outcomes. But it shoves all the operational risk onto Resolve, and the risk is denser than it looks. The buyer sees one clean number. Resolve sees a probability tree where every branch has a cost and only some branches generate revenue.

This is the core tension running through the entire GaaS category: the unit you bill on and the unit you spend on are not the same unit. You bill per resolution. You spend per attempt, and a single resolution might take several attempts, a dozen tool calls, and a fractional minute of human attention. Getting from "attempts" to "resolutions" is the whole game.

The Revenue Side: What "Per Resolution" Actually Means

Start with revenue because it's deceptively simple and that simplicity is the trap.

Resolve bills $1.50 only when the agent autonomously closes a ticket. Define that carefully. A ticket the agent drafts but a human sends? Most contracts don't count that as a resolution. A ticket the agent closes that the customer reopens two hours later because the answer was wrong? That's a reopened ticket, and a well-written contract claws back the charge or never bills it. A ticket the agent escalates to a human in the first place? Zero revenue, but, and this is the part that bites, not zero cost. The agent already burned tokens reading the ticket and deciding it couldn't help.

So your revenue per 1,000 incoming tickets is not $1,500. It's $1.50 times your autonomous resolution rate, the share of tickets the agent both attempts and successfully closes without a human. If that rate is 55%, you're collecting $825 per 1,000 tickets, not $1,500. The distinction between success rate and task completion rate is not academic here; it's the difference between two materially different revenue lines, and it's why agent success rate and completion rate deserve their own analysis.

The buyer, meanwhile, anchors on a different number entirely: their old cost per ticket. If a human agent costs them $6 to handle a ticket and Resolve closes it for $1.50, the buyer sees a 75% saving and signs. The gap between the buyer's $6 reference point and Resolve's true cost-to-serve is the entire margin envelope. Everything below is about how much of that envelope survives.

The Cost Stack, Line by Line

Inference: The Obvious Cost That Isn't the Biggest

Everyone starts with token cost because it's the line item with a public price tag. A support ticket isn't a long document. A typical exchange, system prompt, ticket text, retrieved KB snippets, the drafted reply, might run 8,000 input tokens and 800 output tokens for a single clean pass.

On a mid-tier frontier model, call it roughly $3 per million input tokens and $15 per million output, the per-pass cost lands around $0.036 input plus $0.012 output, about $0.05 per attempt. (Provider rate cards move constantly; Anthropic's model pricing page and OpenAI's API pricing are the live references, and you should never hardcode these into a financial model, see the token-volatility problem.)

Five cents an attempt against $1.50 of revenue looks like a rounding error. This is exactly why naive teardowns conclude support agents have 95%+ gross margins. They stop here. The inference line is real, but it's the cheapest honest line on the page, and treating it as the whole COGS is the single most common error in GaaS financial modeling. Falling token prices, incidentally, haven't rescued anyone's margins the way people expected, the savings get eaten by rising call volume per task.

Retrieval and Tool Calls: The Quiet Multiplier

A support agent doesn't make one model call. It runs a loop. Read the ticket. Decide what to search. Query the vector store. Read results. Maybe query an order-status API. Maybe check the customer's subscription tier in the billing system. Re-reason. Draft. Self-check the draft against policy. Each of those steps is either another inference call or a tool call, and tool calls have their own costs: vector-DB queries, API rate-limit overages, and the latency that makes you re-feed context.

A realistic "clean" resolution isn't one $0.05 pass. It's three to six model calls plus four or five tool calls, and because each model call re-ingests the growing context window, token consumption compounds rather than adds. The retrieved snippets that helped on call two get re-sent on calls three through six. That clean ticket now costs $0.15 to $0.30 in inference alone, before anything goes wrong. The way tool-call costs stack and compound across an agent workflow is its own rabbit hole, and it's where a "five-cent ticket" quietly becomes a thirty-cent ticket.

Retries and Escalations: Where Margin Goes to Die

Now the branches. Not every ticket resolves on the first try. The agent drafts a reply, its self-check flags low confidence, it retries with a different retrieval strategy. Sometimes that second attempt works. Sometimes it burns three more passes and still escalates to a human.

Here's the asymmetry that kills naive models: the tickets that cost the most to process are disproportionately the ones that generate no revenue. An easy ticket resolves in two passes and bills $1.50. A hard ticket grinds through eight passes, racks up $0.60 in compute, and then escalates, earning zero. You are paying premium compute prices specifically for the privilege of failing. As McKinsey has noted in its work on the economic potential of generative AI, the value of these systems concentrates heavily in specific high-volume functions like customer operations, but that value only materializes if the failure cases are cheap, and in agent workflows they are the opposite of cheap.

This is why the hidden cost of retries, where one task quietly becomes dozens of model calls, is the single most important concept in support-agent economics. Your blended cost per incoming ticket has to absorb the wasted compute from every ticket the agent touched but didn't close.

Human Review: The Cost Everyone Pretends Is Temporary

Then there's the line item that pitch decks bury: humans. Two kinds.

First, escalation handlers. When the agent gives up, a person finishes the job. If Resolve runs a managed service, that human is on Resolve's payroll, not the customer's, and they're handling the hardest tickets, the ones the AI couldn't crack. A human resolving a hard ticket might take 10 minutes. At a loaded $25/hour, that's $4.17 of cost on a ticket that earned nothing.

Second, quality review. Early in any deployment, and "early" often lasts a year, a fraction of "autonomous" resolutions get spot-checked by a human to catch hallucinated policies and wrong refunds before they reach customers. Even reviewing 15% of resolutions at 90 seconds each adds real cost per resolved ticket. The human-intervention rate is the metric that tracks this, and it's the closest thing GaaS has to a churn signal: when it climbs, margins fall and the customer starts asking why they're paying for an "autonomous" agent that needs babysitting.

Putting It Together: A Worked P&L Per 1,000 Tickets

Let's run 1,000 incoming tickets through Resolve with plausible numbers.

Outcomes: - 550 resolved autonomously (55% autonomous resolution rate) → revenue - 200 escalated to a human after the agent attempted them → no revenue, full attempt cost - 250 the agent correctly routed straight to a human as out-of-scope → no revenue, minimal attempt cost

Revenue: 550 × $1.50 = $825

Inference cost (all 1,000 tickets consume compute): - 550 resolved: avg $0.22 each = $121 - 200 attempted-then-escalated: avg $0.45 each (these are the expensive grinders) = $90 - 250 quick-routed: avg $0.04 each = $10 - Inference subtotal: $221

Tool/retrieval overage: ~$0.05 blended × 1,000 = $50

Human escalation handling: 200 hard tickets escalated by the agent, plus the 250 routed ones still need a human somewhere, but assume the customer's own staff takes the 250 routed ones (out of scope by contract), and Resolve only eats the 200 it failed at. 200 × $3.00 (loaded, ~7 min avg) = $600

Quality review: 15% of 550 resolutions × $0.60 = $50

Total COGS: $221 + $50 + $600 + $50 = $921

Gross profit: $825 − $921 = −$96. Negative.

That negative number is the whole point of this teardown. With completely reasonable assumptions, a per-resolution support agent loses money, driven almost entirely by the $600 of human labor spent finishing the tickets the agent couldn't. Strip out managed-service escalation (push it back to the customer), and the same business flips to roughly $504 gross profit on $825 revenue, 61% margin. That's a healthy GaaS gross margin by 2026 standards. Same agent. Same model. Same tokens. The only thing that changed was who pays for the failures.

The unit economics of a support agent, in other words, are barely about the AI. They're about the boundary you draw around what the agent is responsible for when it fails.

The Three Variables That Decide Everything

Sensitivity analysis cuts through it. Three numbers move the P&L more than anything else:

1. Autonomous resolution rate. Every point moves revenue directly and shrinks the expensive failure pool. Going from 55% to 70% in our model adds $225 of revenue and removes ~$200 of escalation labor, a ~$425 swing per 1,000 tickets from a 15-point improvement. This is why agent reliability isn't a quality concern, it's the financial lever.

2. Cost per failed attempt. Capping retries, say, escalating after three passes instead of eight, barely dents resolution rate but slashes the wasted compute on the failure branch. Several agent startups are quietly capping autonomy for exactly this reason.

3. Who owns escalation labor. The single biggest line item, and the one decided in the contract, not the codebase. Managed-service GaaS that eats escalation labor needs a much higher resolution rate to break even than pure-software GaaS that hands failures back to the customer.

Notice what's not on the list: token price. It matters, but it's third-order. Anyone who tells you their support-agent margins live or die on inference costs is either selling you something or hasn't run the numbers past the first line.

Insights Most People Overlook

The cheapest tickets subsidize a business model that the expensive tickets quietly destroy. Support ticket difficulty follows a brutal distribution: a large share are trivial password-reset-class tickets that resolve in two passes, and a long tail are gnarly edge cases that grind and escalate. Per-resolution pricing means you earn the same $1.50 on both but spend 10x more on the tail. As an agent's resolution rate climbs, it's eating into that easy base and leaving a harder residual mix, which means your cost-per-attempt creeps up even as your headline resolution rate looks great. Margin can compress while the dashboard says everything's improving.

"Deflection rate" is a vanity metric that hides the reopen problem. A vendor proudly reporting 70% deflection is counting tickets the agent closed, not tickets the agent closed correctly. If 10% of those reopen within 48 hours, you've got a hidden double-cost: you paid to resolve it wrong, then you pay again (often a human, on the hard second pass) to resolve it right. Always ask for net resolution rate after reopens. Most vendors don't track it because it makes the slide uglier.

Per-resolution pricing structurally penalizes the vendor for getting better at saying "I don't know." The honest behavior, escalate early when unsure, costs the vendor money (compute spent, no revenue) while the dangerous behavior, confidently close a ticket it's unsure about, earns $1.50 immediately. The pricing model creates a quiet incentive toward overconfidence. The vendors who resist it pay for that integrity in margin, which is one reason per-outcome pricing is harder to run honestly than it looks.

The escalation handoff is an unpriced externality in most contracts. When an agent escalates, it generates a cost on the buyer's side, a human now has to read the agent's summary and pick up a half-worked ticket, which is sometimes slower than starting fresh. A genuine ROI calculation has to net out this "escalation tax" on the customer's team, and almost none do. The agent's true cost-to-serve includes labor that doesn't show up on the vendor's P&L at all.

Idle and warm-start costs hide in always-on support agents. A support agent that must respond in seconds can't cold-start per ticket; it holds context, keeps retrieval indexes warm, and sometimes pre-fetches. That standby infrastructure is real spend that doesn't map to any single resolution, and per-resolution pricing gives you nowhere clean to put it. It's the support-agent version of the idle-agent cost problem, and it's why blended cost-to-serve, not per-call cost, is the only number worth trusting.

References

• The economic potential of generative AI: The next productivity frontier, McKinsey & Company
• Anthropic, Pricing
• OpenAI, API Pricing