Remote-First Support Design: A Desk Built Without a Building

Tuesday, 09:10, at Redbrook Engineering. Dana runs a desk of four and has just noticed something about the morning's tickets. The three from people in the building were all raised by someone leaning over the counter: "my dock's dead, can you swap it", done in six minutes, logged afterwards. The five from people at home were all e-mails, all sent before eight, all still unanswered. That is because the technician who reads the mailbox is at the counter dealing with the dock. One of the five is from a structural engineer in a flat two hundred miles away whose laptop will not start. He has sent a photo of a black screen. He has also, having heard nothing back, sent it twice.

The desk at Redbrook was designed around a building, as most desks are. The building gave it four things for free: a counter, a cupboard of spares, a corridor the technician could walk down, and a clock everybody shared. Remote-first support design is the practice of designing the desk's channels, hours, tools, stock and self-help as if none of those four things existed. That way, the person in the flat gets the same desk as the person at the counter. It does not mean closing the counter. It means the counter stops being the design. This article is part of our Supporting Remote Workers series. The series covers the policy, the shipping, the starters and leavers, the hours and the measurement of a desk whose users are not in the building.

It starts with what the building was quietly doing for the desk, the channels and the one queue behind them, and hours. Next come the remote tools that must exist before the first ticket, self-service as the replacement for the corridor, and the spare on the shelf. Then it covers what does not change at all and the remote support standard in practice. It ends with a short war story and the standard itself, as a one-page template to copy.

What the Building Was Doing for You

A desk in a building gets a great deal of support work done without noticing. The first job of remote-first design is to list it. The counter did intake: a person appeared, described the problem in their own words, and the technician asked the two questions that sorted it before anyone typed anything. The corridor did diagnosis. The technician looked at the screen, the cable, the light on the dock, and saw in ten seconds what a ticket would take three exchanges to establish. The cupboard did resolution: a spare dock, a spare charger, a loan laptop, handed over on the spot. And the shared clock did expectation: everybody started at nine, stopped at five, and knew that a ticket raised at ten past five would be read tomorrow.

Remove the building and each of those four jobs still has to be done, by something. Intake has to happen through a form or a message that asks the two questions the counter asked. Diagnosis has to happen through a remote session, a photo or a careful phone call. Resolution has to happen through a courier or through self-help the user can carry out alone. Expectation has to be written down, because the clock is no longer shared and the person in the flat starts at seven. A desk that goes remote without replacing all four does not become a worse desk evenly. It becomes a desk that is excellent for the people who can still reach the counter and slow for everyone else. That is what Dana had noticed at ten past nine.

The walk-up, the support request delivered in person, is the first casualty. It is worth being honest that it was never as good as it felt. It was fast for the person who walked up and invisible to everybody else: unlogged, unprioritised, and resolved in whatever order people arrived at the counter. The remote-first desk loses the walk-up and, if it does the design properly, gains a queue in which the engineer's dead laptop is read before the dock, because it is worse. That is not a consolation prize. It is the point.

Channels: Every Door Leads to One Queue

A channel is any route by which a request reaches the desk. The remote worker needs at least three. They need a web form for the request they can describe and e-mail for the request they cannot. They also need a phone number for the moment their device will not do either. Chat, if the organisation has a chat tool, is a fourth. It is the one remote workers reach for first, because it is already open and it feels like leaning over a counter. The question is not which channels to offer. It is where they go.

Every channel must end in the same queue, or the desk has rebuilt the counter problem in a new shape. A queue is the single list of open requests, in one place, that the whole desk works from. The moment a technician is answering chat messages that never become tickets, those requests are walk-ups again. They are fast for whoever sent them, invisible to everyone else, and unprioritised against the laptop that will not start. The principle, and the design for it, is in One Queue, Many Doors. The remote-first application is simply that it stops being optional. If you run QuerySolv, the web form, e-mail, live chat and social messages all arrive as ordinary tickets in one queue. In that case, the engineer's e-mail and the chat message from someone at a desk are the same kind of thing to whoever is on triage. In any tool, the test is whether a message sent through the chat tool at 08:02 is visible, with a number, to a technician who did not receive it.

