Drafting Support Replies With a Human Reviewer
Thursday, 14:05, at Northgate Retail. Leila is on the store-support desk and has ticket 7340 open. It is from Owen, the manager of the Harbor Street store: "Card terminal on till 3 freezes after every refund. Have to pull the power. Third time today." The assistant has drafted a reply. It thanks Owen and confirms the desk has seen the fault. It asks him to note the terminal's serial number. It explains that a freeze after refunds is usually the terminal's software and not the till. And it ends: "We will have a replacement terminal with you by tomorrow morning." Leila's cursor is on the send button when she reads the last sentence properly. Replacement terminals come from the payments provider, on a three-working-day turnaround. Nobody at the desk can make it tomorrow. The first five sentences were fine. The sixth was a promise, and it was the desk's promise the moment she pressed the button.
The draft, review, send loop is the discipline that keeps that button honest. The assistant writes a first version. A named person reads it against the facts, edits it or throws it away, and sends it under their own name. The edit rate is the share of drafts that needed a change before they went out. And it is the number that tells you whether the loop is still working or has quietly turned into draft, send. This article is part of our AI Assistants in Support series. It is about the loop, the reviewer's reading, and the two ways the loop fails. One is the reply that is fluent and wrong. The other is the desk whose voice drifts because nobody is editing any more.
It covers the loop step by step, with a picture, then what the reviewer reads for. Next come the fluent wrong reply and its three species, then tone drift. We cover the edit rate as the health signal and the number to read beside it. Then we look at which replies to draft and which to write by hand, and setting the loop up on a small desk. A short war story follows, then the reviewer's checklist to copy.
The Loop, Step by Step
The loop has six steps and the picture below shows them with the one line that matters marked in red. Inside the building sits the ticket, with its history, its notes and the requester's question. Only the problem crosses to where the assistant runs. The problem is stripped of anything that identifies a person or unlocks a system. What may and may not cross is the subject of Guardrails: What Leaves the Building. This article assumes you have read it or will. The assistant writes a draft, which is fluent and unverified. The draft comes back into an internal note on the ticket, unsent. A person reviews it for facts, promises and tone, and either edits it or discards it. What survives goes to the requester as a public reply with the reviewer's name on it. The side box records the edit rate, because the loop needs a gauge.
The step most desks skip is the fourth: the draft arrives as an internal note rather than as a reply waiting to be sent. The distinction matters because a note cannot leave the building by accident, and because it leaves a record. Most tools, QuerySolv among them, keep public replies and internal notes apart. The draft belongs on the note side until a person moves it across. When the sent reply differs from the note, the ticket itself shows the edit. When it does not, the ticket shows that too. That is where the edit rate comes from without anyone keeping a tally.
The reviewer is the sender. It is not a second person, not the lead, not a rota. The technician who will press the button reads the draft, because they are the one whose name goes on it. A separate reviewer sounds more rigorous and produces less review, since each person assumes the other read it carefully. (The reviewer is you. It was always going to be you.) The loop is one person, one draft, one reading, one decision, and the decision is theirs.
What the Reviewer Reads For
The reviewer reads for four things, in order of how much a mistake costs: facts, promises, tone and names. Facts are the sentences that depend on your environment or on the requester's situation. That includes the menu that exists, the service that is called that here, the step that works on this model of terminal. Each one is checked or deleted. The general argument for why a draft cannot know these is in What an AI Assistant Can and Cannot Do; the reviewer's version is shorter. Every verb that tells the requester to do something is a fact to check.
Promises are any sentence with a time, a date, a deadline or a commitment in it. "By tomorrow morning." "We will replace it." "This will not happen again." "I have escalated this." A draft produces promises because support replies contain them and it has read a great many support replies. It does not know your stock levels, your supplier's turnaround or your on-call rota. The reviewer either knows the promise can be kept or removes it. The honest form of a promise, and how to give one when you do not yet know the answer, is in Honest ETAs. The short rule is that a time in a reply is a time somebody has checked.
Read the last sentence. Then read it again. Yes, every time. Drafts put the commitment at the end, because that is where human writers put it, and the end is where a tired reviewer's attention has run out. The promise lives in the last sentence. It always has. Even before assistants, that was where we hid it.
Tone is whether the reply sounds like your desk. And names are whether it is addressed to the right person, uses their name correctly, and contains nothing from another ticket. The second sounds paranoid until a draft greets Owen as "Dear Olivia" because the previous ticket was Olivia's. Or it refers to "your laptop" on a ticket about a card terminal. Those are quick to catch and embarrassing to miss. Tone is slower, and it gets its own section below. A single reply with the wrong tone is a small problem. A desk whose tone has shifted is a large one.
The Reply That Is Fluent and Wrong
A fluent wrong reply is one that reads well, is structured well, is courteous, and contains at least one sentence that is false for this requester. It is the characteristic failure of drafting and it is dangerous precisely because it does not look like a failure. Technicians read each other's replies for years and learn that a confident, well-organised reply usually comes from someone who knew the answer. A draft is always confident and always well organised. The signal that used to mean "this person knows" now means nothing. The reviewer has to read as if it means nothing. That is harder than it sounds at ten past two with eleven tickets open.
There are three species. The first is the invented step: an instruction that would be sensible on some system and does not exist on yours. The tools menu that is not there, the setting that is on a different version, the "reconnect" option your terminal does not have. The second is the borrowed fact: a detail lifted from the general case or from another ticket. So the reply knows things about the requester's situation that nobody told it. "Since you are working from home" to a store manager on a till. The third is the unearned promise, which is the last-sentence problem above. It is a commitment that any support desk might make, offered on behalf of yours.
Reading for them is a matter of slowing down at two kinds of word. Verbs addressed to the requester, "open", "restart", "select", "wait", each carry a fact about the environment. Numbers and times, "three", "tomorrow", "within the hour", each carry a promise. Everything else in a reply is scaffolding and can be read at speed. A reviewer reads the verbs and the numbers slowly and the rest quickly. That takes about as long as reading the draft aloud, which is roughly the right length. A draft would like to be sent. It arrives looking finished, which is the most persuasive thing a piece of text can do. The reviewer's job is to be unpersuaded for forty seconds.
Tone Drift
Tone drift is the slow change in how a desk sounds when drafts are accepted as written, week after week. Eventually the desk's replies are the assistant's replies with names on them. It happens in two directions. The first is towards the generic. Every reply opens with the same two courteous sentences. Every paragraph is the same length, and every sign-off is the same. The requester notices, in the way one notices that the voice on the phone is reading. The second is towards the apologetic. Drafts tend to apologise early, often and for things that are not the desk's fault. Apology is a safe register for a writer who does not know the facts. A desk that lets that stand has, within a quarter, apologised for the weather.
Drift is a review failure before it is an assistant failure. A reviewer who is reading would change "we sincerely apologise for any inconvenience this may have caused" to "sorry about the till; that is a fault on our side". The second is how the desk talks. The fact that the first went out means nobody read it as a sentence. They read it as a reply, saw it was polite, and sent it. What your desk's voice is, how to write it down and how five people keep to one voice, belongs to Support Tone and Voice. A desk that has done that work has something to review against. A desk that has not will drift towards whatever the drafts sound like, because there is nothing else to drift towards.
The practical defence is to draft from your templates, not from nothing. A template written in the desk's voice, with the blanks the assistant fills, keeps the register anchored. The library of such templates is the subject of Templates and Canned Responses. Give the assistant the template and the facts and ask it to fill the blanks. And the drift problem largely goes, because the parts that carry tone were written by a person. Give it the ticket alone and ask for a reply. You have asked a stranger to speak for you, politely, forever.
One more defence costs nothing. Once a week, the lead picks five sent replies that were drafts. The lead reads one sentence of each aloud to the team, and asks "would any of us have written that?" If the answer is no three times out of five, the desk has drifted. The fix is a better template and a slower review. It is a two-minute exercise. It is also the only part of the week in which anyone hears the desk's voice from the outside. That is how the requester hears it all the time.
The Edit Rate as the Health Signal
The edit rate is edited drafts divided by drafts reviewed, over a week. If forty drafts were reviewed and twenty-nine were changed before sending, the edit rate is about seventy percent. The number itself matters less than its direction. And it is read against one other number: the reopen rate, meaning the share of tickets closed in the period that the requester reopened. Together they tell you whether the loop is doing its job. Apart, each one lies.
A rising edit rate means the drafts are getting worse or the desk's situation is getting less generic. Either way reviewers are catching it. That is the loop working, at a cost. If reviewers are rewriting most of a draft most of the time, drafting is costing more than it saves. The fix is a better template or no draft for that ticket type. A falling edit rate has two readings, and this is the trap. It may mean the drafts are getting better, usually because the desk started drafting from templates. Or it may mean reviewers have stopped reading. The two look identical in the edit rate and different in the reopen rate. The reopen rate rises when unread drafts go out, because unread drafts contain unearned promises and invented steps. Requesters reply to those.
Northgate's numbers, as a worked example. In the first week of drafting, 38 drafts were reviewed and 29 edited, an edit rate near three-quarters. The reopen rate for the month was where it had been for a year, around one ticket in twenty. By the sixth week, 41 drafts were reviewed and 3 edited, an edit rate of about seven percent. The reopen rate for that month had climbed to one in nine. The lead's first reading was that the assistant had learned the desk. Then the lead pulled the nine reopened tickets and found that seven had been unedited drafts. The second reading was that the desk had stopped reading. Both numbers were accurate. Only the pair was true.
Read the edit rate weekly and the reopen rate monthly, side by side. And treat an edit rate near zero as a warning rather than a trophy. If you run QuerySolv, the reopen rate is already among the standard reports. In most tools it is a filter on closed tickets. Either way it costs a minute to read. Where the two disagree, pull a sample of ten sent drafts and read them cold, as the requester did. The sample is the honest version of the number, and it takes a quarter of an hour.
Remember: the draft lives in an internal note until the sender has read every fact, every promise and the last sentence. An edit rate near zero is read beside the reopen rate before anyone calls it good news.
Which Replies to Draft and Which to Write
Not every reply should start as a draft, and the table sorts them by what a wrong sentence costs. Acknowledgments, requests for information and routine status updates are mostly scaffolding with one fact each. A reviewed draft saves time on them. Apologies, refusals, security instructions and the final close are mostly judgement. A draft of one of those gives the reviewer a fluent version of a decision they have not yet made. That is the wrong way round. The full argument for the second group, and the test that sorts a new case, is in What Not to Hand Over to an Assistant. The table is the working version.
| Reply type | Draft it? | What the reviewer checks hardest | Review depth |
|---|---|---|---|
| Acknowledgment of a new ticket | Yes, from the template | The requester's name; any time promised for the next update | Light: read it once, check the time |
| Request for more information | Yes | That each question is one the desk needs answered and has not already asked | Light to medium: read the history first |
| Status update on an open ticket | Yes, with the facts supplied | Every date, every "we have done", every "waiting on" | Medium: verify each claim against the ticket |
| Step-by-step fix instructions | Yes, if a knowledge article exists to draft from | Every step exists in this environment, in this order, on this device | Heavy: walk the steps or link the tested article instead |
| Explanation of a cause | Sometimes | That the cause stated is the cause found, not the common one | Heavy: compare with the technician's own notes |
| Apology for a desk mistake | No | Written by the person responsible, in their words | Not applicable |
| Refusal or saying no | No | The decision, the reason and the alternative are the desk's own | Not applicable |
| Security instruction (reset, revoke, isolate) | No | The action, the timing and the wording are owned by a named person | Not applicable |
| The final close | No | What was wrong, what was done, how to tell if it returns | Not applicable |
Two things about the table. "Review depth" is not permission to skim; light review still reads the whole reply and the last sentence twice. And "no" is not a verdict on the tools. It is a verdict on where the hard part of the reply is. In an apology, the hard part is meaning it. In a refusal, the hard part is the decision. In a close, the hard part is knowing it is fixed. A draft offers none of those, and a reviewer who edits a drafted apology into a sincere one has written the apology, slower.
Setting It Up on a Small Desk
Start with one reply type and one template. Acknowledgments are the usual choice. Take your acknowledgment template and give it to the assistant with the ticket's subject and the time of the next update. Have the draft land as an internal note. For the first two weeks, every draft is read by its sender and one other person. Two readers are not the long-term design. But two people arguing about a draft is how a desk learns what it edits. Write down the edits. By the end of the fortnight you will have a list of the five things the drafts get wrong on your desk. The reviewer's checklist below is adjusted to match.
Give the assistant an instruction line, not just the ticket. "Draft an acknowledgment from the template; the next update is at 16:00; do not promise a fix time" produces a better draft than the ticket alone. The discipline of writing the line makes the technician decide what the reply is for before anything is drafted. That is the part of writing that was always worth doing. The instruction line also keeps the facts flowing in the right direction: the technician supplies them, the assistant arranges them. The moment a draft contains a fact the technician did not supply, that fact is suspect by definition.
Then widen slowly. Add requests for information in week three, status updates in week five, fix instructions only when there is a tested knowledge article to draft from. Keep the edit rate on a whiteboard, by week, next to the reopen rate by month. A desk that can see both numbers reads its drafts. A desk that cannot sees only that replies are going out faster, which they are. It will not find out what else is going out until the requesters tell it.
A Short War Story: The Promised Laptop at Stonebridge Insurance
At Stonebridge Insurance, a technician called Ahmed had been reviewing assistant drafts for about six weeks. Then, on a Monday with a backlog of forty tickets, he began accepting the status-update drafts without reading them. That was because the previous forty had needed no changes. One of the unread drafts went to a claims handler called Beth whose laptop had failed. It read "a replacement laptop will be with you by the end of today". The assistant had produced that sentence because status updates often contain one. The desk's loan stock was empty and procurement's lead time was ten working days. Beth told her team. Four of them raised tickets asking for the same next-day replacement. The claims manager scheduled a meeting about why the desk made promises it could not keep. The desk lead spent two days reading six weeks of sent drafts and found eleven more promises nobody had made. Three were already broken. The edit rate for the previous fortnight had been two percent, and it had been on the whiteboard the whole time. The desk had read it as the assistant having learned the job. A draft that is never edited is a draft that is never read, and the number had been saying so for two weeks.
The Reviewer's Checklist
The checklist is read against the draft before it becomes a reply, in the order shown. It should take about as long as reading the reply aloud. The first block is the one that catches the fluent wrong reply; the second catches the promise. The third is tone and names; the last line is the record that feeds the edit rate. Pin it beside the screen for the first month. After that most reviewers run it from memory, and the ones who do not are the ones the weekly sample finds.
REVIEWER'S CHECKLIST — BEFORE A DRAFT BECOMES A REPLY Ticket: ________ Reply type: ______________ Drafted from template: [ ] yes [ ] no 1. FACTS: every verb addressed to the requester is checked [ ] Each step exists on the requester's device, version and setup [ ] Each menu, service, setting or option named is one we have here [ ] The cause stated is the cause we found, not the common one [ ] No detail appears that the ticket or the technician did not supply [ ] Nothing contradicts the ticket history or the last note 2. PROMISES: every time, date, number and commitment is checked [ ] Each time or date is one a person has confirmed can be met [ ] "We will", "I have" and "this will not" sentences are true now [ ] No replacement, refund, escalation or fix is promised that is not arranged [ ] The last sentence has been read twice 3. TONE AND NAMES [ ] Addressed to the right requester, name spelled as they spell it [ ] Nothing from another ticket or another person [ ] Sounds like this desk; apologises only for what is ours [ ] Says what happens next and when the requester will next hear from us 4. DECISION [ ] Send as edited [ ] Discard and write by hand Edited before sending: [ ] yes [ ] no Reviewer: ______________ Reason for edit, one line (for the weekly tally): ______________________
Leila deleted the sixth sentence and replaced it with two of her own: "Replacement terminals come from the payments provider and usually take three working days; I will confirm the date with you by 16:00 today." Owen replied with the serial number and a thank-you, and the terminal arrived on the Tuesday as the provider had said. Five sentences of the draft were sent unchanged. The review took her a little under a minute. The ticket shows the note beside the reply, one promise shorter. That is the loop working: the assistant wrote the scaffolding, and the person wrote the promise. And the name on the reply was the name of the one who had read it.
Frequently Asked Questions
Should the reviewer be a different person from the sender?
How long should reviewing a draft take?
What is a good edit rate?
Can simple acknowledgments go out without a review?
The drafts apologise constantly. How do we stop that?
How do we record edits without adding paperwork?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.