Gathering the Right Information Up Front

Ticket 3302 arrives at the Meridian Parts desk on Tuesday at 09:50. It is from Grace in accounts, and the whole of it reads: "It's doing it again." Olu, who is on triage, replies at 10:05: "Hi Grace, what is doing what?" At 10:55 Grace replies: "The system." Olu, at 11:10: "Which system?" Grace, at 14:30, after a meeting: "The one for the invoices." Olu, at 14:40: "What does it show when you try?" Grace, Wednesday 09:15: a screenshot of a grey box that says the template could not be found. Olu, 09:20: "Since when, and is it just you?" Grace, Wednesday 11:50: "Since Monday I think. Not sure about the others." It is now Wednesday lunchtime. The ticket has eight entries, and Olu finally knows what it is about. The fix takes four minutes.

Nothing in that exchange was rude, lazy or wrong. Every question was a reasonable question and every answer was an honest answer. The problem is arithmetic. Five facts, asked one at a time, over e-mail, is a day and a half. The requester has a job that is not answering IT. Five facts asked together is one reply, and Grace would have had her templates back on Tuesday afternoon.

Information gathering at intake is the triager's job of making sure a ticket contains the facts its eventual owner will need. This happens before it goes to that owner. The job includes getting the missing ones in a single question. This article is part of our Ticket Intake & Triage series. It is the triager's view of the problem. Designing the web form and training requesters to write better tickets are real subjects and belong to a later group of this library. Here the ticket has already arrived. It says "it's doing it again", and the question is what the person reading it does next.

It covers why the triager owns this job rather than the requester. It covers the five facts every ticket needs, and what each looks like when it is missing. The first three facts and the last two get a section each. It explains the arithmetic of asking once with everything against five times with one, and how to write the question so it gets answered. It covers what an intake form can collect for you before anyone types, and what to do with the ticket's status and clock while you wait. It includes a short war story and the missing-information reply to copy.

Why the Triager Owns This

The requester describes the problem the way it looks from their chair, and that is the only way they can describe it. Grace does not know that there are eleven systems involved in an invoice. She does not know that "template could not be found" is a path problem rather than an invoice problem. Nor does she know that the owner will want to know whether it started before or after the weekend. She knows that yesterday the button worked and today it does not. She has told the desk exactly that, in her words. "It's doing it again" is a complete and accurate report from where she is sitting.

The triager's job is to translate that report into the facts a technician can act on. And the triager is the right person because the triager knows what the technician will ask. Every owner who picks up a ticket asks the same first questions: who, what, where, since when, how bad. A triager who has already collected those five has saved the owner a round trip and the requester a second conversation. A triager who passes on "it's doing it again" with a priority attached has done the easy half of triage and left the expensive half for someone else.

This is also why the job is never a judgement on the requester. The desk that sighs about users who "can't write a proper ticket" has misread the situation. The requester wrote the ticket that their knowledge allowed. The desk has the knowledge to turn it into a useful one, in a single reply, and choosing not to is the desk's decision. Blame is also slow. Nobody has ever gathered a fact faster by being annoyed about not having it.

The Five Facts Every Ticket Needs

Five facts are enough to place almost any ticket with the right owner at the right priority. The owner can start work from them without asking anything back. Who has the problem, and how to reach them. What they see, against what they expected. Where it is: which device, which location, which system. Since when, and what changed. How bad: how many are affected and whether there is a deadline. The anatomy of a well-formed ticket, with these fields on it, is drawn out in Anatomy of a Ticket. This article is about getting them in when they did not arrive.

Most tickets arrive with two or three of the five. Web-form tickets usually have the who and some of the what. E-mailed tickets have the who, if the sender is the affected person, and a what written in a hurry. Chat has a who and a sentence. Walk-ups have everything, briefly, in the air, and nothing written down. The triager's first read is a count: which of the five are here, and which are not. Then one reply asks for the missing ones, all of them, numbered.

The table shows the five facts, why the owner needs each one, and the phrase that tells you it is missing. Learn the phrases; they are the tell. A ticket that says "the system" has no where. A ticket that says "it's broken" has no what. A ticket that says "again" has a since-when that the requester knows and did not write down, which is the easiest kind to recover.

Five is the number because five fits in one reply that a busy person will actually answer. Eight questions reads as a form and gets ignored; three leaves the owner asking the other two. If a particular ticket type needs a sixth fact, the serial number of a laptop, say, add it for that type and keep the general list at five.

Who, What and Where

