Capturing Add-Ons as Tickets in Thirty Seconds

Wednesday, 14:40, on the finance floor at Northgate Retail. Marcus has just finished ticket 7311, a label printer that would print everything except labels. He is winding the cable back onto the spare he brought in case. Jenna, whose printer it was, says the thing everyone says. "While you're here — since I got the new laptop, the shared mailbox doesn't show up for me. It's probably something simple." Marcus does not sit back down. He takes his phone out, opens the desk's web form, and types, with his thumbs, while she watches: "Jenna, finance, 2nd floor. Shared mailbox not visible on new laptop since swap. Desk-side add-on, visit 7311." He presses submit. "That's 7318," he says. "It's in the queue with your name on it, and whoever picks it up will probably sort it remotely. You'll get the e-mail in a minute." The whole exchange has taken about forty seconds, and he is in the lift by a quarter to three.

Capturing an add-on means turning a request made at a desk-side visit into a ticket, on the spot, before the technician leaves. It means doing nothing else with it there. The ticket is the whole of the response. It is not a promise to remember, not a note on a pad, and not a fix. The previous article in our While You're Here series argued that the visit is for one ticket and that the add-on belongs in the queue. This one is about the thirty seconds that put it there. That is the only part of the whole series that happens with the user watching. Get the thirty seconds right and the rest of the series mostly looks after itself.

It covers what capture is and what it is not. Next come the three routes to log it now, then what goes into the thirty-second ticket and what stays out. We cover the linked ticket rather than the merged one, then the sentence that says it is logged. Next come triage later, not now, and why "I'll remember" does not work. We cover the user who says not to bother, then making the habit stick on a team. We finish with a short war story and the add-on capture note to copy, in that order.

What Capture Is, and What It Is Not

Capture is the creation of a ticket that exists, not a ticket that is complete. That distinction matters because technicians imagine logging as the full intake. That means a category, a priority, a proper description, a diagnosis, and perhaps a first attempt at the fix. That is why they do not log add-ons on the spot. That full intake is ten minutes, and nobody has ten minutes standing at a desk. A captured ticket has four things in it: who, what, where and which visit it came from. The rest is added later by whoever triages the queue. Thirty seconds is a generous estimate for four things. Marcus did it in forty with a phone and a label printer cable in his other hand.

Capture is not a note to self, and it is not a note to the user either. "I'll make a note of that" is the sentence the add-on has been hearing for years, and the add-on has learned what it means. A note on paper, a reminder on a phone, an e-mail to yourself at the end of the day: each is a ticket that has not been logged yet. The person taking that note is about to walk into another visit and another add-on. The only capture that counts is the one that produces a ticket number before the technician leaves the desk. The number is the thing the user can quote and the thing the queue can see.

Capture is also not a fix, and the discipline is in not starting one. The hardest part of Marcus's forty seconds was not typing. It was not opening the mailbox settings "just to see", because he had a fair idea what the problem was and it would probably have taken five minutes. Probably. When a probably-five-minutes add-on is done on the spot is the subject of The Two-Minute Rule and Its Limits, and "probably" is not one of the conditions.

The Three Routes to Log It Now

There are three ways to create a ticket from someone else's desk. And a technician should be able to do all of them without thinking, because thinking is what takes the thirty seconds past a minute. The first and best route is the phone: the desk's web form, or a short e-mail to the desk's own address. The request is sent from the technician's own phone with the user's name in the first line. It works anywhere in the building, and it needs no sign-in on the user's machine. And the ticket arrives in the queue the same way every other request does. Bookmark the form. Put it on the first screen. A route that takes three taps to reach is a route that gets skipped at the fourth visit of the afternoon.

The second route is the user's own machine. Open the portal or the form there, and have the user type the one line themselves, or type it for them with their name on it. This is slower by a little. It has one advantage the phone lacks: the user sees their own request go into the queue in their own words. They learn, without being told, how to do it next time. For a how-do-I question, it is also the natural moment to show where the knowledge base is. Use this route when the user is already signed in and the portal is a click away. Do not use it if signing in would take longer than the ticket.

The third route is the pocket note, and it is a last resort with a hard rule attached. The note becomes a ticket before the next visit starts, not at the end of the day. It is for the basement with no signal, the user whose machine is the thing that is broken, and the technician whose phone has died. The rule is strict because the pocket note is where add-ons go to disappear. And the walk between two visits is the last moment at which the note is still attached to a memory of what the user actually said. The table below has the three routes, what each needs, and the way each one fails.

