Blog

The End User Becomes the First Resolver

  • Last Updated: Oct 08, 2026
  • 8 min read

Share on

The End User Becomes the First Resolver
  • Demand for self-service exists, but the capability doesn’t. Nearly half of employees want to fix IT issues themselves, yet only 13% find it easy, because traditional portals hand users the work without the context or authority to finish it.
  • Deflection is the wrong measure of success. It counts tickets avoided, not problems solved, and can’t tell a fixed issue from a user who gave up.
  • A true first resolver brings context and governed action to the user. It draws on device, identity, and history data to diagnose problems, acts automatically when it’s safe, and escalates with evidence when it isn’t.
  • Measure what sticks. Accepted-recommendation rate and resolution without reopen show whether problems were actually solved, and as easy work drains away, the service desk will be left with fewer but harder cases.

Reimagined ITOps is a weekly series about what IT operations becomes when AI stops assisting and starts operating. This is article 6 of Season 1. Stay with it.

49% of office workers now say they would rather fix an IT problem themselves than contact the help desk. 13% say it is very easy to do today.

Read those two numbers together, and you have the whole history of enterprise self-service. The appetite arrived years ago. The capability never did.

So the portal sits there with its knowledge articles and its forms, and employees do what employees do. They ask the person at the next desk. They restart twice. They live with the slow laptop for a month. Or they open a ticket as a last resort and wait.

The customer support landscape highlights a key reality: self-service is essential for scale, but effective resolution requires the right blend of automation and human expertise. 

My claim: the end user becomes the first resolver of IT demand, but only when context and governed action travel to the user. Sending the user to a portal to do IT’s work without IT’s tools is what we have been calling self-service, and it is why the numbers above look the way they do.

Flow diagram titled move the resolver to where the demand begins. Upper path labeled today: a user icon, then portal, then ticket, then queue, then engineer, then fix, drawn as a long chain of boxes. Lower path labeled first resolver: a user icon, then one box labeled context (device, identity, service, history), then one box labeled governed action, then resolved, with a dashed branch labeled escalate with evidence.

Fig. 1: Resolved, not deflected

Alt text: Flow diagram titled move the resolver to where the demand begins. Upper path labeled today: a user icon, then portal, then ticket, then queue, then engineer, then fix, drawn as a long chain of boxes. Lower path labeled first resolver: a user icon, then one box labeled context (device, identity, service, history), then one box labeled governed action, then resolved, with a dashed branch labeled escalate with evidence. Caption: resolved, not deflected. Reimagined ITOps S01 A06.

Self-Service Moved the Work. It Never Moved the Capability.

Every self-service program I have seen made the same trade. It moved the first step of resolution to the employee and left every input that step needed back inside IT.

The employee got a search box. IT kept the device telemetry, the identity state, the change calendar, the ticket history, and the authority to act. Then the program counted how many people used the search box and called that number deflection.

The market has now resold the same trade with a model behind the search box. The pitch this year is the ticketless enterprise, with first-line volume deflected at rates that would have been laughed out of the room 3 years ago. The ambition is right. The measurement is still deflection.

Deflection is the most comfortable metric in service management because it counts where a ticket did not go. It cannot tell the difference between a problem that was solved and a person who gave up. Both leave the queue shorter.

Engineers know this, which is why a new self-service portal usually earns a shrug from the people behind it. They see the same problems arrive weeks later, as escalations, with less information attached.

What a First Resolver Actually Holds

Take the most ordinary sentence in enterprise support: “My laptop is slow.”

In the current model, that sentence becomes a ticket. The ticket waits for triage. An engineer asks questions that the employee cannot answer. A remote session is scheduled, and days later, someone finds an agent pinned at full CPU since the last patch cycle.

A first resolver handles the same sentence differently, because it already holds what the engineer would have had to collect. Which device, which build, what CPU, memory, and disk are doing right now, which applications are consuming them, what changed recently, whether the device is compliant, and what this user has reported before.

