Automating 90% of support tickets without losing the customer

Every support team wants to deflect more tickets, and every customer has been burned by a bot that deflected them straight into a wall. The gap between those experiences is where most automation quietly fails. At Vercel Ship London, Vercel shared how they automate up to 90% of their own support tickets: a figure that only means something once you understand what the remaining ten per cent looks like. The lesson is not “use an AI agent”; it is that high deflection and high satisfaction are the same problem solved well, not two goals in tension.

Grounded knowledge, not a model guessing

A general-purpose model is confident and articulate even when it is wrong, which is the worst possible trait for a support channel. The difference between an agent that helps and one that invents answers is almost all about grounding: it should answer from your real documentation, your changelog, and the patterns in your resolved ticket history, not from whatever it absorbed during training. That means retrieval over sources you control, answering from retrieved context rather than memory. When the material is not there, the right behaviour is to say so and escalate, not to fill the silence with a plausible guess. Past tickets matter most here: they capture the questions customers actually ask, and the answers that resolved them.

Agents that act, not just answer

A surprising share of support tickets are not questions at all. They are requests: refund this charge, reset this setting, resend the invoice, bump the plan limit. An agent that can only answer hands those back with instructions, which is not deflection but delay. An agent that can act resolves them outright. Giving it tools (issue a refund, change a setting, open a ticket, look up an order) is what moves deflection from a modest number to a meaningful one. But actions carry consequences, so each tool needs:

• Clear boundaries: a refund tool capped at an amount and scoped to eligible orders, with anything beyond it routed to a person.
• Confirmation and reversibility for anything touching money, access, or customer data.
• An audit trail, so every action is logged and reviewable like any other support interaction.

The hard 10% is a handoff, not a dead-end

No agent should resolve everything, and the ones that try are the ones customers hate. The remaining tickets (ambiguous, emotional, genuinely novel) belong with a human, and the experience depends on how cleanly the agent steps aside. That starts with a confidence threshold: when the agent is not sure it can help, detects frustration, or the request falls outside its remit, it should escalate rather than keep trying. The handoff must carry full context across (the conversation, what the agent attempted, the account details) so the person picking it up never asks the customer to start again. The cardinal sin is the loop: a customer rephrasing the same request into a bot that keeps offering the same unhelpful reply. A single, obvious route to a human at every step is what stops automation from feeling like a trap.

Measure deflection and CSAT together

Deflection rate is the easiest support metric to game and to misread. You can push it up overnight by making it hard to reach a human, and watch satisfaction collapse while the dashboard looks healthy. Optimising it alone backfires, because a “resolved” ticket and a customer who gave up look identical in the numbers. The two metrics have to move together: deflection tells you how much work the agent took off the queue, while CSAT tells you whether customers were helped while it did. If deflection climbs and CSAT slips, the agent is not resolving tickets: it is hiding them, and the cost surfaces later as churn.

A feedback loop that improves the product, not just the answers

A support agent should get better every week, and the raw material is in its own resolved conversations. Mining them shows where answers were thin, where the agent escalated unnecessarily, and which phrasings customers use that your knowledge base does not: gaps that feed back into better documentation and sharper retrieval.

The same data is one of the best product signals you have. A cluster of tickets about the same confusing step is not a support problem to deflect: it is a product problem to fix. Treating the transcripts as a read on where the product confuses people turns support automation from a cost centre into an early-warning system.

How Inteeka builds this

We approach support automation as a system, not a chatbot. We connect your knowledge sources (docs, changelog, resolved tickets) so answers are grounded in what is true. We build the agent with guardrails and real tools, so it can act on requests that are better resolved than explained, within boundaries you set. We instrument deflection and CSAT side by side from day one, and keep humans in the loop where it matters, with confidence thresholds and clean handoffs, so the hard ten per cent is genuinely handled rather than quietly dropped.

The bottom line

Automating most of your support volume is achievable, but the headline number is the easy part. What makes it work is grounded knowledge, an agent that can act, a confident handoff for the cases that need a person, honest measurement of deflection and satisfaction together, and a loop that keeps improving everything. Get those right and the ninety per cent takes care of itself, without losing the customer.