IT service desk process: where requests stall

A designer asks for an Adobe license in #it-help at 9:40 on Monday. Someone turns her message into a ticket at 11. It lands in the hardware queue, because the form had no option for software, and it moves twice before the applications team picks it up on Tuesday. They check her role in Workday, add her to the Okta group and assign the seat in four minutes. The ticket closes on Wednesday, and nobody tells her in Slack.

Every step worked. The request still took two days, and almost none of that time was spent doing anything. It went on waiting between systems: from chat to the ticketing tool, from the wrong queue to the right one, and from the closed ticket back to the person who asked.

This post walks through the six stages of the IT service desk, where each one stalls, and what to fix first.

The six stages, and where each one stalls

1. Intake, triage and routing. Every channel feeds one queue, and each ticket goes to the team that fixes it. It stalls when the requester picks the wrong category and the ticket moves three times before anyone works it. Why IT tickets keep getting moved.
2. Password resets and lockouts. People reset a password or clear a lockout themselves, after a check with a second factor they already use. It stalls when every reset is a ticket, and it fails when anyone with a name and a manager’s name can trigger one. Who is really asking for that reset.
3. Request fulfillment. Software, groups and mailing lists the role already allows are handled end to end. It stalls when an allowed request waits a day for someone to click the same three buttons. Why IT needs an AI support agent.
4. Access requests and approval. Access the role doesn’t include goes to the owner of the system, and every grant gets an end date. It stalls when requests wait in a shared queue for someone who can judge them. Access requests, and access before day one.
5. Incident to resolution. One action opens the channel, pages the right people and starts the timeline. It breaks when the timeline is pieced together from Slack a week later, and the same incident comes back. Why incidents come back.
6. License reclamation. Unused seats are found, the holder is asked, and the seat comes back before the renewal. It breaks when a seat is taken without asking and requested back the same week. How we reclaim unused licenses at Tray.ai.

Why requests stall between systems

The work happens outside the ticketing tool. A password is reset in the identity provider, a seat is assigned in the app’s admin console and a role is checked in the HRIS. The ITSM platform records that the work was done, and every step between it and those systems is a person copying something across.

Requests arrive everywhere. People ask in Slack, in Teams, by email, in the portal and at someone’s desk. Each channel has its own path into the queue, and requests made in passing never become tickets, so IT handles more than it can report.

Routine work waits in the same queue as hard work. A password reset sits behind a broken VPN, because both are tickets and the queue treats them alike. The routine requests take the least judgment and still wait the longest.

Nothing comes back to the person who asked. The ticket closes in the ITSM platform. The requester finds out by trying again, or by asking in Slack whether anyone saw their message.

What to fix first

1. Bring every channel into one intake. A Slack message and an email to the help address become the same ticket, with a link back so the reply goes where they asked.
2. Classify from what the ticket says. Route on the description, with the requester’s role and devices attached, and count how often tickets move.
3. Hand password resets to the requester. Use a second-factor check and a one-time link, and send every admin account to a person.
4. Fulfill what the role already allows. Check the request against the role in the HRIS, grant it through the integration, and close the ticket in the thread where it started.
5. Send everything else to the person who can decide. That means the system’s owner for access, the on-call engineer for an incident, and IT for anything that needs judgment.

Where an AI agent fits

Most of these fixes are workflows that run the same way whoever starts them. An AI agent sits in front of them in Slack or Teams. It answers what it can, calls the workflow for a reset or an allowed request, and hands the rest to IT with the context already gathered.

Apollo’s IT agent, built on Tray.ai, deflected 40% of IT tickets in its first two weeks.

“The agent only responds when it knows it can fully or partially solve the problem. If it can't, it escalates. That's why people trust it.”

For the agent side in more depth, read everything you need to know about ITSM agents.

Many requests start with a change in who works at the company: a new hire, a move or a departure. Employee lifecycle automation covers that side.