The device ticket is the one your desk handles worst

Roughly a quarter of what lands on an enterprise service desk is about the device in front of the employee: either the ticket says so, or the real cause turns out to be the laptop once somebody looks. Hardware tickets take the longest to close of any category a desk handles, with a median of about 80 hours in Fixify's 2026 benchmark of 50,000 tickets across more than 30 organizations, slower than anything except onboarding. By the time a ticket reaches desktop support, it costs roughly seven times what a ticket closed at first line costs (about $109 against about $16, in MetricNet's cost-per-ticket figures published through HDI). And the ticket count understates the problem, because only about half of IT issues are ever reported at all. Nexthink's 2020 survey of 3,000 employees found people simply live with a slow or unreliable machine, and Lakeside's 2022 survey of 600 put the unreported share at 40 percent.

The quarter needs to be handled carefully, because it is a blend rather than a single published number. Fixify's own categories put hardware plus connectivity at about 11 percent of tickets, HDI's broader enterprise figure is nearer a third, and a meaningful share of what gets logged as a software or collaboration ticket (Microsoft Teams freezing, Outlook crashing, "everything is slow") is a device fault once you investigate it. So if you want a floor, use 11 percent, and treat the rest as what you find when you look properly.

Those four facts describe a category of work your desk is bad at. Not because your people are bad at it, but because the way a device ticket moves through a desk is designed to avoid looking inside the machine. That habit is the single most expensive one in end-user computing, the tools that exist today have not been able to change it, and this article is about why, and about what we have built at Rezolve.ai to change it.

What happens to a device ticket after it is logged

The research on this is better than most people expect, and it tells one story.

An incident that is never reassigned still costs the employee who raised it about two hours of lost time: HappySignals' 2023 benchmark of 1.86 million end-user responses across 130 countries puts the figure at 2 hours and 2 minutes. Four out of ten incidents get reassigned at least once, and every hand-off adds about 1 hour and 46 minutes to the employee's lost time while taking seven points off their satisfaction score. By the fourth reassignment, the employee has lost over nine hours, and "I had to explain my case several times" has become the third most common reason for a negative experience. HappySignals does not publish reassignment counts by ticket category, so it cannot be said that device tickets bounce more than others, but Fixify's 80-hour median is hard to explain any other way.

Somewhere in that chain, a technician opens a remote session. HDI's desktop support survey of nearly a thousand organizations found that 80 percent of desktop teams use remote tools, yet only 38.5 percent resolve more than half of their tickets remotely, and only a third even track remote resolution as a metric. The survey is from 2013, and nothing more recent measures the same thing industry-wide, which is itself a finding. Most desks cannot tell you how often a remote session actually fixes a device problem.

When the remote session does not fix it, the device gets swapped. Forrester's 2022 Total Economic Impact study for Lakeside modeled a 40,000-device fleet in which 1.5 percent of devices went back each year for repair or reimaging, and found that three in four of those returns were avoidable. Each one cost about $100 in round-trip shipping, two and a half hours of an engineer's time and four hours of the employee's. The wider electronics industry calls the device that comes back and tests fine "no fault found," and Accenture put that share of consumer electronics returns at 68 percent. Nobody publishes an enterprise-laptop version of that number, which again tells you something.

Then the fleet pays for the whole chain a second time. Most organizations refresh laptops at about four years partly because the devices seem to be wearing out. Yet the same Forrester study found that once the software causes of poor experience were being found and fixed instead of the device being replaced, the composite organization extended its refresh from four years to five, avoiding the purchase of 800 devices a year at $1,100 each. Nexthink reported something similar in 2022: offered a new laptop, 73 percent of employees whose device scored as healthy chose to keep the one they had for another year.

So the chain runs logged, bounced, remote session, swap, early refresh. At every step somebody handles the ticket, and at no step does anybody work out what is actually wrong with the machine. It is a large part of why keeping the lights on keeps growing.

Why has nothing fixed this?

Your enterprise almost certainly owns two kinds of tool that touch this problem. Both are good at what they do, and neither can reach it.

