Use case · Customer support
Answer the repetitive tickets. Hand the rest over with context.
An assistant on your chat and messaging channels answers the questions your help centre already covers, cites the article it used, and stops at a line you draw. Anything past that line becomes a helpdesk ticket with the transcript, the intent and what the customer has already been told.
At a glance
- What it takes on
- Answer from your help centre
- Classify every message
- Check identity before account answers
- Collect what the agent will need
- Connects to
- Your helpdesk, via its API
- Help centre and policy documents
- Order or account system, read-only
- Chat channels
- Model provider on your account
- Review log
- Typical rollout
- Week 1 → Weeks 5–6See the plan
The problem
Where the work gets stuck today
Most support queues mix two kinds of work. A large share of messages ask things your team has answered hundreds of times: where an order is, how to reset a password, what the return window is. The rest need judgement: a dispute, an angry customer, a case the policy never imagined. Agents spend the day retyping answers to the first kind while the second kind waits behind them.
A generic chatbot usually makes this worse in two ways. It answers things it should not touch, such as refunds or legal threats, and it hands off badly, so the customer explains everything again to the person who picks up the ticket.
- Agents paste the same help-centre answer many times a day, with small differences each time.
- First replies to urgent tickets wait behind easy ones in the same queue.
- Policy answers drift between agents and shifts, so customers hear different rules.
- Handoffs lose the conversation, and customers repeat their order number and story.
Deflection only pays off when the assistant knows where to stop. We design the never-answer list first and the answer list second.
Task catalog
What the system takes on
Task 01
Answer from your help centre
Questions covered by a published article or policy get a short answer that cites the source, so the customer and your team can check it.
Task 02
Classify every message
Each message gets an intent and a queue. A single message with two intents is split, so the easy half is answered and the hard half is routed.
Task 03
Check identity before account answers
Order and account questions are answered only after the customer is matched by sign-in, order email or a one-time code.
Task 04
Collect what the agent will need
Before a handoff the assistant asks for the order reference, photos or account email your team always asks for, so the ticket starts complete.
Task 05
Open the handoff ticket
Tickets land in the right helpdesk queue with the transcript, the detected intent, the sources tried and the reason for the handoff.
Task 06
Report the gaps
Unanswered questions and low-rated replies are grouped into a weekly gap report, so the fix is a help-centre article rather than a prompt tweak.
Step trace
One run, step by step
- 00:00PLANIntakeIntake › Web chat message: the blender jar arrived cracked, and the card was charged twice for the order.
- 00:01TOOLClassifierClassifier › Two intents found. Damaged item: in scope. Duplicate charge: billing, on the never-answer list.
- 00:01OKIdentity checkIdentity check › Order matched to the email the customer signed in with. Order details may be used in the reply.
- 00:02TOOLRetrieverRetriever › Help centre searched: "Damaged on arrival" article and the returns policy section on photo evidence.
- 00:03OKAnswererAnswerer › Reply drafted for the damaged item: replacement or refund, photo needed. Both sources cited.
- 00:03OKGrounding checkGrounding check › Each sentence maps to a cited passage and the answer clears the threshold for this intent. Sent.
- 00:04NOTEPolicy gatePolicy gate › Billing intent is not answered by the assistant. Refunds and charge disputes stay with people.
- 00:04HANDOFFRouterRouter › Helpdesk ticket opened in the Billing queue with transcript, order reference and what the customer was already told.
- 00:05DONEAssistantAssistant › Customer told a billing specialist will reply in this thread, and given the ticket reference.
Read the trace as text (Sample data)
- 00:00IntakeStepWeb chat message: the blender jar arrived cracked, and the card was charged twice for the order.
- 00:01ClassifierStepTwo intents found. Damaged item: in scope. Duplicate charge: billing, on the never-answer list.
- 00:01Identity checkDoneOrder matched to the email the customer signed in with. Order details may be used in the reply.
- 00:02RetrieverStepHelp centre searched: "Damaged on arrival" article and the returns policy section on photo evidence.
- 00:03AnswererDoneReply drafted for the damaged item: replacement or refund, photo needed. Both sources cited.
- 00:03Grounding checkDoneEach sentence maps to a cited passage and the answer clears the threshold for this intent. Sent.
- 00:04Policy gateCheckBilling intent is not answered by the assistant. Refunds and charge disputes stay with people.
- 00:04RouterApprovalHelpdesk ticket opened in the Billing queue with transcript, order reference and what the customer was already told.
- 00:05AssistantDoneCustomer told a billing specialist will reply in this thread, and given the ticket reference.
Where the line sits
Move the threshold, watch the queue change
Higher sends more messages to people. Lower answers more automatically.
Answered with citations4
- Order statusconfidence 0.93
“Where is my order? It said it would ship on Monday.”
- Return windowconfidence 0.88
“Can I still return shoes I bought three weeks ago?”
- Password resetconfidence 0.81
“The reset email never arrives.”
- Damaged itemconfidence 0.77
“My jar arrived cracked, what do I do?”
Handed to a person4
- Size adviceconfidence 0.68
“Is the medium closer to a UK 10 or 12?”
- Bulk orderconfidence 0.56
“Can you do forty units with our logo for an event?”
- Charge disputeNever-answer list: always a person
“I was charged twice and want the money back today.”
- ComplaintNever-answer list: always a person
“This is the third time and I am contacting my lawyer.”
Systems involved
What it connects to
- Your helpdesk, via its API
- System of record for conversations. The assistant opens and tags tickets in your existing queues; agents keep working where they work today.
- Help centre and policy documents
- The only source of answers. Indexed with their version dates and re-indexed when an article changes.
- Order or account system, read-only
- Order status and account facts, looked up only after the identity check, never written to.
- Chat channels
- Your website widget and the WhatsApp Business Platform, with the same rules and the same handoff on both.
- Model provider on your account
- OpenAI, Anthropic Claude or Google Gemini for classification and answer drafting, chosen per task and billed to you at cost.
- Review log
- Transcripts, citations, confidence and handoff reasons, kept for the weekly review and masked for personal data.
Guardrails
- The never-answer list is checked in code before any model call: refunds, charge disputes, legal threats, safety issues and account closures always go to a person.
- Answers come only from retrieved passages. When nothing relevant is found, the assistant says it will pass the question on instead of guessing.
- Confidence thresholds are set per intent and tested on your own past tickets before launch, then reviewed after the first weeks of traffic.
- Order and account answers require an identity match first; without one the assistant gives the general policy only.
- Typing “agent” or “human” hands the conversation over at once, at any point.
- The assistant says it is an AI assistant in its first message, and personal data is masked in the logs it keeps.
Human checkpoint
Every conversation the assistant does not fully resolve becomes a ticket in the right queue, with the transcript, the detected intent, the passages it used and what it already told the customer. Agents own refunds, disputes and anything on the never-answer list. Each week a support lead reviews a sample of answered conversations plus every one the customer rated down; corrections become help-centre edits, so the fix reaches every future answer.
What we plan for
Typical targets
Typical target
40–60%
of eligible repetitive intents answered without an agent
Basis: Counted from the intent mix in your own ticket export during discovery, for questions your knowledge base or written policy answers; re-measured after the first month live.
Typical target
All of them, by design
of never-answer test messages routed to a person
Basis: The never-answer list runs in code before the model, and is tested before each release with deliberately reworded refund, dispute and complaint messages.
Typical target
None the assistant already collected
Details customers repeat after a handoff
Basis: The handoff ticket schema requires the transcript, intent and collected fields; agents see them on open, checked in acceptance testing with your team.
Rollout
Week by week
Week 1
Export of recent tickets, intent analysis, the never-answer list agreed with your support lead, help-centre gaps listed.
Week 2
Help centre indexed with version dates; answer and handoff flows; the helpdesk ticket fields and queues mapped.
Week 3
Evaluation on held-out past tickets, thresholds tuned per intent, walkthrough with the agents who will receive handoffs.
Week 4
Soft launch on one channel or part of the traffic, with a daily transcript review.
Weeks 5–6
Further channels, the weekly review rhythm, and help-centre fixes from the first gap report.
FAQ
Frequently asked questions
Which support tickets should an AI assistant never answer?
Anything where a wrong answer costs money, safety or trust: refunds, charge disputes, legal threats, medical or safety questions, account closures and complaints. We write that list with your support lead in week one and enforce it in code before the model sees the message, so a cleverly worded request cannot talk its way past it.
What does our agent see when a chat is handed over?
A ticket in your existing helpdesk queue with the full transcript, the detected intent, the reason for the handoff, the customer match, the sources the assistant used and exactly what it already told the customer. The agent can reply in the same thread without asking for the order number again.
How do you estimate deflection before anything is built?
From your own ticket export. We classify a sample of recent tickets by intent, mark which intents have a written answer in your help centre, and count them. That gives a planning range and a list of articles worth writing first. We do not quote a deflection number without that exercise.
Does this replace our helpdesk software?
No. The assistant works through your helpdesk’s API: it opens tickets, tags them and puts them in your existing queues. Your team keeps its views, macros and reporting. If a helpdesk has no usable API, we fall back to its email-to-ticket address with structured fields.
How will we know when the assistant gave a wrong answer?
Every answer is logged with the passages it cited and its confidence. Customers can rate a reply, and the weekly review covers a sample of answered chats plus every low-rated one. Because answers are cited, a wrong one usually traces back to an outdated article, which you fix once.
Do we need a tidy help centre before we start?
It helps, but it is not a precondition. The intents the assistant can answer are limited to ones with a written answer, so week one lists the gaps. We can draft missing articles from your resolved tickets for your team to approve before they go live.
Can customers still reach a person straight away?
Yes. Typing “agent” or “human” hands over at any point. Outside your support hours the assistant opens the ticket, tells the customer when your team is back, and answers what it safely can in the meantime.
Next step
Have a workflow in mind? Let’s scope it together.
Book a free 30-minute strategy call. Bring one process you want to automate and we will talk through scope, integrations and a sensible first step.
Free 30-minute call · no commitment