What Goes Into the Thirty-Second Ticket

Four things go in, and the first is the requester's name, because a ticket without a requester is a ticket nobody will ever get an update about. On the phone route the technician is the one submitting, so the user's name goes in the first line of the description. Whoever triages moves it into the requester field. Then the symptom, in one line, in the user's own words where possible: "shared mailbox not visible on new laptop since swap" is better than "mailbox issue". It is also better than the technician's guess at the cause, which may be wrong and will anchor the next person. Then where: the floor, the room, the device if it has a label. And then the visit it came from, as a ticket number, so that the add-on can be linked and counted later.

Mark the source, because the source is what makes the add-ons countable as a group later. Most tools record where a ticket came from, e-mail, form, phone, or chat. And the add-on logged from a phone will show as "form" or "e-mail" like everything else. A convention fixes that: the words "desk-side add-on" in the first line, or a tag or custom field if the tool offers one. A search for the phrase then returns every add-on the desk has captured. The last article in this series depends on this one line entirely. Without it, add-ons are just tickets, and nobody will ever learn that a third of them came from the same floor.

Three things stay out, deliberately. The priority stays out, because the technician at the desk can see one ticket and the triager can see the queue. A priority set by the person who can see the least is a guess with a label on it. The category stays out, for the same reason and because the triager will set it in two seconds with the taxonomy in front of them. And the diagnosis stays out, because a thirty-second ticket that says "probably a profile issue" has just told the next technician where to look. The next technician will look there for twenty minutes before looking anywhere else. Write what the user said. Let the queue work out what it means.

The Linked Ticket, Not the Merged One

The add-on is linked to the visit's ticket, not merged into it, and the difference is the difference between a record and a mess. Linking connects two tickets so that each shows the other; merging folds one into the other so that only one survives. The visit's ticket is about the label printer and it closes today. The add-on is about a mailbox and it has its own life: its own owner, its own priority once triaged, its own fix, its own close. Merge them and the mailbox lives inside a closed printer ticket, invisible to every report and reopened by nobody. Link them and the mailbox is a ticket in its own right that also remembers where it came from.

The link pays off in both directions. From the add-on, the triager can open the visit's ticket and see what the technician was there for. That often explains the add-on: a new laptop was swapped in and the mailbox was never re-added. From the visit's ticket, anyone reading it later sees that two further requests arrived at the same desk. That is how a desk eventually notices that one floor generates add-ons the way another floor generates printer tickets. If you run QuerySolv, the add-on logged from the web form on your phone lands in the same queue as the e-mails and chat requests, as an ordinary ticket. Linking it to the visit's ticket keeps the two connected without either losing its own history. Most tools can link; a few can only merge. For those the link is a line in each ticket quoting the other's number, which is clumsier but does the same job.

The proxy request, "could you look at Mel's machine while you're here", gets a ticket in Mel's name, not Jenna's. It is Mel's problem, Mel will get the updates, and Mel may not have wanted a technician at all. The ticket in her name lets the desk ask her before anyone walks over. It is still linked to the visit, and it still has "desk-side add-on" in the first line, because it is one, just one removed. Logging it in Jenna's name because Jenna is the one talking is how a desk ends up with a requester who cannot answer a single question about her own ticket.

The Sentence That Says It Is Logged

The ticket is only half the capture; the other half is the sentence, and it has four parts. It is logged. Here is the number. Here is what happens next. Here is how you will hear. "That's logged as 7318, it's in the queue with your name on it, someone will pick it up and probably sort it remotely, and you'll get an e-mail with the number in a minute." Every part answers a question the user has not asked yet. And the number is the part that makes the rest believable, because a number is a thing that exists. "I've logged it" without a number is a sentence; "7318" is a receipt.

The sentence is honest about what happens next, which means it does not promise a time the technician cannot see. The triager will set the priority against everything else in the queue. And the technician at the desk does not know what else is in the queue. So the sentence says "someone will pick it up", not "I'll do it this afternoon". If the user asks when, the honest answer is "I can't see the queue from here, but you'll get an update when someone takes it, and you can reply to the e-mail if it gets worse". Honest expectations for a ticket in a queue have a whole series of their own. Honest ETAs is the one for this moment, and its advice fits in a sentence: name the next step, not the finish.

