The Desk-Side Visit and Its Scope: One Ticket, One Visit

Tuesday, 10:02, at Meridian Parts. Dana walks up to the second floor with a docking station under her arm for ticket 4408. The ticket says that Rob's dock has stopped charging his laptop. The swap takes six minutes. She plugs in the laptop, watches the charging light come on, confirms the two monitors wake up, and writes four lines into the ticket on her phone while Rob signs back in. She stands up. "While you're here," Rob says, in the tone of someone who has been saving it, "my second monitor goes black sometimes. Only sometimes. Could you have a quick look?" Dana has an appointment on the fourth floor at half past ten. She looks. It is a quarter to eleven when she gets to the fourth floor, and the second monitor still goes black sometimes.

A desk-side visit is a technician going to a user's desk to work one ticket in person. The fix needs hands on the machine, a part, or eyes on a symptom that will not travel down a phone line. An add-on is any request made during that visit that is not the ticket the visit was for. It usually begins with the three words in the title of this series, and it is the most reasonable request a user ever makes. That is exactly why it is so expensive. This article is part of our While You're Here series, which is about the add-on at the desk-side visit. It covers how to honour it without doing it on the spot, and how to keep the visit to the one ticket you went for. The hallway request, the corridor ambush and the chat message that bypasses the queue are a different animal with its own series, The Walk-Up and Drive-By Culture. Here the technician has already arrived, for a reason, with a clock running.

It covers what a visit is for, then the add-on and where it comes from. Next come why it is hard to say no in person and the cost in hours from one month at a fictional desk. We cover the visit's scope, written down before you stand up, then the three honest answers to "while you're here". Next come the same morning drawn twice and holding the scope without being cold. We finish with a short war story and the visit card to copy, in that order.

What a Visit Is For

A visit exists to close one ticket, and everything about it is sized to that ticket. The time you block out and the part you carry are all derived from the one line in the queue that sent you. So are the note you plan to write and the moment you plan to leave. The visit is the most expensive thing a desk does per ticket. It takes the technician away from the queue, away from the phone and away from every other ticket for as long as it lasts. The walk there and back adds to that. A desk of four that does thirty visits a week has one technician's entire week in corridors and at other people's desks. That is fine when the visits are the right length. It is not fine when they are not.

The visit produces three things, and the ticket is only the first. The fix, tested with the user watching. The note, written at the desk and not from memory an hour later, which is a habit with its own article later in the library. And an on-time departure, so that the next visit starts when the next user was told it would. The third one is the one nobody thinks of as a deliverable. It is also the one the add-on destroys first.

The scope of a visit is the scope of its ticket, and this is the sentence the rest of the series rests on. If ticket 4408 is "dock not charging", the visit is "dock not charging". The monitor that goes black sometimes is a different ticket, whether or not it is also at Rob's desk. That holds whether or not Dana is already standing there, and whether or not it would probably only take a minute. The desk decided, when it accepted the ticket, how much time the problem was worth and when it would be worked. The add-on asks the technician to make the same decision again, alone, on her feet, with the user watching. She is the worst-placed person on the desk to make it.

The Add-On, and Where It Comes From

Add-ons come from a perfectly rational place, and it helps to see it before deciding what to do about it. Users save things up. The monitor that goes black sometimes is annoying but not worth a ticket, or the user thinks it is not. Or the user has tried once to describe "sometimes" in a form and given up. Then a technician appears in person, for a different reason. For the first time in weeks the cheapest way to raise the monitor is to say it out loud. The user is not being pushy. The user is doing what anyone does when the dentist is already looking in their mouth.

Three kinds of add-on arrive at nearly every visit, and they are worth telling apart because they get different answers later. The first is the saved-up fault: something broken that the user never reported, like the monitor, the printer that "has been like that for ages" or the laptop fan that sounds wrong. The second is the how-do-I: a question about the shared calendar, a setting, a feature, which is not a fault at all. It is usually a knowledge base article nobody has written. The third is the proxy request: "and while you're here, could you look at Mel's machine, she's just over there." Mel has not raised a ticket either. Mel may not even know she is about to be visited.

