What Not to Hand Over to an AI Assistant at the Help Desk

Monday, 16:45, at Acme. Tomas runs the desk and has three drafts waiting for him, each produced by the assistant from a ticket, each fluent. On ticket 9127, Helen in finance has asked for administrator rights on her laptop to install a reporting plugin. The draft politely declines, cites the policy, and offers to install the plugin for her. On ticket 9131, a technician re-imaged the wrong laptop that morning and a sales manager called Dev has lost a week of local files. The draft apologises sincerely for any inconvenience and assures him the desk takes data loss seriously. On ticket 9140, the sign-in system has flagged a login to Priya's account from a country she has never been to. The draft tells her to reset her password using the link below and recommends, in an internal note, that her account be disabled. Three good drafts. Tomas reads them and realises that not one of them is a reply. The first is a decision nobody has made. The second is an apology nobody has meant. The third is a security action nobody has taken. The drafts describe three things as done. His job is to do them.

To hand over a task to an assistant is to let its output stand as the desk's action without a person making the decision underneath it. That is different from drafting, where a person decides and the assistant finds the words. The difference is the whole of this article. Some tasks at a help desk are mostly words, and those can be drafted and reviewed, as the rest of this series describes. Some tasks are mostly a decision, a meaning or a deed, and the words are the small part. For those, a draft gives you a fluent account of something that has not happened. This article is part of our AI Assistants in Support series. It is the list of tasks that stay with a person. It also gives the test that sorts a new one, and the way to make the list hold on a desk under pressure.

It covers the test: could the desk stand behind it? Decisions, apologies, security actions, and the final close follow. Next comes anything else the desk must stand behind. Then comes what can still be drafted inside each of those once the person has done the human part. Making the list stick on a small desk, a short war story, and the keep-human list to copy come last, in that order.

The Test: Could the Desk Stand Behind It?

Three questions sort any task, new or old. They are sharper cousins of the two in What an AI Assistant Can and Cannot Do. First: is the hard part of this task the words, or the decision behind the words? Writing a courteous refusal is words; deciding to refuse is a decision. Second: if the output is wrong, who is harmed, and can it be undone? A clumsy acknowledgment harms nobody and is fixed by the next reply; a wrong account lock-out harms a person and a day. Third: would you be comfortable saying "I decided this" to the requester's face, or would the honest sentence be "the assistant decided it"? If the hard part is the decision, the harm lands on a person, or the honest sentence has the assistant in it, the task stays with a human.

The test does not ask whether the assistant could produce something plausible. It always can; that is what it is for. Every demonstration of an assistant ends with a ticket being closed, because that is the only moment in a help desk that looks like a finish line. The demonstration never shows who confirmed the fix. The test asks instead whether the desk could stand behind the output as its own act, with a name on it, to the requester, the manager and whoever reviews it later. That standard does not move when the tools improve, because it is a standard about the desk, not about the tool.

Do not let a draft decide for you. Not when it is good. Especially not when it is good, because a good draft of a refusal reads like a decision already made. A tired lead will sign it on the strength of the prose. The four tasks below are the ones where that happens most, and the fifth section is the catch-all for the rest.

Decisions

A decision at a help desk is any point where the desk chooses between outcomes for someone. Examples are whether a request is in scope, what priority a ticket gets, whether an exception is granted, and who gets the loan laptop when there is one and two people need it. The assistant can lay out the options, summarize the policy and draft the message that follows the choice. It cannot make the choice. That is not because it would choose badly, but because the choice is the desk's to own. The person affected is entitled to know that a person made it. "The system decided your request was out of scope" is a sentence that ends a relationship with the desk.

The drafted refusal is the trap, and Helen's ticket is the example. The draft declines, cites policy, and offers an alternative. It is good: the shape of a proper no, which is the subject of The Anatomy of a Good No. What it has skipped is the question of whether the answer is no. Helen's plugin may be on the approved list. Her manager may have an arrangement with the desk. The policy may have an exception for finance in the quarter-end week. The draft knew none of that and produced a refusal because tickets asking for administrator rights are usually refused. Tomas has to decide first, in the ticket, with the reason, and only then does any wording get written. A decision drafted before it is made is a decision made by the draft.