Say the sentence every time, including when the add-on was done on the spot under the two-minute rule. The sentence "I've fixed that and logged it as 7319 so there's a record" is how the user learns that everything the desk does has a number. Users who know that stop saving things up. A ticket, they have learned, is not a hurdle in front of the help; it is the help, with a receipt.

Triage Later, Not Now

Triage is the first look at a new ticket to decide what it is, how urgent it is and who should have it. The whole point of capturing on the spot is that triage happens somewhere else. The technician at Jenna's desk can see Jenna's problem. The triager may be the desk lead, a rota, or whoever has the first-touch duty that day. They can see Jenna's problem next to the thirty-eight others that arrived this week and can place it. What triage is, and why the first look should be a sort rather than an attempt at a fix, is in What Triage Actually Is. The discipline of touching each new ticket once, quickly, and moving on is the next article in that series. The captured add-on is just a new ticket, and it gets exactly that treatment.

Triage is also where the add-on turns into something more useful than itself. The triager who sees the third "shared mailbox missing after laptop swap" in a fortnight does not just assign it; they notice it. And the laptop swap process gets a step it was missing. The how-do-I question about the shared calendar becomes a knowledge base article, or a link to one that already exists. The user could have been sent that link in the first place. The "sometimes" monitor joins two other "sometimes" monitors from the same floor and becomes a question about that floor's docking stations. None of this happens if the technician fixes the add-on at the desk, because nobody but the technician ever sees it, and the technician sees it one at a time.

Resist the urge to triage at the desk with the user watching, because it is slow and it is public. The user does not want to see a technician choosing between "medium" and "low" for their mailbox; they want a number and a next step. The queue has never once been embarrassed by a priority.

Why "I'll Remember" Does Not Work

Memory fails in a specific way on a desk, and the specific way is that it holds the first add-on of the afternoon and loses the third. Marcus can carry Jenna's mailbox in his head to the lift. He cannot carry it, the slow laptop on the third floor and the projector remote on the fourth to the end of the day. And he does not notice which one he dropped, because a dropped memory does not feel like anything. The user whose add-on was dropped notices in about a week, when nothing has happened. The next thing the desk hears is "I told your technician about this last Wednesday", which is true, and which no ticket can confirm or deny.

The arithmetic is lopsided in favour of logging. Capturing at the desk costs thirty to sixty seconds. Remembering costs nothing now and, at the end of the day, five to ten minutes of "what was that thing on the second floor, and who was it". That is followed by a ticket with half the information. On a bad day, it is followed by an e-mail asking the user to repeat what they said while the technician stood there. I kept pocket notes for most of a year, early on. And the ones that became tickets were the ones I found before the trousers went in the wash.

The deeper reason is the one in Keeping Tickets From Hiding: work that is not in the queue is work the desk cannot see, plan, count or defend. An add-on remembered is a ticket hiding in a technician's head, which is the one place no report can reach.

The User Who Says Not to Bother

Some users, hearing the phone come out, will say "oh, don't log it, it's not important", and they mean it kindly. Log it anyway, lightly, and say why in one sentence: "It's no trouble, and it means it won't get forgotten, which it would if it stayed in my head." Nobody has ever objected to that sentence. The user was trying to save the technician work. And the technician has just explained that the ticket is less work than not having one, which is true and which most users have never heard.

Occasionally "don't bother" means "I don't want to be the person who complained about the printer", and that deserves a straight answer too. Faults the technician notices herself, or that a user mentions about shared kit, go in as desk-raised tickets. Those tickets have the technician's name on them and the location in the first line. That way, the printer gets fixed and nobody is on record as having complained about it. A desk that makes people feel reported-on for mentioning a broken printer will stop hearing about broken printers, and will find out about them from the backlog instead.

Then there is the user who, having seen the first add-on logged, produces four more, and this is the moment to be glad of the phone. Four add-ons take three minutes to capture and three hours to fix. Capturing all four, with four numbers, is a far better outcome than fixing one and forgetting three. Say the numbers as they come. The hallway version of this, where the requests arrive before you have a ticket at all, is handled in The Hallway Request, Handled Well. The two articles agree on the only thing that matters: every request leaves the conversation with a number.

Making the Habit Stick on a Team

