Time Zones, Coverage and the Remote Worker's Day

Monday, 07:50, at Kestrel Analytics. Arjun opens the queue and finds a ticket from Mei, an analyst six hours ahead of the desk, raised at 02:10 desk time: "VPN shows a certificate warning and will not connect. I have a client call at nine." Her nine was five hours ago. Arjun replies at 08:05 with a sensible question: which network is she on, home or the client's office? Mei answers at the end of her day, which is the middle of his. He asks the next question on Tuesday morning. She answers on Tuesday evening. By Thursday the ticket has four exchanges, one per day, and Mei has been working from a colleague's connection all week. The fault would have taken ten minutes if the two of them had been awake at the same time.

Nothing in that ticket was slow. Every reply went out within the hour of being read. The problem was that each reply contained one question, and a question across six time zones costs a day. Time zones and coverage, as a desk subject, is the design of the desk's hours and the way it works a ticket. The aim is that a person whose working day does not overlap the desk's gets the same service as a person whose day does. That means the asynchronous ticket done well, the expectation written down, coverage that matches where the users are, and an honest answer to the out-of-hours question. This article is part of our Supporting Remote Workers series. The desk's hours as a published fact were set in the remote support standard. This article is about what the hours mean for the ticket when they do not match the user's.

It starts with the overlap map, the asynchronous ticket done well, and writing the expectation down. Then come business hours and the service-level clock, coverage options for a small desk, and the handoff between regions. The out-of-hours question, a short war story, and the coverage statement to copy finish the article.

The Overlap Map

Start by drawing the desk's hours against each group of users' hours, in the desk's time, and counting the hours in which both are at work. The overlap is the part of the day in which a question can be asked and answered inside an hour. It is the single number that explains why some remote tickets take a day per exchange and others do not. A user in the same time zone as the desk has the whole desk day as overlap. A user six hours ahead has the desk's morning. A user eight hours behind has the desk's last two hours. A user twelve hours away has none, and every exchange with that user costs a working day whatever the desk does.

Kestrel's map, as Sofia the desk lead drew it, looked like this. The desk was staffed from 08:00 to 18:00 in its own city. The head office analysts were in the same zone, with ten hours of overlap. The eastern analysts were six hours ahead, working 08:00 to 17:00 their time. That is 02:00 to 11:00 desk time, for three hours of overlap. Two consultants were eight hours behind, working 09:00 to 18:00 theirs. That is 17:00 to 02:00 desk time, for one hour. The map took twenty minutes and ended the belief that the eastern team was "a bit slower to reply". They were replying at once, in a day that ended at eleven in the morning.

The map tells the desk three things it cannot otherwise see. It shows which tickets must be worked in a particular hour of the day and which must be worked in one reply. And it shows where a change in the desk's hours would buy the most. It is also the honest picture to show whoever asks why the western consultants' tickets take longer. They take longer because the clock says so, and the desk's job is to stop spending that time one question at a time.

The Asynchronous Ticket Done Well

An asynchronous ticket is one in which the desk and the requester are never at work at the same time. Every exchange crosses a night. The discipline for it has one rule: every reply must let the requester act without waiting for the next one. That means the reply asks everything it will need, at once, and for each likely answer says what the requester should do next. "Which network are you on?" costs a day. "If you are at home, do this; if you are at the client's office, do this instead; either way, send me the exact wording of the warning and the time it appeared, in your local time" costs nothing. Whichever answer is true, Mei can act on it tonight and the desk can finish tomorrow morning.

The complete reply is longer than a quick question and takes more thought, and the thought is the point. The technician is doing, in one sitting, the diagnosis they would otherwise spread over four days of one-line exchanges. The reply has a shape. What the desk has already checked on its side, so the requester knows the ticket was read properly. The questions, numbered, all of them. The branches: for each likely answer, the step the requester can take now, with the self-check article linked where one exists. And the promise: when the desk will next look, in the requester's time. That way, "tomorrow morning" means something to a person whose tomorrow starts at the desk's midnight. The reply that follows all four will often close the ticket at the next read, because the requester did the step and it worked.

Write times in the requester's zone, always, and say which zone. "I will check again at 08:00 your time" is a sentence the requester can plan around. "First thing tomorrow" is a sentence that means something different in every city the organisation has a person in. The same applies to the acknowledgment, the status update and the resolution. A desk that works across zones puts the zone after every time it writes. Most of the confusion that remote desks attribute to distance turns out to be a missing three letters after a number. (Nobody has ever complained that a time was too clearly stated.)

The confirmation deserves a line, because it also crosses a night. A fix sent at 09:00 desk time is tested by the eastern analyst at 09:00 theirs, which is 03:00 at the desk. The "it worked" or "it did not" arrives as the desk opens. If it did not, the requester's reply reopens the ticket, as it does in QuerySolv and in many tools. In that case, the technician's first job of the day is the reopened ticket rather than the new ones. That requester has already lost a day once. If it did, the ticket closes with the note and nobody has waited. The asynchronous desk starts each morning with yesterday's answers, and reads them before anything else.

