Measuring Remote Support: The Remote-Against-Office Cut

Wednesday, 11:20, at Ashgrove Housing. Hana, who runs a desk of four, is in the monthly operations meeting with one slide, and the operations director has stopped on it. The slide shows the median time to resolve a ticket for the month, split two ways. For people based in the office, it is a little under a day. For people based at home, it is two and a half days. "So the home workers are getting worse service," he says, and writes something down. Hana suspects that most of the gap is a courier. The rest, she suspects, is a housing officer in a loft with a weak signal. But she cannot prove either from the slide. The thing he wrote down is now a thing she will be asked about next month.

The slide was honest and the conclusion was wrong, which is what happens when a cut is shown without its causes. Measuring remote support is cutting the desk's ordinary numbers by where the requester works, remote against office. Then it means explaining every difference the cut reveals. Which part is the desk's doing, and which part is the courier's? Which part is a household network the desk cannot touch, and which part is an hour of overlap between two working days? This article is part of our Supporting Remote Workers series. It follows the house rules for numbers: every figure is a worked example from a fictional desk, in hours and in ranges. None of it is a benchmark.

It starts with how to mark the cut on the ticket and volume per person rather than volume. Then come resolution time and its four honest causes, the shipping lag measured on its own, and first response and the overlap. Next are the satisfaction difference, per-technician figures handled carefully, and the report line. A short war story and the remote support scorecard to copy finish the article.

Marking the Cut on the Ticket

A cut is the same metric computed for two groups of tickets so that the groups can be compared. The remote-against-office cut needs one thing the desk may not yet have: a mark on each ticket saying where the requester works. There are three ways to get it. A field on the request form, which is the cleanest, since the requester fills it in. A tag or a category the triager applies at first read, which is reliable if the triager is. Or the requester's base location from the directory, joined to the ticket afterwards in a spreadsheet. That works until the directory is stale, and the directory is always stale. Pick one, and write the choice on the desk's metric definition sheet beside the other definitions. Two people counting remote tickets from two sources will get two numbers and argue about the service instead of the source.

Decide what "remote" means before the first count, because hybrid workers break every simple rule. A person in the office two days a week is remote on three of them. Suppose they raise a ticket on a Tuesday from the office about a laptop that failed on Monday at home. The cut cannot place that ticket without a rule. The honest rule for most desks is where the person was when the problem happened. That is what determines whether the desk could have walked over. The simple rule is where the person is based, because the form can ask it once. Either is defensible. Write it down, apply it every month, and do not change it when the number disappoints. The counting discipline, including what "created", "closed" and "open" each mean and why merged tickets count once, is in Counting Tickets Properly. The remote cut inherits all of it.

Mark the ring as well, if the desk uses the three rings from the home support scope. A ticket about the organisation's laptop, a ticket about the household network, and a ticket about the personal printer are three different kinds of work. They have three different honest resolution times. A cut that mixes them will blame the desk for the loft. The ring is a second tag or a second field, applied by the triager. It is the single most useful mark on a remote ticket after the location itself.

Volume: Tickets Per Person, Not Tickets

The first number anyone asks for is how many tickets the remote people raise. The first mistake is to compare the raw count, because the groups are different sizes. Ashgrove has about a hundred and twenty people based in the office and about sixty based at home. In the month on Hana's slide the office group raised 190 tickets and the home group 110. That looks like the office is the bigger load until it is divided by heads. The result is a little over one and a half tickets per office person and a little under two per remote person. The per-head rate is the number to show. The raw count is the number to keep for the workload planning.

Then look at the mix, because the mix explains most of what the per-head rate shows. Remote tickets at Ashgrove were heavier in VPN and connectivity, hardware that needed a swap, and second-factor problems. They were lighter in printers, meeting rooms and anything that needed a person at a desk. That mix is not a finding about the remote workers' behaviour. It is a finding about what breaks when the desk is not in the building. It tells the desk which self-help articles to write first and which spares to keep. A remote category that grows month on month is a hotspot like any other. The systematic method for finding hotspots belongs to the hotspot series; the remote cut is one of its inputs.

