The Desk-Side Visit Done Well, From Arrival to Leaving

Tuesday, 09:55, in the lift at the Bluewater Bank regional office. Nadia is reading ticket 6204 on her phone on the way up to the fourth floor. Tom, a mortgage adviser, reports that the signature pad customers sign on keeps disconnecting mid-appointment. The history shows the same pad was reported three weeks ago and "fixed" by reseating its cable, by a colleague who wrote exactly that and nothing else. Nadia has a replacement pad and a new cable in her bag, because a fault that came back after a reseat is a fault that wants a part. The finish line she wrote before leaving the desk reads "pad stays connected through three test signatures, Tom confirms". At 10:00 she is at his desk. At 10:24 she is walking away from it with the pad replaced, the note written, and two add-ons logged with their numbers read out. She has six minutes in hand before the half-ten visit on the floor below. Tom's next customer is at half past, and the pad will work.

A desk-side visit done well is one that arrives prepared and fixes the thing it came for with the user watching. It leaves a note that the next technician can use. It invites the add-on on purpose and captures it rather than doing it. It leaves on time with the user feeling served rather than hurried. Every earlier article in our While You're Here series has been about one part of that. This one walks the whole visit from the lift to the corridor afterwards, in order. A visit is a sequence, and most of its failures are a step done out of order or not at all.

It covers what to do before you stand up, then arriving and the fix with the user watching. Next come the note written there and not later, asking "anything else?" deliberately, and leaving on time and kindly. Then come the few minutes after the visit and the three sentences that carry a visit. A short war story and the visit checklist to copy finish the article, in that order.

Before You Stand Up

A visit is won or lost before the technician leaves the desk, and the first step is to read the ticket, all of it, including the history. The history is where the previous fix lives. A previous fix that did not hold is the most useful sentence in the ticket, because it tells you what not to try again. Nadia's colleague reseated the cable three weeks ago; Nadia therefore knows the cable is either not the fault or not the whole fault, and brings a pad. A technician who arrives having read only the subject line will reseat the cable, declare it fixed, and be back in three weeks with the same bag.

Then write the finish line and pick the kit from it. "Pad stays connected through three test signatures, Tom confirms" tells Nadia what to carry: a pad, a cable, and the sign-in she needs to pair a new one. It also tells her how long the visit is, which is how the schedule from the previous article gets its honest number. A visit without a finish line is sized by guesswork and stocked by hope, and hope has never once brought the right cable.

Last, know the next appointment and the user's name, and say both to yourself in the lift. The next appointment is the honest reason you will give when the add-on arrives, and you cannot give it convincingly if you have to check. The user's name is what makes "Morning, Tom" the first thing you say rather than "are you the signature pad?", and it costs nothing. Users notice the difference between a technician who came for them and one who came for a fault. Both fix the pad. Only one gets asked back by name.

Arriving

The arrival is three sentences, said with the bag still closed. Who you are and which ticket: "Morning, Tom, I'm Nadia from the desk, here for 6204, the signature pad." The symptom in the user's words, checked: "It's dropping out partway through a customer signing, is that right, and does it come back by itself or do you have to unplug it?" And the time: "I've got until about twenty-five past on this one and then I'm due downstairs." The third sentence is the one technicians skip and the one that makes the rest of the visit possible. The user now knows the shape of the next half hour before anything inside it has happened.

Ask to see the fault before touching anything, if it can be shown. A user who demonstrates the fault teaches the technician in thirty seconds what the ticket took three paragraphs to half-say. A fault that cannot be reproduced on request is itself a finding worth a line in the note. Tom cannot make the pad drop out on demand, which Nadia writes down, and which fits a pad with a worn connector better than a loose cable. Watching costs a minute. Guessing costs a second visit.

Confirm the symptom in the user's words rather than translating it into yours, because the translation is where the diagnosis sneaks in early. "The pad disconnects" is what Tom sees. "The pad's connector is worn" is what Nadia suspects. The first goes in the note as the symptom; the second waits until a new pad proves it. The series on soft skills has an article on listening for the problem behind the request. The desk-side version of its advice is short: hear what the user says happens, write that, then look.

The Fix, With the User Watching

Work the fix in the cheapest-first order. For a pad that has already had its cable reseated, that means a new cable first because it is thirty seconds. Then comes the new pad because it is the likely culprit. The pairing and the driver come last because they are the slowest and the least probable. The order itself, and why the cheap test comes before the clever one, belongs to The Diagnostic Order. Here it is enough to say that the technician who starts with the clever fix spends twenty minutes on it and then finds the cable.

Narrate in single sentences and do not lecture. "I'm trying a new cable first because it's quick, and if that's not it the pad itself is next" is one sentence that tells Tom what is happening and roughly how long it will take. A paragraph on the failure modes of signature pads is not required and will be remembered as the time the technician talked for ten minutes. Users want to know what you are doing, that you know what you are doing, and when you will be done. Three sentences across a visit will cover all three.