Who is usually present and occasionally wrong. The sender of an e-mail is the requester. But the requester is not always the affected person. It could be a manager raising a ticket for a new starter, or a receptionist reporting a visitor's problem. It could be a shared mailbox called "accounts" that six people read. The owner needs the affected person's name and a way to reach them that works today, which may be a phone extension rather than the mailbox. Many small-team tools identify requesters by e-mail address rather than by a user account. Such tools make it easy for anyone to raise a ticket. They make it equally easy for a shared address to hide who actually has the problem. So "who is affected?" is worth a line in the reply whenever the sender is a role rather than a person.

What is the fact most often present and least often useful. "The invoice thing doesn't work" is a what in the grammatical sense only. The owner needs two halves: what the requester sees, as exactly as possible, and what they expected to see. "A grey box saying the template could not be found, when I press Create Invoice, where yesterday I got the invoice" has both halves and leads straight to a cause. The fastest way to get the first half is to ask for the exact words on the screen or a screenshot, and to say which. Requesters are good at screenshots and bad at transcribing error codes. The triager who asks for the one they are good at gets it first time.

What also includes what has already been tried, because the owner will otherwise suggest it. "Have you restarted?" is a fair question that has ended more conversations than it has started. Most requesters have, and most of them resent being asked. Fold it into the what: "and what have you already tried?" It takes four words and spares everyone the second round.

Where is the fact that stops the owner from having to phone. Which printer, by the label on its front; which computer, by the name on the sticker; which system, by the name on the login page. Where also means physically where the person is. "In the office" and "at home on the VPN" are different problems with the same symptom. The owner wants to know before they walk to a desk that is empty. On a desk that supports several sites, where is the fact that decides who owns the ticket at all.

Since When and How Bad

Since when is the most underrated fact on the list, and the owner will ask it first whether or not the triager did. Nearly every incident has a cause that is a change, and the time the symptom started points at the change. "Since Monday" at Meridian Parts pointed at a server that had been renamed over the weekend, and the owner who knew that could skip four other theories. Since when also tells apart a first occurrence from a recurrence, which is what "again" means. A recurrence means a previous ticket exists, with a previous fix in it. The triager who searches for it has done the owner's first ten minutes.

Ask since when in two parts: when did it last work, and did anything change around then. The second part is where requesters produce the useful detail they did not think was relevant. For example, a laptop was updated, a password changed, or a desk was moved. Or a new piece of software was installed by a colleague on Friday. Nobody writes that in the first ticket, because nobody connects it. Everyone remembers it when asked.

How bad is the fact that sets the priority, and it is two questions wearing one coat. How many people are affected, and has their work stopped or merely slowed? Is there a deadline, such as the invoice run on Thursday or the courier at 14:00? The requester knows both answers and rarely volunteers either, because from where they sit the problem is theirs and it is bad. The triager asks, and uses the answers to set the priority from the desk's own scale. That scale is the subject of the Prioritization Frameworks pillar and will not be repeated here. The question is simply worth asking before the priority is set rather than after the requester complains about it.

How bad has one caution. Requesters sometimes answer "everyone" when they mean "everyone I have asked", which is two people. Ask it as "who else have you heard from?" rather than "is everyone affected?". The answer comes back with names, which is a count the triager can trust. (The word "everyone" has a different meaning in every department, and in sales it means "me, quite strongly".)

Ask Once, With Everything

Every question asked separately costs one round trip, and a round trip over e-mail is rarely shorter than an hour and often a day. The requester is at their own job. They see the reply when they next look at their mail and answer it when they have a moment. The triager sees the answer when they next sweep the queue. Two people's attention has to line up for each exchange, and it lines up two or three times in a working day at best. Five questions, asked one at a time, is a working week with luck and more without. Five questions asked at once is one of those exchanges.

Grace's ticket makes the arithmetic concrete. Five one-question replies produced a complete picture at Wednesday 11:50, twenty-six hours after the ticket arrived. There were eight entries in the history and a requester who had been interrupted five times. One five-question reply at 10:05 on Tuesday could have been answered at 10:55 when Grace next looked at her mail. That would have given Olu the whole picture at 10:55, with two entries in the history and a requester interrupted once. The fix would have been in by 11:00 on Tuesday. The information was the same. The number of trips was different.

The rule is therefore simple and slightly unnatural. When a ticket is missing anything, ask for everything it is missing, in one reply, before doing anything else with it. Unnatural, because the conversational instinct is to ask the obvious first question and wait, as one would in person. In person the wait is two seconds. On a ticket it is an afternoon. The triager who notices three missing facts and asks for one is choosing to have the same conversation three times.