Resolution Time and Its Four Honest Causes

The median time to resolve a remote ticket is almost always longer than the office median, and the honest work is in saying why rather than in explaining it away. Use the median and the ninetieth percentile, never the average. A single laptop that spent three weeks with a courier will drag an average anywhere it likes. The reasons, and the spreadsheet method in plain words, are in Median and Percentiles, Not Averages. Then take the gap between the two medians and attribute it to the four causes below. Do this ticket by ticket if the volume is small and by category if it is not. Only one of them is the desk's fault, and the report has to say which.

The first cause is the shipping lag. A hardware fault that would have been a corridor walk and a spare is now a parcel each way. The ticket's clock runs through the transit. The second is the exchange across time zones or across a working day that does not match the desk's. A question costs a day instead of a minute, three times. The third is the ring. A household-network ticket that the desk can advise on but cannot fix is resolved when the person tries the cable. That may be next week, and the clock runs until then. The fourth is the desk's own neglect. The remote ticket was read later because nobody was leaning over the counter about it. It was claimed later because it was an e-mail rather than a face, and updated less because the requester could not be seen waiting. The fourth cause is the one the operations director assumed was the whole gap. At Ashgrove it was about a fifth of it.

Seeing the fourth cause on its own takes one honest comparison: time to first response and time to claim, remote against office, for tickets of the same priority and category. If a remote password reset is claimed an hour later than an office one, the desk is reading faces before mail, and that is the desk's to fix. If the two are claimed in the same ten minutes and the remote resolution is still longer, the gap is in the other three causes. In that case, the report can say so with the numbers beside it. Hana's slide had the gap. It needed the four lines under it.

The Shipping Lag, Measured on Its Own

The shipping lag is the time a remote hardware ticket spends waiting for a parcel. It is measured separately. Apart from the desk's own end, this is the only part of remote resolution time the desk cannot control and should not be judged on. The five dates on a swap ticket from Shipping and Swapping Hardware make it a subtraction. The time from the swap decision to the courier collection is the desk's dispatch time. The time from collection to delivery is the courier's transit. The ticket is resolved at delivery, when the user is working again. The return journey is logistics and is not in the user's number at all. A desk that resolves the ticket only when the old unit is back has added the courier's return trip to its own resolution time. It will be asked about it in a meeting.

Measured that way, Ashgrove's swaps in the month looked like this, in a range because eleven tickets is not a precise number. Dispatch at the desk's end took between half a day and a day and a half before the runbook, and under a quarter of a day after it. Courier transit took between one and a half and two and a half days. The user's total wait was between two and four days. The desk's part was the first figure, and it is the one on the scorecard in hours. The transit is reported as a fact about the courier, with the range. That way, nobody mistakes it for the desk's performance and nobody forgets that it is still the user's wait. The report line for a swap is honest in both directions: "the user waited three days, of which the desk's end was two hours".

First Response and the Overlap

First response for remote tickets is measured the way the desk already measures it, in business hours against the target. Then it is read beside the overlap map from the time-zones article. A first response of two business hours means something different to a person whose day ends before the desk's begins. Cut first response by region as well as by remote against office. Show the two times together: the desk's time to reply, and the requester's clock time until they read it. The first is the desk's number. The second is the one the requester experiences, and it is the one the far-zone team will quote back.

Add one count that is specific to remote work: exchanges per ticket before the fix. An office ticket with four exchanges cost a few minutes of walking; a remote ticket with four exchanges cost up to four days. Count remote tickets with three or more exchanges before resolution, by technician and by category, and read it as a measure of how complete the first reply was. A technician whose remote tickets run to five exchanges is asking one question at a time. That is a habit, not a failing, and the fix is the complete reply from the coverage statement. Ashgrove's count fell from about a third of remote tickets to about one in eight in the quarter after the desk adopted it. The requesters did not change. The replies did.

