AI Support Agents: From FAQ Bot to Chatbots That Resolve Tickets

Why deflection-rate bots disappoint

The first generation of support bots was a search box with a personality. It matched the question to an FAQ article and pasted a summary. That works for questions with one written answer, such as opening hours or return windows, and those are rarely the tickets that cost money. The expensive tickets are about a specific order, a specific booking or a specific charge, and a bot that cannot see the customer's account can only point them at a policy page.

Deflection rewards exactly that behaviour. A bot that answers every message with a confident article and hides the contact option will post an excellent deflection rate while the same customers return through email, social media and the phone line, now angrier. In ticket data this shows up as repeat contacts on the same issue within a few days, and it is the first number we pull when auditing an existing bot.

The shift we recommend is from deflection to resolution: did the customer's problem end in this conversation, without a repeat contact and without a human redoing the work. It is harder to measure and harder to achieve, and it is the only number the finance and support leads will still believe a quarter later. It also changes what you build: an agent aiming for resolution needs access to systems, permissions and a way out, not just a bigger knowledge base.

From answering to acting: agents with tools

A resolving agent is a language model with a small set of typed tools it is allowed to call: get_order, get_shipment_status, list_available_slots, reschedule_booking, create_refund_request, update_address. Each tool is a thin wrapper over an existing internal API, with a JSON schema that describes its inputs precisely. The model decides which tool to call and with what arguments; your code decides whether the call is allowed and executes it.

Most of the engineering effort sits in those wrappers, not in the prompt. Internal APIs were built for staff screens and often return forty fields when the agent needs five, expose internal status codes customers should never see, or require three calls where one would do. We build a support-facing facade that returns small, customer-safe payloads with plain-language status values, which makes the model's answers more accurate and keeps sensitive fields out of the context window entirely.

Start with read tools. Order lookups, delivery tracking and appointment details typically cover a large share of contact volume, carry little risk and immediately make the bot useful. Write tools come later, one at a time, each with its own limits and its own evaluation set. Resist the temptation to expose a generic tool that runs arbitrary queries or calls any endpoint; narrow tools are easier to test, easier to audit and far harder to misuse.

• Separate read tools from write tools in code, so a write can never be reached through a tool that was registered as read-only.
• Return customer-safe fields only; strip internal notes, margins, fraud scores and staff names in the facade, not in the prompt.
• Make every write tool idempotent with a request key, so a retried or duplicated call cannot issue two refunds.
• Give every tool a timeout and a typed error the model can explain, such as courier tracking currently unavailable, rather than a stack trace.

Permissions, confirmation steps and guardrails

The agent should act with the customer's permissions, never with a service account that can see every order. After the customer is verified, through a logged-in session, an OTP to the registered mobile number or a signed link from an email, the backend issues a short-lived token scoped to that customer, and every tool call carries it. If the model is manipulated into asking for someone else's order, the API refuses, because authorisation lives in the API and not in the instructions.

That matters because prompt injection in support is not theoretical. Customers paste text from emails, screenshots get transcribed, and some people will simply type an instruction telling the bot to approve a full refund. Policy limits belong in code: refund ceilings per order and per day, eligible reasons, allowed date ranges for rebooking. The model can propose; a deterministic policy check approves or rejects.

Every write action needs an explicit confirmation step. The agent states what it is about to do in plain terms, for example a refund of the stated amount to the original card for one damaged item, and waits for a clear yes. Ambiguous replies such as ok I guess are treated as a no and clarified. The confirmed summary, the tool call and the result are written to an audit log, so a disputed refund can be traced to exactly what the customer agreed to.

• Authorise in the API layer with a customer-scoped token; never rely on the prompt to keep data separate.
• Enforce monetary and frequency limits in a policy service the model cannot override.
• Require an explicit confirmation turn before any write, and log the exact summary the customer agreed to.
• Keep a per-tool kill switch so a misbehaving action can be disabled in minutes without taking the whole bot down.

Handing off to a human without starting over

Every agent will meet conversations it should not handle: an angry customer on a third contact, a legal threat, a medical or financial hardship, a case that falls outside policy. The rule we use is simple. A customer who asks for a person gets a path to a person within one turn, and the bot proactively offers one when sentiment drops, when the same intent fails twice, or when a policy check rejects the request.

The handoff itself is where most bots throw away their value. If the human agent opens a blank ticket and asks for the order number again, the customer has wasted their time twice. The agent should create the ticket in the helpdesk with a structured summary: verified identity, intent, order or booking references, what was checked, what was attempted, which tool failed or which policy blocked it, and the customer's stated preference.

