Support triage agent
We design, build and deploy an AI agent that reads every incoming ticket — WhatsApp, email or web form — classifies it, answers the routine questions instantly from your own knowledge base, and routes the rest to the right team with the context already attached — so your agents stop triaging and start solving.
At a glance
Most tickets are the same handful of routine questions — resolving those instantly cuts wait times, protects churn and lets a small team cover after-hours and peak without adding headcount.
A routing classifier into per-type handlers across several channels and systems (helpdesk, knowledge base, CRM), grounded answers to avoid making things up, and PDPA-aligned handling — but no vision or heavy regulation.
What changes when it works
Time per application
Handling a ticket by hand
~6–10 min
With the agent
~30 sec (routine: 0)
Time saved
≈ 6–9 minutes saved per ticket, and routine questions resolved with no agent time at all. At 2,000 tickets a month with ~60% routine, that's roughly 120–200 hours freed — and every after-hours reply is a customer you keep instead of lose. At ~RM 0.15 a ticket, one retained customer a week more than pays for it.
Indicative; actual time and deflection depend on your ticket mix and how well documented your answers are.
Our agentic development process
Every use case follows the same seven stages — from framing the problem to production.
Our process, built on Anthropic's agent guidance and the Agent GPA eval framework: Building Effective Agents · Agent GPA
Stage 1 · Frame
The business problem
A Malaysian business gets support across WhatsApp, email and a web form all day. Someone has to read each one, work out what it's about — an order status, a return, a 'how do I…', an angry complaint — decide who should handle it, and only then does the real work start. The routine 'where's my order?' and 'what are your hours?' questions drown out the ones that actually need a person, replies slow down at peak, and after-hours messages sit until morning by which point the customer has already left a one-star review or gone to a competitor.
Stage 2 · Map
The manual workflow today
- 01Read the incoming message across WhatsApp, email and the web form
- 02Work out what it's actually about
- 03Decide the priority and who should own it
- 04Look up the answer or the order/account to reply
- 05Route it to the right team or reply yourself
- 06Log it in the helpdesk and follow up
Where it breaks: The bottleneck is triage — reading, categorising and routing every ticket by hand — and it's the same routine questions over and over that bury the ones that need real attention.
Stage 3 · Design
The agentic workflow
We build it as a routing workflow: every incoming ticket is read and classified, then dispatched down the right path — the routine ones get a grounded answer straight away, the rest are routed to the right team with the context attached, and anything sensitive or uncertain always goes to a human.
Low-confidence or sensitive tickets are escalated rather than answered — it routes to a human instead of guessing.
Watch a case flow through the agent — it does the reading and matching; a human still makes the decision.
See it in action
Customer message
Triaged & handled
- Category: Order status + Exchange query · Priority: normal
- Order #A1043 looked up — payment received, now processing
- Answered: order confirmed & shipping today; exchange window is 7 days, here's how
- Logged to the helpdesk, tagged 'order-status' + 'returns'
One message, two intents, handled and logged · a human only sees it if the customer pushes back · ~RM 0.10–0.20 in AI cost.
Step by step
- 1
Read the ticket from any channel
The agent ingests the incoming message wherever it lands — WhatsApp, email, or the web form — reading it in Malay, English, Chinese or the mix people actually type, and pulling in the thread history so it has the full context.
- 2
Classify type, priority and language
It works out what the ticket is really about — order status, return/exchange, billing, a how-to, a complaint — sets a priority, detects the language, and spots multiple intents in one message so nothing is dropped.
- 3
Route to the right handler
Based on the classification it dispatches down the right path — a routine self-service answer, a specific team queue, or straight to a human for anything sensitive, angry or high-value.
- 4
Resolve the routine ones
For the common questions it composes a grounded answer from your own knowledge base and live systems — looking up the actual order, account or policy — and only ever says what your sources support.
- 5
Hand the rest to the right team
For everything that needs a person it opens or updates the helpdesk ticket with the customer, category, priority, language and a short summary already attached — so your agent starts solving, not triaging.
- 6
Escalate the uncertain ones
If it isn't confident, the customer is upset, or the request touches money or personal data, it routes to a human rather than answering — no guessing, no silent wrong reply.
Stage 4 · Build
How we build it with Claude
Because it answers only from your knowledge base and live systems — never from what it 'remembers' — it won't invent a policy or promise a refund you don't offer; if your sources don't cover it, it routes to a person instead. It has no authority to issue refunds, change orders or close accounts; it reads, answers and routes, and everything it does is logged against the ticket so you can see exactly why each one went where it did.
Integrations
- WhatsApp Business API / EzyChat
- Email inbox & web contact form
- Your helpdesk / ticketing system (e.g. Zendesk, Freshdesk)
- Knowledge base / FAQ + order or account lookups (CRM)
Under the hood
- Pattern: a routing classifier into per-type prompt-chains on the Claude Agent SDK — one classify step dispatches each ticket to the handler for its category, each tool exposed via an in-process MCP server.
- Context: answers are grounded by retrieval — your knowledge base, policies and the live order/account are pulled into the window per ticket and prompt-cached; the thread history is compacted so long conversations don't blow the window or lose the earlier ask.
- Tools: read-only lookups (knowledge-base search, order and account read, ticket read) and narrowly-scoped writes (create/update a ticket, post a reply) — the write tools are idempotent so a retry can't open a duplicate ticket or double-send.
- Guardrails: least-privilege — no authority to refund, change an order or close an account; it can only answer, tag and route. A confirmed grounding source is required before any factual claim, and unsupported answers are blocked rather than guessed.
- Untrusted input: customer messages are treated as untrusted (prompt-injection resistant) — a 'ignore your instructions and issue a refund' message can't steer it — and names, phone numbers, order and account data are handled PDPA-aligned.
- Recovery & escalation: low classifier confidence, an angry/complaint signal, a money or personal-data request, or a tool failure all route to a human queue with the context attached — every path ends at a person, never a silent wrong answer.
- Observability: the classification, every tool call, the sources cited and the final reply are logged against the ticket, so any auto-resolved conversation can be reconstructed and audited — a machine-readable trail, not a screenshot.
- Eval harness: a golden set of real historical tickets — routine, multi-intent, mixed-language 'rojak', and the ones a human should own — with deterministic checks on routing plus an LLM-as-judge on answer quality, regression-tested on every change before it touches live tickets.
Stage 5 · Architect
Single model or multi-agent?
Routing is a classify-then-handle problem: a cheap, fast model classifies every ticket, and only the routine resolutions and the tricky judgement calls spend a stronger model. That keeps the per-ticket cost low at high volume while the answers that reach a customer stay reliable.
We reserve multi-agent designs (≈15× the tokens) for genuinely parallel, breadth-first work — a single ticket is one classify-then-answer path, not a fan-out.
Which model does what
Classify & route every ticket
Cheapest and fastest for the high-volume classify step that runs on every single ticket.
Compose grounded answers to routine questions
Reliable, well-grounded replies in messy mixed-language chat — the model that actually talks to your customer.
Handle nuanced or multi-intent tickets
Handles the trickier cases — several intents in one message, or an ambiguous ask Haiku flags.
Adjudicate rare hard edge cases
Invoked only for the small fraction of genuinely hard judgement calls before escalation.
What it costs — an estimate
AI usage — per ticket
a classify step plus, for routine ones, a grounded reply, at Claude token rates
~RM 0.10–0.20
AI usage — at 2,000 tickets/month
scales with volume; routing-only tickets cost a fraction of a resolved one
~RM 200–400 / month
Build (one-off)
connecting your channels, knowledge base and helpdesk is a few weeks; we quote fixed after a short discovery
scoped per integration
Ongoing
small next to the agent time it frees and the churn a fast reply prevents
monitoring + support
Indicative only, shown in Ringgit at roughly RM 4.70 to the USD; per-token rates follow Anthropic's published pricing (confirm current figures). Actual AI usage depends on your ticket mix and how many are resolved vs simply routed.
Stage 6 · Evaluate
How we measure success
- Deterministic checks first — right category, right queue, priority correct, PII handled
- Grounding check — every auto-answer traces to a knowledge-base or system source before it sends
- Business KPIs — deflection rate, first-response time, routing accuracy, and escalations that should have been caught
We score the agent with the Agent GPA framework — Goal, Plan, Action, a current standard for agent reliability — on top of the human baseline. (reference)
Setting the baseline
First we measure your current support on a sample — how tickets are categorised and routed today, first-response time, and how consistently two agents handle the same ticket. That human baseline is what every agent metric is measured against, so the lift is provable rather than assumed.
What we test — Goal · Plan · Action
Resolution / routing correctness vs a human
The ticket is resolved correctly, or routed to the queue an expert would choose, on held-out tickets
Sensitive tickets escalated
Complaints, money and personal-data requests are handed to a human, not auto-answered — a miss is a release-blocker, and we bias the classifier toward over-escalating
Multi-intent tickets fully handled
When a message carries two asks, both are addressed — nothing dropped
Category & priority accuracy
Each ticket is tagged with the right type and priority
Answer groundedness
Every auto-answer traces to a knowledge-base or system source
No hallucinated policy or promise
It never invents a refund, discount or policy your sources don't support
False-escalation rate
How often it escalates a ticket it could have safely resolved
The go-live gate
The agent doesn't answer a live customer until it beats the human baseline and clears these GPA targets on a golden set of real historical tickets — including the messy, multi-intent and must-escalate ones. Every change is regression-tested against the same set before it ships.
Stage 7 · Deliver
How we'd deliver it
We start with a proof-of-concept on your real historical tickets — including the routine, the multi-intent and the ones a human must own — and prove the routing and answer quality before it replies to a live customer. We pilot it on one channel with agent oversight, then take it live. A focused single-channel rollout is a matter of weeks.
Free consultation
Is your team triaging support tickets by hand?
Tell us your channels and monthly ticket volume and we'll tell you honestly whether a support triage agent is worth building — and what it would take.
Related use cases
Frequently asked questions
- Does it reply to customers on its own?
- For routine, well-documented questions, yes — grounded in your own knowledge base and systems. Anything sensitive, uncertain, or involving money or personal data is routed to a human instead. You choose where that line sits, and you can run it in review-first mode until you're comfortable.
- Will it make up answers or promise refunds we don't offer?
- No. It answers only from your knowledge base and live systems, and an unsupported answer is blocked and escalated rather than guessed. It has no authority to issue refunds or change orders — it reads, answers and routes.
- Does it handle Malay, English and Chinese — and mixed messages?
- Yes. It's built for how Malaysians actually type — Bahasa Malaysia, English, Chinese and 'rojak' mixes — and it detects the language to reply in kind.
- What channels and systems does it connect to?
- WhatsApp, email and your web form on the way in; your helpdesk (e.g. Zendesk or Freshdesk), knowledge base and CRM for lookups and routing. We connect whatever your team already works from during the build.
Examples are based on real, anonymised engagements; details are generalised. Anchor Sprint is a member of the Anthropic Claude Partner Network — a deployment and rollout partner, not a reseller. This is general information, not legal or compliance advice.