AI customer support bot cost per ticket: the real math

Quick answer: cents per ticket, usually fractions of a cent.

A support-bot ticket is a short conversation: a few model calls, each carrying your system prompt, some retrieved help-center content, and the chat so far. Price that honestly and a typical resolved ticket lands between a tenth of a cent and four cents depending on the model tier. It is one of the cheapest line items in a SaaS P&L, and also one of the easiest to let quietly grow tenfold. The cost is almost entirely input tokens. Your instructions and knowledge-base chunks get re-sent on every turn, while the bot's actual replies stay short. On a normal ticket the input-to-output ratio runs around 13 to 1, which is why the input price column matters far more than the output column when you pick a model for support. If you operate a subscription product, three numbers govern this line item: the token budget of one ticket, which model tier handles which ticket type, and the share of tickets the bot resolves without a human. The rest of this page puts real numbers on each, then works the result into per-user COGS so you can see exactly what the bot does to margin.

Where the money goes on one ticket.

A resolved ticket typically takes about three bot turns: the user describes the problem, the bot asks one clarifying question or runs a lookup, then delivers the fix. With the overhead above, each turn averages around 4,000 input tokens, growing slightly as history accumulates. That structure explains the two facts operators keep re-learning. First, the same bot costs wildly different amounts on different tickets, because a one-turn FAQ hit and a seven-turn billing dispute differ by an order of magnitude in tokens. Second, prompt and retrieval discipline is worth more than model shopping: cutting retrieval from ten chunks to three saves more than switching between two adjacent model tiers.

• System prompt and tool definitions: roughly 1,500 tokens of instructions, policies, and tone rules, re-sent on every turn of every ticket.
• Retrieved help-center chunks: about 2,000 to 3,000 tokens per turn with a disciplined top-3 retrieval; a lazy top-10 setup triples this overnight.
• Conversation history: each turn re-sends everything before it, so turn three carries turns one and two as billable input.
• Tool calls: an order lookup or subscription check adds a hidden model round trip, with the full context billed again.
• Output: short structured replies keep completions near 300 tokens per turn; an uncapped max_tokens on a chatty model can double the whole ticket.

Worked example: a thousand tickets, model by model.

Take a reference ticket of three turns. Each turn carries the 1,500-token system prompt, about 2,500 tokens of retrieved documentation, and the growing history, averaging 4,000 input tokens per turn, with 300 output tokens per reply. Total: 12,000 input tokens and 900 output tokens per resolved ticket. The table prices that ticket across the catalog, from budget to flagship. Now fold it into unit economics. Say your product charges $19 per user per month and users file 0.5 tickets a month on average. On deepseek-v4-pro the bot adds 0.5 times $0.0054, about $0.003 per user per month, roughly 0.014% of revenue. Even running everything on claude-sonnet-4-6 costs about $0.02 per user per month, around 0.1% of revenue. The model bill is a rounding error next to what the bot displaces: every ticket a human does not touch. That is why deflection rate, not token price, is the number your margin actually depends on, and why the goal of cost work is keeping this line item boring while deflection climbs.

Why the bill still surprises people.

None of these show up in a demo with five test tickets. All of them show up at volume, usually as a bill that is three to ten times the estimate while the average ticket still looks normal. The fix is unglamorous: meter tokens per ticket from the first week, alert on outliers, and treat a 40,000-token ticket as a bug to investigate, not noise to absorb.

• Retrieval bloat: raising top-k "to be safe" is the single most common mistake; it multiplies the biggest cost component on every turn of every ticket.
• History creep: hard tickets run long, and input grows with every turn, so your worst conversations cost the most per turn precisely when they drag.
• Free-tier abuse: an open chat widget gets used as a free general-purpose assistant, and homework questions bill exactly like support questions.
• Silent retries: a timeout followed by a retry bills the full context twice, and naive retry loops can triple a ticket without anyone noticing.
• Agent loops: a tool-using bot that keeps re-calling the same lookup burns a full context window on every attempt.
• Verbose defaults: no max_tokens cap plus a model that likes to elaborate quietly doubles output spend across the whole queue.