Writing the Expectation Down

The remote worker in another zone cannot see the desk. So the hours and what they mean are written where tickets are raised, in the worker's own terms. The page that sets expectations for the whole desk, with the published response times in plain words and the text of the acknowledgment, is the subject of Setting Expectations at the Desk Level. The cross-zone desk adds one paragraph to it. First are the staffed hours stated in the desk's zone, then translated for each region the organisation has people in. Then comes the sentence about what happens to a ticket raised outside them. "The desk is staffed 08:00 to 18:00 in Harbour City, which is 14:00 to midnight for the eastern team and midnight to 10:00 for the western consultants; a ticket raised outside those hours is read within the first hour of the next desk day, and the reply will tell you when to expect the next one, in your time."

The acknowledgment does the same work on each ticket. The three things any requester wants to know are the same across zones: that the ticket arrived, who has it, and when they will hear. The third is where the acknowledgment for a far-zone requester differs. It gives the time in their zone and it is honest about the gap. "Your ticket was received at 02:10 desk time; the desk opens at 08:00, which is 14:00 for you, and you will have a first reply by 15:00 your time." A requester who reads that at 09:00 their time knows the next six hours are theirs, and can decide whether to work around the problem or wait. The requester who reads "we aim to respond within four hours" at the same moment has no idea what that means. Is that four hours from now or from a desk that is asleep?

Business Hours and the Service-Level Clock

A service-level target measured in business hours counts only the hours the desk is staffed. So a ticket raised at 02:10 and answered at 08:30 has waited thirty minutes against the target, not six hours. The arithmetic is honest from the desk's side and feels dishonest from the requester's, and both are right. The target is a promise about what the desk will do while it is at work; the requester's experience is the whole night. The distinction between the two, and the difference between a response target and a resolution target, is in Response vs Resolution Targets. The cross-zone desk needs to know which hours its tool counts and to say so to the users.

If you run QuerySolv, the service-level targets are set per priority on a business-hours schedule. In that case, the clock for a ticket raised in the middle of the desk's night starts when the desk opens. Most tools work on some version of the same idea. The thing to check in yours is which schedule the clock follows and whether it is the desk's. Then publish the consequence rather than hiding it inside the target. For the western consultants, "response within two business hours" means "by 10:00 your time at the earliest for anything raised after our close". The honest sentence costs nothing and prevents the complaint that the desk "broke its promise" on a night it was not open. A target the requester understands is a target that defends the desk. One they do not is a trap with the desk's name on it.

Coverage Options for a Small Desk

Coverage is who is at work on the desk at each hour of the day. A desk of three cannot cover twenty-four hours, so the question is which hours to buy and how. The options below are in rising order of cost, and the overlap map says which one is worth it. A desk whose far-zone users are two consultants needs none of them. A desk with a third of its people six hours away needs the first two. Each option is costed in hours, because hours are what a small desk spends. The calendar that shows who covers what and where the gaps are, before they happen, is in The Coverage Calendar and the Single Point of Failure. Every option here is a line on it.

Working the overlap deliberately is the option that costs nothing and gets skipped, so it is worth a paragraph. Each morning, before the new tickets, the desk reads the far-zone tickets that arrived overnight and sends complete replies. It does this in the hour when those users are still at work. Each evening, in the last hour, it does the same for the region whose day is starting. A desk of three that does this has given its far-zone users two live hours a day without changing a single rota. The ticket order is the only thing that moved.

The partner desk is the option that most needs the eyes open. An outsourced desk in another region can take first response while yours is asleep. The arrangement works when the handover is written, the scope is narrow and the quality is checked. The shape of that relationship, what to keep in house and how to read the partner's numbers, is in Working With an MSP. What it is not is a way to have the eastern team supported "properly" without anyone at the organisation noticing how. Somebody still reads the partner's tickets every morning. If nobody does, the partner is covering the hours and nobody is covering the partner.

The Handoff Between Regions

Whenever two people or two desks cover different hours, a ticket will cross from one to the other, and the crossing is where it is lost. The handover note, the five-minute ritual and the open-items list are the subject of The Shift Handover. The cross-zone handoff is that routine with a twist: the two people never meet, so the note is the whole handover. The note is written on the ticket, not in a chat message. It says what has been tried, what the requester has been asked and told, what the next step is and when the requester expects to hear. The receiving technician claims the ticket, so that the owner changes visibly, and the requester is told in one line who has it now.

The ticket that travels west is the one to watch. Suppose a fault is raised by the eastern team at their morning and worked by the desk in its morning. It is handed to the western consultant's technician in the evening. It has had three owners in a day. Each one has a chance to assume that the last one told the requester something. The rule is that whoever claims the ticket owns the next message to the requester, and the message says so. "Arjun has handed this to me for the evening; the next step is the one below, and I will update you by 09:00 your time." Three owners and three messages is a ticket being worked. Three owners and one message is a ticket being passed.

The Out-of-Hours Question