Route by intent and language to the right queue, and be honest about waiting times. Outside staffed hours, say when someone will reply and confirm the channel they will use, then make sure the ticket actually lands there. Finally, feed handoffs back into the backlog: every escalation reason is either a missing tool, a missing policy, a model failure or a case that should always go to a person, and each of those has a different fix.

Multilingual support, including Indian languages and Hinglish

For Indian customer bases, English-only support leaves a large share of customers behind, and the reality of chat is messier than a language list suggests. People write Hindi in Latin script, switch between English and Hindi mid-sentence, use Tamil or Marathi on WhatsApp, and mix product names, numbers and local abbreviations. A message like order abhi tak nahi aaya, tracking bhi update nahi ho raha is completely normal and has to be understood first time.

Current frontier models handle code-mixed and romanised text far better than older intent classifiers, but quality is uneven across languages and drops on domain vocabulary. We build a test set from real transcripts in each language the business supports, including romanised and code-mixed messages, and measure intent accuracy and tool-argument accuracy per language rather than trusting a single average. Product names, city names and local abbreviations deserve their own test cases, because they are where errors cluster.

Reply in the language and script the customer used unless they ask otherwise, keep identifiers such as order numbers and amounts unchanged, and route to human agents who speak that language when escalating. Policy wording needs more care than casual replies: for refund terms, warranty conditions and legal text, keep human-reviewed versions in each supported language and have the agent quote them rather than translate or paraphrase on the fly.

Measuring resolution, CSAT and cost per conversation

Define resolution precisely before launch. Our default is a conversation where the intent was completed or correctly answered, with no human touch and no repeat contact on the same issue within seven days. Track it per intent, because a blended figure hides the fact that order tracking may be near-perfect while refunds are failing badly. Agree the definition with the support and finance leads in advance, so nobody can redefine success after the launch numbers arrive.

Containment is still worth tracking, but pair it with the signals that reveal trapped users: requests for a human that were not honoured, conversations abandoned mid-flow, and repeat contacts. Measure CSAT separately for fully automated and escalated conversations, and read a sample of low-scoring transcripts every week; the numbers say where, and the transcripts say why. Automated LLM grading of transcripts is useful for scale, but calibrate it against human reviewers before you trust it.

Cost per conversation is model tokens plus tool and infrastructure costs plus the human minutes spent on escalations, divided by conversations. Compare it with the fully loaded cost of a human-handled ticket for the same intent, not the average across all tickets. Long system prompts, verbose tool payloads and needless retries are the usual reasons it runs high. Prompt caching for the fixed instructions and routing simple intents to a smaller model usually bring it down without hurting quality.

• Resolution rate per intent, with repeat contacts within seven days counted as failures.
• Escalation rate, split into customer-requested and agent-initiated, plus the share of human requests honoured within one turn.
• CSAT for automated and escalated conversations reported separately.
• Cost per resolved conversation, compared with the human cost for the same intent.
• Tool error rate and policy rejections, which point to API or rule problems rather than model problems.

A rollout plan that earns trust

Pick three to five intents with high volume, clear policy and clean APIs, such as order status, delivery address change before dispatch and appointment rescheduling. Build an evaluation set from a few hundred real historical conversations per intent and replay it against the agent before any customer sees it. Include the awkward cases on purpose: partial shipments, expired payment methods, customers with two accounts, and messages that try to talk the agent out of policy.

Then run in shadow mode: the agent reads live tickets and drafts a response and tool plan, and human agents use, edit or discard it. Their edits are the best training signal you will get. When drafts are accepted without changes most of the time, switch the read-only intents to autonomous, then enable write tools one at a time with low limits that rise as the data supports it. Keep a weekly review of failures with the support team leads; they will spot problems long before a dashboard does.

• Weeks 1 to 2: intent analysis of historical tickets, API audit and an evaluation set for the first intents.
• Weeks 3 to 5: tool facade, guardrails, helpdesk handoff and shadow mode on live traffic.
• Weeks 6 to 8: autonomous read intents, then write tools with conservative limits and per-tool kill switches.
• After launch: add intents and languages one at a time, each with its own evaluation set and release gate.

How we would approach this

We would start with your ticket data rather than a demo. A week of intent analysis tells us which conversations are worth automating, which internal APIs need a support-facing facade, and where policy needs to be written down before a model can follow it. From there, Next-Gen AI Chatbots covers the conversational agent and channels such as web chat and WhatsApp, API Integration & Development covers the tool facade and helpdesk connections, and AI Automation & Workflow Orchestration covers the back-office steps a resolved conversation triggers.

If you want a rough sense of timeline and team size first, our Budget Calculator gives an estimate in a couple of minutes. For anything more specific, a scoping call with a sample of anonymised tickets is the fastest way to a realistic plan. We will tell you plainly which intents are worth automating now and which should stay with your team.