← Insights
Operating Model7 min read

How Much of Your Service Desk Is a Logistics Problem?

A meaningful share of what you call "IT support" isn't a support problem at all. It's inventory and movement, misclassified as troubleshooting. Here's how to find your own number.

Open any service desk queue and the tickets look, at first glance, like a wall of undifferentiated support work: password resets, application questions, connectivity issues, a laptop that won't boot, a new hire without a machine, an offboarding to process, a monitor to move to a different desk. The label on the queue — "IT support" — invites everyone to treat the whole pile as the same kind of work: someone has a problem, someone diagnoses it, someone resolves it.

Sort the pile and it splits into two very different piles. One is a support problem: an application misbehaving, an identity issue, a configuration question, a policy that needs a human. The other is a logistics problem wearing a support ticket: a device needs to arrive, leave, get replaced, or move. The work in the second pile isn't resolved by talking to the user. It's resolved by something physical moving to the right place, in the right state, at the right time.

Most IT organizations run both piles through the same queue, staffed by the same people, measured with the same metrics. That's the misclassification we want to name.

The five categories that are logistics

When we walk a service desk with the leader who runs it and ask them to reclassify their last quarter's tickets, five buckets consistently pull out of what they used to call "support":

  • Joiners. Every new hire is a work order for a device that has to arrive, imaged and correct, on a specific date. Whether it lands as one ticket or several — laptop, peripherals, access, day-one setup — the resolution is a package on a desk, not a conversation.
  • Leavers. Every departure is a recovery order: the device has to come back, its data has to be sanitized with evidence, and the asset record has to close out. "Resolved" here means a serial number returned to inventory in a known state, not a phone call completed.
  • Breakfix. A device stops working. In the traditional model this is a support ticket that begins with diagnosis. In a logistics-shaped model it's a swap order — a working device dispatched, a failed one retrieved — and the diagnosis happens later on a bench, without anyone waiting on it.
  • IMAC — installs, moves, adds, changes. Someone changed desks. A workstation needs to move to a new lab bench. A monitor needs to be added. A department reorganized. None of this is troubleshooting; it's small-scale physical work, scheduled and executed.
  • Device refresh. A tranche of machines is aging out. Replacements have to be procured, imaged, delivered, and the old units retrieved and disposed. This shows up in a service queue as dozens or hundreds of related tickets, but it's a single logistics program with a schedule.

Every ticket in those five buckets has the same shape: the resolution is a movement of a device, not a change to a person's understanding. The support team can talk to the user all day and the ticket won't close until something physical happens.

Why the misclassification is expensive

Running logistics tickets through a support queue costs more than it looks like on paper, for three reasons.

First, the wrong people are doing the work. Support engineers hired for judgment under ambiguity are unboxing laptops, taping return labels, and standing at a shipping counter. It's not that they can't; it's that every hour they spend on it is an hour of expensive, hard-to-hire talent used for work a fulfillment operation does faster and better. The people are fine. The assignment is wrong.

Second, the metrics obscure the problem. Time-to-resolution on a joiner ticket includes the days the laptop was in transit — and the queue treats that as "the support team is slow." Breakfix resolution time is measured from ticket-open to ticket-close, which rewards fast triage and long user downtime equally with slow triage and short user downtime. The metric can't see the thing that matters, which is time-to-working-device.

Third, the work never gets industrialized. Because it's mixed into a support queue, no one ever redesigns it as the repetitive, physical, standardizable operation it is. It gets performed one ticket at a time, in the margins, by people whose day job is something else. And so it stays slow and stays expensive, forever.

How to find your own number

You don't need us to tell you what share of your service desk is a logistics problem. You can measure it directly, and we recommend you do — the number will be more persuasive to your CFO than any external benchmark, because it's yours.

The method is simple and only requires the ticket data you already have:

  • Pull a representative window — a full quarter is ideal, at least a month if that's what you can export.
  • Classify every ticket into one of six buckets: Joiner, Leaver, Breakfix, IMAC, Device Refresh, or Genuine Support. Most ticketing systems don't tag this natively; you'll do it by keyword, category, or a sampling pass. Err on the side of "genuine support" when uncertain — you want the logistics number to be conservative, not inflated.
  • Count. Sum the five logistics buckets and divide by total tickets. That percentage is your answer.
  • Now weight by time. Not every ticket takes the same effort. Repeat the exercise using labor hours (or ticket-touch-count as a proxy) instead of ticket count. The two numbers are usually different, and the labor-weighted one is the one your budget cares about.

Do this once and the conversation about the service desk changes shape. It's no longer "we need more support headcount" or "we need to be faster." It's "a specific share of what our support team does is logistics work, and it should be run as a logistics operation." Once the number is on the page, the follow-on questions — who should do this work, where should it happen, what does it cost to run it properly — become normal operational decisions, made with data.

The share is almost always larger than the leader running the desk expects. It's rarely small enough to ignore, and it's the part of the service desk where a different operating model produces the biggest change per dollar.

Run the classification with us

/ Diagnose your environment

Run the diagnosis on your own environment.

Surya runs the physical device lifecycle — on-site spare pools at your sites, same-day swaps, serialized chain of custody — backed by our national hub in Research Triangle Park, NC.

Start the conversation →