Hexaware Positioned as a Visionary in the 2026 Gartner® Magic Quadrant™ for Custom Software Development Services
Hexaware Positioned as a Visionary in the 2026 Gartner® Magic Quadrant™ for Custom Software Development Services
Gartner, Magic Quadrant for Custom Software Development Services, By Jaideep Thyagarajan, Ryan McKinney, Nathan Davie, 7 October 2026. Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates. Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose. This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Hexaware.
Blog
Share on
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.

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.
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.
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.
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.
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.
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.
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.