Desktop Support as Its Own Function

It is 08:55 and Sam is under a desk on the second floor with a flashlight in his teeth. He is following a power cable through a tangle that predates him. Meanwhile, the phone in his back pocket buzzes for the fourth time. The buzzing is ticket 6204, a remote session a user is waiting on, assigned to Sam, because Sam is also the desk. The cable turns out to end in a power strip that is plugged into nothing. He fixes it, stands up, and finds the user on 6204 has sent a second message asking whether anyone is there.

Nobody has done anything wrong. Sam is doing two jobs with one body, and the two jobs have different physics. Remote work can be interrupted and resumed. A person under a desk cannot type. That is the whole argument for treating desktop support as its own function with its own rhythm. It holds even when the function and the desk are the same two people, or the same one. This is the third article in our Helpdesk vs Service Desk series. Three Terms, One Job? defined the words. This one is about the term that needs a screwdriver.

It covers what desktop support is and why it does not fit a queue the way remote work does. A table lists the signals that say it is time to split it from the desk. Then come the handoff between desk and deskside, with a worked example, and what breaks when both are one person, with the fix. Spares and standards follow in one section. The article ends with a war story about two hours a day lost to walking, and a deskside visit checklist to copy.

What Desktop Support Is

Desktop support is the part of support that needs hands on hardware. It happens at the user's desk, under it, in the stock room, and in the car on the way to the other site. The work is imaging new machines, swapping dead ones, moving people and their equipment, and replacing peripherals. It includes diagnosing in person what a remote session cannot see. It is also called deskside support, because the technician comes to the desk, and field support when the desks are spread across buildings or towns. Larger organizations file it under end-user computing, which is the same work with a longer name.

The defining property is place, not difficulty. A remote technician can fix a complicated software problem from a chair. A deskside technician may spend a visit on something trivial that happened to need a hand. Desktop support is not "whatever the desk could not fix", and it is not a lower tier. It is the set of tasks where the fix requires being there, and that set is decided by physics rather than by skill.

Treating it as a difficulty tier causes a specific harm. The desk escalates hard software problems to deskside because deskside is "the next level". Deskside walks to a desk to do work it could have done from the chair it just left. Tiers are about knowledge and access, and they are the subject of Designing Support Tiers. Deskside is about hands. The printer, as ever, requires both.

Why It Does Not Fit a Queue the Way Remote Work Does

A ticket queue assumes that work can be picked up in priority order, done, and put down. It assumes that the cost of switching between tickets is small. Hands-on work breaks each assumption. Every deskside ticket has a commute attached: five minutes to the third floor, twenty to the warehouse, half a day to the other site. A queue sorted by priority sends the technician up and down the stairs. A round sorted by floor does not, and the two orderings disagree.

Interruptions cost more at a desk than at a screen. A remote session can be parked while the technician answers a chat. A half-installed docking station cannot, and the user is standing there watching. A visit interrupted by a phone call becomes two half-visits, each with its own commute. The queue does not see any of this. It sees one ticket that took fifty minutes and wonders why.

Batching is where the efficiency lives. Six visits on the same floor in one block cost one commute and six fixes. The same six spread across the day as they arrive cost six commutes and six interrupted fixes. The arithmetic is not subtle. At ten minutes of walking per visit, six visits a day is an hour of corridor. The corridor is where the remote queue goes quiet.

None of this means deskside work should live outside the ticket system. Every visit is still a ticket, with a number, an owner and a history, because the alternative is work that happened and no record of it. It means the ticket system is the record of deskside work and not its scheduler. The scheduler is a block of time on a calendar and a short walking list.

When to Split It From the Desk

Splitting desktop support from the desk means giving it a named person, a block of time, or a team of its own. That is the order as the organization grows. The decision is not about headcount alone. It is about how much of the work needs hands and how far apart the hands have to go. It is about how often the remote queue stops because the only person is walking. The table lists the signals I would look at, and what each one suggests. These are opinions from running desks, stated as opinions.

Read the table as a direction rather than a threshold. An organization of sixty people on four floors has a deskside problem that an organization of a hundred on one floor does not. The wider question of which model fits which size, with the remote desk and the specialists included, is the subject of Choosing the Support Model for Your Size. This table is only the hands-on part of that decision.

The Handoff Between Desk and Deskside

A handoff is the point where a ticket that started remotely needs a visit. It is where most deskside time is lost or saved. A good handoff ticket means the technician arrives knowing what to bring and what to do. A bad one means the technician arrives and starts the diagnosis again, in front of the user, with the wrong spare. The handoff is written by the desk, as an internal note the user never sees, and it contains seven things.

