Training Users to Write Better Tickets Without Lecturing

Wednesday, 16:40, at Acme. Nadia has been running the desk for four months and has had enough of tickets that say "it's broken". She is drafting an all-company e-mail. The subject line is "Submitting IT tickets correctly". It has eleven bullet points. The word "must" appears seven times. And the second paragraph begins "Going forward, tickets that do not include the following will be returned". It is a good list; every bullet is a fact the desk genuinely needs. Sam, who sits next to her, reads it over her shoulder and asks the only question that matters: "Would you read this?" Nadia would not. Nobody at Acme would. It would be opened by about a third of the company and read by a tenth. It would be remembered by nobody on the day, three weeks later, when their printer jammed.

The memo fails for a reason that has nothing to do with how well it is written. It arrives when the reader has no problem and asks them to remember rules for a moment that has not happened yet. It frames the people it is sent to as the cause of the desk's difficulty. Then it is forgotten, and the next new starter never sees it at all. Users do not learn to write good tickets from a memo. They learn from the form they are looking at when they write one, and from the reply they get. They learn from the colleague who says "just send them a photo, they like that".

Training users, for a help desk, means arranging things so that the good ticket is the easy one. The requester learns what the desk needs at the moment they need to know it, without being told they have done anything wrong. This article is part of our Getting Better Tickets From Users series. It is about the methods that work in place of the memo. Those are nudges in the form, a two-line guide in the acknowledgment, a specific thank-you, and a refusal to scold. They also include a one-minute slot in the new-starter induction and a one-page guide that people keep.

It covers why lecturing does not work, then training at the moment of asking, with the form as the teacher. Next come the two-line guide in the acknowledgment, thanking a good ticket specifically, and never scolding, with what to say instead. We cover the new-starter minute, then showing rather than telling, and managers and champions, used lightly. A short war story follows, then the "how to ask IT for help" one-pager to copy.

Why Lecturing Does Not Work

A lecture is training delivered at the wrong moment to the wrong audience in the wrong tone, and it fails on all three counts at once. The wrong moment: the memo arrives on a Wednesday when nothing is broken, and the rules in it have nowhere to attach. The wrong audience: it is sent to everyone. That includes the three hundred people who already write perfectly good tickets and the forty who will never raise one. That is to reach the handful whose tickets say "broken". The wrong tone: "must", "correctly", "will be returned" tell the reader that the desk sees them as the problem. People do not take instruction from someone who has just said that.

Even a good memo decays. It is accurate on the day, out of date when the form changes, and unknown to every starter who joins afterwards. It is buried under six hundred newer messages within a month. Any training that lives in a document people have to remember is training the desk will have to repeat every quarter. Desks do not repeat it, because it did not work the first time. The desks that give up on training users are usually the ones that tried a memo, saw no change, and concluded users cannot be trained. They can. The memo cannot train them.

There is also a quieter cost, which is what the memo teaches about the desk. A requester who reads "tickets that do not include the following will be returned" learns that the desk is a place where requests get rejected. The next time something breaks, they weigh that against the technician they know by name and the hallway. The memo meant to improve the tickets. It improved the shadow channels. (It did, to be fair, improve the tickets of the two people who read it to the end, both of whom already wrote good ones.)

Train at the Moment of Asking: The Form as Teacher

The only training every requester receives, every time, at exactly the right moment, is the form they are looking at when they write the ticket. So the form is where the training goes. A label that reads "What were you trying to do, and what happened instead?" teaches the two-part description without a single rule. An example under the box might read "for example: printing a delivery note; the printer says 'paper jam' and nothing comes out". That shows what a good answer looks like and how long it is. A line beside the photo field might read "the exact words on the screen usually tell us what is wrong straight away". That explains why the desk wants the picture and turns a chore into the fast route. The requester has been trained in thirty seconds, standing up, and has no idea it happened.

The form trains four hundred people at once and trains every new starter on their first ticket without anyone remembering to. That is what makes it worth more than any memo, induction slide or poster. The desk writes the labels once. From then on the form asks the same five questions in the same plain words to everyone, forever, without getting tired or cross. Designing those labels and examples is the subject of A Request Form People Will Finish. This article assumes the form is doing that job and asks what else the desk can do.