Asking once also means thinking once. Before writing the reply, the triager reads the ticket against the five facts and decides which are missing. They consider what the owner will want beyond them for this ticket type. A request for access needs the name of the folder and who approves it; a laptop problem needs the asset label. Add those to the list. The reply that goes out should be the last question the requester is asked before the fix. And the triager should write it with that ambition, even knowing it will not always come true.

Writing the Question So It Gets Answered

The reply gets answered when it is short, numbered and gives a reason. It gets ignored when it is a paragraph of prose with the questions buried in it. Number the questions. A requester reads on a phone between meetings. If the questions were numbered, they will answer "1. The printer by the lift. 2. It says paper jam but there is none. 3. Since this morning." They will write "see below" if the questions were not numbered. The numbers are not for the triager. They are a courtesy to the person being asked to do the desk's work for a minute.

Say why, in a few words, for the question that looks nosy. "When did it last work, so I can check what changed that day" turns an interrogation into a collaboration, and requesters answer collaborations faster. The reason also helps them answer the real question: told that the triager is looking for a change, the requester remembers the update on Friday. Told only "since when?", they write "a while".

Ask for the form of answer that is easiest for the requester, which is nearly always a screenshot over a transcription, and a label over a description. "A photo of the sticker on the printer" beats "the printer's network name" with everyone who does not know what a network name is. That is everyone who would raise the ticket in the first place. The triager can read the sticker. The requester cannot find the name.

Close with what happens when they answer, so the reply has a shape and the requester knows the questions are not a delaying tactic. "Reply with those and I will pick it up within the hour. Until then it is logged as Medium under reference 3302." That tells them that answering produces action, when, and what the ticket is doing in the meantime. The first-reply variants in First-Touch Discipline follow this shape; the missing-information version at the end of this article is the full one.

One thing the reply should never do is ask a question the triager could have answered by reading the ticket again or looking at the queue. Asking "which printer?" when the attachment is a photo of the printer tells the requester that nobody looked at the attachment. That is a hard impression to recover from. Read twice. Then ask.

What the Form Can Collect for You

A web form can collect most of the five facts before a person reads the ticket. And the triager should know what their own form asks so they know what to expect. Suppose a form requires the requester's name and contact, asks for a location, and offers a short list of systems or devices. It has a free-text box labelled "what do you see, and what should happen?". It asks "since when?" and "is anyone else affected?". That form produces tickets that arrive nearly complete. The triager's work on those tickets is a read and a priority. E-mailed tickets never have any of this, which is one reason the same problem arrives as a two-minute triage from the form and a two-day one from the mailbox.

Most help desk tools let an administrator add fields to the form, and the useful ones are the five facts as fields. Some tools give each department or team its own form. In those, the IT form can ask for a device label and the facilities form can ask for a room number. In some, a value in one of those fields can also drive which SLA rule applies. In tools with one form for everything, the compromise is a short "what is this about?" list at the top. The rest of the fields are kept general. What a form cannot do is make people fill it in thoughtfully. A required field with no good answer gets "n/a" or "see above" from a requester in a hurry. That is why the triager's read still matters. Form design, which fields to require, and how to teach requesters to use the form at all are later subjects in this library. They are mentioned here only so the triager knows where the complete tickets come from.

The honest view is that the form reduces the gathering job; it does not remove it. Chat tickets arrive as one sentence because chat is a sentence at a time. E-mail arrives as whatever the requester wrote to whoever they wrote it to. Walk-ups arrive as a conversation. The triager who knows the five facts can take any of them and, in one reply, make it whole. That skill is the one this article is about, and it works whatever the form looks like.

While You Wait: Status, Clock and Follow-Up

A ticket that is waiting for the requester's answer should say so, and most tools have a status for it. A status is the word on a ticket that says what state it is in and who it is waiting for. "Awaiting Reply" or its equivalent means the desk has asked and the requester has not yet answered. Set it when the question goes out. It takes the ticket out of the "waiting on us" view, so the sweep does not keep stopping on it. And it tells anyone else on the desk why the ticket is sitting still. The fine distinctions between waiting on a user, a vendor and a genuine hold are in Pending User vs Pending Vendor vs On Hold.

The status does not necessarily stop the clock, and the triager should know which their tool does. Some SLA engines pause the response and resolution timers while a ticket waits on the requester. Some do not. Some pause on one waiting status and not another. Some exclude only non-working hours and holidays whatever the status says. Test yours. Put a test ticket into the waiting status on a Friday afternoon. Read its due time on Monday, and write down what happened. On a desk whose tool does not pause, a ticket waiting two days for Grace's reply will breach its resolution target through no fault of the owner. That breach will sit in the ticket's history with the reason visible to anyone who reads it. That is a reason to ask once and well, and a reason to chase the answer rather than wait for it. It is not a reason to guess.