Every desk that supports people in other zones is asked, eventually, "what if it is urgent at two in the morning?" The honest answer has two parts: a short written list of what counts, and a phone number that reaches a person for those things only. Out-of-hours urgent means the person cannot work at all, has no workaround, and the work is time-critical in the next few hours. A client presentation with a laptop that will not start qualifies. A password that expired does not, because the password can wait for the desk's morning and the presentation cannot. Write the list, publish it with the number, and keep it short. A list with twelve items is a list in which everything is urgent, and the on-call phone becomes a second desk that one tired person is running at midnight.

On-call has a cost in hours and in people, and the organisation pays it, not the technician. Whoever holds the phone is paid or rested for holding it. The rota is written so that nobody holds it two weeks running. Every call is logged as a ticket the next morning so that the pattern is visible. Three calls a month for the same thing is a self-help article and a standing fix, not a reason for a bigger rota. The quiet promise that goes with the list is as important as the list: "we will not read your ordinary ticket at two in the morning, and we will say so, and your first reply will tell you when we will." A desk that is honest about being asleep is trusted when it says it is awake.

A Short War Story: The Nine-Hour Reply at Saltmarsh Software

At Saltmarsh Software, a developer called Tomas worked nine hours ahead of the desk. In his first month he raised a ticket about a shared repository he could not reach. A technician called Priya answered within twenty minutes of the desk opening with a single question about which network he was on. Tomas answered at the end of his day, and Priya asked the next question the following morning. The ticket ran for eleven working days and twelve exchanges, every one of them prompt. Then the two of them discovered it was a permission that had been set on the wrong group and took four minutes to change. Tomas had worked around the fault for two weeks by asking a colleague to copy files for him. The desk lead later put the cost at thirty hours of two developers' time. There was also a complaint from Tomas's manager that the desk "did not support the overseas team". The desk had answered every message inside the hour and had never once asked everything at once. The rule that followed is now the first line of Saltmarsh's coverage statement: a reply to a far-zone ticket contains every question the desk will need and the step for every answer, because a question across nine hours costs a day, and twelve of them cost a fortnight.

The Coverage Statement

The template below is the one-page coverage statement, written by the desk lead from the overlap map. It is published alongside the remote support standard and re-read whenever a region is added or the hours change. Section A is the hours in every zone the organisation has people in, and B the overlap map in a few lines. C is the rules for the asynchronous ticket, and D the coverage options the desk has chosen and their rota. E is the handoff rule, and F the out-of-hours list and the number. Fill in every zone; a region left off the page is a region the desk has decided not to see.

COVERAGE STATEMENT — ONE PAGE
Desk: ______________________   Owner: ______________________   Reviewed: ____________

A. STAFFED HOURS, IN EVERY ZONE WE HAVE PEOPLE IN
   Desk time: ______ to ______ (zone: ______________)
   For ______________ (region): ______ to ______ their time
   For ______________ (region): ______ to ______ their time
   A ticket raised outside these hours is read within the first ______ of the next desk day.

B. THE OVERLAP MAP
   Region ______________: ______ hours of overlap, from ______ to ______ desk time
   Region ______________: ______ hours of overlap, from ______ to ______ desk time
   Region ______________: no overlap; every exchange crosses a night

C. THE ASYNCHRONOUS TICKET (for any requester with under four hours of overlap)
   [ ] Every reply asks everything the desk will need, numbered, at once
   [ ] For each likely answer, the step the requester can take now, with the self-check linked
   [ ] What the desk has already checked on its side
   [ ] When the desk will next look, written in the requester's zone, with the zone named
   [ ] Overnight replies read first each morning; reopened tickets before new ones

D. COVERAGE WE HAVE CHOSEN
   [ ] Overlap worked deliberately: far-zone tickets first at ______ and last at ______ each day
   [ ] Staggered starts: early ______ to ______ (rota: ______________); late ______ to ______ (rota: ______________)
   [ ] Region's own cover: ______________ (hours ______ to ______ their time)
   [ ] Partner desk: ______________ (hours ______; scope ______________; handover read daily by ______________)

E. THE HANDOFF
   The receiving person claims the ticket; the handover note is on the ticket, not in chat;
   the requester is told who has it now and when they will next hear, in their zone.

F. OUT OF HOURS
   Urgent means: cannot work at all, no workaround, and time-critical in the next few hours.
   Examples that qualify: ______________________________________________
   Examples that wait for the desk's morning: ______________________________
   The number: ______________   Held by (rota): ______________   Every call logged as a ticket next morning.
   Ordinary tickets are not read out of hours; the first reply says when they will be.

Sofia published Kestrel's statement with the overlap map in section B, and Arjun moved the eastern tickets to the top of his morning. Mei's next ticket, a month later, was raised at 03:40 desk time and answered at 08:10. The reply asked four questions, gave the step for each, and promised a next look at 15:00 her time. She had done the step by then. The ticket closed on the first morning, which is as fast as a ticket across six hours can close, and faster than the certificate warning ever did.

Frequently Asked Questions