Find the leaks before you build the agents
Automating operations has no natural starting point. The queue is thousands of tickets deep, every one of them looks automatable, and the ranking usually comes down to whoever argues hardest in the room.
We analyse a ticket export, typically one to two quarters of it, and we make sure the full work logs come with it. Metadata on its own will not tell you where the time went. Three patterns then show up again and again across large orgs, and they are rarely the three a team would have picked. This article walks one estate through all three as a case study.
Where the time actually sits
The subject here is 28,077 tickets a month of production-operations work, every one of them touched by a person who wrote something in the journal. Every percentage below is a share of that number.
Customer wait is severity-weighted time that people outside the company spent waiting. Engineering toil is time your own people spent on these tickets. Both are measured from the work journals. Every figure on this page comes from this one export. The three patterns carry across the orgs we read. The sizes change every time.
Pattern 1. The ticket that changes hands
Ask a team where their time goes and they will point at the hard tickets. The work logs point somewhere else, and it is not close.
One journal first, so the rest of this section has a shape to refer to. Each mark is one person writing in it.
A ticket that changed hands cost 4.34 hours against 0.78 for one that did not, across 12,939 tickets and 8,570.
A hand-off is what happens when whoever is holding the ticket cannot answer it. Each one is a search for somebody who can, and these tickets went looking 18,275 times a month. The journal above took eight people to arrive at check the application is up. The expensive part was producing an answer that was cheap to produce.
Measured on closed tickets, where both sides have a real end time. This re-prices tickets that already exist: it assumes a ticket kept in one pair of hands would behave like the ones that already are.
Pattern 2. Answering beats fixing, four to one
There are two obvious things to automate in this work, and they turn out to be very different sizes.
Answer it at intake. A lot of tickets never need a production change at all. The whole ticket is a question, a routing decision or an explanation, and it ends when somebody replies. An agent can answer those on arrival and close them without a person picking them up.
Automate the fix. For the tickets that do change production, give the repair work to an agent instead of an engineer.
The second one reaches more tickets. The first one saves far more time.
Automating the fix reaches the larger share of the tickets, 61% against 39%, and returns 9% of the engineering toil the two save between them.
Per ticket those totals are easier to weigh. Answering one at intake saves 4.2 engineering hours. Automating its repair saves 16 minutes. On customer waiting it is 2.3 hours against 22 minutes. That 4.2 is worth holding against Pattern 1, where a handed-off ticket cost 4.34 hours: answering a ticket on arrival saves close to the entire cost of letting it travel.
The fixing was never where the time went. It went on working out what was wrong and getting that to somebody who could act.
This compares only the tickets these two automations reach: 5,000 a month that never needed a production change, and 7,787 that did. Tickets in neither group are left out, which is why each bar sums to 100. Automating every production change is the more impressive programme, and the one that usually gets funded first.
Pattern 3. It is never one automation. Here it is 6,364 small ones.
The count changes from one company to the next. Nothing in it is ever big. Here the single largest build reaches 3.1% of the 28,077, it takes 100 of them to reach half, and all 6,364 to reach three quarters.
Note: an "is the filesystem full" check is a separate build on bare metal, on Windows, on z/OS and on Kubernetes, and we counted each one separately rather than assuming it ports.
So you phase it, against the curve
Ranked by return, coverage bends early and then flattens hard. That shape is what makes a phased plan work.
| Builds | Tickets covered | Customer wait removed | Eng toil removed |
|---|
What handling a ticket actually looks like
Not every build costs the same. Sorted by how much has to be written, the 6,364 fall into four rungs, and half the work sits on rungs where an agent does the writing and an engineer only reviews it. The bottom rung is already built: the Skills library is public, at registry.runwhen.com, currently 854 tools across 188 Skill templates. The 531 below are the builds where something in it already matches the ticket.
I picked three real tickets from the set, one from each rung. Pick one, then walk its stages.
A stage begins when one credential is granted. Everything the earlier stages could do keeps working, so stage 3 is the agent at full reach on that ticket. Each request is written down before it is asked for.
The amber notes are the ones worth reading. An agent that knows when to stop and name a team is the difference between something you can point at production and a demo.
Want to start on a free ticket analysis?
One queue is enough to start with.
Walk through your own queues
Bring one queue you already suspect. Under NDA, we look at what an export would show for it, and what the first ten builds would probably be. You keep the analysis whether or not anything follows.
Book a time