The Satisfaction Difference

The satisfaction score for remote tickets is read with more caution than the office score, because the sample is smaller, the response rate is different, and the people answering are different. Remote requesters answer the survey more often in my experience. The resolving reply is the only contact they had and the survey is attached to it. Office requesters were thanked in person and never opened the mail. That alone can move the remote score either way without the service changing. The rules for reading a satisfaction cut are in Satisfaction by Category, and Carefully by Agent. They include the minimum sample before a number means anything and why comments matter more than scores at small volumes. They apply to the remote cut without change.

Read the comments by ring and by cause. A low remote score on a swap ticket with a comment about the wait is about the courier. The honest response is the dispatch time and the range. A low score on a household-network ticket with a comment saying "they just said it was my Wi-Fi" is about the sentence the technician used. The honest response is the scope's sentence. A low score with "nobody told me what was happening" is the fourth cause, and it is the desk's. Three comments of the same kind in a quarter are a finding. One is a Tuesday.

Watch for the silent remote user, who is the satisfaction problem the survey cannot see. An office user who gives up on the desk is still visible in the corridor. A remote user who gives up simply stops raising tickets and starts asking a colleague. Their silence looks like success. Once a quarter, list the remote people who raised no tickets in the period and ask their managers one question: is that because nothing broke, or because they stopped asking? The answer is sometimes the first. It is worth finding out which.

Per-Technician Figures, Carefully

Any cut by technician on remote tickets is for coaching and never for ranking. It is not read at all below a minimum sample. For most small desks that means something like forty comparable tickets per person over a quarter. The reason is structural: the technician who takes the remote tickets has longer resolution times by construction. Their tickets carry the courier and the time zones. A ranking would punish them for the rota. Compare like with like, remote tickets of one category against remote tickets of the same category, or do not compare at all. The exchanges-per-ticket count is the per-technician figure that is actually useful, because it measures the reply and not the parcel. A technician who sees their own count fall from five to two over a quarter has learned something nobody could have lectured into them.

The Report Line

The monthly report to leadership is one page with five numbers, three sentences and one ask. The shape of it is in The Monthly Report They Will Actually Read. The remote cut earns one line on it, and the line carries its causes. Hana's line, the month after the meeting, read: "Remote tickets: 110 of 300, about two per person against one and a half in the office. Median resolution two and a half days against under a day; of the gap, about a day and a half is courier transit on eleven swaps, half a day is household-network tickets resolved when the person tried the cable, and the rest is ours, in first response, which we are fixing by reading the queue in priority order rather than by door. Our dispatch end on swaps averaged two hours." The operations director read it, crossed out what he had written the month before, and asked about the courier. Which was the right question, a month late.

The report line never shows the per-technician cut. It never shows a remote score from fewer responses than the minimum sample. And it never shows the raw count without the per-head rate beside it. It does show the ask when there is one. That might be a second spare for the pool if the swap count justifies it. Or a staggered start if the far-zone overlap does, or a cable in the kit if the household-network count does. The cut is the evidence. The ask is why anyone is measuring. If you run QuerySolv, the standard reports already give the response and resolution times, the backlog by age and the satisfaction figures the line needs. In that case, add a field for the requester's location on the remote team's form. That turns the remote cut into a filter on those same reports rather than a spreadsheet exercise. In any tool, the aim is that the cut costs the desk fifteen minutes a month. A cut that costs a day will be done once.

A Short War Story: The Slow Remote Desk at Greyfield Architects