Every one of these is a legitimate piece of work the desk would happily do through the queue. None of them is the ticket Dana came for. The whole difficulty is that the request is good and the timing is wrong. And most technicians, hearing a good request, have never been taught that timing is allowed to be the reason for a no.

Why It Is Hard to Say No in Person

It is hard because the no has a face in front of it. A ticket in the queue can be left until Thursday without anyone feeling anything. A person who has just asked, politely, for a quick look at their monitor is standing eighteen inches away. The social cost of "not now" lands immediately on the technician. The cost of "yes" lands on the user on the fourth floor, who is not in the room. Humans discount costs that are not in the room. The fourth floor is very much not in the room.

It is hard because the request is reasonable. Nobody is asking for anything the desk would refuse in writing; they are asking for it in a place and at a time that the desk did not choose. Take a technician who has been trained that the job is to help, and who is good at the job. For that technician, "I can't look at that now" sits badly with the whole reason they took the job. The no feels like a failure of character rather than a management of time, and it is the second thing, not the first.

It is hard because of pride, and I say this as someone with a fair amount of it. The monitor that goes black sometimes is interesting. The docking station was not. A technician standing at a desk with a toolkit and a diagnosis forming in her head wants to be the person who found it. The add-on offers that in exchange for twenty minutes she does not have. I have taken that trade more times than I would admit to a desk lead, and the fourth floor has waited every time.

And it is hard because the cost is invisible to everyone but the next user. Rob is delighted. Dana feels useful. The desk lead sees a technician who is "always out helping people", which sounds like praise. The only person who sees the cost is the user at the fourth-floor appointment. And she sees it as a technician who was late, not as a monitor on the second floor. The add-on is the only kind of work on a desk where doing it well makes the queue worse and everyone involved feels good about it.

The Cost in Hours: One Month at Meridian Parts

The cost is best shown with a month, so here is a fictional one, with the numbers invented for the example and stated as such. Meridian Parts has a desk of four and a workforce of about three hundred across two buildings. In the month before the desk lead, Kemi, started paying attention, the technicians made fifty-eight desk-side visits. She asked them to note, for a fortnight, every add-on that arrived during a visit and roughly how long it took. Then she doubled the fortnight to get the month. The notes gave her seventy-one add-ons, which is a little over one per visit. They averaged about fourteen minutes each, with the longest at fifty minutes and a few at under two. Call it sixteen to seventeen hours in the month, which is two full working days of one technician. That was spent on work that was never in the queue, never prioritised and never counted.

The seventeen hours were not the whole cost, and this is where it gets uncomfortable. Each add-on done on the spot pushed the next appointment back. The technicians, being decent people, often skipped the note or shortened it to make up time. So the ticket they had gone for was closed with "replaced dock" and nothing else. Eleven of the seventy-one add-ons were "sometimes" faults that could not be reproduced in the time taken. So the time was spent and the fault was still there, with no ticket to carry it forward. And four of the month's satisfaction comments, out of about forty returned, mentioned a technician arriving late. Kemi put the whole thing in a table for the desk, which is below with the arithmetic shown. The desk stopped arguing about whether the add-on was a problem and started arguing about what to do, which is the right argument.

Your numbers will differ, and the point is not the seventeen hours; it is that the hours existed and nobody could see them. A desk that captures its add-ons as tickets, which the next article teaches in thirty seconds a time, does not do less of this work. It does the same work later, in order, with a note. And the seventeen hours finally appear in the reports where they can be planned for. The last article in the series is about what those reports then reveal. And it is more than you would guess from a month of monitors.

The Visit's Scope, Written Down Before You Stand Up

The defence against the add-on starts before the visit, not during it, and it is a written scope. Before a technician leaves the desk, the ticket says what the visit is for, what "done" looks like, how long it has, and when the next appointment is. That takes about a minute and it changes the conversation at the user's desk completely. The technician is no longer deciding on her feet whether the monitor is in scope. The scope was decided at the desk, in the queue, before she stood up. She is just reading it.

"Done" is the part most people skip, and it is the part that stops the visit stretching from the inside. "Dock not charging" is a symptom; "laptop charges from the dock, both monitors wake, user signed in and working" is a finish line. Without it, a technician will keep going as long as there is anything at the desk that could be better. There is always something at a desk that could be better. With it, she tests three things, writes the note, and the visit is over. The add-on is then visibly outside a line that already existed.

