The invisible half of Employee Self-service

I've spent the past several months working on employee self-service. The thing that has taught me the most in that time isn't a language model or an integration. It's a small asymmetry in how work gets requested.

A contractor needs elevated permissions for two weeks. Someone approves the request, someone grants the access, and the ticket closes. Two weeks later, what takes the access away? At most companies, nothing does. Nobody files a ticket asking to lose access. The grant had a requester. The removal doesn't. So it waits for someone to remember, or for the quarterly access review, a compliance ritual that exists mostly to claw back access that no process ever took away.

It looks like an edge case. I think it's the whole problem in miniature.

The ticket was never meant to solve problems. It was meant to coordinate humans: capture a request, put it in a queue, assign it to someone, track it until it's closed. For that job, it's genuinely good design. So good that it quietly became the unit of everything. Look at how an employee self-service tool gets measured: cost per ticket, time to resolution, first contact resolution.

There are firms that publish benchmarks for all of it, down to cost per voice minute. Every one of those metrics is a property of a ticket.

None of them measure whether the employee's problem got solved.

And a ticket only exists when someone asks for something. Work that nobody requests, like taking the contractor's access back, is invisible to the entire apparatus.

When companies set out to scale employee self-service, they usually start with password resets, which is fair. But it's worth noticing what a reset request actually is. Self-service tools handled the mechanical part long ago.

When someone still ends up at the help desk, they're not really asking about a password. They're locked out, and what they want is their access back. Even the oldest request in the book is an access request in disguise.

It's just the simplest one: one system, one action, no approval. The requests that show you what's broken are the ones further up. Who can use what. And access isn't the point here, any more than resets are.

It's just the clearest place to watch the ticket break down, because it forces every question the ticket was never built to answer.

Take a request every IT team gets constantly. An employee is moving into a new role on Monday and needs access to a reporting dashboard. What would it take to resolve that, rather than route it? You'd have to know who the person is. You'd have to know what their new role entitles them to.

You'd have to know whether that access needs approval, and from whom. Then get the approval, make the change in the identity system where access actually lives, and record what you did. Almost none of that is AI. It's identity, entitlements, policy, and the ability to write a change into another system. Old problems, all of them.

Access requests also break the industry's favorite metric.

The proudest number in employee self-service AI is deflection: the ticket that never got created because the employee was shown the right article. But there is no article that grants access. An access request can't be deflected. It has to be performed, with authority, in a system of record.

A tool that can only read and suggest, can't touch this category at all, no matter how good the model is.

Onboarding and offboarding are the same problem at scale. Onboarding is dozens of grants tied to a start date, spread across the identity provider, the HR system, device management, and a pile of SaaS tools.

Everyone has seen it fail. The new hire spends their first week borrowing a coworker's login. Offboarding is the mirror image, and probably the one that should worry people more, because its failure mode isn't slowness. It is incomplete-ness. A departure handled as a checklist of tickets is only as thorough as the checklist, and the accounts it missed don't announce themselves.

Companies notice onboarding failures right away, because new hires complain. They notice offboarding failures much later, if at all.

When I started building in this space, the thing that reoriented me was realizing that the language model is close to the least important component. It matters at the front, translating a messy human request into a structured one. That's the part the old self-service portals never solved. Nobody could find the right form.

But everything behind the model is plumbing, and the plumbing decides the outcome. Most AI tools deployed on employee self-service so far are models without plumbing: read-only API access, context rebuilt from scratch for each session, knowledge articles maintained by hand while the systems they describe change weekly. Give a model a memoryless, read-only view of the world and the only thing it can do is answer questions. So that's what it does.

The missing piece, writing back to systems of record, is missing for a reason. Reading is safe. Writing can break things. A wrong answer wastes a few minutes. A wrong action gives the contractor domain admin, or deprovisions the wrong person. Enterprises are right to treat those differently. In every deployment I've been part of, the actual critical path was the security review, not the technology, and I've come to think that's how it should be.

The thing that surprised me most is what determines whether a category gets automated. It isn't technical difficulty. It is policy clarity. Standard software access automates cleanly, not because it's easy to execute but because the organization has an unambiguous rule about it.

The categories that resist fail in one of two ways. Sometimes nobody ever wrote the rule down. Who approves elevated access for a contractor? It depends. On what? On things that live in the heads of two senior IT people. And sometimes the rule was written, but scattered.

At one large enterprise we worked with, a new employee requesting access to a sensitive data store could wait hundreds of hours. Not because anyone was lazy. The entitlements lived in one system and identity in another.

So a human had to verify who the person was, look up what they were entitled to, figure out who the approvers were when it wasn't the direct manager, and then chase those approvers down. The rule existed. It just lived in three systems and two people's heads, and someone reassembled it by hand for every ticket.

Either way, people fill the gap with judgment, one ticket at a time, which is exactly what doesn't scale. Taking humans out of that loop turns out to be largely an exercise in making an organization state its policies, completely and in one place. Technology is almost the easy part.

I work on this at DevRev, so discount accordingly. It's fair to ask why the incumbents haven't rebuilt around resolution. Partly because retrofitting write-back, persistent state, and data-level permissions onto a twenty-year-old ticketing architecture is genuinely hard.

And partly because their revenue scales with human agents and tickets. That doesn't make anyone dishonest. It just means the incentive to make tickets disappear sits outside the companies that own them.

I don't know how long this transition takes. Enterprises move slowly here, mostly for good reasons, and trust in systems that act will be earned one category at a time, starting with the boring ones. But my test for whether the architecture has really changed is simple.

When someone leaves a company, does their access disappear from every system by the end of the day, without anyone asking? Today the answer is almost always no. The day it's yes, the ticket will have stopped being the unit of work.