First-Touch Discipline for Every New Ticket

At 11:12 on a Thursday, Rosa on the reception desk at Harbourview Clinic submits a ticket: "Check-in screen frozen, patients queuing, please help." At 11:12 and four seconds she receives an e-mail that says her request has been received and assigned reference 6621. It says the team will respond as soon as possible. At 11:40 she phones the desk, because the queue in reception is now nine people long and the screen is still frozen. Dev, who is on triage that day, answers the phone, searches for the ticket, and says the only honest thing available: "I haven't seen it yet." Rosa has had a ticket number for twenty-eight minutes. She has not, at any point, had a person.

The auto-reply is not a first touch. It is a receipt, and nobody has ever been reassured by a receipt. The first touch is the first time a human being reads a new ticket and does something with it. They read it properly, tell the requester a person has it and what happens next, and give it a priority and a category. They either claim it or send it to whoever should have it. Done well, it takes about two minutes and changes the requester's day. Skipped, it produces twenty-eight minutes of silence and a phone call.

This article is part of our Ticket Intake & Triage series, and it is the practical companion to What Triage Actually Is. That article explains the three questions a triager answers. This one is about the four things the triager does, in the order they happen, and the reply that goes out at the end.

It covers what the first touch is for. Next come the four steps, one section each: read it properly, acknowledge like a person, set priority and category, route or claim. It then covers the first reply that buys time honestly, with the phrases that work and the ones that quietly cost trust. Then come the two-minute time box and what to do when a ticket will not fit in it, and what goes wrong when the first touch is skipped. It ends with a short war story and the first-reply text and first-touch checklist to copy.

What the First Touch Is For

The first touch does two jobs at once, one for the requester and one for the desk. For the requester, it ends the silence. From the moment they pressed Submit until the moment a person replies, they do not know whether the desk is empty, busy, or ignoring them. The auto-reply does not help, because it would have arrived whether the desk was staffed or on fire. One sentence from a human, inside the hour, answers the question they are actually asking, which is not "when will this be fixed?" but "has anyone seen this?"

For the desk, the first touch guarantees that nothing in the queue is unread. A ticket that has been first-touched has a priority, so the desk knows how much it matters. It has an owner, so the desk knows whose list it is on. And it has a category, so the desk can count it later. A ticket that has not been first-touched could be anything. And the dangerous part of "anything" is that it includes the thing that cannot wait. The pile of unread tickets is where outages hide on a busy morning. And the first touch is the habit that keeps the pile at zero.

Both jobs are done by one person in one pass, and the pass is short on purpose. The first touch is not where tickets are solved; it is where they are seen. A desk that confuses the two ends up with a triager who has solved three tickets beautifully by lunch and left thirty unread. That is a story told at length in What Triage Actually Is. The discipline here is the opposite: see everything, solve nothing, reply to everyone, and do it before the first-response clock runs out.

Step One: Read It Properly

Reading properly means the whole ticket, not the subject line, and it is the step most often skipped because it looks like the easiest. The subject says "Printer". The body says the printer is fine but the label printer on the dispatch bench has been printing blank labels since the overnight update, and dispatch stops at 14:00 when the courier comes. Everything that matters is in the second sentence. A triager who sets "Printing, Low" from the subject has triaged a different ticket from the one that arrived.

Properly also means the attachment and the quoted history. The screenshot often shows the actual error, which the requester did not type because they attached the picture instead. The quoted thread below an e-mailed ticket often shows that the requester already asked a colleague, who already tried the obvious thing, which saves the owner from suggesting it. Thirty seconds of reading saves a round trip, and a round trip on e-mail is rarely shorter than an hour.

The third part of reading properly is a glance at the rest of the queue. Is this the third ticket this morning about the same thing? Then it is not a new ticket. It is a duplicate, or a symptom of an incident that already has a ticket. In that case, the first touch is a merge or a link and one reply rather than a fresh priority and owner. The glance takes ten seconds in a queue sorted by last update, and it is the cheapest way to turn four tickets into one.

What reading properly is not is investigating. The triager reads what the requester wrote and looks at what the requester attached. The triager does not open the log, try the login, or walk to the bench. One look at the monitoring page, to see whether the thing is already known to be down, is allowed because it changes the priority. Anything beyond that is diagnosis, and diagnosis belongs to the owner after the pass. The rule of thumb: if you have opened a second window, you have stopped triaging.

Step Two: Acknowledge Like a Person

The acknowledgement is one short reply, written by the triager, that tells the requester three things. It says a person has read the ticket, what happens next, and when they will hear again. It is not a fix. It is not a promise of a fix. It is the sentence Rosa did not get at 11:14, and it would have changed her morning more than the fix did.