Build on the API, buy per-resolution, or keep it human?

There are three ways to staff a support queue, and they bill in fundamentally different shapes. Helpdesk AI add-ons typically charge a flat vendor-set fee per resolved conversation or per seat, regardless of how few tokens the resolution consumed. A bot you run on a metered API bills raw tokens, cents per ticket at worst, plus the engineering time to own retrieval quality and escalation logic. Human-only support scales linearly with headcount; approximate, commonly cited industry estimates put a human-handled ticket in the dollars, varying widely by region and complexity. The spread between raw token cost and per-resolution fees is the margin you keep by building. At a few cents per bot-resolved ticket, a vendor fee near a dollar per resolution implies you are paying mostly for the vendor's packaging, not the model. That trade can still be rational when you have no engineering capacity to spare, but it should be a decision you price, not a default you inherit from your helpdesk suite.

How to cut cost per ticket without cutting resolution rate.

The routing and unit-price levers compound. One gateway option is APIsRouter, an OpenAI-compatible API with pay-as-you-go billing and no subscription: global models are priced 20% below official list, Chinese models sit below their official rates, the first top-up adds +100% balance, and the checkout at /topup takes payment first and emails the key without a signup step. The ladder below shows what tier routing does to the blended number using the same 12,000-input, 900-output reference ticket.

• Cap retrieval at three reranked chunks. Reranking a wider candidate set and sending only the best three beats dumping ten raw chunks on quality and on cost.
• Keep the system prompt lean. Every policy paragraph is re-billed on every turn of every ticket in the queue.
• Cap max_tokens around 400 and instruct short answers. Support replies are not essays, and users resolve faster with tight ones.
• Route by ticket tier. FAQ lookups do not need the model that handles churn-risk escalations; most queues are 70% easy tickets.
• Cap bot turns. After four turns without resolution, escalate to a human; long loops burn tokens and goodwill simultaneously.
• Gate the widget. Require login for bot access on free tiers, rate-limit per user, and set budget alerts per API key.
• Lower the unit price itself by routing through a cheaper OpenAI-compatible endpoint, keeping the same models and the same code.

Meter cost per ticket from day one.

You cannot manage a number you never compute. Every OpenAI-compatible response returns a usage object with exact prompt and completion token counts, so per-ticket cost is one multiplication away. Tag every model call with the ticket ID, store the cost next to the ticket, and your outlier alerts, tier-routing decisions, and COGS reporting all fall out of one table. The snippet below routes by tier, prices each call from the catalog rates, and logs cost against the ticket. Verify the endpoint and key with a one-off curl before wiring it into the queue:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.apisrouter.com/v1",
    api_key="sk-APIsRouter-...",
)

# USD per 1M tokens: (input, output)
PRICES = {
    "deepseek-v4-flash": (0.126, 0.252),
    "claude-haiku-4-5": (0.80, 4.00),
    "claude-sonnet-4-6": (2.40, 12.00),
}

TIER_MODEL = {
    "faq": "deepseek-v4-flash",
    "account": "claude-haiku-4-5",
    "complex": "claude-sonnet-4-6",
}

def answer_ticket(ticket_id: str, tier: str, messages: list[dict]) -> str:
    model = TIER_MODEL[tier]
    resp = client.chat.completions.create(
        model=model,
        messages=messages,
        max_tokens=400,
    )
    p_in, p_out = PRICES[model]
    usage = resp.usage
    cost = usage.prompt_tokens / 1e6 * p_in + usage.completion_tokens / 1e6 * p_out
    record_ticket_cost(ticket_id, model, usage.prompt_tokens, usage.completion_tokens, cost)
    return resp.choices[0].message.content

FAQ