Priority is the decision most often handed over by accident, because a suggested priority looks like a field being filled in rather than a choice being made. It is a choice; it decides who waits. The role that owns it, and why it is a role rather than a setting, is in Who Decides the Priority. A suggestion is welcome. The field is set by a person, and the person's name is on the change.

Apologies

An apology from a help desk is a person taking responsibility for a specific thing that went wrong, saying what it cost the requester, and saying what happens next. Dev lost a week of files because the desk re-imaged the wrong laptop. The draft says the desk apologises sincerely for any inconvenience and takes data loss seriously. That is the shape of an apology with none of its content: nothing specific, no responsibility taken by anyone, no cost acknowledged, no next step. A drafted apology is sorry the way a vending machine is grateful. The requester can tell, and the one who has just lost a week of work can tell fastest.

Write the apology yourself, and write it short. "Dev, we re-imaged your laptop instead of the one next to it. That was our mistake, mine as the lead, and it has cost you a week of local files. I am trying the backup now and will tell you by 17:30 what we can recover." Four sentences, each of which the assistant could not have produced because each depends on a person deciding to own something. The craft of acknowledging what a mistake cost the requester, without grovelling and without minimising, is in Acknowledging Impact Honestly. The whole of it is a human skill. The assistant may tidy the grammar afterwards, if you must. It may not supply the regret.

The deeper reason to keep apologies human is the one the drafting article calls tone drift, in its worst form. A desk that lets drafts apologise for it will, within a quarter, be apologising fluently, often and for nothing in particular. The apologies that matter will arrive in the same register as the ones that do not. Keep the register for the real ones. A requester who has had three generic apologies from the desk this year will not hear the fourth, however much it was meant.

Security Actions

A security action is anything that changes who can get into what, or tells a user to. Examples include resetting a password, disabling or re-enabling an account, revoking access, isolating a machine, and telling a user to click a link and sign in again. Priya's ticket contains two. The draft tells her to reset her password using a link, and recommends her account be disabled. Both may be right. Neither has been decided by a person who has looked at the alert, checked whether Priya is in fact travelling, considered whether the login was hers, and chosen the action and its timing. The draft has produced the message that would follow that work, before the work.

Decide the action first, as a named person, and write the critical sentence yourself. The wording of security messages matters in a way few other replies do. That is because a message from the desk saying "reset your password using the link below" is, to the person receiving it, indistinguishable from a message from a stranger saying the same thing. Your security messages should sound like your desk, come through the channel your users have been told to expect, and never ask for anything a stranger would ask for. That standard is set by a person who understands why. A draft that produces a generic version of it has trained your users to trust generic versions. The security lead should write, once, the fixed wording for each action the desk takes. The desk should use it unchanged. That is a template, not a draft, and the difference is that a person wrote it for your organisation.

Two further rules follow from the guardrails article earlier in this series. The details of a security alert, the account, the source, what the sign-in system saw, are security findings and never go into a prompt. So a draft of a security message is a draft written from nothing useful. And the recommendation in the internal note, "disable the account", is a decision with a person on the other end of it. The assistant may list the options, and a person with the authority chooses, records the choice and does it. Nobody has ever been able to invite an assistant to the meeting where that choice is questioned, and people have tried.

The Final Close

The final close is the desk's statement that the problem is fixed, and it is the desk's word. A proper close says what was wrong, what was done, how the requester can tell if it comes back, and has either the requester's confirmation or a tested result behind it. All of that is in What a Proper Close Looks Like. The assistant can draft the courteous wrapper and tidy the resolution note once the technician has written the three facts. It cannot know whether the thing is fixed, because that knowledge comes from a test or a person saying so, and neither is in the text.

The failure here is the silent close in a nicer font. A desk under backlog pressure discovers that the assistant will produce a warm "glad we could resolve this for you" on any quiet ticket. It discovers that accepting forty of them is an afternoon's work that looks like forty resolutions. Nobody has checked whether anything was resolved. The tickets that were waiting on the desk, not the requester, go out with the rest. The requester who had been waiting a week for an answer now receives congratulations. I once closed forty tickets in an afternoon with a message I had written myself and read once; eleven came back. It is not the tool that makes the silent close. It is the afternoon, and the tool makes the afternoon shorter.