"Read by a person" is conveyed by specificity. "Thanks, Rosa. I can see the check-in screen is frozen and that there is a queue" proves the ticket was read, because the auto-reply could not have written it. "Your request has been received" proves nothing. The requester can tell the difference in the first six words, and so can you, when you are on the other end of it.

"What happens next" names a step, not an outcome. "I am sending this to Priya, who looks after the clinic systems, as an Urgent" is a step. "We will resolve this as quickly as possible" is a wish, and the requester has heard it before, from everyone. The step can be small: "I have it, and I am looking at it after I finish the morning's new tickets, in about twenty minutes." Small and true beats grand and vague every time it has been tried.

"When they will hear again" is a time, and the time must be one the desk can keep. "By 12:00" or "within the hour" is a commitment. "Shortly" is not, and "as soon as possible" is a commitment to nothing, dressed in a tie. The time can be generous. Requesters do not mind being told 15:00 if 15:00 is true. They mind being told "shortly" and then hearing nothing until Friday.

The acknowledgement is also where the triager tells the requester the priority, in plain words, if the requester asked for a higher one. "I have logged this as Medium, which means we aim to have it fixed by tomorrow lunchtime; if there is a deadline I have missed, reply and tell me." One sentence, no apology, no defence of the scale. Most requesters accept a priority they were told; nearly all of them resent one they discovered.

The First Reply That Buys Time Honestly

The first reply buys time by making a small promise and keeping it, rather than by making a large promise and hoping. That is the entire technique. The requester's trust is a loan the desk takes out at the first reply and pays back at the next one. The interest is set by whether the next one arrives when the first one said it would. A desk that says "by 14:00" and replies at 13:50 can say "by 14:00" for years. A desk that says "shortly" has no credit at all.

There are four variants, one for each thing the first touch can conclude. They share a shape: what I saw, what happens next, when you hear again. For an incident that is being routed: "I can see that, and I am passing it to Lena who looks after the warehouse network. She will be in touch by 09:30." For a request the triager will own: "Got it. I have logged this as a new account request; I will set it up today and send the details by 16:00." For a question answered in one line: "Settings, then Mail, then Automatic replies; here is the article with pictures. Closing this one; reply if it does not work." For a ticket missing information: "I need three things before I can place this: which printer, what the screen says, and since when. Reply with all three and I will pick it up the same hour."

Notice what none of the four variants contain. No "sorry for the inconvenience", because nothing has been inconvenienced yet by the desk. No "we take your request seriously", because the sentence after it will show whether that is true. No "please be patient", which is a request for something the desk has not yet earned. And no fix time unless the triager actually knows one, which during a first touch they almost never do. The reply promises the next contact, not the outcome. That is the honest part, and it is also the part that keeps the promise keepable.

The table lists the phrases that cost trust and the ones to use instead. They look like small changes. They are the whole difference between a desk that feels responsive and one that feels like a letterbox.

Write the four variants once, as predefined replies, and the first touch gets faster without getting colder. Most tools let an agent keep a personal set of canned replies, and many let the team share a set, sometimes behind a permission so that the shared ones stay consistent. If yours has neither, a text file open beside the queue does the same job with less ceremony. The reply still gets the requester's name and the specific thing seen typed in by hand, because that is the part that proves a person read it. The canned part is the shape. The typed part is the proof.

Step Three: Set Priority and Category

Priority is set on every ticket during the first touch, by the triager, from the desk's own scale, and never left at the default. The default priority is a trap because it looks like a decision. A ticket at "Medium" might mean a triager judged it Medium or might mean nobody looked, and the two are indistinguishable in the list. If the desk's scale has a Low, use it. A ticket honestly rated Low is a ticket that will not surprise anyone. A ticket left at the default is a ticket waiting to.

The judgement itself, how many affected and how fast it grows, is covered in the Prioritization Frameworks pillar. The scale it maps onto is in Priority Tiers That Are Realistic. So the first-touch rule is only this: decide, record, and say it in the reply if the requester asked for something different. When the triager cannot tell, set the higher of the two plausible answers and ask the one question that would settle it. A priority that comes down with a note at 11:00 cost nothing. A priority that goes up at 16:00 cost the day.

Category is set at the same moment, for the reports, and should take five seconds. The category describes what the ticket is about, so that next month someone can count how many printing tickets there were. If the list is so long that the triager scrolls, or so vague that two categories fit equally, the list is the problem. See Why Categories Exist for where to take it. During the first touch, pick the best fit and move on. (Nobody has ever been promoted for a perfectly categorised ticket.)

Step Four: Route or Claim

