What an AI Assistant Can and Cannot Do at a Help Desk

Tuesday, 09:40, at Meridian Parts. Dana has been on the desk for three weeks. She has just opened ticket 5118 from Marcus in the warehouse: "Label printer won't print from the picking app since Monday. Other stuff prints fine." The assistant the desk switched on last month has already written a reply. It is four paragraphs long, polite, and confident: clear the print queue, reinstall the printer driver, restart the picking app, and "let us know if the issue persists". Dana reads it twice. It sounds exactly like something a technician would write. It is also wrong. On Friday her colleague Tomas renamed every warehouse printer to match the new asset tags. The picking app still points at the old name. Nothing in the ticket said so. The assistant wrote from what was in the ticket, and what was in the ticket was a symptom.

An AI assistant, for the purposes of this library, is a piece of software that takes text in and gives text back. That might be a draft reply, a summary of a long thread, a suggested knowledge article, or a label such as a category or a priority. The text you give it is the prompt, and the prompt is the whole of what it knows about your ticket. That one sentence is most of this article. Everything an assistant does well at a help desk follows from it, and so does everything it cannot do. Both halves stay true when the tools change. The tools change roughly every time you have finished reading about the last change. This article is part of our AI Assistants in Support series. It is the map of the territory: what to hand an assistant, what to keep, and the test that tells you which is which.

It covers why an assistant works on text and only on text. The four durable jobs follow: drafting, summarizing, suggesting and classifying, each with where it helps and where it bites. Then come the three things that stay with a person: knowing your network, verifying a claim and taking responsibility. Next is the one test that sorts any new task. A short war story and the capability and responsibility table to copy come last.

It Works on Text, and Only on Text

Everything an assistant produces is made from the text it was given plus whatever general writing it absorbed before it ever met you. It has read a great deal about printers, drivers and picking apps in general. It has read nothing about your printers unless somebody pasted it in. So when Dana's assistant drafted "reinstall the driver", it was not diagnosing her warehouse. It was producing the most plausible reply to a ticket like this one, as written by someone who had never been in the building. That is not a flaw in the tool. It is the shape of the tool.

The useful consequence is that any task which is genuinely about text is a candidate. Turning six bullet points into a courteous reply is a text task. Reducing forty replies to a paragraph is a text task. Spotting that a new ticket resembles an existing knowledge article is a text task. Guessing that "nothing works and payroll is tomorrow" is probably urgent is a text task, with a guess attached. None of those require the assistant to know your network, and all of them are jobs technicians do slowly and reluctantly on a busy afternoon.

The dangerous consequence is that fluency is not evidence. A draft that reads like a senior technician wrote it has the same relationship to the facts as one that reads badly. Neither has a relationship to the facts until a person checks. Technicians are trained, by years of reading each other, to treat a confident, well-structured reply as a sign that the writer knew what they were doing. An assistant breaks that signal. Fluent text is persuasive, and it has never once wanted to be checked.

So the rule for the whole series is this: the assistant produces, a person reviews, and the desk is responsible. Every article that follows is a variation on where the review goes and what it looks for. If you take one thing from this one, take the shape of that sentence.

What It Can Do: Draft

Drafting is producing the first version of a reply from the ticket and a few words of instruction. For example: "tell them we need the printer's name and a photo of the error, and that we will look today". The assistant turns that into three polite paragraphs in the time it takes you to find the template. The value is real. Most of a support reply is scaffolding: the greeting, the acknowledgment, the "please let us know". Scaffolding is the kind of text an assistant produces well, because there is little in it to get wrong.

The facts are where it bites. A draft contains two kinds of sentence: the ones that could be wrong and the ones that cannot. "Thank you for letting us know" cannot be wrong. "Restart the print spooler service" can, and in Dana's case was. That is not because the sentence is bad advice in general but because it was the wrong advice here. The reviewer's whole job is to find the sentences of the first kind and check each one. The draft does not mark them for you. The mechanics of that review are the loop, the checklist and the edit rate that tells you whether the drafts are earning their keep. They are in Drafting Replies With a Human Reviewer.

Where the desk already has good templates, the assistant's drafting role shrinks and gets safer. In that case, it fills in the template rather than inventing the reply. The library of templates and the voice they are written in belong to the Templates and Canned Responses series. A desk that has done that work first gets more from an assistant than one that has not. An assistant drafting from nothing produces generic text. An assistant drafting from your template produces your text, slightly faster.

What It Can Do: Summarize

Summarizing is reducing a long ticket to a short account: what was asked, what has been tried, where it stands, what is waiting on whom. The forty-reply ticket that has been passed between three technicians over two weeks is the natural case. Nobody wants to read it; everybody has to; the assistant reads it faster than any of us and produces a paragraph. For a handoff at the end of a shift, an escalation to someone senior, or a manager asking "where are we with the warehouse printers?", that paragraph is worth having.