Test the finish line with the user doing the action, not you. Nadia does not sign three times on the new pad herself; she asks Tom to. Tom is the person who will be signing when the next customer is in the chair. A fault that only shows for the user is also more common than anyone would like. Three signatures, three stays-connected, "yes, that's it", and the finish line is met. If it is not met, the visit does not stretch until it is. The technician says so, writes what was tried, logs the next step, and leaves on time. That is a disappointment handled honestly rather than a schedule broken quietly.

The Note Written There, Not Later

The note is written at the user's desk, on the phone or the user's machine, before the bag is closed. It has five parts: the symptom as confirmed, what could and could not be reproduced, what was tried in what order, what fixed it, and the finish-line test with the user's confirmation. Five lines. "Pad disconnecting mid-signature, not reproducible on demand. Cable reseated three weeks ago, fault returned. New cable: no change. New pad: three test signatures, stayed connected, Tom confirms. Old pad to desk for inspection; connector looks worn." Two minutes at the desk, with everything fresh.

The same note written at four o'clock is a different note, and a worse one. By four o'clock the technician has done three more visits and the pad has blended into the day. "Replaced pad" is what gets written, and the next technician in three weeks learns nothing from it. That is exactly the note Nadia inherited. The habit of writing the note while the work is in front of you is the subject of The Working Note Habit. A desk-side visit is the hardest place to keep it and the place it pays most. That is because the desk-side note is the only record of a visit nobody else saw.

Keep the working note and the user's reply apart. The five lines above are for the desk: they mention the worn connector, the colleague's earlier reseat, and the pad going back for inspection. Tom needs none of these, and he might read one as blame. Tom gets one sentence, in plain words, which is the resolving reply: "Replaced the signature pad; the old one had a worn connector. If it drops out again, reply to this and it reopens." If you run QuerySolv, the five lines go in as an internal note and the sentence goes out as a public reply, on the same ticket. That way, the desk's reasoning and the user's answer sit together without being the same text. Most tools keep the two apart in some similar way. The point is that the note is written for a stranger on the desk and the reply for the person at the desk. Neither does the other's job.

Asking "Anything Else?" on Purpose

Ask "is there anything else?" deliberately, at the moment the note is finished and the phone is still in your hand. This will seem odd advice in a series about not doing add-ons. The reason is that the add-on is coming anyway. The user has been saving things up, as the first article explained. The only question is how they arrive. They could arrive as an ambush at the door with the bag on your shoulder. Or they could arrive as an answer to a question you asked with the capture form open. Invited, the add-on is a thirty-second ticket; ambushed, it is a negotiation. The question changes which one you get.

The answer is captured, not done, and the question is asked in a way that says so. "Before I go, is there anything else I should log for you while I've got the form open?" has the word "log" in it, and the form open, and users hear both. Tom mentions that his second monitor flickers when the heating comes on and that he has never been able to find the shared mortgage templates. Both become tickets while Nadia stands there, in the way Capturing Add-Ons as Tickets describes. Both get numbers said out loud. The second one will become a knowledge base article by Friday, because nobody had written where the templates were. Neither is done at the desk. Both are done.

The question also has an effect the technician does not see, which is on the hallway. Users who know that a visit ends with "anything else?" and a ticket number stop saving things for the corridor. They have learned there is a better moment and that it comes round. The series on the walk-up and drive-by culture explains why the corridor request happens at all. One of its causes is that users do not believe there is a moment when they will be asked. Give them the moment, with the form open, and the corridor gets quieter by itself.

Leaving on Time and Kindly

Leaving is a sentence, not a retreat, and the sentence has four parts: what was done, what was logged, what happens next, and thanks. "So that's the new pad in and tested, the monitor and the templates are logged as 6219 and 6220 and you'll get e-mails for both, the templates one will probably come back as a link to where they live, and thanks for showing me the fault, that saved a lot of guessing." It takes fifteen seconds and it closes the visit from the user's side as well as the technician's. A technician who leaves without it has, as far as the user can tell, simply stopped.

The user with three more things gets the same answer three more times, with the phone still out. The leaving sentence is not a signal that the capture form has closed. It is the moment some users finally think of the thing they meant to say. The right response is "that's another one, let me log it", not a visible glance at the time. Three more captures cost ninety seconds. Three more things fixed cost the visit downstairs. The user who wanted them fixed would, if asked, rather have the numbers than the technician's half attention while they worried about the half-ten.

Do not run. The step from "thanks" to the corridor is where a visit feels either finished or fled. The difference is about two seconds of standing still, a nod, and walking at an ordinary pace. The user who wants to chat gets one sentence of chat and the honest "I'd better get downstairs". The user who is anxious about the pad gets "if it drops out again, reply to the e-mail and it comes straight back to us". This is true in most tools and is the sentence that lets them stop worrying. Then go. The schedule is protected by leaving at twenty-five past, not by leaving quickly.

After the Visit

Three things happen in the corridor or at the next desk, and they take about two minutes between them. The resolving reply goes to the user, if it did not go from the desk: the one plain sentence with "reply to this and it reopens". The visit's ticket is set to resolved, with the finish-line test in the note as the evidence, in the way What a Proper Close Looks Like lays out. That way, the close is a statement about a tested fix rather than about the technician having left. And the add-on tickets are checked: linked to the visit's ticket, with the user's name on them and "desk-side add-on" in the first line. That way, triage finds them and the month's count finds them later.