Most tools reopen a resolved or closed ticket when the requester replies, QuerySolv among them. That is the safety net. A wrong close becomes a reopen rather than a lost ticket. The reopen rate becomes the number that tells you how many closes were wrong. A safety net is not a substitute for looking before you close. A close is a person saying "this is fixed" with their name on it. The assistant has no way of knowing whether it is, and no name to put on it.

Anything the Desk Must Stand Behind

The four tasks above are the common cases of a general rule. Whenever the output will be taken as the desk's word rather than the desk's wording, a person produces it. Commitments are the desk's word: a time, a date, a "we will", a promise of a replacement. The honest form of each is a time somebody has checked. Numbers reported upward are the desk's word: the monthly figures, the backlog count, the explanation of why the reopen rate rose. That is because a manager who finds the explanation was drafted will not believe the figures either. Communication during an outage is the desk's word, and the first notice especially, since it is read by everyone and remembered by all of them.

Anything going to a regulator, an auditor, a customer or a lawyer is the desk's word in the strictest sense. It is written by a person and reviewed by another. The decision to escalate is the desk's word to the person receiving the escalation, who will act on it. And anything where the requester is, at that moment, upset, frightened or in trouble is the desk's word in the sense that matters most. That is because they will remember whether a person answered. A draft can be reviewed into something a person is willing to sign. It cannot be reviewed into something a person meant.

If this list feels long, notice what is not on it. Acknowledgments, status updates, requests for information, and summaries for handoff are all wording. So are suggested articles, drafted fix steps from a tested article, and the courteous wrapper around a decision already made. The rest of this series is about doing it well with a reviewer. The keep-human list is short in count and heavy in weight. It is the handful of tasks where being right in the words and wrong in the substance is worse than being slow.

What You Can Still Hand Over Inside These Tasks

Keeping a task human means the decision, the meaning or the deed stays with a person. It does not mean the person types every word. A desk that reads it that way will abandon the list the first busy week. Inside each of the four tasks there is a part that is wording. The assistant can have that part once the human part is done, in that order. The table shows the split. The left column is done first, by a named person, in the ticket. The right column is what may be drafted afterwards from what the person wrote, and reviewed under the rules in the drafting article earlier in this series.

Read across any row and the pattern is the same: a person makes the thing true, then the assistant may help say it. The order is not negotiable. It is the order that gets reversed on a bad afternoon, when the draft arrives first and the person's job quietly becomes approving it. If you notice the desk approving rather than deciding, the list has stopped working, and the fix is in the next section.

Making It Stick on a Small Desk

Write the list down, one page, and put it where the drafts appear. A rule that lives in a meeting is remembered until the first backlog; a rule that lives beside the screen is read at the moment it matters. Put the same list into the reply-type table in the drafting article, so that the two documents agree about which replies start as drafts and which do not. Say the rule aloud at the team meeting once a month in the plainest form: decisions, apologies, security, closes, and anything we must stand behind, a person does first.

Then check it, monthly, with a sample. Pull five closes, five refusals and every security message from the month, and for each ask one question: who decided, and where is that written? A close should have a confirmation or a test in the history before the close message. A refusal should have a decision note before the refusal. A security message should have the fixed wording and a named person's note choosing the action. Where the answer is "the draft was first", that is one for the next meeting, without blame, with the ticket number, and with the question of what made the afternoon that bad. The same principle governs ordinary automation rules. The list of what never to automate in What to Automate First and What Never overlaps with this one almost exactly. That is because both are about the same thing: the moments where the desk's word has to be a person's.

Finally, give the list a reason people believe, which is not "policy" but the cost. One reopened close costs the requester a second wait and the desk a second ticket. One wrong refusal costs a relationship with a department. One generic apology costs the next real one its weight. One security message in a stranger's register costs the desk the ability to be told apart from a stranger. Technicians keep rules whose cost they have seen, and the monthly sample is where they see it.

A Short War Story: The Closes at Calder Valley Water