The habit takes about a fortnight to form and it forms faster if the desk can see it forming. The desk lead's check is one search a week: every ticket with "desk-side add-on" in the first line, counted against the week's visits. In the first week the count will be low, not because add-ons stopped arriving but because they are still being done on the spot or remembered. The number is a prompt for a conversation rather than a judgement. A technician whose twelve visits show no add-ons at all has either had an unusually quiet week or is still fixing them in person. And the difference is one question, asked kindly.

Make the route trivial before asking for the habit. The web form bookmarked on every technician's phone, on the first screen. The desk's e-mail address in the phone's contacts. A card in the toolkit with the four things that go in and the sentence to say, for the first fortnight, after which nobody will need it. Technicians do not skip capture because they disagree with it; they skip it because the form was four taps away and the user was still talking. Fix the taps.

Then let the captured tickets do the persuading. Two weeks in, the triager will have found a pattern nobody knew about. By then, a knowledge base article will have been written from three how-do-I questions, and a floor's docking stations will be under suspicion. Show the team that, and the thirty seconds stop feeling like paperwork. The pocket note never told anyone anything.

A Short War Story: The Signing Tablet at Ashgrove Housing

At Ashgrove Housing, a technician called Femi visited the Northside branch office to replace a failed monitor. As he was leaving, a housing officer called Carol mentioned that the tablet they used for tenancy signings had stopped holding a charge. It now had to stay plugged in, which was awkward but workable. Femi said he would make a note of it, and he did, on the back of the monitor's packing slip. The slip went into the recycling with the box that afternoon. Eleven days later the tablet died in the middle of the branch's signing day, with four tenancies to complete. The officers did them on paper and re-keyed everything over the following two days. The branch manager put that at eleven hours of staff time plus a complaint from a tenant whose paperwork went astray between the two systems. When the desk lead searched the queue for the tablet, there was nothing. When she asked Carol, Carol said "I told Femi about it when he came for the monitor". Femi, who had genuinely meant to log it, could only agree. The replacement tablet took a day to arrive and would have taken the same day eleven days earlier. The lesson the desk wrote down was that an add-on is captured as a ticket before the technician leaves the desk, from the phone, with a number said out loud. A note is a ticket that has not been lost yet.

The Add-On Capture Note

The capture note below is in two halves. The ticket is what goes into the form or the e-mail in thirty seconds. The sentence is what the technician says once the number comes back. Keep the ticket half to four lines; everything else belongs to triage. Keep the sentence half to the four parts; everything else is a promise you cannot see from the user's desk. The last block is for the proxy request and the desk-raised fault, which follow the same shape with a different name at the top. Put the note on a card in the toolkit for a fortnight, and after that it will be in the technician's thumbs.

THE ADD-ON CAPTURE NOTE — THIRTY SECONDS, THEN LEAVE
Route used:  phone form / phone e-mail / user's machine / pocket note (entered before next visit)

THE TICKET (four lines, nothing more)
  Requester: ______________________  (the user's name; in the first line when sent from the phone)
  Symptom in their words: ____________________________________________
  Where: floor ______  room/desk ______  device label ______
  Source and visit: desk-side add-on, from visit ticket ________

  Leave OUT: the priority, the category, the diagnosis. Triage sets those.

THE SENTENCE (say all four parts)
  "That's logged as ________.
   It's in the queue with your name on it.
   Someone will pick it up and ______________________ (next step, not a finish time).
   You'll get the e-mail with the number shortly; reply to it if it changes."

IF THE ADD-ON WAS DONE ON THE SPOT (two-minute rule)
  Log it anyway, in the same four lines, with "done at visit" in the symptom line.
  Say: "I've fixed that and logged it as ________ so there's a record."

IF IT IS SOMEONE ELSE'S PROBLEM (the proxy request)
  Requester: the colleague's name, not the person asking.
  Add: "mentioned by ______________ at visit ________; check with requester before visiting."

IF IT IS A FAULT NOBODY WANTS THEIR NAME ON (shared kit, the printer)
  Requester: the technician.   Symptom line starts: "desk-raised at visit ________:"

Jenna's ticket, 7318, was picked up at ten past three by Ines on the desk. Ines recognised it as the third missing shared mailbox since the laptop swaps began. Ines added the mailbox remotely in four minutes, and wrote a line in the laptop swap checklist so there would not be a fourth. Jenna had her mailbox back before Marcus had finished the visit he went to next. She has raised two tickets herself since, both from the portal, both in one line, both with the floor in them. Nobody told her how. She watched someone do it with their thumbs.

Frequently Asked Questions