The first is experience monitoring, which the industry calls DEX. A monitoring product collects telemetry from every device, scores each one, and tells you that a machine is unhealthy, which is valuable and is where the fleet-level numbers above come from. What it cannot tell you is what is wrong with this particular laptop, this morning, because a telemetry product answers "is something wrong" and was never designed to answer "what, on this machine, right now." That limit is not a gap in anyone's execution; it is what telemetry is.

The second is automation: runbooks, scripts and, more recently, AI assistants that write scripts faster. Your scripts close a great many tickets every week, and you would not want to lose one of them, but a script only covers a fault somebody already thought of. A script library is a catalog of anticipated problems, a catalog cannot by construction hold the problem nobody anticipated, and the tickets that survive your automation survived it for exactly that reason. Eliminating L0 and L1 work is the floor, not the finish line.

Between those two tools sits the senior engineer: the one or two people in every desk who actually investigate, who look at the event log rather than the dashboard, who form a theory and test it. Those two people are the capacity ceiling on device tickets, and the 80-hour median is mostly the queue waiting for them.

What changes now

What we have built at Rezolve.ai is a product called Rapport, and the claim for it is narrow and specific: it investigates the device the way your best engineer does. It forms a hypothesis, runs a check, reads what came back, and decides what to look at next, in minutes, from the ticket, without a remote session and without the employee having to stop working. The reasoning happens in the cloud through our gateway. A native agent on the device runs the permitted checks and classifies every command locally: read-only checks run on their own, anything that changes the machine waits for a named approval, destructive commands are refused outright, and nobody can approve their own request. Every session is recorded, turn by turn, with every tool result and approval step. If your security team would rather it never executed anything at all, you can switch execution off and still get the investigation, which is where most of the value sits anyway.

Two cases from our own pilot show what that means better than a description can.

The first was a desktop whose owner had been saying for a month that it "stutters and locks up, not always, just sometimes." Rapport checked memory pressure (normal, 15 GB free, no paging), crashes and hangs over seven days (one, unrelated), GPU driver resets (none), hardware error events (none, all disks healthy) and disk latency (sub-millisecond). Every tool we own would have reported those five clean results and closed the ticket. Rapport then asked something nobody asks on a stutter complaint, whether the filesystem itself was consistent, and found that the NTFS volume had been flagged dirty. Windows had been requesting a full disk check at every boot since late September, 45 times in 30 days, and could not repair the volume while running. Rapport added, unprompted, that because it had never caught the machine mid-stutter, the finding was a strong correlation rather than a proven cause, and that the repair needed someone at the machine for a reboot, so it wrote the instruction for a human instead.

The second was a home-office PC whose Wi-Fi was painfully slow while a Mac in the same room on the same router was fine. Rapport measured both (105 Mbps against 19), saw the PC stuck on 2.4 GHz while the Mac sat on 5 GHz channel 108, and then scanned from the PC: eleven networks visible, none at all on channels 52 to 144, the radar-shared band the router was using. The cause was a 2019-era wireless card whose region settings blocked those channels, and no driver update would have changed that. Rapport switched on country detection with approval, rescanned to prove the limit was in the hardware, and recommended a $30 card instead of "restart your router."

Neither of those tickets would have closed at first line, and both would have gone around the chain described above: bounced, remote session, probably a swap.

Where this leaves your desk

This is not a request to replace anything on day one. Rapport also carries the inventory, the experience score, a detections-and-rules layer, remote management and patching (in controlled release with early clients), and over time one agent can take the place of the tools that do those jobs separately. But consolidation is a closing argument, not the reason to look. The reason is the 80 hours, and the chain of hand-offs inside them.

The practical place to start is your own numbers: what is your average age on a hardware ticket, how many times does one get reassigned, and how often does your remote session actually fix the device? Most desks do not know those three figures, and not knowing is the point. (For benchmarks to compare against, see these ITSM statistics, each with a real source.) Then put Rapport on the twenty machines that generate your oldest open tickets, with execution switched off if your security team prefers, and let your technicians investigate them from the ticket. If Rapport finds what your best engineer would have found, and tells you how sure it is, you will know within two weeks whether the quarter of your tickets that are about the device can stop being the quarter you handle worst.