The nudges work because they are tiny and present, not because they are clever. A requester does not read a form; they glance at it while thinking about their problem, and anything longer than a sentence per field is skipped. One question, one example, one reason, each a line long. The rest of the training in this article follows the same rule. It is a line or two, at the moment it is useful, in the place the requester is already looking. If a piece of guidance needs a paragraph, it is a knowledge base article, linked from the line, for the one person in fifty who wants it.

The Two-Line Guide in the Acknowledgment

The automatic acknowledgment is the most-read thing the desk writes, and two lines in it do more training than any document the desk will ever publish. Every requester reads it, because it is the proof their ticket exists. They read it within a minute of sending, while they are still beside the problem with the facts fresh. That is the moment to ask for one or two things more. "If there is a message on the screen, reply to this with a photo of it. If you can, tell us which device it is and since when." Two lines. A large share of requesters reply at once, and the ticket arrives at triage with the facts the e-mail left out.

Keep it to two lines, because the acknowledgment has other jobs and a long one is not read either. It must say the ticket number, when a person will reply, and how to add to the ticket. Then come the two training lines, and then the acknowledgment must stop. Every channel that creates a ticket sends an acknowledgment of some kind. And the two lines belong in each of them, worded for the door: the e-mail version asks for the photo and the device. And the form version can skip whatever the form already asked. Whatever your tool, find where the acknowledgment text lives and treat it as the desk's most valuable paragraph. It is read more often than the home page.

Add a third line only for the e-mail channel. Make it an invitation rather than a correction. It can say: "Next time, the form at helpdesk.example.com asks these questions up front and usually gets you a faster answer." That sentence moves people to the form gently, one ticket at a time. It arrives at the exact moment they have just discovered the e-mail route needs a follow-up. It does not say they did anything wrong. It says there is a quicker way, and offers it. Over a few months the share of tickets arriving by form rises, with no policy, no memo and nobody having been told what they must do.

Thank a Good Ticket, Specifically

When a ticket arrives with a photo, a device label and a since-when, say so in the first reply, in one specific sentence. A thanked behaviour is a repeated one. "Thanks for the photo; the message in it told me the cause straight away" is worth more than any instruction. It connects what the requester did to what it got them, in the moment. The requester learns that the photo mattered, and the next time something breaks they take the photo before they write a word. Generic thanks do not do this. "Thanks for the detailed ticket" is pleasant and teaches nothing; the requester does not know which detail earned it.

The thank-you spreads further than the requester. People talk about the desk in offices, and "send them a photo, they like that" is exactly the kind of advice that passes between desks at lunch. A desk that thanks good tickets specifically is, over a year, training departments it has never written to. It does so through the only channel that reaches everyone, which is the colleague who has just been helped quickly. It costs one sentence, and the sentence is true. There are not many investments on a desk with that return.

Make it a habit rather than a mood. The first reply to a well-formed ticket starts with the specific thank-you, every time, from every technician. And the habit is written down in the desk's standard for first replies. Not because requesters need praise, but because the sentence is the cheapest training the desk has and it only works if it is consistent. A desk that thanks a photo on Monday and ignores one on Thursday is teaching that it does not matter, which is a lesson, and the wrong one.

Never Scold, and What to Say Instead

A scold is any reply that tells the requester they asked wrongly, and every scold trains them to ask somewhere else next time. "Please use the form" is a scold. "Insufficient information" is a scold. "As per the IT policy, tickets must include..." is a scold with a footnote. Returning a ticket is a scold the tool delivers on the desk's behalf. So is setting it to a status that reads "needs more info" with no human words beside it. Each one is reasonable from the desk's chair and lands, from the requester's, as "you did it wrong". Nobody who has been told that comes back for more.

The replacement for every scold is a request with a reason, and the table below has the usual pairs. The pattern is the same each time: say what you need, say why in half a sentence, and never mention what was missing as a fault. The requester ends up supplying the same fact the scold was demanding, and ends up feeling helped rather than corrected. That is the difference between a requester who uses the desk and one who uses the hallway. The wider subject of writing like a person rather than a policy is in Writing Like a Person, Not a Policy. These pairs are that article's rule applied to one moment.