Some add-ons are outside not just the visit but the desk, and that is a different conversation with its own articles. The user might ask, while you are there, whether you could set up their personal tablet, look at their home printer, or install the thing their nephew recommended. That user is asking for something the desk has decided not to do at all. The answer comes from the scope page, not from the visit card. The thinking behind that page lives in Scope Boundaries. And the words for the no itself, which are harder than the policy, are in Declining Out-of-Scope Requests. The visit card only has to say: not this, not now, logged.

The Three Honest Answers to "While You're Here"

Every add-on gets one of three answers, and a technician who knows all three before the visit does not freeze when the words arrive. The first is do it now, which is the right answer for a genuinely two-minute task with everything in hand and no next appointment at risk. Even then the task is logged, because work that is not in a ticket did not happen as far as the desk's reports are concerned. The rule, and the ways two minutes becomes twenty, has its own article, The Two-Minute Rule and Its Limits. And it is a shorter list of exceptions than most technicians hope.

The second answer is capture it: log the add-on as a ticket there and then, from your phone or the user's own machine. Say that it is logged, give the number, and leave on time. This is the answer for almost everything, including the saved-up fault that is interesting and the how-do-I that would take ten minutes to explain properly. It includes the proxy request for the colleague two desks over. The add-on is not refused. It is accepted into the queue, where it will be prioritised against the forty other things in there by someone who can see all forty. The technician at Rob's desk cannot.

The third answer is not something the desk does. And it is the rarest of the three at a visit, because most add-ons are real work. When it comes, the technician says so plainly, points at where the scope is written, and offers whatever the alternative is. She does not apologise for a policy she did not write and should not be defending alone. If you run QuerySolv, or any tool that pulls every channel into one queue, the capture answer is especially cheap. In that case, the add-on logged on the spot lands in the same queue as the e-mails and the form submissions and is triaged with them. That is what makes "I've logged it" a true sentence rather than a polite one.

The Same Morning, Drawn Twice

The picture below draws Dana's morning two ways on the same clock. In the top version she works the docking station for twenty-five minutes and then takes the four add-ons that arrive, in order. First come the monitor that goes black sometimes and a question about the shared calendar. Next come a colleague's laptop that has been slow since Tuesday and a printer nobody had reported. The add-ons run the visit to twenty to twelve, past the planned end at twenty to eleven, past the eleven o'clock appointment. And the fourth-floor user waits forty minutes for a technician who is, at that moment, under a desk two floors down looking at a printer. In the bottom version she works the same ticket and logs the four add-ons as tickets in about four minutes between them. She writes a proper note, leaves at twenty-five to eleven with a buffer in hand, and is at the fourth floor at eleven. The four add-ons are in the queue. Nothing was refused. The only thing that changed is when.

Look at the bottom row of the picture for a moment, because it is the part people miss. The four blue boxes in the queue are the same four problems. In the top version they were worked in the order they were mentioned, by whoever happened to be standing there, for as long as they took. In the bottom version they will be worked in the order the desk chooses, by whoever is best placed, with a note each. The printer that nobody reported will finally have a ticket number, which it has been needing for a month. The top version looks like better service from Rob's desk. The bottom version is better service from everywhere else.

Holding the Scope Without Being Cold

The scope only holds if the technician can say it kindly, so the words matter more than the policy. The sentence that works is short, true and ends with an action: "I can't look at that in this visit, because I'm due on the fourth floor at half past, but I've logged it just now as 4411 and someone will pick it up from the queue." Every clause earns its place. The constraint is real and named. The request is accepted, with a number the user can quote. And the technician is not the person who decides when the monitor gets looked at, which takes the decision out of the room, where it belongs.

Avoid the three sentences that make the no feel like a wall. "That's not what I'm here for" is true and sounds like a door closing. "You'll need to raise a ticket" is true and makes the user do work the technician could do in thirty seconds standing there. "I'll try to come back later" is not true, in my experience, and the user will remember it at the next visit. The user is not being managed. They are being told, honestly, when their problem will be looked at, by a desk that has written down how it decides. That is a better answer than most people get from most organisations about anything.