Chasing is a small routine. If the answer has not come by the time promised, send one short reminder that repeats the numbered questions. It says the ticket will be closed if nothing comes by a stated day. Write it kindly and send it once, then once more. The wording that gets replies, and the cadence that stops tickets ageing quietly, are in Follow-Up Messages That Get Replies. If the second reminder gets nothing, the ticket is resolved with a note saying what was asked, when, and that it will reopen on a reply. In tools that reopen a resolved ticket automatically when the requester replies, that is a safe close and not a brush-off. In those tools, the history is intact and the requester's next message lands exactly where it should. In tools that do not, a reply to a resolved ticket may create a new one or vanish into a mailbox. So test it before relying on it. If yours needs a hand to reopen, say in the closing note how to get the ticket reopened. How long to wait before taking that step is covered in User Confirmation Without Chasing Forever.

The waiting ticket is also where the five facts earn their second keep. When the answer comes back, the owner reads it against the five and finds either a complete ticket or exactly one gap. Any such gap can be closed by phone in a minute. What the owner does not find is "it's doing it again" with a priority on it. That is what they find on a desk where the triager asks one question at a time, or none.

A Short War Story: "It's Doing It Again" at Meridian Parts

The grey box on Grace's screen at Meridian Parts was a mapped drive that pointed at a file server renamed over the weekend. Once Olu knew the symptom, the system and the day it started, fixing it took four minutes and a reboot. The cost was the twenty-six hours before those three facts were in the ticket. The Tuesday invoice run, sixty-one invoices to trade customers, went out on Thursday instead. The finance manager, Petra, spent an hour on Thursday afternoon fielding calls from two customers. Their payment terms ran from the invoice date, and they had noticed. The desk's review counted the entries in the ticket: eight, five of them questions, each one reasonable, each one a day of Grace's attention apart. Olu's own note on the review was the lesson, and it is the one this article is built on. He had known all five questions at 10:05 on Tuesday, and had asked one.

The Missing-Information Reply

The reply below is the one to send when a ticket arrives without the facts the owner will need. Keep it as a predefined reply with the numbered list intact. Before sending, delete the questions the ticket already answers. That way, the requester is never asked something they told you. Fill in the reference, the provisional priority and the time you will pick it up, by hand, every time. The reasons in brackets after each question are part of the text; they are what makes it a request rather than an interrogation.

MISSING-INFORMATION REPLY
Delete any question the ticket already answers. Fill every blank by hand.

Subject: Ref ______ — a few details so the right person can start

Thanks, ______. I have your ticket about ______________________ and I
want to get it to the right person with everything they need, so that
you are not asked again later. Could you reply with:

  1. Who is affected, and the best way to reach you this afternoon?
     [so the technician can call rather than e-mail back and forth]
  2. What exactly do you see? A screenshot or the exact words on the
     screen is ideal, and what should happen instead?
     [the exact message usually points straight at the cause]
  3. Which device or system, and where is it? The label on the machine
     or the name on the login page is perfect.
     [so nobody has to come and find it first]
  4. When did it last work, and did anything change around then,
     such as an update, a new password, or a move?
     [most faults start with a change, and the date finds it]
  5. Is anyone else affected, has work stopped, and is there a
     deadline I should know about?
     [this sets how fast it is handled]

Anything you have already tried is useful too, so it is not suggested
again.

Reply with those and I will pick it up within ______. Until then it is
logged as ______ priority under reference ______, and it will reopen
automatically when you reply, with everything above attached.

Three variations earn their place. For a request rather than an incident, replace questions 2 and 4 with "what exactly do you need, and who approves it?" and "when do you need it by?". A request has no symptom and no since-when. For a ticket from a shared mailbox, make question 1 the first line of the message rather than an item, because without it the rest cannot be acted on. For a desk whose tool pauses the clock while waiting on the requester, add a line saying so. For one whose tool does not, say nothing about the clock and set a reminder for the day after tomorrow instead. The requester does not need to know about the clock. The triager does.

Grace's ticket, done this way, is two entries long. The reply above comes at 10:05, with the five questions, and Grace's answer at 10:55 with a screenshot. Her answer says "the invoice system on my PC, label MP-ACC-07". It also says "since Monday morning, the server thing was renamed I think", and "just me so far, but the run is tomorrow". Olu has the fix in by 11:00 and the invoice run goes out on Tuesday. Same ticket, same requester, same four-minute fix. One question instead of five.

Frequently Asked Questions