Scolds are tempting at four in the afternoon on a day when the ninth ticket in a row said "broken". The temptation is why the replacements are written down. A technician can have a saved reply that says "could you tell me which device, and what the screen shows?" Then they do not have to find kind words when they have run out. The desk's predefined replies are, among other things, its manners on a bad day. Keep the pairs in the table in the reply library, and the scold never gets typed.

The New-Starter Minute

Every new starter gets one minute from the desk in their first week. The minute covers four things. It covers where the form is, what a good ticket has, that a photo is fine, and that there is no such thing as a stupid ticket. Not a slide deck, not a policy acknowledgment to sign, not a tour of the ticket system. One minute, ideally in person, with the one-pager from the end of this article handed over on paper or pinned to their chat. "This is where you ask us for anything. Tell us what you were doing and what happened, which thing it is, and since when, and send a photo if there is a message. Ask early; a question that takes us two minutes on Monday is a problem on Friday." That is the minute.

The minute works because it is delivered before the starter has learned any other route. A new person who is shown the form in week one uses the form. A new person who is shown nothing asks the colleague at the next desk, who says "just message Arjun, he's quick". And a shadow channel has acquired a user. Getting into the induction is a one-off negotiation with whoever runs it, and the pitch is honest. It saves their new starters time, it saves the desk four e-mails per ticket, and it takes sixty seconds. The desk's place in onboarding is the same argument as Announcing the Desk, run once per starter rather than once for everybody.

End the minute with the desk's name and a face. A starter who has met Nadia raises a ticket to Nadia's desk; a starter who has met a URL raises nothing until something is on fire. The minute is partly information and mostly introduction, and the introduction is the part they remember. If the desk cannot get a minute in the induction, the one-pager alone, handed over by whoever does the induction, does most of the job. It is a page. It can be read at a new desk on a quiet afternoon, which new starters have, and nobody else does.

Showing, Not Telling

People copy examples far more readily than they follow rules, so put a good ticket where requesters will see one. The knowledge base article behind the form's help link should open with a single example ticket, three lines long. It should be labelled "a ticket that got fixed in ten minutes". The same problem should follow, written as "it's broken" and labelled "the same problem, which took a day". No rules, no bullets; two tickets, side by side, and the reader draws the conclusion. A knowledge base with articles visible to everyone, which most tools have and QuerySolv among them, is the natural home for that page. It is linked from the form and the acknowledgment and otherwise left alone.

The example also belongs on the landing page that leads to the forms, as one short line under the link. It can say: "the fastest tickets say what you were doing, what happened, which device and since when, with a photo". Not a rule, a description of what fast looks like. And it belongs in the technician's first reply when a ticket needed questions. After the questions have been answered and the fix made, use one sentence. Say "for next time, a line saying which printer and a photo of its screen would have let me start straight away" once, kindly. Never repeat it to the same person. Said twice it is a scold. Said once, after help, it is advice from a colleague.

Managers and Champions, Lightly

Ask each department head, once, to forward the one-pager with a sentence of their own, and ask nothing more of them. A page that arrives from the person's own manager with "this is how to get IT to help quickly" is read. The same page from the desk is filed. Ask for one forwarding, once, when the form changes or the desk is new, and then leave the managers alone. A desk that keeps sending managers things to forward becomes a desk whose things are not forwarded.

Every department has one person who writes good tickets already, and that person is worth more than any manager. Find them by looking at the tickets; they are the ones with the photo and the device label. Thank them specifically, as above, and when someone in their department raises a vague ticket, do not mention it. The good writer is already the person colleagues ask "how do you get IT to come so fast?" And the honest answer they give is the training. Do not appoint them, do not name them "champion", do not give them a badge or a monthly meeting. The moment they are an official role, they are the desk's representative rather than a colleague, and the advice stops being taken.

Never create ticket police. A desk that asks managers to enforce ticket quality, or that reports vague-ticket counts by department to anyone, has turned a form problem into a performance problem. It will get neither better tickets nor a friendly building. The numbers that show which department's tickets arrive vague are for the desk, to fix the form and the examples that department sees. And that use of them is the subject of Measuring Ticket Quality and Fixing the Form, Not the User. Shared with a manager as a league table, the same numbers do only harm.

A Short War Story: The Eleven-Rule Memo at Pinecrest Academy