The bite is the dropped fact. A summary is a selection, and the assistant selects by what looks important in the text. That is not always what was important in the building. The one line on day three where Marcus mentioned that the printers had new names is exactly the kind of line a summary leaves out. It reads like an aside. The person who then acts on the summary has lost the clue. The check that catches this, reading the summary against the ticket's own history before trusting it, is the subject of Summarizing Long Tickets and Handoffs.

A summary also has a tense problem. It describes the ticket as it was when the summary was written, and a ticket does not stop moving because somebody summarized it. Date every summary and treat it as a photograph, not a window. I have handed over a ticket with a summary that said "waiting on the vendor" two hours after the vendor had replied. The summary was accurate. It was just old, and I had read it instead of the ticket.

What It Can Do: Suggest

Suggesting is pointing at something that already exists: a knowledge article, a past ticket with a similar symptom, a template that fits. The assistant reads the new ticket, compares it with what the desk has written before, and says "this looks like the article about printer names". This is the quietest of the four jobs and, in my experience, the one that pays most reliably, because it does not generate anything. It finds. Whatever it finds was written by a person, tested by a person, and can be checked by opening it.

The dependency is the knowledge base. A suggestion can only be as good as the article it points to. A desk whose articles are stale, duplicated or unowned will get suggestions that are stale, duplicated and unowned, delivered faster. The relationship between suggestion quality and knowledge base quality, and how to measure whether suggestions are being used, are in Suggesting Knowledge Articles. The short version is that an assistant does not fix a bad knowledge base. It gives it a louder voice.

What It Can Do: Classify

Classifying is attaching a label from a fixed list: this ticket is probably about access, probably urgent, probably from someone who is annoyed. It is text in, one word out. Where a desk has a short category list with clear boundaries, a guessed category is often right enough to save the triager a click. Where it is wrong, the triager was going to look anyway. The limits of letting a rule or an assistant pick the category, and why the triager's eye stays on it, are in Auto-Categorization and Its Limits.

Priority is the label to be careful with. A category guess that is wrong costs a report a little accuracy. A priority guess that is wrong decides who waits, and "the system marked it low" is a sentence no requester has ever found comforting. Treat a suggested priority as a prompt to the triager, not a verdict. The assistant says "this reads as urgent". A person decides whether it is, and the person's name goes on the decision. Who holds that decision on a desk, and why it is a role rather than a tool, is a subject the prioritization series owns.

Those are the four durable jobs. Draft, summarize, suggest, classify: four verbs that take text and give text. Nearly every assistant feature you will be shown at a help desk is one of these four or a combination of them. That holds under whatever name the vendor has chosen that quarter. Knowing that saves a great deal of time in demonstrations.

What It Cannot Do: Know Your Network

The assistant does not know your network because nobody told it, and the things it would need to be told change daily. Which printers were renamed on Friday. That the finance share moved to the new server. That Marcus's scanner is the one with the cracked screen that drops its connection. That the picking app is pinned to a version the vendor no longer supports. None of this is in any ticket in a form an assistant could use, and most of it is in no document at all. It is in Tomas's head and in the ticket history. If you run QuerySolv, the event history on each ticket is where the renames, handoffs and "tried this already" notes survive. That local knowledge is also in the fact that Dana walked past the warehouse last week.

This is a limit of position, not of cleverness, and that is why it stays true. An assistant knows what is in the text in front of it. If the desk starts feeding it more of the building, the inventory, the change log, the ticket history, then it knows more of the building. The question then becomes what it is safe to feed it. That is the subject of Guardrails: What Leaves the Building. But at any moment, the assistant knows the building only as well as the last thing somebody wrote down about it. (Which, on most desks, is a sobering standard to be measured against.)

The practical rule: every sentence in a draft that depends on how your environment is set up is a sentence to check. "Restart the service" assumes the service exists and is called that here. "Ask your manager to approve" assumes you have an approval step. "Connect to the office network" assumes the requester has one to connect to. The assistant wrote the generic version of each. The reviewer writes the local one, or deletes it.

What It Cannot Do: Verify a Claim

A claim is any statement that could be checked against the world. Examples are: "I have already restarted it twice", "the server is up", "this fix worked last time", "the requester has confirmed". An assistant can repeat a claim, rephrase it, summarize it and build a reply around it. What it cannot do is walk to the server. Verification means comparing a statement with something outside the text, and the assistant has only the text.

This matters in both directions. Claims arrive in tickets. A draft reply built on "since you have already restarted it, the next step is..." has taken the requester's word for the restart. A technician would have quietly doubted that restart. The assistant did not. Claims also appear in the draft itself, produced by the process of writing a plausible reply. They might be a menu that does not exist in your version, or a setting your tool does not have. They might be a step that would work on the common configuration and not on yours. Neither kind of claim is marked. Both read exactly like the true sentences around them.