The last step gives the ticket an owner. And the owner is a person or a department that will put a person on it, never a group name that means everyone. The triager has three choices. Claim it, if the triager will work it before the next pass. Route it to another department, if it belongs to facilities, HR, a second IT team or the customer desk. Each of these has its own queue. Or assign it to a named colleague, because that colleague owns the system or the site. The choice takes a few seconds once the triager knows who owns what, and the triage card in the companion article has a space for exactly that list.

Claiming has one rule, and it is the one most triagers break on their first week: claim only what you will work before the next pass. The triager who claims everything has an impressive list and a queue that has stopped moving. And the colleagues who could have taken half of it are watching an empty unassigned view. Claim the two you will do this hour. Give the rest names.

Most tools make claiming a one-click action, and some make it automatic. In the automatic kind, any agent who can see an unassigned ticket can take it. Sending the first public reply claims it for whoever sent the reply. That means the acknowledgement in step two and the claim in step four are the same action. A good tool of that kind also tells the second agent when two claim at once. That ends the quiet morning in which two people work the same ticket. In the manual kind, the claim is a separate step and the discipline is to do it before the reply, every time. That way, the ticket never has a reply from a person and no owner. Test yours with two browsers. Whichever kind you have, an agent who is assigned a ticket by someone else should find out at once, and most tools e-mail them. If yours does not, the triager tells them in the chat tool. That is because a ticket assigned to someone who does not know is a ticket assigned to no one.

Routing to a department is not quite the same as assigning to a person, and the triager should know which the tool is doing. A ticket routed to Facilities is now in the Facilities pile, unassigned, and one of them must still claim it. That is fine if Facilities does its own first touch within the hour; it is a slow leak if nobody there triages. The reply to the requester should say which it is: "This is with Facilities, who own desk moves" is true and useful; "This has been assigned" is true only if there is a name on it. The subject of tickets hiding in a group queue is Keeping Tickets From Hiding. Routing is the step where the hiding starts.

The Time Box

The first touch has a time box of about two minutes per ticket. And the box is there to protect the rest of the queue, not to rush the triager. Two minutes is enough to read a ticket properly, decide three things and type a four-sentence reply, once the replies are predefined and the owner list is known. It is not enough to investigate anything, which is the point. When a ticket is taking longer, one of two things is true, and both have a fixed response.

The first is that the ticket is missing information. The triager cannot tell what it is, who should own it or how bad it is, because the requester wrote "the thing is broken again". The response is not to guess and not to investigate. It is to send the missing-information reply, asking for every missing fact at once. The triager then sets the provisional priority and owner, and moves on. The art of asking once is in Gathering the Right Information Up Front. A ticket that leaves the time box with a good question has been triaged. A ticket that leaves it with a bad guess has not.

The second is that the triager has started diagnosing, and the sign is a second window. The log is open, or the console, or the remote session. The response is to close the second window, give the ticket an owner, write the acknowledgement with the next contact time, and continue the pass. If the owner is the triager, the ticket will be waiting in their list in twenty minutes, exactly where it was. In that case, the other fifteen tickets will have been seen in the meantime.

The time box also has an outer edge, which is the first-response target. Most desks promise a first response inside a set time per priority. Most tools count the first public reply from an agent as the first response. That is exactly what the acknowledgement in step two is. A few count the auto-reply, which flatters the number and helps nobody. So check which yours does. Many tools show a countdown beside each ticket in the list, or a view of tickets that are response overdue or due within the hour. In those tools, the triager can see which new tickets are closest to the edge and touch those first. If yours cannot, sort the new-ticket view by time logged and work from the oldest. One detail matters for small desks. In tools that warn the assignee when a target is breached, a breach on an unassigned ticket warns nobody, because there is nobody to warn. The first touch is what puts a name on the ticket in time for the warning to reach someone. The difference between response and resolution targets, and why the first one is the one to protect, is in Response vs Resolution Targets.

What Goes Wrong When the First Touch Is Skipped

The first thing that goes wrong is the auto-reply becomes a decoy. The requester gets a number and assumes a person is coming. The desk sees the auto-reply went out and assumes the requester has been told; and both are waiting for the other. Twenty-eight minutes later there is a phone call. The phone call is now the first touch. That is the most expensive first touch there is, because it interrupts whoever answers and leaves no record unless someone types it in afterwards.

The second is "any update?" A ticket that was acknowledged with a time does not get this reply until the time has passed. A ticket that was never acknowledged gets it on day two, day four and day seven. And each one lands in the same unread ticket, where it waits with the others. A queue full of "any update?" replies is a queue that has told you, politely and repeatedly, that its first touch is missing.

The third is the default priority. Every unread ticket sits at whatever the form or mailbox sets, usually Medium, and the queue looks evenly important from end to end. The Urgent one is in there, at Medium, between a font question and a request for a mouse. Nobody is working the queue in the wrong order on purpose. They are working it in the only order the queue offers, which is arrival.