The user who pushes, "it'll only take a minute, honestly", is not being difficult. It helps to say the real thing: "It might, and if it turns out to be the cable I'll be cross with myself, but the last three 'sometimes' monitors I looked at took half an hour each, and Priya on the fourth floor has been waiting since Monday." Most users, hearing that there is a Priya, stop pushing. The few who do not are the subject of a later article in this series, about the schedule and the manager's backing when the complaint arrives. It will arrive. It is a shorter conversation than you fear.

A Short War Story: The Fourth Floor at Tollgate Foods

At Tollgate Foods, a technician called Marek was the desk's favourite person to send on visits, because he was good with people and nobody ever complained about him. For about a year the desk lead, Sunita, read his long visits as thoroughness. Then a payroll clerk called Beth had an appointment for a failing hard drive on a Thursday at two. She waited until twenty past three, during which the drive failed. The recovery that followed cost the finance team most of a day's work re-keying the week's timesheets and the desk two evenings restoring what it could. Sunita pulled Marek's last twenty visits from the ticket history. She found that the average ran to an hour and ten minutes against the thirty the desk planned for. Almost none of the extra time was in any ticket. On the Thursday he had been at the previous desk replacing a mouse, fixing a shared drive mapping and then looking at a colleague's laptop. None of that had been reported and none was urgent. Marek had not been slow; he had been doing three unlogged tickets per visit and calling it one. The lesson Sunita wrote on the desk's scope page was that a visit is one ticket, and an add-on is a ticket too. The user who waits for a late technician is the one person who pays for everyone else's "while you're here".

The Visit Card

The visit card is a one-page record filled in before the technician stands up and finished at the user's desk. And it is the scope made visible: one ticket, one finish line, one leaving time, and a place for every add-on that arrives. Fill in the top half at the desk, from the ticket, and the bottom half on the phone as the add-ons arrive. The card lives in the ticket as a note when the visit is over. The add-on lines become their own tickets, linked to the visit's ticket, in the way the next article describes. A card with three add-ons and an on-time departure is a successful visit. A card with no add-ons and a forty-minute overrun is a visit where somebody did not fill in the bottom half.

THE VISIT CARD — ONE TICKET, ONE SCOPE
Ticket: __________   Requester: ______________   Location: ______________
Technician: ______________   Planned start: ______   Planned end: ______
Next appointment after this one: ______ at ______________

THE SCOPE (filled in at the desk, before leaving)
  The visit is for: ____________________________________________
  "Done" looks like:
    [ ] ______________________________________
    [ ] ______________________________________
    [ ] ______________________________________
  Parts or kit to carry: ______________________________________
  Anything in the ticket history to read first: __________________

AT THE DESK
  Arrived: ______   Fix tested with the user watching: [ ]
  Note written at the desk, not later: [ ]

ADD-ONS THAT ARRIVED (one line each; never worked in this visit
unless it meets the two-minute rule, and logged even then)
  1. ______________________________  Answer: do now / captured / not the desk
     Ticket number given to the user: __________
  2. ______________________________  Answer: do now / captured / not the desk
     Ticket number given to the user: __________
  3. ______________________________  Answer: do now / captured / not the desk
     Ticket number given to the user: __________

LEAVING
  Left at: ______   On time: yes / no   If no, minutes over: ______
  Next appointment told if running late: [ ]
  Card copied into the ticket as a note: [ ]

Dana filled in her first card the following Tuesday, for a keyboard on the third floor. She wrote "keyboard replaced, user typing, no stuck keys" as the finish line before she left the desk. Two add-ons arrived, as they do. One became ticket 4431 while she stood there. The other was a question about the shared calendar, which she logged too, with a note that it was probably a knowledge base article nobody had written. She was at the next appointment four minutes early. Rob's second monitor, logged as 4411 the week before, turned out to be a cable with a bent pin, and took a different technician nine minutes on the Friday. It would have taken Dana nine minutes too, if she had known it was the cable. That is the whole point: nobody knows at the desk, and the queue is where you find out.

Frequently Asked Questions