Digital employee experience: what the score measures, and what has to happen after it

Somewhere in your enterprise this morning, a project manager opened her laptop, waited for Microsoft Teams to load, watched it stall, closed it, opened it again, and got on with her day. She did not raise a ticket. She raised one in March, when the same thing happened, and it came back closed with a note saying the technician could not reproduce the problem. So she has worked out a routine (open Outlook first, wait, then open Microsoft Teams) that gets her through most mornings, and the routine is now simply part of how she works.

None of that would show up on a service desk report, because none of it ever reached the service desk. A 2020 Nexthink survey of 3,000 employees found that only about half of the IT problems people experience are ever reported, and a 2022 Lakeside Software survey of 600 put the unreported share at 40 percent. The same surveys put the cost at roughly 100 hours a year per employee and 54 minutes a week, respectively. Across 1,500 people, that is the output of a mid-sized department quietly disappearing into restarts and workarounds.

Digital employee experience exists as a discipline because of that gap between what employees experience and what IT can see. This piece covers what the term means for an enterprise of your size, why the industry settled on a score as its answer, and why the score, useful as it is, only takes you halfway. The other half is what happens on the specific machine after the score drops, and most organizations have never had a good answer for it.

What is digital employee experience?

Digital employee experience (DEX) is the quality of an employee's interaction with the technology they are given to do their job: the laptop, the applications on it, the network it joins, the identity that signs them in, and the support they get when any of those fail. The phrase took hold around 2018 as a counterpart to customer experience. Organizations that measured every click a customer made on their website had, in most cases, no idea whether their own staff could join a video call without the fan spinning up.

In practice, DEX in an enterprise covers four layers. The first is the device itself: its age, its health, how long it takes to boot, whether it crashes. The second is the applications and how they perform on that device, not in the vendor's data center but on this person's machine over this person's connection. The third is the network and the services behind it, meaning Wi-Fi, VPN, identity and single sign-on. The fourth, and the one most easily forgotten, is the support experience: what happens when the employee asks for help, how long the ticket takes, and how many times the problem comes back.

The discipline matters more for a large organization than a small one, and the reason is arithmetic. In a company of 80 people, the person with the bad laptop sits near the person who can fix it, and the problem gets solved over a desk. In a company of 1,500 or 15,000, hybrid, spread across time zones and possibly supported by an outsourced service desk, the bad laptop can stay bad for a year without anyone who can replace it ever hearing about it.

Why did the industry settle on a score?

Once you accept that employees will not report most of what goes wrong, you need another way to see it. The market's answer was telemetry: an agent on every device collecting signals (boot time, crash counts, CPU and memory pressure, application response time, Wi-Fi quality, battery health) and rolling them up into a number. The established DEX vendors each built a version of this, and the DEX score became the common currency. It is a figure per device, per department and per fleet, trended over time, so a CIO can tell the board that experience is 74 this quarter, up from 71.

The score was a real advance, and it deserves credit before we get to what it lacks. It made the invisible visible: the project manager's morning routine shows up as a device with poor application start times whether she raises a ticket or not. It allowed comparison across the fleet, so a cohort of three-year-old laptops in one office could be seen dragging the number down. And it gave IT a metric a CFO would accept as a proxy for productivity, which moved the conversation from "how many tickets did we close" to "how well are people's devices actually working." Every enterprise of your size should be measuring it.

What a score cannot do

The limit is structural, not a flaw in any one vendor's product. A score tells you that something is wrong, and roughly which category the problem falls into (disk, memory, network, an application). It cannot tell you what is wrong with this machine, this morning, or what to do about it. The score is built from aggregated signals, and the cause of a specific fault nearly always sits in the detail those signals were aggregated away from.