The direct message is the channel that breaks this most often. Remote workers learn the technicians' names and message them directly, because it worked once. Within a month the senior technician has a private queue of favourites that nobody else can see or cover. The fix is a rule the whole desk keeps. A direct message gets a one-line reply that says "logged it for you as ticket 4471, you will hear from whoever picks it up", and then the ticket, raised by the technician on the user's behalf. Nobody is refused. Nobody is told off. The request simply goes where requests go. (The senior technician will keep getting the messages for a while. The reply is the cure, not the lecture.)

The phone keeps its place, and in a remote-first desk it is the channel for one specific situation: the device that cannot raise a ticket. A laptop that will not start, a VPN that will not connect, an account that is locked, all leave the user with a phone and nothing else. A desk that offers no number has told those users to wait for a colleague to notice. The number can be a desk line that rings on whoever is on duty, logged as a ticket by the person who answers. The point is that it exists, is published, and is for the moments the other doors are shut.

Hours: The Desk's Day Is Not the User's Day

The shared clock was the fourth free thing the building provided, and it is the one most desks forget to replace. In a building, everyone knew the desk was staffed from nine to five because they could see it. Remote workers start at seven, or at ten because of the school run, or at two in the afternoon because they are five hours west. None of them can see the desk. The hours therefore have to be written down and published where tickets are raised, together with what happens to a ticket raised outside them.

The remote-first rule on hours is that the desk states its hours as a fact and its first-response commitment as a promise, and keeps the two separate. "The desk is staffed from 08:00 to 18:00 in the head office time zone; a ticket raised outside those hours is read within the first hour of the next working day" is a sentence a person in any time zone can plan around. It is not the same as being open longer, and it does not need to be. Most remote-worker frustration with hours comes from not knowing them rather than from their length. The design of coverage across regions, the asynchronous ticket done well, and the out-of-hours question are the subject of Time Zones, Coverage and the Remote Worker's Day. Here it is enough that the standard says what the hours are and what the gap means.

Remote Tools Before the First Ticket

The corridor did diagnosis, and its replacement is a remote control session: the technician, with the user's consent, seeing and operating the user's screen from wherever the technician is. A remote-first desk has this working, tested on the standard laptop build, documented for the user, and governed by a short policy before the first remote user raises a ticket. That is because the first remote ticket is the wrong moment to discover that the tool needs something installed that the user cannot install. The principles that make a remote session safe are consent every time, a visible session, logging, and the least access that does the job. They are the subject of Remote Control Done Securely. This article does not repeat them. It adds one design rule: the session is the second step, never the first.

The first step is always the one that works when the session cannot. A laptop that will not start cannot host a remote session. Neither can one that cannot reach the network. Neither can one whose owner is on the phone from the kitchen because the laptop is the problem. The remote-first desk therefore designs a ladder, cheapest and most reliable rung first. It starts with the written question that gathers facts, then the phone call with the user's own eyes as the camera. Next come the photo of the screen or the light or the cable, the remote session, and finally the courier. The phone-and-photo method, and the ladder for the moment remote control fails, are laid out in Remote Support for People Working From Home. The design point is that every technician knows the ladder exists and starts at the bottom of it rather than at the rung they like.

Consent deserves one sentence here even though it has its own article, because it is where remote-first desks drift. In a building, the technician at your shoulder is visibly there and you can see what they touch. Remotely, the user sees a cursor move and has to trust that the person behind it is who they say they are. Every session is asked for, in the ticket, every time, and the session note goes on the ticket afterwards. The desk that skips this once because the user "is always fine with it" has started a habit that ends in a session nobody can account for.

Self-Service First, Because the Corridor Is Gone

Self-service is the user finding the answer, or doing the task, without raising a ticket. In a remote-first desk it stops being a nice-to-have and becomes the replacement for the corridor. In the building, half the desk's small fixes never became tickets because a colleague at the next desk knew the answer. At home there is no next desk. Every small question becomes a ticket, raised through a channel, read by triage, answered by a person. The remote worker who asked it waits an hour for the information that a colleague would once have shouted across the room. The only way to give that hour back is to put the answer where the user looks first.

The remote-first self-service set is short and specific, and it is written before the desk needs it. How to raise a ticket, and what to put in it. How to reach the desk when the laptop will not start. The VPN setup and the VPN self-check. The home-network self-check, which the desk will otherwise do by phone, badly, forty times a year. What to do when the second factor is on a phone that has died. How the swap-by-post works, so that the user who is sent a laptop knows what will happen. Each one is a knowledge base article that anyone can read without signing in, because the person who needs "my laptop will not start" cannot sign in to anything. If you run QuerySolv, an article in the knowledge base can be visible to everyone rather than only to agents. That is the setting that matters for this set. In any tool, test every article from a phone with the laptop switched off.

