The Support Copilot: Drafted Replies, Summaries & Suggested Triage
Three buttons on a ticket: draft a reply, summarise the thread, suggest the triage. None of them changes anything. That constraint is not timidity — it is the design, and it is what makes the feature safe enough to hand to a new agent on their first week.
The honest use case for AI on a support desk is not answering your customers. It is the twenty minutes a day your agents spend on the mechanical parts of answering: re-reading a thread they inherited, finding a courteous way to say something awkward, and deciding which of your fourteen categories a request belongs to. None of that is judgement. All of it is friction.
So the copilot on our tickets does three things and refuses to do a fourth. It drafts a reply, it summarises a thread, and it suggests a triage. It does not send, save, assign, close or notify anybody — and it never will, because the whole reason a support desk can adopt this in a week is that pressing the button cannot produce a consequence.
The constraint that makes it usable
Every one of the three actions returns its result to the screen and nothing else. The suggestion is flashed to your session, rendered once, and gone on the next page load. Nothing is written to the ticket. Nothing is persisted anywhere.
That has a real cost, which we will come to. It also has three consequences worth stating in order, because together they are the entire risk assessment.
- A drafted reply cannot reach a customer. It appears in your reply box for you to edit; you press send, so a wrong draft is a wasted thirty seconds rather than an incident.
- A suggested triage cannot change a ticket's routing or its SLA. It shows you a category, a department, a priority and one sentence of reasoning; you save them, or you do not.
- A summary cannot overwrite anything, because there is nowhere for it to go. It is a paragraph for the person reading it.
The safest AI feature is one where the worst possible output costs an agent half a minute.
Why suggest-only is a design decision, not a limitation
Two gates sit in front of all three buttons. The copilot is only offered if a language-model provider is enabled on the deployment and the agent holds the specific permission for it — so a desk can grant it to its senior agents and not to its interns, and a deployment with no provider simply does not render the controls. There is no half-configured state where a button exists and fails.
What each button is actually asked to do
The prompts are short and unromantic, and knowing them tells you exactly where the feature will help and where it will disappoint.
What the prompts do well
- Draft a reply is told to write as a professional, empathetic support agent, concisely, and explicitly not to invent facts, prices or commitments. No subject line, no placeholder brackets, just the reply body.
- Summarise is told to write two to three sentences for an agent taking the ticket over: the request, what has happened so far, what is needed next. That is precisely the handover paragraph nobody writes.
- Suggest triage is given your own category and department names, and the four allowed priorities, and asked for one small JSON object with a one-sentence reason.
- All three receive only this ticket: its subject, its priority, its description and its thread. Nothing about your other customers or your other tickets.
What no prompt can fix
- It does not know your product, your prices, your stock or your policies. It has this one thread and nothing else, so it can phrase an answer and cannot find one.
- It has not read your previous tickets, so it cannot tell you "we fixed this last March by replacing the regulator".
- It has no knowledge base to draw on. There is no article library wired into the drafting prompt.
- It will happily write a fluent, courteous, entirely content-free reply if the thread contains no facts. Fluency is not the same as usefulness, and this is where it will waste your time.
That right-hand column is the point most vendors blur. A drafted reply is a rewriting tool, not an answering tool. Give it a thread where an agent has already established the facts internally and it will produce a good customer-facing paragraph in two seconds. Give it a thread that contains only a complaint and it will produce a beautifully worded acknowledgement that commits to nothing — which is occasionally what you want, and is never a resolution.
The triage round trip, including what gets thrown away
Triage is the most interesting of the three, because it is the only one where the model is asked for structured output — and structured output from a language model has to be treated as untrusted input, which is exactly how it is treated.
A model reply, and what survives validation
priority: "critical" — not one of the four allowed values Discarded category_id: 7 — exists in this organization's categories Accepted department_id: 91 — not an id in this organization Discarded reason — 400 characters of explanation Truncated to 240 Illustrative of the mechanism, which is exact. Two things to notice. The ids are checked against your category and department lists, so a hallucinated id cannot be shown to you, let alone saved — the model is treated as a suggestion engine whose output is filtered, not as an authority. And a partial result is shown as a partial result: one accepted field is offered on its own rather than being padded out with plausible defaults.
Before you accept a category on an old ticket, read this
Saving a category is what computes a ticket's SLA targets, and they are anchored to when the ticket was created — not to when you categorised it. So accepting a triage suggestion on a ticket that has been sitting uncategorised for three days, where that category promises a four-hour resolution, instantly puts the ticket into breach. This is correct behaviour: the promise was always four hours and you took three days. But it is a surprise the first time, and it means a bulk clean-up of old uncategorised tickets will make your breach count jump. Do that deliberately, on a day you can explain the number.
Which button, when
If you have inherited a long thread
Summarise first, always
This is the highest-value action in the set and the least used. Two or three sentences of "here is the request, here is what has happened, here is what is needed" saves reading twelve comments, and because it includes internal notes it tells you what colleagues concluded as well as what the customer said.
If you know the answer and are struggling to word it
Draft the reply
The right use. You establish the facts, the copilot handles the courtesy, you edit and send. Particularly useful for the awkward replies — a refusal, a delay, an apology — where the difference between a good and a bad wording is a complaint.
If you do not yet know the answer
Do not draft the reply
It will write something courteous and empty, and the temptation to send it is real because it reads well. An acknowledgement is a legitimate first response, but write that yourself in one line rather than dressing up an absence of information in three paragraphs.
If a queue of uncategorised tickets has built up
Suggest triage, one at a time, and read the reason
The one-sentence reason is the useful part — it tells you whether the suggestion understood the request or matched on a keyword. Mind the SLA anchoring above before you work through a backlog.
If the thread contains a credential, an ID number or medical detail
Use none of them
Drafting and summarising send the whole thread, internal notes included, to a provider outside Kenya. That is fine for most support conversations and not fine for some. The inventory is in what leaves your server.
Using a drafted reply without embarrassing yourself
Six checks, which become instinct after a week
- Delete any commitment you did not make. The prompt forbids inventing prices and promises, and it mostly complies. Mostly is not a control — you are the control.
- Check every number and every date. If a figure appears in the draft that is not in the thread, it came from nowhere and must go.
- Check the name and the greeting. The model is told not to use placeholder brackets, and it is not told your customer's name, because names are not sent. Add it yourself.
- Check the language. If your customer wrote in Swahili or in a mix, the reply may come back in English. There is no language setting; you are the translator.
- Cut it by a third. Drafted replies are consistently a little too long and a little too warm for a Kenyan business context. Shorter reads as more competent.
- Never paste a draft into an internal note thinking it is safe. It is a reply; put it where replies go, and if it is not ready, do not post it at all.
Questions worth asking about any support copilot
Four questions, and what the answers reveal
Can the AI send a reply to a customer without a human pressing send?
What you will hear
"You can configure auto-response."
How to read it
The moment the answer is yes, your risk assessment changes completely — you are now liable for text nobody read. Ours cannot, at all, by construction. If theirs can, ask what stops a hallucinated commitment reaching a customer at 2am.
What does the drafting prompt actually have access to?
What you will hear
"It uses your knowledge base and ticket history."
How to read it
If true, that is genuinely more capable than ours — and it means far more of your data is crossing a boundary on every draft. Ask for the payload. Both answers are defensible; only one of them can be true.
Are the AI's suggestions stored, so I can audit them later?
What you will hear
"They're in the ticket history."
How to read it
Ask to see one. Ours are not stored and we say so below — which means neither we nor you can measure whether its triage suggestions were any good. A vendor who stores them has a better answer here, and a bigger retention question.
What happens when the provider is down or over quota?
What you will hear
"It retries."
How to read it
You want the desk to carry on working. Ours reports unavailable and the agent does the job manually, which is the correct degradation. Watch for anything that queues, blocks a page, or leaves a half-written reply in a box.
What we do and do not do
What AWRA OpsHub does today
- Three suggest-only actions on a ticket: draft a reply, summarise the thread, suggest triage. None of them writes to a record, sends anything, or notifies anybody.
- A dedicated permission, so the copilot can be granted to some agents and withheld from others, plus a hard requirement that a provider is enabled — no half-configured button that fails when pressed.
- A drafting prompt explicitly instructed not to invent facts, prices or commitments, and not to emit placeholder brackets or a subject line.
- Triage output treated as untrusted input: ids validated against your own category and department lists, priority validated against the allowed set, the reason truncated, and a fully invalid response reported as no suggestion rather than a guess.
- JSON extraction that tolerates code fences and surrounding prose, so a chatty model does not break the feature.
- A queue narrative and a transparent risk ranking on the support AI hub, both described in numbers first, words second.
- Fail-soft everywhere: no provider, a timeout or unparseable output produce a plain "unavailable" message and the agent carries on manually.
What it does not do
- No suggestion history. Results are flashed to the screen and gone on the next page load. Nothing records what the AI proposed, so there is no audit trail and no way to measure whether its triage was ever right.
- No one-click apply. An accepted triage suggestion is retyped into the fields and saved by hand. Deliberate, and mildly annoying at volume.
- No knowledge base or ticket history in the drafting prompt. It sees this thread only, which is why it can phrase an answer and cannot find one.
- No canned responses or reply templates anywhere in the module, so there is no deterministic alternative to a generated draft for your six most common questions.
- No control over tone, length, signature or language. The prompt is fixed, and there is no Swahili or bilingual setting.
- No usage visibility or per-agent rate limiting — nothing shows how often the copilot was used, by whom, or what it cost.
- No AI on the customer-facing side at all: no suggested articles at intake, no automatic acknowledgement, no deflection. Intake is entirely human-to-human by design.
The gap we would close first is suggestion history, because it is the one that compounds: with no record of what was suggested, nobody can ever answer "is the triage suggestion good enough to trust?", and that question is the difference between a toy and a tool. A small template library would be worth more than any of it for a desk answering the same six questions all day — say so if that is you.
Our take
Adopt this for summarising inherited threads and for wording difficult replies, and be sceptical of it as a way to answer questions — it has your thread and nothing else, so eloquence is the only thing it can add. The design constraint is the feature: because nothing it produces can reach a customer or change a ticket, you can hand it to a new agent on day one and the worst outcome is a wasted half minute. Give it to your senior agents first, watch what they actually use it for, and expect the honest answer to be the summarise button. That is the one that saves real time, and it is the one nobody demos.
Read alongside this: what leaves your server gives the exact payload each button sends, the internal note explains why drafts and summaries include your internal thread, numbers first, words second covers the queue narrative and the risk ranking, and routing and escalation explains what a category actually changes when you accept a triage suggestion.
A copilot that cannot send anything
Draft, summarise and triage on any ticket — permissioned, suggest-only, validated against your own categories, and nothing reaches a customer until an agent presses send.
See the AI assistantsFrequently asked questions
Can the copilot reply to a customer on its own?
No, and there is no setting that would allow it. All three actions return their result to the agent's screen and write nothing — the drafted reply appears for editing, and an agent presses send. This is the reason the feature is safe to roll out quickly: the worst possible output is a bad paragraph that costs somebody thirty seconds. If you are evaluating another product, this is the first question to ask, because a copilot that can auto-respond puts you on the hook for text no human read.
Does the AI know our prices, policies or previous tickets?
No. Each action receives one ticket: its subject, priority, description and comment thread. There is no knowledge base wired into the prompt, no access to your other tickets, and no product or price data. This is the most important limitation to internalise, because it changes what the tool is for — it can phrase an answer you already know, and it cannot find an answer you do not. Given a thread with no facts in it, it will write a fluent and completely empty reply, which reads well enough to be a trap.
Are internal notes included when we ask for a draft?
Yes, for the drafted reply and the summary — deliberately, because a draft written blind to the internal discussion repeats questions the team has already answered among themselves. The triage suggestion uses public comments only. Nothing is sent in the background: all three require an agent to press a button. If your internal notes routinely contain material you would not transfer outside Kenya, either restrict the permission or change what goes in your notes.
What stops the AI from inventing a category or a department?
Validation, not trust. The suggested ids are checked against your organization's own category and department lists and discarded if they do not exist, the priority is checked against the four allowed values, and the reason is truncated. If every field fails, the feature reports that it could not suggest a triage rather than showing you a guess. The model's answer is treated as untrusted input arriving over the wire, which is the correct posture for any structured output from a language model.
Why did accepting a triage suggestion put our ticket into breach?
Because a category is what gives a ticket its SLA targets, and those targets are anchored to when the ticket was created rather than when you categorised it. A ticket that sat uncategorised for three days, then received a category promising four-hour resolution, is immediately past that target. The behaviour is correct — the promise was always four hours — but it means clearing a backlog of uncategorised tickets will make your breach count jump on the day you do it. Do it deliberately and be ready to explain the number.
Can we see a history of what the AI suggested?
No, and this is the gap we would close first. Each result is flashed to the screen and gone on the next page load; nothing is stored. The consequence is that neither you nor we can answer the question that matters — were the triage suggestions actually right? — and without that, adopting it more widely is a matter of feel rather than evidence. If you would use this at volume, tell us, because recording the suggestions is the change that makes the feature measurable.
Will it reply in Swahili if our customer writes in Swahili?
Sometimes, and you cannot rely on it. There is no language setting: the prompt is fixed English and the model takes its cue from the thread, so a message written in Swahili or in a mix may come back in either language. Treat the draft as raw material and translate it yourself. A configurable prompt with a language choice is a small piece of work and a fair request if your desk is genuinely bilingual, which most Kenyan desks are.