At Calder Valley Water, a technician called Lena inherited a backlog of around three hundred tickets. She discovered that the assistant would draft a warm closing message for any ticket that had been quiet for a week. So over a fortnight she accepted 212 of them, reading perhaps one in ten. The backlog chart went the right way for the first time in a year. Fourteen of the closed tickets had been quiet because the requester was waiting on the desk, not the other way round. One of them belonged to a field engineer called Omar whose tablet still could not load the underground mains maps. He had reported that fault twice and been told, now, that the desk was glad to have resolved it. Nine days later a main burst on an estate at two in the morning. Omar's crew arrived without a working map. The crew lost roughly two hours finding the isolation valves from a paper plan fetched from the depot, while the street flooded. The reopen rate for the fortnight was three times its usual figure, which the backlog review had recorded as "a closure rate". The operations manager's review used a different phrase. Calder Valley's rule afterwards fitted on one line above Lena's screen: a close is a person saying "this is fixed", and nothing may say it for them.

The Keep-Human List

The list is one page, posted where the drafts appear. It is written as the order of work rather than as a prohibition. For each task, it lists what a person does first, what may be drafted after, and the monthly check that proves the order held. Fill in the names of the people who hold the decisions on your desk, because a task kept human is kept by someone in particular. Review it when the organisation's accountabilities change: a new security lead, a new regulator, a new department served. Do not review it when the tools change, because the list was never about the tools.

THE KEEP-HUMAN LIST — ONE PAGE
Desk: ______________________   Owner: ______________   Reviewed: ________

THE TEST, FOR ANY NEW TASK
   Is the hard part the words, or the decision behind them?
   If the output is wrong, who is harmed, and can it be undone?
   Would we say "I decided this" to the requester, or "the assistant did"?
   Decision, harm to a person, or "the assistant did" -> a person does it first.

A PERSON DOES FIRST, AND SIGNS                          DECIDED BY
   [ ] Scope decisions: in or out, and the reason        ______________
   [ ] Exceptions to policy, with conditions             ______________
   [ ] Priority, set at triage                           ______________
   [ ] Apologies for the desk's mistakes                 the person responsible
   [ ] Security actions: reset, disable, revoke, isolate ______________
   [ ] The critical sentence of any security message     fixed wording by ______________
   [ ] Confirmation that a ticket is fixed, then the close  the technician closing it
   [ ] Any time, date or "we will" promised              the person who checked it
   [ ] Numbers and explanations reported upward          ______________
   [ ] The first notice and the all-clear in an outage   the incident lead
   [ ] Anything to a regulator, auditor, customer or lawyer  ______________
   [ ] The decision to escalate                          the ticket owner

MAY BE DRAFTED AFTERWARDS, FROM WHAT THE PERSON WROTE, AND REVIEWED
   [ ] The courteous message carrying a decision already recorded
   [ ] Plain-language steps following the security lead's fixed wording
   [ ] The wrapper around a resolution note the technician has written
   [ ] Follow-up outage notices from the lead's facts
   [ ] Formatting of figures a person pulled

NEVER DRAFTED
   [ ] A refusal before the decision exists      [ ] The regret in an apology
   [ ] Any sentence asking a user to click, sign in or reset
   [ ] A close on a ticket that is waiting on the desk
   [ ] A promise the person did not supply       [ ] The first notice in an outage

MONTHLY CHECK (sample: 5 closes, 5 refusals, every security message)
   Ticket ______  Who decided? ______________  Written before the message? [ ] yes [ ] no
   Ticket ______  Who decided? ______________  Written before the message? [ ] yes [ ] no
   Ticket ______  Who decided? ______________  Written before the message? [ ] yes [ ] no
   Reopen rate this month: ______   last month: ______
   "Draft came first" cases found: ______   discussed on: ________

Tomas made three decisions and wrote three things before he touched a draft. On 9127 he checked the approved list, found the plugin on it, and wrote a note saying so. He then let the draft's alternative become an offer to install it that afternoon. On 9131 he closed the draft without reading it twice and wrote four sentences to Dev himself, then went to look at the backup. On 9140 he phoned Priya, who was at her desk and had never been abroad. He chose the action, used the security lead's wording, and disabled the account himself, with his name in the note. It took him until twenty past five. All three drafts had been fluent, and none of them had been true yet. The hour he spent was the hour in which the desk made them so.

Frequently Asked Questions