The portal is where these articles live and where the ticket form is. Remote workers use it only if the first visit succeeds. That is the subject of Making the First Visit Succeed. The remote-first addition is that the portal link goes everywhere the remote worker already is. It belongs in the signature of every reply from the desk, in the welcome message to every starter, and on the card in the box with every shipped laptop. A portal that is only linked from the intranet is a portal that the person with the dead laptop cannot reach. A portal link on the card in the box is one they can read by the light of a phone.

Self-service first does not mean self-service only. The rule is that the desk answers every ticket, and improves the article afterwards so the next person does not need to ask. A desk that replies "there is an article for that" and closes the ticket has not deflected anything. It has sent a remote worker to go and read, alone, something that might not apply. The reply gives the answer and the link. The article gets better. The count goes down. In that order, and the first one is not optional.

The Spare on the Shelf and the Box in the Cupboard

The cupboard did resolution. Its remote-first replacement is a shelf of pre-built spares and a stack of courier boxes with return labels already in them. That makes the engineer's dead laptop a swap on the day rather than a diagnosis over a week. A spare, here, is a device of the standard model. It is already imaged with the standard build, signed in once to prove it works, charged, and sitting in a box that is ready to ship. The size of the pool, the loan log and the case for stocking it at all are in the loaner and spares article of the hardware series. The courier process end to end is in Shipping and Swapping Hardware. The design rule from this article is only that the decision to swap is made by a threshold the desk agreed in advance. It is not made by a technician on the phone at 09:40 wondering whether a courier is justified.

The threshold is the remote equivalent of "come to the counter and I'll give you a spare". A reasonable threshold for a small desk makes any device that will not start after the phone-and-photo checks a swap that day. The same applies to any fault visible in a photo and any ticket that has taken an hour of phone time without progress. Below the threshold, the ladder continues. Above it, the box goes out and the diagnosis happens when the old unit comes back, at the desk, with the technician's hands on it. That is where diagnosis was always easiest. The courier is cheaper than the second hour. The user's second day is dearer than either.

What Does Not Change

Almost everything about running the queue is the same. It is worth saying so plainly because desks going remote sometimes conclude that the whole discipline needs reinventing. It does not. A ticket from a flat two hundred miles away is still read by triage and still given a priority on impact and urgency. It is still claimed by one named owner and still updated before the requester has to ask. It is still closed with a resolution note that a stranger could follow in a year. The requester still wants to know three things: did you get it, who has it, when will I hear. None of that moved when the user did.

Priority in particular does not change, and the pressure to change it is real. A remote worker with a dead laptop cannot borrow a colleague's machine, cannot walk to the counter, and cannot be "squeezed in" at lunchtime. So the same fault costs them more hours than it costs someone in the building, and the desk notices the difference. The right response is to let impact carry that difference, rather than to invent a remote priority that sits above the queue. That is because a person with no working device and no workaround is a higher impact than one with a spare at the next desk. The framework is the ordinary one from the prioritization series, and remote is an input to it, not a lane beside it.

Ownership does not change either, and remote makes it more visible rather than less. In the building, a ticket with no owner was sometimes rescued by whoever walked past the requester's desk. At home, nobody walks past. A ticket nobody has claimed is a ticket nobody is working. The requester cannot tell the difference between "claimed and being worked" and "unread" unless the desk tells them. Claim-based ownership, where a technician picks the ticket up and their name goes on it, was always the right design. For remote users it is the only thing that stops the second e-mail, and the third.

The Remote Support Standard in Practice

The remote support standard is the desk's one-page statement of how it supports people who are not in the building. It covers the channels, the hours, the tools it will use and how, and what it ships and when. It also covers what it expects the user to have and what it will not do. It is written for two readers at once. One is the remote worker who wants to know what to expect. The other is the technician who wants to know what the desk has promised. It is short enough that both will read it. The template is at the end of this article. The table below is the standard in practice: each habit the building allowed, and what the remote-first desk does instead.

