Why Walk-Ups Happen and What They Cost the Desk
Tuesday, 10:40, at Meridian Parts. Dev has been inside the same ticket for twenty-five minutes. It is about a label printer in goods-in that prints every third label as a grey smear, and he is close. Then Farah from accounts leans on the partition: "Can you just look at my screen? It's doing the thing again." Four minutes. Then Omar from the warehouse, on his way to the kitchen: "Is the wireless down in bay three or is it just me?" Three minutes, mostly walking. Then the operations manager, phone in hand, not stopping: "Dev, my laptop's making a noise, I'll bring it over later." Dev says "sure" to all three, sits back down, and reads the printer ticket from the top because he cannot remember where he was. The queue shows fourteen open tickets. None of the three people who just spoke to him is in it.
A walk-up is a request for help made in person, to a technician, outside whatever route the desk built for requests. A drive-by is its faster cousin: the question thrown on the way past, often answered before anyone has finished standing still. Together they are the busiest support channel most small desks have, and the only one with no inbox, no number and no report. This article is part of our The Walk-Up & Drive-By Culture series, which is about turning that channel from something the desk suffers into something it runs.
It covers what a walk-up is and why it counts as a channel. It then covers the three human reasons people walk up: speed, friendliness and the feeling that the queue is a void. Next come the four costs to the desk: interruption, unlogged work, the invisible backlog and the fairness problem. Then comes a one-week census at Meridian Parts as a worked example. The article ends with what to do with the census once you have it, a short war story, and the census sheet to copy, in that order.
A Walk-Up Is a Channel, Whether or Not You Built It
A channel is any route by which a request reaches the desk. The desk usually thinks of the ones it designed: the web form, the shared mailbox, the phone number on the poster. The hallway is a channel too. It has an opening time (whenever a technician is visible), a service level (immediate), a routing rule (whoever is nearest or nicest), and a volume that nobody has counted. The only thing it lacks is a record. The thinking behind designing channels on purpose, so that every door leads into one queue, lives in One Queue, Many Doors. This series is about the door that opened itself.
The desk did not build the hallway channel, but it did earn it. Somebody once asked a technician in person and got help in two minutes. The lesson spread the way useful lessons spread in an office, which is by lunchtime. From then on the requester chooses between a form that was slow once and a person who was fast once. Nobody who makes that choice is being difficult. They are being accurate.
If you run QuerySolv, the web form, the mailbox, live chat and the API all land in the one queue already. In that case, most doors need no human to open them. The hallway is the exception. It becomes a ticket only when the technician makes it one, there and then. That is why the second article in this series is about the twenty seconds that follow "can you just". This article is about why those twenty seconds keep being needed.
The First Reason: It Is Faster, or Feels It
People walk up because a person in front of them answers now, and a form answers never, as far as they can tell from the chair. The web form produces an automatic acknowledgement with a number in it, and the number is where the requester's knowledge of the process ends. Nothing on the acknowledgement says when a human will look. The hallway has no acknowledgement. It has Dev, who is looking already.
The speed is often real for the requester and almost always false for the desk. Farah's four-minute fix was four minutes for Farah. For Dev it was four minutes plus the ten it took to get back into the printer ticket. Then there were the two further tickets that slid toward the end of the day because of it. A requester has no way of seeing the second half of that sum. They have no reason to care about it, which is not a criticism. The desk is the only party with the whole picture, and the desk is the only party who can act on it.
There is also a kind of speed the queue cannot beat and should not try to. A question with a one-word answer ("is the wireless down?") is faster in the hallway than in any system ever built. The honest approach is not to drive those into a form but to answer them, and log them if they matter. Save the redirect for the requests that need work. The walk-up culture is not cured by making every question slower. It is cured by making the queue fast enough that the hallway stops being the obvious choice for anything bigger than a sentence.
The Second Reason: It Is Friendlier
Asking a person is a social act and filling in a form is an administrative one. Most people prefer the social one even when it costs them. A form asks for a category, a priority, an asset tag and a description. Each field is a small test the requester might fail. A person asks "what's up?" and nods. For a requester who does not know whether their problem is a "network" problem or a "laptop" problem, the person is not just friendlier; the person is the only route that does not require them to guess.
The friendliness also runs the other way, and that is what makes it sticky. Technicians like being asked. Being the person people come to is one of the few forms of recognition a support role gets. A technician who is good with people will be asked more often than one who is not. That is exactly backwards from what the queue would do. The hallway rewards approachability with interruptions. It is a strange prize, and people keep winning it.
None of this is a reason to be less friendly. The series is called "without alienating people" for a reason, and the fifth article is entirely about keeping the warmth while moving the request. The point here is only that the pull toward the hallway is a human one, built from ordinary preferences. A desk which treats it as laziness or disrespect has misread the room. Nobody walks up to annoy you. They walk up because you are nice and the form is not.
The Third Reason: The Queue Feels Like a Void
The strongest reason people walk up is that they tried the queue and it swallowed the request. A ticket that gets an automatic acknowledgement and then nothing for three days teaches the requester one lesson, permanently. And the lesson is "find a person". This is the black hole from the seven ways support quietly fails, and the walk-up culture is its most reliable symptom. A void does not have to be big. One ticket, one silence, one colleague who says "oh, I just go and find Dev", and the channel is born.
The portal that failed once does the same work. A requester who tried the self-service form, could not find the right category, got an error on submit, or submitted and heard nothing, is not coming back to try again next month. The reasons are laid out in Why Users Bypass the Portal, and every one of them ends in the hallway. The queue has to be fast and visibly alive before anyone can be asked, fairly, to use it. Asking people to use a queue that has already let them down is asking them to be worse at their jobs on principle.
The void is also where the technician's own habits come home. A desk that answers hallway requests instantly and form requests in two days has, without meaning to, published a service level: in person, now; in writing, eventually. Requesters read it perfectly. They would be foolish not to. (They are not foolish. That is the whole problem.)
The First Cost: Interruption
An interruption is a request that arrives while the technician is inside another piece of work and demands attention before that work is finished. Its cost is not the minutes the interruption takes but the minutes it takes to get back. Dev's printer ticket needed twenty-five minutes of attention and got it in three pieces, with a reload between each. The reload is where the time goes. It means re-reading the notes, re-finding the driver page, remembering which of the four things already tried was the one that nearly worked. The arithmetic of that reload, and why it makes a day of small requests more exhausting than a day of large ones, belongs to The Interruption Load. Here it is enough to say that a four-minute walk-up is never four minutes.
The interruption cost also lands unevenly, which is the second reason it matters. The approachable technician, the one nearest the door, and the one who fixed the scanner once each absorb more than their share. Meanwhile, the colleague who sits round the corner and keeps headphones on gets a quiet day. The queue, if the desk used it, would spread the work by claiming. The hallway spreads it by seating plan.
And the interruption has a cost the requester never sees, which is the ticket that was interrupted. Somebody is waiting on that printer. They filed properly. They are in the queue. And their fix is being delayed four minutes at a time by people who did not file at all. That is where the fairness problem begins, and it gets its own section below.
The Second Cost: Unlogged Work
Every walk-up that is fixed on the spot and not written down is work the desk did and cannot prove. On the day it feels harmless; the problem is solved, the person is happy, and a ticket would have taken longer than the fix. Over a month it adds up to a desk that logs thirty tickets a day and does fifty. Every report from that desk, from volume to resolution time to first contact resolution, is computed on the thirty. The desk looks less busy than it is, in writing, to the people who decide whether it gets a third technician.
The unlogged work also takes the knowledge with it. A fix made in the hallway leaves no note. So the next time the same thing happens, to the same person or the next one, the desk starts from nothing. Patterns cannot be seen in work that was never recorded. If accounts has had "the thing again" eleven times this quarter, the one place that fact could have surfaced is the queue. In that case, the queue has heard about it zero times.
I have run a desk that did this for most of a year. We were tired all the time. The closed count was modest. Our manager, reasonably, read the modest count and concluded we were coping. We were not coping. We were just not writing it down, which from the outside looks identical.
The Third Cost: The Invisible Backlog
The invisible backlog is the set of promises made in the hallway that live in no list. "I'll bring it over later." "I'll have a look this afternoon." "Leave it with me." Each is a ticket with no number, no owner on record, and no clock. And each is remembered by exactly two people, one of whom will forget. The requester will not forget, because they are waiting. The technician will, because thirty other things happened. The next the desk hears of it is "I asked Dev about this two weeks ago" in a tone that has every right to be cold.
The invisible backlog is worse than the visible one because nothing ages it. A ticket in the queue that goes stale turns a colour, shows up in the weekly review, and gets chased. And that routine works only because the tickets exist. A promise in a technician's head does none of that. It just waits, in silence, for its moment to become a complaint.
The invisible backlog also cannot be handed over. When Dev is off sick on Thursday, the fourteen tickets in the queue get covered and the nine promises in his head do not, because nobody knows they were made. A desk with a large invisible backlog is a desk where every technician's absence is a small outage for a handful of people. And the handful never find out why.
Remember: a walk-up fixed on the spot and not logged is work the desk cannot prove and knowledge the desk cannot reuse. If it was a promise rather than a fix, it is a ticket nobody will chase. Log it, even in one line, even afterwards.
The Fourth Cost: The Fairness Problem
A queue is a fairness machine, and the hallway bypasses it. The person who walks up at 10:40 is served before the person who filed at 09:00, every time. That is because the person standing there is louder than the ticket and standing is a kind of loudness. The queue, with its order and its priorities, exists so that the desk serves people in a sequence it can defend. The hallway serves people in the sequence they happen to walk past, which is a sequence nobody chose and nobody can defend.
The people the hallway serves last are the ones who cannot walk up. The warehouse at the far end of the site, the remote workers, the night shift, and the branch office all use the queue. So does the person who is simply too polite to interrupt. None of them has any other option. And the queue is slow because the desk is busy with the hallway. A walk-up culture is, without anyone intending it, a culture that serves the nearest and the most confident first. The table below is the same point as a list of who wins and who waits.
| Who | How they ask | What the hallway culture gives them |
|---|---|---|
| The person two desks from the technician | Leans over the partition | Help in minutes, no ticket, no record |
| The manager with a confident manner | Walks up, phone in hand, does not stop | A promise, remembered by one of the two people involved |
| The warehouse at the far end of the site | The web form, because the walk is twelve minutes | A number, and a wait behind everyone who walked up |
| The remote worker | E-mail or chat; cannot walk up at all | The slowest service the desk offers, through no fault of theirs |
| The quiet colleague who does not like to interrupt | The form, filled in carefully | The same wait as the warehouse, plus the sense that politeness was a mistake |
Put that way, the walk-up culture stops looking like a quirk and starts looking like a policy, which is what it is. The desk has a policy of serving the nearest and the boldest first. It just never wrote it down, which is the only reason nobody has objected to it.
The One-Week Census at Meridian Parts
A walk-up census is a count, over one ordinary week, of every request that reached the desk by any route other than the ones that create tickets. It includes a tally for each one of what it was, how long it took, and whether it was fixed, promised or redirected. It is a count, not a change. Nobody redirects anyone during census week. Nobody is asked to use the form. The technicians change nothing about how they work except that they keep a tally sheet by the keyboard. The whole point is to measure the hallway as it is.
Meridian Parts has a desk of four supporting a site of about three hundred. Dev's lead, Anneke, ran the census for one week after the printer morning. Each technician kept a paper tally with a row per request. Each row recorded time, source (hallway, drive-by, direct message, phone to a personal extension, or "found me in the kitchen"), the person's department, rough minutes, and the outcome. The outcomes were three: fixed on the spot, promised for later, or sent to the queue. At the end of the week Anneke typed the sheets into a spreadsheet and counted.
The numbers were these, and they are a worked example from one fictional desk, not a benchmark. The queue logged 143 tickets in the week. The tally sheets held 112 walk-ups and drive-bys, 61 direct messages to individual technicians, and 40 calls to personal extensions. That is 213 requests outside the queue against 143 inside it. Of the 112 walk-ups, 71 were fixed on the spot, 32 became promises, and 9 were sent to the queue. Of the 32 promises, 7 had been logged as tickets by Friday; the other 25 were in somebody's head. The rough minutes on the walk-ups alone added up to a little over eleven hours across the four technicians, before counting the reload after each one.
| Route | Count in the week | Fixed on the spot | Promised for later | Sent to the queue | Logged by Friday |
|---|---|---|---|---|---|
| Hallway and drive-by | 112 | 71 | 32 | 9 | 16 |
| Direct message to a technician | 61 | 38 | 14 | 9 | 12 |
| Phone to a personal extension | 40 | 24 | 11 | 5 | 8 |
| All routes outside the queue | 213 | 133 | 57 | 23 | 36 |
| The queue itself | 143 | every one logged, owned and counted | |||
Anneke's summary to her manager was one sentence: "We are a desk of four doing the work of about 350 requests a week and reporting 143 of them." The manager had been reading the 143 for a year. He asked where the other two hundred were. She showed him the tally sheets. And the conversation about a fifth technician, which had been going nowhere on the strength of the 143, started again on the strength of the 356.
Reading the Census
The first thing the census tells you is the size of the desk, and it is usually larger than anyone, including the desk, believed. The ratio of outside-the-queue requests to logged tickets is the number to keep. At Meridian Parts it was about three to two. Anything above one to one means the reports describe a minority of the work. This is the figure that reopens the staffing conversation. And the way to carry it into a report that leadership will act on is in The Monthly Report They Will Read. The census is not the report. It is the evidence the report was missing.
The second thing it tells you is the shape of the promises. Fifty-seven promises in a week, of which twenty-one were logged, means thirty-six things people are waiting for that no list contains. That is the invisible backlog with a number on it. And it is also the most urgent thing to fix, because it is the one that turns into complaints. Before any redirecting, before any window, the desk logs every promise it makes. That one habit, which costs twenty seconds per promise, is the subject of the next article.
The third thing it tells you is who walks up, and from where. Sort the tally by department and the pattern is rarely even. At Meridian Parts, accounts and the operations office, both within forty paces of the desk, produced more than half the walk-ups. Meanwhile, the warehouse, with three times the headcount, produced almost none and filed carefully by form. That is the fairness problem in a column. It is also the beginning of an argument for a walk-up window at set hours, which the fourth article in this series designs. It is also the beginning of an argument for a measured shift away from the hallway, which the sixth measures.
The fourth thing the census tells you is what the hallway is good at. And it is worth saying plainly because the rest of this series spends its time on the costs. Seventy-one of the 112 walk-ups were fixed on the spot, in a few minutes each, by a person who could see the screen. That is excellent support. The job is not to stop it; the job is to log it so that it counts. The job is also to move the other forty-one, the promises and the real work, into a queue that can hold them. Anything the hallway does well, the desk should keep doing. It should simply stop pretending it did not happen.
A Short War Story: The Headcount Request at Tollgate Foods
Tollgate Foods ran a three-person desk for a production site of four hundred. For two years the desk lead, Marcus, asked for a fourth technician and was turned down on the strength of a logged volume of about ninety tickets a week. The finance director described that as "comfortable for three". Marcus knew the desk was not comfortable, because his technicians were in the production office more than they were at their desks. But he had no number for it. So the conversation ended the same way each spring. A new technician called Leila, who had come from a desk that logged everything, kept her own tally for a fortnight out of habit. Her sheet alone showed sixty-eight hallway requests, forty of them from one production office that had never raised a ticket in its life. Marcus ran a proper census. He found the desk was handling closer to two hundred and twenty requests a week. He took the sheet, not an opinion, to the next budget meeting. The fourth technician was approved in the same meeting that had refused one twice. The cost of the two years before was a backlog, a burned-out senior technician who left that summer, and a production office that had learned to expect IT to appear when called. The number that justifies the desk is the number the desk is not writing down.
The Walk-Up Census
Run the census for one ordinary week, which means not the week after a big release and not the week half the office is away. Every technician keeps the tally beside the keyboard and fills a row for every request that did not arrive through a route that makes a ticket. That includes the ones they fixed in ten seconds and the ones they did not fix at all. Minutes are rough; "about five" is fine. Change nothing else that week, and tell the team the sheet is for counting the desk's size, not for judging anyone's day. A technician who thinks the sheet is a performance review will quietly stop filling it in on Wednesday. Total it on Friday afternoon, by route, by outcome and by department, and keep the sheets. They are the baseline that the last article in this series measures against.
THE WALK-UP CENSUS — ONE WEEK, ONE SHEET PER TECHNICIAN
Technician: ______________ Week beginning: ____________ Desk size: ____
For every request that did NOT arrive through a ticket-creating route:
Time Route* Department What was asked (five words) Mins Outcome** Logged?
_____ _______ ___________ _______________________________ ____ _________ [ ]
_____ _______ ___________ _______________________________ ____ _________ [ ]
_____ _______ ___________ _______________________________ ____ _________ [ ]
_____ _______ ___________ _______________________________ ____ _________ [ ]
_____ _______ ___________ _______________________________ ____ _________ [ ]
(continue on the back)
* Route: H = hallway / walk-up D = drive-by on the way past
M = direct message P = phone to a personal extension
K = found me away from the desk (kitchen, car park, lift)
** Outcome: F = fixed on the spot PR = promised for later Q = sent to the queue
FRIDAY TOTALS (desk lead fills in from all sheets)
Tickets logged in the queue this week ..................... ______
Requests outside the queue (all sheets) ................... ______
Ratio, outside : logged ................................... ______ : 1
Of the outside requests: fixed ______ promised ______ sent to queue ______
Promises logged as tickets by Friday ...................... ______ of ______
Rough minutes on outside requests, all technicians ........ ______
Top three departments by walk-up count .................... __________ __________ __________
Departments with headcount over 30 and under 5 walk-ups ... ______________________________
Keep every sheet. This week is the baseline for the shift to logged work.
Anneke's sheets went into a folder labelled "the other two hundred". That is how the desk at Meridian Parts still refers to the hallway, three technicians and one walk-up window later. The folder is not a complaint about the people in it. It is a count, which is the one thing the hallway had never been given.
Frequently Asked Questions
Is a walk-up always a bad thing?
Should we redirect people during the census week?
Our technicians say logging walk-ups takes longer than fixing them. Are they wrong?
How do I estimate the time walk-ups cost without a stopwatch?
What if the census shows very few walk-ups?
Should the census count requests from other technicians or from management?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.
