A new hire's first week is a sequence of requests. A laptop. Access to the code repository. A license for the design tool. A VPN certificate. Membership in three systems that each answer to a different owner. A seat in the ticketing tool itself, so they can start filing their own tickets. Every one of those runs through the same surface: the internal service catalog, the intake form behind it, the queue behind that, and a fulfillment promise that may or may not be real.
That surface is the product IT actually ships to most of the company. Not the platform the engineers rave about. Not the reference architecture on the slide. The catalog. It is the interface almost every employee touches, over and over, for their entire tenure, and in most organizations it is where their experience of working there quietly goes to die. One slow request. One dead-end form that demands a cost center they have never heard of. One ticket reopened because it came back wrong. The damage is never a single dramatic failure. It is accumulation.
My argument is narrow and, I think, underappreciated. The service catalog and the request flows behind it are IT's real product surface. Latency and friction on that surface are the actual mechanism by which shadow IT spreads and by which good people quietly disengage. Measure and fix that surface the way a growth team measures a conversion funnel, not the way an operations team measures a queue.
A product surface, not a service desk
I don't run an enterprise IT service desk, and I'm not going to pretend I own the whole IT operating model. I run security and DevOps, and my team built AgentOS, a governed internal agent platform with real users. That gave me a front-row seat to the difference between an internal flow people choose and one they route around, and a habit of reporting a platform's return to a board rather than its ticket count. Read this as reasoning up toward the seat that owns the catalog, from the seat that owns a slice of it.
Here is the reframe. A service desk is an operations function: intake, triage, resolve, close, measured against an SLA. A product surface is an interface a customer uses to get value, that succeeds or fails on whether they got it and how it felt. Those are two different jobs wearing the same tooling. The service-desk framing asks whether we closed the ticket inside the SLA. The product framing asks whether the person got the thing they needed, quickly, without having to become an expert in our internal taxonomy to do it. Most catalogs are run as the former and judged as if that answered the latter. It does not.
The tell is who the catalog is designed around. Walk into a typical one and it is organized by IT's org chart: a category per team, a form per tool, fields named after the system that consumes them. It is a filing cabinet for the fulfillment side, not a storefront for the person with a need. The person with a need does not think "I require a change to an entitlement group." They think "I can't get into the thing my manager told me to use." Every catalog that makes them translate the second sentence into the first is leaking experience at the front door.
Measure the request like a funnel, not a queue
ITSM tooling is very good at queue metrics and nearly blind to funnel metrics. It will tell you tickets opened, tickets closed, mean time to resolution, SLA attainment. All real, all operationally useful, and all measured from the moment a ticket already exists. The problem lives upstream of that moment and downstream of the close, in exactly the places a queue view cannot see.
Borrow the growth team's instrument instead. A request is a conversion event, and conversion events have a funnel: someone has a need, discovers the path, starts down it, completes it, and eventually gets value. Every stage has a drop-off, and the drop-offs are where the experience actually lives. Instrument these, most of which your ITSM tool does not report by default:
- Findability, not catalog size. Of the people who needed something, how many found the right item without asking a human? A catalog with four hundred entries and a search that doesn't work is a maze, not a library.
- Start rate, not submission count. How many people who opened a request form actually began filling it out, versus bounced off the first screen? A form that opens by demanding a cost code and a business justification loses people before they type a word.
- Completion, not the fulfillment SLA. Of the requests started, how many were submitted, and where do the rest die? Abandonment mid-form is invisible to a queue view, because no ticket was ever created. It is the single most important number you are not collecting.
- Time to value, not time to first touch. The clock the employee feels runs from "I asked" to "I have it and it works," not from "I asked" to "an agent acknowledged." First-touch SLAs flatter the desk and ignore the human.
- Reopen rate, not close rate. A ticket closed and reopened is not one resolved request. It is one failed request plus a second one, and the employee lived through both.
None of these require a new platform. They require treating the request as the unit of measurement, with a life before the ticket and after the close.
Every abandoned request is a shadow-IT purchase
The abandonment number matters more than any SLA, and here is why. When someone gives up on the sanctioned path, the need does not evaporate. It reroutes. They put the SaaS tool on a corporate card. They message a colleague who "knows a faster way." They copy the data into whatever unsanctioned thing gets them moving. The abandoned request and the shadow-IT signup are the same event seen from two ends. Analysts have estimated for years that a large and growing share of technology spend now happens outside the formal IT budget, and I read most of that number as abandonment rather than defiance: the aggregate of every request that was slower or harder to make than the workaround.
This reframes the security posture too. The instinct when you find shadow IT is to hunt it and shut it off. But the shadow tool is a symptom, and the funnel drop-off is the cause. Shut off the tool without fixing the flow and you have removed the symptom and kept the disease. The person still has the need, and they will find the next workaround, one you have not discovered yet. In regulated fintech, where the platform I help run ultimately serves more than 1,500 financial institutions, a handful of boundaries genuinely are non-negotiable and you enforce them without apology. But the overwhelming majority of shadow IT is not exfiltration. It is a funnel telling you where it leaks. Read the abandonment before you police the alternative.
Latency is the tax nobody books
Latency is the most expensive property of a request flow and the one least likely to appear in a budget. Every day a new hire waits for access is a day of salary spent on someone who cannot fully work, plus the harder-to-see cost of the impression forming in their first week that this place does not have its act together. Every hour an engineer waits on a routine entitlement is an hour of the most expensive labor you employ, idled by a queue. None of it books to a line item. All of it is real.
The queue view hides this because it measures the desk's throughput, not the requester's wait. A team can hit its SLA on every ticket and still leave the organization slow, because the SLA was written around what the desk could promise rather than what the work needed. The honest metric is aggregate wait: the total person-time the company spends waiting on its own internal flows. Almost nobody computes it, because computing it makes the tax visible. Make it visible anyway. Latency that stays unmeasured is latency nobody is accountable for reducing.
Friction is a quiet-attrition driver, not a survey line item
What friction does to people over time is the part that gets underweighted. A single slow request is an annoyance. A hundred of them, spread across a tenure, is a slow accumulating verdict: the tools fight me, the place does not work, nobody fixed the thing I flagged. That verdict rarely shows up as a complaint. It shows up as a good engineer who was already half-considering leaving deciding it isn't worth the friction to stay. Attrition attributed to "growth" or "fit" is sometimes just the sum of a thousand papercuts nobody counted.
The research on employee experience keeps landing in the same place: the day-to-day quality of the tools people use tracks with engagement and retention, and analysts now put a name on it, digital employee experience, precisely because it had been going unmanaged. I hold those findings loosely, and I would not trust one that claimed a clean line from a slow ticket to a resignation letter. But the direction is not controversial. The interface people touch a hundred times a year shapes how they feel about the place, and IT owns a large share of that interface.
This is where the deflection trap bites. Under pressure to cut ticket volume, a lot of programs chase deflection: the chatbot that "resolves" the request by making it tedious enough to file that the person gives up. That is abandonment rebranded as a win, and it moves the friction off the desk's dashboard and onto the employee's day, where you have stopped measuring it. Deflection that answers the question is progress. Deflection that hides the question is quiet attrition with a success metric attached.
Instrument the funnel this quarter
You do not need a transformation program to start. You need to change the unit of measurement and follow it where it leads.
- Measure the request as a funnel. Findability, start rate, completion, time to value, reopen rate, before the ticket and after the close, not just inside the SLA.
- Read abandonment as a shadow-IT forecast. Every mid-form drop-off is a workaround about to be bought. Fix the flow before you police the alternative.
- Book the latency. Compute aggregate wait time and give it an owner, so the tax becomes something someone is accountable for cutting.
- Refuse deflection that hides. Count a request resolved only when the person got the thing, not when they stopped asking.
If you own an internal service catalog, or you are the executive deciding whether it is a cost center to be minimized or a product to be run, start with one number: what is your abandonment rate, and can you even see it today? Most teams cannot, and the day they can is usually the day the real work starts. My bet on what is waiting at the bottom of the drop-off is a corporate card and a SaaS login.