At Greyfield Architects, the operations manager asked for remote and office resolution times. The slide received showed the remote median at three times the office figure. The manager concluded that the technician who handled most remote tickets, a patient man called Dev, was the problem. A plan to hire a "remote support specialist" was drafted, and Dev was moved to office tickets. His remote tickets were spread across the other three technicians, who had never shipped a laptop. As a result, the remote median got worse the following month and Dev started answering recruiters. The desk lead, Carla, finally cut the gap by cause. She found that nine of the month's fourteen slow remote tickets had been swaps. Courier transit accounted for most of the gap on every one. The desk's dispatch end had been fastest when Dev did it. The remaining slow tickets were household-network advice resolved when the architect in question moved house. The hire was cancelled, and Dev was given the remote tickets back and an apology. The cost was a quarter of a plan built on one number and a month of worse service for the remote architects. And a technician who very nearly left over a slide. A cut without its causes is not a measurement; it is an accusation with a chart on it.

The Remote Support Scorecard

The template below is the scorecard, produced once a month from the same export the desk already uses. The definitions are fixed in section A and the four causes attributed in section D before anything is reported. Section B is volume, C the resolution cut, D the attribution, and E the shipping lag. F is first response and the exchange count, G satisfaction, and H the single line that goes to leadership. The rules at the bottom are the ones that keep the sheet honest: ranges where the counts are small, no per-technician figure without the sample, and no cut without its causes.

REMOTE SUPPORT SCORECARD — MONTHLY
Desk: ______________________   Month: ____________   Produced by: ______________________

A. DEFINITIONS (fixed; change only with a dated note)
   "Remote" means: [ ] where the person was when the problem happened   [ ] where the person is based
   Marked by: [ ] form field   [ ] triage tag   [ ] directory join
   Ring marked by the triager: owned / helped / left alone
   Business hours used for the clock: ______ to ______, zone ______________

B. VOLUME
   Remote tickets ______ of ______ total   Remote people ______   Per head: remote ______  office ______
   Top three remote categories: ______________, ______________, ______________

C. RESOLUTION TIME (median and ninetieth percentile; never the average)
   Remote: median ______  90th ______      Office: median ______  90th ______      Gap at the median: ______

D. THE GAP, ATTRIBUTED (do this before section H)
   Shipping lag on ______ swaps ............ about ______ of the gap
   Time-zone exchanges (3+ exchanges) ...... about ______ of the gap
   Household-network / left-alone tickets .. about ______ of the gap
   The desk's own (first response, claim, updates) ... about ______ of the gap   <-- the only part that is ours

E. THE SHIPPING LAG (from the five dates on each swap ticket)
   Desk's dispatch end: ______ to ______ hours   Courier transit: ______ to ______ days   User's wait: ______ to ______ days
   Ticket resolved at delivery: yes / no (if no, fix the runbook before reporting)

F. FIRST RESPONSE AND THE EXCHANGE COUNT
   First response, business hours: remote ______  office ______   By far-zone region: ______________
   Remote tickets with three or more exchanges before the fix: ______ of ______

G. SATISFACTION
   Remote responses ______ (minimum before a score is read: ______)   Score ______   Office score ______
   Comments by cause: courier ____  the sentence ____  no updates ____  other ____
   Remote people with no tickets this quarter: ______ (managers asked: yes / no)

H. THE REPORT LINE (one line; causes included; no per-technician figure)
   "Remote tickets ____ of ____, ____ per head against ____. Median ____ against ____; of the gap,
    ____ is courier transit on ____ swaps, ____ is household-network, ____ is ours and we are ______.
    Our dispatch end averaged ____ hours."   Ask, if any: ______________________________

RULES: ranges where counts are under thirty; per-technician figures for coaching only and never below
____ comparable tickets; the exchange count is the coaching figure; no cut leaves the desk without section D.

Hana's second slide, the month after, had the gap and the four lines under it. The meeting spent its time on the courier's transit range and whether a second spare would shorten the user's wait. That is a conversation a desk can win. The operations director's note from the first meeting was never mentioned again. The housing officer in the loft got a cable.

Frequently Asked Questions