At Pinecrest Academy, a school trust with about four hundred staff across three sites, the desk lead, Ruth, sent an all-staff memo. It was titled "Logging IT faults correctly". It had eleven numbered rules, a warning that incomplete tickets would be closed, and an attachment explaining the asset-tag format. Ticket volume fell by a third over the following month, which Ruth reported as a success, until the week before mock exams. Then, in the staff room, a teacher called Idris mentioned the computer lab on the second site. He said it had had nine machines out of action for a fortnight and nobody had logged it "because of the memo". The lab's teachers had instead been borrowing laptops from the library. The library had been short for two weeks. And the exam timetable was rebuilt over a weekend at a cost Ruth estimated at forty hours of other people's time. She withdrew the memo, rewrote the form's labels as questions, and put two lines in the acknowledgment. She spent a term thanking every ticket that arrived with a photo by name. Volume came back within a month. The lab was logged on the first morning the next time, and the asset-tag attachment was never mentioned again. A memo that frightens people out of raising tickets does not reduce faults; it hides them until the exam.

The 'How to Ask IT for Help' One-Pager

The page below is written for the requester, not the desk, in the second person, with no rules and no "must". It goes to new starters in the induction and to department heads once for forwarding. It goes into the knowledge base behind the form's help link, and on paper beside the printer that jams most. Replace the address and the names with your own, keep it to one page, and resist adding anything. Every line you add is a line fewer people read. The point of the page is that it can be read in a minute. The reader may never have raised a ticket and may not know what the desk needs. Everything the desk needs is on it, phrased as what gets the requester helped fastest.

HOW TO ASK IT FOR HELP — ONE PAGE
Keep this somewhere you can find it on a bad day.

WHERE TO ASK
  The quickest way: helpdesk.example.com (link on your desktop)
  Also fine: e-mail ____________@example.com, or call ______
  Walk-ups and chat messages work too; we will log them for you.
  Every request gets a ticket number. Reply to the ticket, not to a
  person, and it will always reach whoever is working on it.

WHAT GETS YOU HELPED FASTEST
  Tell us these, in your own words, in as many sentences as you like:
    1. What you were trying to do, and what happened instead
    2. Which thing it is, and where it is
       [the label is usually a sticker on the front or the back]
    3. When it last worked, and anything that changed around then
    4. Whether anyone else is affected, and any deadline you have
    5. A photo of any message on the screen. A phone photo is fine.
       The words in that message usually tell us the cause.

A TICKET THAT GOT FIXED IN TEN MINUTES
  "Printing a delivery note from the dispatch PC. The printer by the
   east wall (label SF-02) says 'paper jam, tray 2' and nothing comes
   out. Started this morning after the toner was changed. Six of us
   use it and the 9 o'clock lorry is waiting. Photo attached."

THE SAME PROBLEM, WHICH TOOK A DAY
  "Printer broken again, can you come?"

THINGS THAT ARE ALWAYS FINE
  Asking early. A two-minute question on Monday beats a Friday problem.
  Not knowing the name of the thing. Describe it; we will work it out.
  Saying "I think I clicked something". Nothing you can click is a
    problem we cannot put right. Tell us; it saves time.
  Telling us your deadline. It helps us put your ticket in the right
    place, and we will plan around it.
  Adding to your ticket later. Reply to the acknowledgment e-mail and
    it goes straight onto the same ticket.

WHAT HAPPENS NEXT
  You get a ticket number straight away.
  A person replies within ______, with what we think is happening and
    when you will next hear from us.
  If we need to come to you or take your screen, we will say so first.
  When it is fixed, we will tell you what was wrong and ask you to
    confirm. If it comes back, reply to the same ticket and it reopens.

WHO WE ARE
  ______________, ______________ and ______________
  ______ desk, ______ floor, open ______ to ______

Nadia deleted the eleven-rule e-mail and sent nothing in its place. She rewrote the form labels that afternoon and put two lines in the acknowledgment the next morning. She gave the one-pager to the person who ran inductions with a request for sixty seconds in each. Four months later, the first-reply-is-a-question rate at Acme had halved, and nobody had been told what they must do. The two people who had read the original memo to the end were still writing good tickets, as they always had.

Frequently Asked Questions