• Where: building, floor, desk number, and how to find the user if they are not at it.
• What: the asset tag or serial of the device, and the exact symptom in the user's words.
• Tried: what the desk did remotely, and the result of each step, so nothing is repeated.
• Bring: the spare, cable, image or part the visit will need, confirmed to be in stock.
• When: the hours the user is at the desk, and whether the visit can happen without them.
• Done means: the test that proves the fix, such as "steady picture for five minutes".
• Ticket owner: who updates the user while the technician is walking.

The ticket owner during the visit is the desk, not the walking technician. The technician owns the visit. The desk owns the ticket, the user's updates and the confirmation at the end. This is the same ownership rule that a service desk applies to any other team doing the work, described in What a Service Desk Adds to a Helpdesk. Deskside is the team that most needs it, because the technician's hands are full. A tool helps when the handoff can live in internal notes that are never mailed to the requester. QuerySolv's internal notes work that way, and the user sees only the replies.

Without a written handoff the visit starts from zero. The technician asks the user what is wrong. The user explains it for the second time. The technician tries the two things the desk already tried, then goes back for the spare that nobody checked was in the cabinet. Forty minutes, two commutes, and one user who has now told the story twice. A handoff note takes the desk three minutes to write. It is the best three minutes in the ticket.

A Worked Example: Ticket 6208 at Bluewater Bank

At 09:05 on a Tuesday Priya in finance at Bluewater Bank reports by chat that her left monitor flickers every few seconds. Dana at the desk logs ticket 6208 and starts a remote session at 09:08. She checks the display driver, has Priya reseat the cable at both ends, and swaps the cable to the right-hand monitor, which stays steady. By 09:20 the fault follows the monitor and not the cable or the port. It needs hands.

At 09:22 Dana writes the handoff as an internal note. The location is floor 2, desk 2-14. The device has asset tag BWB-MON-0417 and is a 24-inch monitor. The flicker happens every few seconds and follows the monitor when cables are swapped. The driver was checked, and the cable was reseated and swapped. Bring the 24-inch spare from cabinet B, shelf 2, confirmed in stock. Priya is at her desk until 12:00. Done means a steady picture for five minutes on the spare. Dana owns the ticket. She replies to Priya at 09:24: it is the monitor. Sam will swap it in the 10:30 block. You will hear from me when it is done.

Sam's morning block starts at 10:30 with three visits on floor 2, and 6208 is the second. He arrives at desk 2-14 at 10:41 with the spare on a trolley. He swaps the monitor, watches it for five minutes while Priya works, and tags the old one for return. He adds a note at 10:52: swapped, steady, old unit tagged for the returns shelf. Dana messages Priya at 11:00 to confirm. Priya confirms at 11:05, and the ticket closes. Elapsed time from report to confirmation: two hours. Time Sam spent diagnosing at the desk: none. Remote tickets that waited on Sam during the visit: none, because Dana had the queue.

What Breaks When Both Are One Person

When the desk and deskside are the same person, the queue stops while they are under the desk. Chat goes quiet. The phone rings out, and the remote tickets that arrived at 09:00 are still unread at 09:40. That is not because anybody is idle but because the one person is on their knees with a flashlight. From the user's side it looks like nobody is there. From the technician's side it looks like the job.

The second failure is the interrupted visit. The one person starts a monitor swap. The phone buzzes, and they answer because they are also the desk. The swap takes twice as long and gets done less carefully. The third is the invisible walking, which nobody counts and which turns out to be an hour or two a day. That is the war story below.

The fix is batching and a visible block. Choose two blocks a day, say 10:30 to 11:30 and 15:00 to 16:00. Do every visit inside them, with the walking list sorted by floor. Publish the blocks to users on the support page and set the chat status during them. Before each block, pre-triage every visit remotely so the handoff note is written even when the same person will read it. Outside the blocks, the one person is the desk and does not walk. There is one exception: a user who cannot work at all and cannot be given a loaner remotely.

The exception needs a written definition, or it swallows the rule. "Cannot work at all" means no device and no loaner, not a flickering monitor. The block will be tested in its first week by a cable that cannot possibly wait. Hold the block. The cable can be collected from the desk, which is a different and older kind of deskside support. If you are the entire IT department, the same rhythm is the subject of the one-person IT department pillar.

Spares and Standards in One Section