Do not build the review around the assistant telling you when it is unsure. Some tools flag uncertainty better than others, the tools change, and the review cannot depend on it. The durable discipline is the one technicians already use with each other: a claim is a claim until someone checks it, whoever wrote it. The checking is the work. Writing the sentence around the checked fact was never the hard part. That is why handing that part to an assistant is reasonable, and handing the check to it is not.

What It Cannot Do: Take Responsibility

When the reply to ticket 5118 goes out, it goes out from the desk. Marcus reads it as the desk's answer. If it wastes his morning, the desk wasted his morning. If it promises a fix by Thursday, the desk promised. An assistant is not on the roster, does not attend the review, cannot be asked why, and cannot be told not to do it again. Responsibility is something people with jobs have, and the assistant does not have a job. It has a prompt.

This is the limit that no improvement in the tools changes, because it is not about what the assistant can do. It is about what the requester, the manager and the auditor will accept. "The assistant said so" is not an explanation anyone will take from a help desk, any more than "the template said so" would be. The desk that tries it will be told, correctly, that someone chose to send it. The person who presses send owns the sentence. Make that explicit, make it visible, and make it the same person every time: the reviewer.

There is a version of this that gets missed. Responsibility covers not only the words sent but the decision not to check them. A technician who sends an unread draft has not delegated the work to the assistant. They have delegated it to nobody and signed it themselves. The decisions, apologies and security actions that a desk must stand behind personally, and the test for recognising them, are in What Not to Hand Over to an Assistant. The principle here is simpler: whatever leaves the desk has a human name on it, and that human read it.

The One Test That Sorts Any Task

New assistant features arrive faster than articles about them, so you need a test rather than a list. Ask two questions of any task. First: is the task made of text? Does it take words in and give words out, with nothing in between that requires touching a system, a person or a decision? If yes, an assistant can do a first version of it. Second: what would it cost if the output were wrong and nobody noticed? If the answer is "a slightly worse sentence", the review can be light. If the answer is "a requester misled, a promise made, a priority wrong, a password sent", the review is the job. In that case, the assistant did the easy part.

Run Dana's ticket through it. Drafting the acknowledgment to Marcus is text, and the cost of a wrong word is small. The assistant drafts; Dana glances and sends. Drafting the fix is text, but the cost of a wrong step is Marcus's morning. The assistant drafts. Dana checks every step against the building, which is where she remembers the rename. Deciding whether the warehouse printers are more urgent than the finance export is not a text task at all. It is a judgement about the business, and it stays with a person. Three parts of one ticket, three different answers from the same two questions.

The test also tells you what to do when a vendor shows you something new. "It resolves tickets on its own" is drafting plus sending without review. The second question says the cost of a wrong one is high. So the answer is no, or not yet, or not for that ticket type. "It suggests the three most similar past tickets" is suggesting, and the cost of a wrong suggestion is a click, so yes. The feature's name tells you nothing. The two questions tell you everything you need for a decision that will still look sensible in a year.

A Short War Story: The Confident Draft at Redbrook Engineering

At Redbrook Engineering, a technician called Priya was working a ticket from six design engineers who could not open their drawing software. The licence server was refusing connections. The assistant drafted a reply telling them to open the licence manager, choose "Reconnect" from its tools menu and re-enter the server address. The draft was clear, numbered and courteous. Priya had never used the licence manager herself and had nine other tickets open. She sent it as written. The firm's licence manager had no tools menu and no reconnect option. The draft had described a different product. Six engineers spent most of a morning looking for a menu that did not exist. Two of them phoned the vendor independently. The actual fault was a certificate on the licence server that had expired overnight. Priya's colleague found it at lunchtime, having read the server's log instead of the draft. The cost was about half a day for six engineers and a conversation with their manager that Priya afterwards described as "educational". The lesson Redbrook wrote into its desk notes was one sentence: a draft is a suggestion from someone who has never seen our building, and it is sent as fact only after someone who has seen it says so.

The Capability and Responsibility Table

The table is the article on one page. Pin it where new technicians will see it, and use the last column literally. Nothing in the first column is finished until the check in the last column has been done by the person in the third. When a new assistant feature arrives, add a row by answering the two questions above. If you cannot fill in the third and fourth columns, the feature is not ready for your desk, whatever the demonstration looked like.

Dana deleted the four paragraphs about drivers. She wrote two sentences telling Marcus that the printers had been renamed on Friday. They also said she would repoint the picking app within the hour. She sent that. It took her six minutes, two of them reading the draft she did not use. The assistant had done nothing wrong. It had answered the ticket as written. The ticket, as written, was missing the only fact that mattered. That fact was in Tomas's head and the Friday change note. The desk knew the building. The assistant knew the text. Keeping those two straight is the whole of this series, and most of the next five articles are about the places where desks forget.

Frequently Asked Questions