Consider what happens in most organizations when a device's score drops. An alert fires or a dashboard turns amber, and a technician is assigned. The technician opens the device record and sees the same signals the score was built from, say high disk latency or repeated application crashes. From there, the process is exactly what it was before the score existed: a remote session, a look through the event log, a restart, a note on the ticket and, if the fault does not reproduce on cue, a closure that solves nothing. HappySignals' 2023 benchmark of 1.86 million end-user responses found that an incident costs the employee two hours of lost time even when it is never reassigned, and nearly four hours after a single hand-off (more service desk numbers, each with a source). A device problem the score can see but nobody can explain is exactly the kind of incident that gets handed off.

So the score has moved the problem rather than removed it. IT once did not know the laptop was bad. Now IT knows the laptop is bad, has known for weeks, and still does not know why, which is arguably a harder position to explain to the employee.

What has to happen after the score

What the discipline has been missing is the step between the score and the fix: an investigation, on the device, that works the way your best engineer works once they finally get their hands on the machine. A good engineer does not run a checklist. They form a hypothesis (this feels like disk), run a check, read what came back, rule it out or confirm it, and decide what to look at next. And they keep going past the point where the obvious signals look clean, because the obvious signals are what everybody already checked.

We built Rapport at Rezolve.ai on that premise, and it is the example I know best. The DEX score is there, per device and per fleet, with the telemetry behind it. But on any device with a low score, an Investigate action is one click away, and it starts an investigation on that specific machine rather than a ticket. In our own internal pilot, a desktop with a complaint of intermittent stutters came back clean on memory, crashes, GPU resets, hardware errors and disk latency, five checks any monitoring tool would have reported as healthy. The investigation kept going and found that the NTFS volume had been flagged dirty: Windows had been requesting a full disk check at every boot for a month and never getting one. No score would have surfaced that, because no score is built from that signal. It took somebody, or something, to keep asking.

An agent that investigates devices has to be trusted on them, so the architecture matters as much as the reasoning. In Rapport, the reasoning happens in the cloud through a gateway, and the device only ever makes outbound HTTPS calls on port 443, so there is no inbound port for your network team to open. On the device, the native agent runs the checks and classifies every command locally before it runs. Read-only checks go ahead, anything that would change the machine waits for a human to approve it, destructive commands are refused outright, and nobody can approve their own request. Every session is recorded step by step, which is what governance looks like when it is built in rather than bolted on. And if your security team would rather no command ran at all, execution can be switched off and the investigation still runs. The same agent also carries the rest of the endpoint job, from asset inventory and detection rules to remote management and patching (currently in controlled release), so the score, the investigation and the fix are not three products with three agents on every laptop.

How should an enterprise approach DEX now?

If you are starting from nothing, measure first. Get an agent on the fleet, get a score per device, and look at the distribution rather than the average. The average hides the cohort of old machines and the one office with bad Wi-Fi, and those cohorts are where the lost hours concentrate. Pair the score with the unreported-issue figures above and you will have, for the first time, a defensible estimate of what device problems cost your enterprise in people's time, the kind of hidden cost that quietly inflates keeping the lights on.

If you already have a score, ask what happens after it drops. Walk one low-scoring device from alert to resolution and count the hand-offs, the remote sessions and the days. Then ask whether anyone in that chain ever worked out what was actually wrong, or whether the device was eventually reimaged or swapped because that was easier than finding out. That single exercise tells you more about the state of your digital employee experience than the score does.

Whichever stage you are at, treat the adjacent questions as separate decisions rather than folding them into this one: how to evaluate digital experience monitoring tools, what "autonomous" should mean when a vendor promises autonomous endpoint management, and what a device ticket actually costs once you count the touch points and the eventual swap. Each deserves its own evaluation, and the DEX market itself is overdue for a rethink.

Go back to the project manager with the Microsoft Teams routine. A DEX score would have found her device months ago, and that is worth having. What she needed next was for somebody to look at her machine and tell her why. In the end, the measure of your digital employee experience program is whether that second step happens, or whether the score simply confirms on a dashboard what she already knew.