Two things the standard does not do. It does not promise that remote support is as fast as the counter was for the person standing at it, because for hardware it is not. A promise that the courier cannot keep is a promise the desk will be reminded of. And the standard does not try to describe the household network, the personal printer or the second monitor the user bought themselves. That boundary is its own subject, written up in What the Desk Supports at Home, and What It Does Not. The standard points to it rather than restating it. The standard says how the desk works. The scope says what it works on.

A Short War Story: The Walk-Up Window at Tollgate Foods

When Tollgate Foods moved a third of its office staff to permanent home working, the desk kept its walk-up window open. That is because the two thirds who remained liked it and the desk lead, Marcus, saw no reason to close something that worked. Within two months the remote staff had learned that e-mails to the desk waited while the window was busy. They had started messaging technicians directly. So by the autumn the senior technician was carrying nineteen private conversations in the chat tool, none of them tickets. Meanwhile the queue showed a backlog that looked manageable because it was missing a third of the work. The problem surfaced when that technician went on leave for a fortnight. Eleven remote users, each of whom thought their request was being handled, discovered on the same Monday that it had been handled by nobody. Marcus counted the cost afterwards at about sixty hours of remote staff time lost waiting. He also counted two weeks of the senior technician's return spent reconstructing what had been promised to whom from a chat history. Marcus closed nothing. He published the hours, put a one-line "logged as ticket" reply in every technician's hands, and made every chat message a ticket on the day it arrived. The window stayed open, and the building stopped being the design.

The Remote Support Standard

The template below is the one-page standard, filled in once by the desk lead, published where tickets are raised, and re-read whenever a channel, a tool or the hours change. Section A is the channels and where they go, and B is the hours and the first-response promise. C is the tools the desk will use and the consent rule, and D is the ladder the technician follows. E is the swap threshold and what ships, and F is what the desk expects the user to have. G is what the desk will not do. It points at the home support scope rather than repeating it. Fill in every blank; a blank left empty becomes a promise somebody else will make for you.

REMOTE SUPPORT STANDARD — ONE PAGE
Desk: ______________________   Owner: ______________________   Reviewed: ____________

A. CHANNELS (every one lands in the same queue)
   Web form .......... ______________________ (first choice; asks what the desk needs to know)
   E-mail ............ ______________________ (for anything the form does not fit)
   Chat .............. ______________________ (becomes a ticket on arrival; direct messages are logged and redirected)
   Phone ............. ______________________ (for the device that cannot raise a ticket; logged by whoever answers)
   Portal and self-help: ______________________ (readable without signing in)

B. HOURS AND THE FIRST-RESPONSE PROMISE
   Staffed hours: ______ to ______, time zone ______________
   A ticket raised outside those hours is read by: ______________________
   First response within ______ working hours; the acknowledgment says who has it and when you will hear next.

C. TOOLS AND CONSENT
   Remote session tool: ______________________ (tested on the standard build; the user guide is at ______________)
   Consent is asked in the ticket before every session; the user can end a session at any time.
   Every session is noted on the ticket: who, when, what was done.

D. THE DIAGNOSIS LADDER (start at the bottom; go up only when the rung below fails)
   1. Written questions in the ticket     2. Phone call, user as the eyes
   3. Photo of the screen, light or cable   4. Remote session   5. Swap by courier

E. THE SWAP THRESHOLD
   A swap is dispatched the same day when: [ ] the device will not start after the phone-and-photo checks
                                           [ ] a hardware fault is visible in a photo
                                           [ ] one hour of phone time has passed without progress
   Spares kept ready and boxed: ______   Courier used: ______________   Return label in every box: yes

F. WHAT THE DESK EXPECTS THE USER TO HAVE
   [ ] The organisation's laptop on the standard build   [ ] A phone that can take a photo and make a call
   [ ] The portal link and the phone number somewhere that is not the laptop
   [ ] The home-office kit as described in the home support scope

G. WHAT THE DESK DOES NOT DO
   The boundary for the household network, personal devices and personal printers is in the
   home support scope: ______________________ (link). This standard does not restate it.

Dana published Redbrook's version of this standard on a Thursday, with the hours in the first line and the phone number in the second. The following Tuesday she looked at the morning's tickets again. The five from home had become seven, because two people who used to message the senior technician had used the form instead. All seven had an owner by nine. The engineer with the black screen had a courier box on its way, dispatched the previous afternoon under section E. He had not needed to send his photo twice. The counter was still open. It was no longer where the desk lived.

Frequently Asked Questions