A deskside visit is only as fast as the cabinet behind it. A standard is the short list of models the organization buys: two laptop models, one docking station, one monitor size, one headset. That way, the spare on the shelf fits the desk it is going to. Spares are the counted stock of those standards. There is a number on a label, a reorder point, and a named owner who counts them on the first of the month. A visit that ends with "I will have to order one" has cost a commute and gained nothing.

Keep the standards to one page and the spares to one cabinet per site, and resist the drawer. The drawer holds a cable of every kind except the one needed, and three monitors that were "going back" a year ago. The full story of stock, lifecycle and the returns shelf belongs to a later group of articles. Here the rule is one page, one cabinet, one count.

Standards also decide what the handoff note can promise. "Bring the 24-inch spare from cabinet B, shelf 2" is possible because there is one monitor size and a shelf for it. An organization with nine monitor models and no shelf writes "bring a monitor" and hopes, and hope is not a part.

A Short War Story: Two Hours a Day at Acme

Tomas was the whole of IT support at Acme, about ninety people across three floors and a warehouse. He did both the queue and the visits by answering whatever arrived next. During a quiet week his manager asked him to keep a log of where his time went. The log showed that he spent a little over two hours a day walking between floors, most of it in single trips to do one thing. His remote first response time was worst between ten and noon, which was when the walking happened. Nobody had been idle. The day had been shaped by the order the tickets arrived in. Tomas moved every visit into two blocks, one at 10:30 and one at 15:00. He pre-triaged each visit from his chair the hour before, and put a trolley with the common spares by the stairs. Walking fell to about fifty minutes a day. The morning first response time came back to where it was in the afternoons. The warehouse got a fixed visit on Thursdays instead of a phone call whenever a scanner died. The log is still kept, one week a quarter, because the blocks drift if nobody looks.

I kept the same log on my own desk once, out of curiosity, and stopped reading it after two days. The corridor had been getting a third of me.

The Deskside Visit Checklist

The checklist below is the one page the walking technician carries, on paper or on a phone. It is split into before, during and after because the visit is lost or saved at the edges. "Before" is the desk's handoff turned into a packing list. "After" is what makes the ticket honest. Copy it, shorten it to your own site, and laminate the first version, because the trolley has a coffee on it.

DESKSIDE VISIT CHECKLIST
Ticket: ________   Location: ______________   Block: ________   Tech: ________

BEFORE (at the desk, from the handoff note)
[ ] Read the handoff: where, what, tried, bring, when, done-means, owner
[ ] Spare or part confirmed in the cabinet and on the trolley
[ ] Tools: screwdriver set, spare cables (power, display, network), label pen
[ ] Loaner device on the trolley if the fix might not finish in one visit
[ ] User's hours checked; visit placed in a block they are present for

DURING (at the user's desk)
[ ] Say who you are, which ticket, and what you are about to do
[ ] Do not repeat the steps the desk already tried; start from "bring"
[ ] Swap, install or fix; label the removed item with the ticket number
[ ] Run the done-means test with the user watching (not "it should be fine")
[ ] If it is not fixed: loaner in place, user working, next step agreed and said aloud
[ ] Anything else seen at the desk noted, not fixed now

AFTER (within ten minutes, before the next visit)
[ ] Note on the ticket: what was done, test result, items removed and their tags
[ ] Ticket owner told the visit is complete, so they can confirm with the user
[ ] Removed item on the returns shelf, labeled; spare count adjusted
[ ] Anything noted "not fixed now" logged as its own ticket

Two of the lines do most of the work: "do not repeat the steps the desk already tried" and "run the done-means test with the user watching". The first keeps the handoff honest in both directions, because a desk that knows its notes will be trusted writes better notes. The second is the difference between a visit that is finished and a visit that comes back on Thursday.

Where the Advice Stops

Below about thirty people on one floor, do not split anything. One person, one block in the morning, and a cabinet is the whole model. A separate deskside function at that size is an org chart with more boxes than people. Above a few hundred, or across several towns, the question changes from "how do we schedule visits" to "who should be doing them". Whether field support is better bought than built is the subject of the internal versus outsourced support pillar.

Between those edges the model in this article holds, and it holds on any tool. Its parts are a calendar block, a walking list, a handoff note and a cabinet. The ticket system records all four. It does not need to understand any of them. Sam, for his part, now does his visits at 10:30 and 15:00. The phone from his back pocket is on the desk, where Dana can hear it. The flashlight is still in his teeth. The queue no longer notices.

Frequently Asked Questions