Anything the technician noticed but the user did not mention goes in too, as a desk-raised ticket. The old pad with the worn connector is a ticket of its own. A worn connector on a pad that is three years younger than the others on the floor is a question about that model. The question is only askable if the ticket exists. Nadia logs it from the corridor in the thirty seconds she would otherwise have spent waiting for the lift. The lift at Bluewater is not fast. It has, over the years, been responsible for a great deal of good documentation.

The Three Sentences That Carry a Visit

Strip a good visit down and three sentences carry it, said at three moments, and the table below gives each with what it does. The arrival sentence sets the scope and the time before anything is asked. The anything-else sentence invites the add-on into a ticket rather than into the visit. The leaving sentence closes the visit from the user's side with the numbers in it. A technician who says all three, in roughly those words, at roughly those moments, has done most of this article without having read it. A technician who skips one will find the visit goes wrong at exactly the point where it was missing.

A Short War Story: The Wrong Bag at Acme

At Acme, a technician called Jonah was sent to the sales floor for a ticket that read "laptop won't connect to the projector in the small meeting room". He went straight from the previous visit without reading further, carrying the adapter he usually carried. It did not fit the small meeting room's projector. That fact was recorded in the ticket's history from a visit two months earlier along with the adapter that did. He spent twenty minutes trying settings and told the sales rep, Carla, that he would come back with the right adapter. He did not log the two other things she mentioned because he was now late. He arrived at his next visit twenty-five minutes behind. Carla's quote presentation to a prospective customer went ahead on a laptop screen turned to face three people. The second visit happened the following morning and took six minutes. The two unlogged things came back as a complaint a week later in the words "I told your technician about these". The cost was two visits for a six-minute fix and a sales presentation that the rep described to her manager as "embarrassing". There was also a complaint the desk could not answer because nothing had been written down. The lesson Jonah wrote in his own notes, which the desk later adopted, was that the ticket's history is read before the bag is packed. The last technician already found out what does not fit.

The Visit Checklist

The checklist below is the visit in order, from the desk to the corridor afterwards. It is meant to be read on the phone in the lift until it is no longer needed, which for most technicians is about three weeks. The first block is done before standing up and takes five minutes; the middle blocks are the visit; the last block is the two minutes afterwards. Nothing on it is a judgement call, which is the point. A visit done well is mostly a visit where the ordinary steps were done in the ordinary order while the user watched. Print it, tick it, and after the third week throw it away and notice that you still do it.

THE VISIT CHECKLIST — FROM THE DESK TO THE CORRIDOR
Ticket: ______   User: ______________   Location: ______________   Next appointment: ____:____ at ______________

BEFORE STANDING UP (five minutes at the desk)
  [ ] Ticket read in full, including the history and any previous fix
  [ ] Finish line written: "______________________________________________"
  [ ] Kit picked from the finish line: ______________________  Spare: ______________
  [ ] Sign-ins or rights needed are available to me now
  [ ] Next appointment known; user's name known

ARRIVING (bag still closed)
  [ ] Said who I am and which ticket
  [ ] Confirmed the symptom in the user's words; asked to see it happen
  [ ] Said the time I have and where I am due next

THE FIX
  [ ] Cheapest test first; one sentence of narration per step
  [ ] Finish line tested by the user, not by me; user's confirmation heard
  [ ] If not met: said so, wrote what was tried, logged the next step, left on time anyway

THE NOTE (at the desk, before the bag is closed)
  [ ] Symptom confirmed   [ ] What reproduced   [ ] What was tried, in order
  [ ] What fixed it        [ ] Finish-line test and the user's confirmation
  [ ] Working note kept separate from the one-sentence reply to the user

ANYTHING ELSE (phone in hand, form open)
  [ ] Asked: "anything else I should log for you?"
  [ ] Each answer captured as a ticket, linked to this one, number said out loud
  [ ] Nothing done on the spot unless it met the two-minute rule; logged even then

LEAVING
  [ ] Said what was done, what was logged, what happens next, and thanks
  [ ] Left at or before the planned time; walked, did not run

AFTERWARDS (two minutes)
  [ ] Resolving reply sent: one plain sentence, "reply to this and it reopens"
  [ ] Ticket resolved with the finish-line test as evidence
  [ ] Add-on tickets checked: user's name, "desk-side add-on", linked
  [ ] Anything I noticed myself logged as a desk-raised ticket

Nadia's five-line note on 6204 was read three months later by a different technician, sent to a different adviser on the same floor with the same pad. The technician read "connector looks worn" and brought a pad instead of a cable, and was done in eleven minutes. The templates ticket, 6220, became a knowledge base article that has since been sent to nine people, which is nine visits that did not happen. The lift is still slow. Tom still gets asked, by colleagues, how he got his pad sorted so quickly, and tells them to raise a ticket. That is the most useful thing a user has ever said on that floor and nobody from the desk had to say it.

Frequently Asked Questions