With that in hand, the conversation returns a cause, a health position, and a recommended action within the exchange that started it. Where the action is low-risk and well precedented, it runs. Where it is not, it is handed to a human with the evidence already assembled.

That last clause matters more than the first. The user never runs an agent. They describe a problem in their own words, and the governed execution path underneath decides what is safe to do, exactly as it would for an engineer. Context has to travel with the work, which is why the context floor sits beneath every stage rather than being a feature of one of them.

Say “I Don’t Know” to the Person Who Asked

Here is the concession. A first resolver cannot resolve everything a user brings to it, and the design decision that matters most is what it does with the rest.

We built ours to state its coverage out loud. On a request where the system has a strong precedent, it acts or guides. Where precedent is partial, it says so and asks for more. Where it has none, it says that too and escalates with the evidence attached, instead of producing a confident paragraph that sends the employee down the wrong path.

That choice costs us on the metric everyone quotes. A system tuned to always answer deflects more. It also teaches employees, within a handful of bad answers, to stop asking. In operations, a confident wrong answer costs more than no answer, because it burns the user’s time and then the engineer’s.

So we score the first resolver on 2 numbers that are hard to game: how often its recommendation was accepted, and how often the issue came back. Resolution without reopen is the only version of deflection I would put in front of a CIO.

What This Changes

First, the service desk stops being where demand arrives. It becomes where the residual arrives: the cases that the first resolver could not carry. Volume falls, but the average difficulty of what remains rises, and a desk staffed and measured for volume will feel that as a problem before it feels it as a gain.

Second, the employee experience budget and the operations budget are no longer separate. The device and identity context that makes a first resolver work is the same context that makes an autonomous action safe later. Build it once, and fund it under both.

Third, retire deflection as a target. Keep it as a diagnostic if you must, but pay for resolved-without-reopen and accepted-recommendation rate. A vendor who will not report those 2 numbers is selling you a shorter queue, not a solved problem.

The Question for IT Leaders

Pull your self-service numbers for the last quarter. Next to the deflection figure, look for the column that says how many of those deflected issues were resolved and stayed resolved. If that column does not exist, you have been measuring where tickets did not go.

So my question: when your employees fix their own IT problems today, is that because you gave them the capability, or because they stopped waiting for you?

Next week: what happens to the service desk when the easy work drains out, and what remains is harder than the desk was staffed for.

Sanjesh Rao leads product strategy and innovation for Hexaware’s Agentic ITOps platform.

Frequently Asked Questions

Because most self-service programs moved the first step of resolution to the employee while leaving every input that step needed inside IT: device telemetry, identity state, the change calendar, ticket history and the authority to act. The employee got a search box. Deflection then counted how many people used it, and deflection cannot tell the difference between a problem that was solved and a person who gave up.

It means the context and the governed action travel to the user rather than the user being sent to a portal. When an employee says their laptop is slow, a first resolver already holds the device, build, resource usage, recent changes, compliance state and prior reports, returns a cause and a recommended action inside the same conversation, runs the action where it is low risk and well precedented, and hands the rest to a human with the evidence assembled. The user never runs an agent.

Accepted-recommendation rate and resolution without reopen. Both are hard to game. A system tuned to always answer will deflect more, but it teaches employees to stop asking after a handful of bad answers. Resolved-without-reopen is the only version of deflection worth putting in front of a CIO.

Author

Sanjesh Rao

Sanjesh Rao

Senior Vice President, Product Strategy and Innovation, Digital IT Operations, Hexaware

Sanjesh Rao is Senior Vice President for Product Strategy and Innovation in Hexaware’s Digital IT Operations business, where he leads the company’s Agentic ITOps platform. Part strategist, part think tank, part builder, he has shaped how Hexaware and its customers run IT operations: from scripted automation to reasoning systems to governed autonomy. He writes from live enterprise deployments, and his teams build the platform his ideas describe. Reimagined ITOps is his weekly column on where IT operations go next.

Read more Blue Arrow Black Arrow