The fourth is double work, which happens when the first touch is done informally and nobody records it. Two technicians see the same new ticket. Both think "I'll have a look at that". Neither claims it. At 10:15 they meet at the same desk with the same screwdriver. A claim is a one-click action in most tools and it costs nothing. Doing it in your head costs a colleague's morning.

The fifth is the slow leak into other departments. The triager routes the ticket to Facilities, tells nobody, and Facilities, which has no triage habit, finds it on Monday. The requester, who was told "this has been passed to the appropriate team", has had four days to form an opinion about the appropriate team. Routing without a reply that names the destination and a time is not a first touch; it is a forwarding rule with a person attached.

A Short War Story: Twenty-Eight Minutes at Harbourview Clinic

The frozen check-in screen at Harbourview Clinic was, in the end, a seven-minute fix. Priya restarted the kiosk service remotely at 11:47 and Rosa was checking patients in again by 11:50. The cost was the twenty-eight minutes before anyone read the ticket. During that time, nine patients were checked in on paper by hand. Two were sent to the wrong waiting area because the paper list had no room numbers. And the practice manager, Alun, walked through reception, saw the queue, and asked why IT had not been told. He had been told. He had a ticket number to prove it. The desk's review found that the triager had been inside a remote session on a laptop rebuild from 11:05 to 11:38 and had not looked at the queue once. It also found that nothing in the process had required him to. The fix was a rule that the person on triage looks at the new-ticket view at least every fifteen minutes and sends every new ticket a human reply inside that window, before doing anything else. Rosa's ticket had not needed a faster technician; it had needed one sentence at 11:14 saying someone was coming.

The First-Reply Text and the First-Touch Checklist

The block below is the four first-reply variants and, under them, the checklist for the whole pass. Put the replies into your tool as predefined replies and keep the checklist beside the keyboard for the first fortnight. After that the pass becomes a habit and the list becomes a thing you glance at on a bad morning. The blanks are the parts that must be typed by hand every time, because they are the proof that a person read the ticket.

FIRST-REPLY TEXTS — FOUR VARIANTS
Fill every blank by hand. Never send one with a blank left in.

ROUTED TO ANOTHER PERSON OR DEPARTMENT
  Thanks, ______. I can see that ______________________________.
  I am passing this to ______________, who looks after ____________,
  as a ________ priority. You will hear from them by ________.
  Reference ________.

CLAIMED BY ME
  Thanks, ______. I can see that ______________________________.
  I have this, logged as ________ priority, which means ____________.
  I will start on it at ________ and update you by ________ either way.
  Reference ________.

ANSWERED IN ONE LINE
  Thanks, ______. ______________________________________________.
  Here is the short guide: ________________.
  I am marking this resolved; reply to this message if it does not work
  and it will reopen with the history attached.

MISSING INFORMATION
  Thanks, ______. To place this with the right person I need:
    1. ____________________
    2. ____________________
    3. ____________________
  Reply with all three and I will pick it up within the hour.
  Until then it is logged as ________ priority, reference ________.

FIRST-TOUCH CHECKLIST — PER TICKET, UNDER TWO MINUTES
  [ ] Read the whole ticket, the attachment and the quoted history
  [ ] Glanced at the queue for the same problem; merged or linked if found
  [ ] Decided: incident, request, question, duplicate, not ours, cannot tell
  [ ] Priority set from the desk scale, not left at the default
  [ ] Category set
  [ ] Owner set: claimed, routed to a department, or assigned to a name
  [ ] One human reply sent: what I saw, what happens next, when they hear again
  [ ] Priority told to the requester if they asked for a different one
  [ ] Nothing fixed, nothing investigated beyond one look
  [ ] Next ticket

Two adjustments by desk size. A one-person desk can drop the routed variant, because there is no one to route to. The desk keeps the claimed variant honest by naming a start time it can meet with the phone ringing. A desk with several departments in one tool adds the department's own contact line to the routed variant. That way, the requester has a door to knock on if the destination is slow. In both cases, the blanks stay blanks until a person fills them. A predefined reply with the requester's name already in it is an auto-reply with better manners.

Rosa's ticket, done the way this article says, reads like this at 11:14: "Thanks, Rosa. I can see the check-in screen is frozen and there is a queue. I am passing this to Priya, who looks after the clinic systems, as an Urgent; she will call reception within fifteen minutes. Reference 6621." Four sentences, forty seconds, and the twenty-eight minutes do not happen. The fix still takes seven minutes. The difference is that nobody spends them wondering whether anyone is coming.

Frequently Asked Questions