The Broken-Process Signal: Tickets That Are Really a Process Failure

Monday, 09:05, at Ashgrove Housing. Ticket 5218 is from Femi, a housing officer who started twenty minutes ago and cannot sign in to anything. Nothing has been created for him to sign in to. Priya has seen this ticket before. Not this one, but its four older siblings. Each came from a starter and was raised on a first morning. In each case, the access request reached the desk on the start date or after it. Priya creates the account, the mailbox and the folder access in forty minutes. Femi is working by ten, and the ticket is closed with a tidy note. The subject line said "new starter has no access". What the ticket was really about was that the onboarding process hands the desk its one task a day late. Nobody on the desk owns that process.

A broken-process signal is a run of tickets whose cause is a step in some department's way of working rather than a technical fault. It might be the approval that stalls, the form nobody can find, or the month-end crunch. It might be the handover between two teams in which the ticket is what fell through the gap. The tickets are real and the fixes are real. The cause is upstream of the desk, in a process the desk did not design and cannot change. And the only thing the desk can do about it is see it, prove it, and carry it to the person who can. This article is part of our Ticket Data as Organisational Intelligence series. It is about that seeing, proving and carrying.

It covers what a process failure looks like when it arrives as a ticket, then the four classic shapes. Next come the three tells that separate a process fault from an ordinary request. Then comes evidencing it from the tickets with counts, stall times and hours, and finding the process owner. It covers what the desk fixes anyway, and the trap in doing so, then the ask. A short war story follows, then the process-fault brief to copy.

A Ticket Wearing a Process

A process, in plain words, is a sequence of steps across several people that produces something. That could be a new starter with a working account, an invoice paid, a leaver removed, a purchase approved, a month closed. Most of the steps belong to other departments. One or two of them, typically, touch IT. When a step outside IT fails, the failure very often arrives at the desk anyway. That is because the desk is the step after the failure, and because the desk is the one place in the building where you can raise a ticket. Nobody can raise a ticket against the finance director's inbox. They can raise one that says "still waiting for my access", and they do.

The ticket, in these cases, is a symptom with the wrong name on it. Femi's ticket is called "no access" and is filed under accounts. Its cause is that HR's new-starter form has no field for a start date. So the hiring manager fills it in on the morning the person arrives. That is the first morning anyone remembers. Three different teams each did their part correctly and late. The desk did its part correctly and fast. The process still produced a person sitting at a desk with nothing to do for an hour, and it will produce another next month.

The desk sees these before anyone else because it sees the downstream end of every process in the building. Finance sees month-end as a deadline; the desk sees it as eleven tickets in two days. HR sees onboarding as a form; the desk sees it as five starters in six weeks who could not work on day one. The desk's view is partial: it is only the IT end. But it is the only view that is counted, dated and written down. Everyone else's view of the process is how it felt last time.

The Four Classic Shapes

The approval that stalls is a request that needs a yes from someone outside IT. It waits in a pending status for days while the yes does not come. Access requests, software requests and equipment requests are the usual carriers. In the queue it looks like a ticket whose age is almost entirely spent in a waiting state. The requester replies "any update?" twice. The desk has learned to chase the approver as part of the job. The approval design that stops this is in Approval Workflows That Do Not Stall. This article is about noticing that your queue needs it.

The form nobody can find is a request that has a proper route and arrives by the wrong one. The proper route is on a page nobody visits. The ticket arrives as free text ("can someone sort out a laptop for the new person"). It is missing half of what the desk needs and costs a round of questions before any work starts. In the queue it looks like requests of one kind that never arrive through the form built for them. The technician's standard first reply is a list of questions. The form exists. It may as well not.

The month-end crunch is a hill of tickets on the same working days every cycle, from the same team, about the same systems. Its cousins are payroll day, the enrolment week and the quarter close. The tickets are often "slow", "won't run" or "locked". And each is genuine at the moment it is raised. That is because a process that pushes forty people through one system on one afternoon will make that system slow on that afternoon. The calendar cut that finds the hill is in Application and Process Hotspots, and it is linked here rather than repeated. The hill is the easiest of the four to prove and the hardest to get changed, because the deadline usually belongs to someone outside the building.

The handover between two teams is the gap in which a ticket is born. HR hires; IT provisions. Facilities moves a desk; IT moves the network port. Sales signs the order; finance raises the invoice and somebody needs the customer record created. Where the handover is a conversation rather than a step, it fails whenever the two people are busy. The failure lands at the desk as "the new person has nothing", "the moved desk has no network", "the customer isn't in the system". In the queue it looks like tickets that begin with a thing another team should have triggered and did not. It is the shape most often mistaken for an IT fault, because the IT step is where the gap becomes visible.

The Three Tells

Three tells separate a process fault from an ordinary request, and a ticket that shows all three is a candidate for this article's evidence sheet. The first is that the fix is never technical. The desk created an account, chased a person, explained where a form is, or ran something early. No technician's skill was needed, only a technician's time. The second is that the ticket's age was spent waiting on someone outside IT. The waiting statuses in Pending User, Pending Vendor, On Hold exist to record this. It shows up as a ticket that was open for six days and worked for twenty minutes. The third is that the requester is not the cause: different people, same step, same stall. One person waiting for one approval is a Tuesday. Nine people waiting on the same step across a quarter is a process.

Run the tells on a pile, not a ticket. A single ticket can show all three by accident. A pile of a dozen that shows all three is a process, and the only remaining question is which one.

Evidencing It From the Tickets

The evidence a process owner will accept has four parts, and all four come from the tickets you already have. The first is the count per run, not per month. The owner thinks in runs: per intake of starters, per month-end, per office move. "Nine of the fourteen starters this quarter had no working access on their first morning" is a sentence an HR manager can picture. "Nine tickets" is not. Count the pile against the number of times the process ran, and say both numbers.

The second is the stall: the time between the step that should have triggered the desk and the moment it did. Or it is the time between the request leaving the desk for approval and the approval coming back. Read it from the ticket history, not from memory, as a median and a worst case in working days. If you run QuerySolv, every ticket already carries its complete event history. In that case, the stall is the gap between two timestamps rather than anyone's recollection of how long it felt. Most tools keep some version of that history. Where yours does not, a waiting-status timestamp written into the note at the time will do.

The third is the cost in hours, with the owner's team first and the desk second, in ranges. At Ashgrove the arithmetic for one quarter ran like this. Nine starters were idle for a median of about three hours each before their access worked. That was between twenty-five and thirty hours of paid time spent waiting. The desk's forty minutes per rushed account plus a chase each came to between eight and ten hours. There was also the hiring managers' own time filling in the form on the morning rather than in advance. Nobody could count that, and the brief said so. The total was between thirty-five and forty hours a quarter. The desk's share was the smallest, which is the point. The hours that persuade are the ones that belong to the person reading the brief.

The fourth is three example tickets, with the requester's name and the approver's name removed and the dates left in. That way, the owner can see a real case without the case becoming a person. Three is enough to make it true and few enough to be read. Attach the pile's count beside them. The examples make the owner believe the count; the count makes the owner care about the examples. Neither works alone, and the desk that sends twenty tickets instead of three has sent a complaint with attachments.

Finding the Process Owner

The process owner is the person who can change the step: the form, the approval list, the deadline, the trigger. It is not the most senior person involved, and it is often not obvious who it is. Most processes in a small organisation have no owner written down and were never designed. They were started by somebody who left. The test is to ask who could, by Friday, make the step different. For onboarding it is usually HR, who own the form, with the hiring managers who fill it in. The desk's own half of that fix is in Getting the Request Before the Start Date. For an approval it is whoever decides who approves, which is usually the department head rather than the approver. For month-end it is the finance manager. The deadline may belong to someone above them. In that case, the ask changes from "move the deadline" to "move the report".

When ownership is unclear, ask your own manager to find out rather than guessing upward. A brief sent to the wrong owner is a brief that gets forwarded with a comment, and the comment is rarely "how helpful". When the owner turns out to be a peer of your own manager, send the brief through your manager, who can hand it across at the same level. The signal does not care who carries it. The owner does.

Expect the owner to be surprised. They have seen the process from their end, where it looks fine, because from their end the form was filled in and the approval was given. Nobody has shown them the downstream count before, because nobody downstream has counted it. This is the single most useful thing the desk brings to the conversation, and it is worth remembering when the surprise sounds like disagreement. It is usually just surprise.

What the Desk Fixes Anyway, and the Trap

The desk does its own part before it carries anything. An owner who hears "we have already done X and Y on our side" hears a colleague. One who hears "you need to fix this" hears an auditor. For the stalled approval the desk's part is a standard set of roles per job so fewer approvals are needed, and a reminder sent on day two. For the missing form it is a link in the auto-reply and in the knowledge base, and a template first reply that asks the missing questions once. For the starter it is a form of the desk's own with a start-date field. That way, whoever reaches the desk first is asked the one thing that matters. For the crunch it is a known-error note and a reply template, so each ticket in the hill costs five minutes instead of twenty. None of this stops the tickets. All of it makes them cheaper, and it is the right thing to do on its own.

The trap is that it works too well. A desk that absorbs a process fault efficiently makes the fault invisible to its owner. The owner now sees a process that runs smoothly, because the desk is running the missing step by hand every time. The month-end hill still arrives. The desk clears it in an afternoon. Nobody upstream hears anything. The hotspot article makes this point about applications and it holds with more force for processes, because a process has no vendor to blame. Do the desk's part. Then carry the signal anyway, with the desk's part listed in the brief as the thing already done. A fault the desk has learned to live with is not a fault that has gone away. It is a fault with a permanent member of staff.

The Ask

The ask is one change to one step, small enough to say yes to in a meeting and dated so that it can be counted again. For the stalled approval it is "add a deputy to the approval for this request type, so that it does not wait on one inbox". For the missing form it is "put the link on the page your team actually uses, and we will put it in our auto-reply". For the crunch it is "could the report run at nine on the first working day instead of four on the last? We will count the hill next month". For the starter it is "a start-date field on the HR form, and the form sent when the offer is accepted rather than when the person arrives". Each is reversible. Each costs the owner almost nothing. And each produces a count that will either prove the case or disprove it within a run or two.

Resist the larger ask, even when the larger ask is right. "Redesign onboarding" is correct and will not happen. "Add a date field" is small and will happen by Friday. The desk that comes back a quarter later with "the field cut first-morning tickets from nine to two" has earned the next conversation. The craft of the conversation itself, the tone, the brief and what to do when the owner says no, is in Taking the Signal to the Owner Without Making an Enemy, and nothing here replaces it. A small ask that is granted is worth more than a large one that is admired.

A Short War Story: The Drawings Folder at Redbrook Engineering

Redbrook Engineering's desk closed about sixty tickets a year that read "can't open the drawings folder for project so-and-so". Each came from someone in the workshop on the first morning of a new job. Each was fixed in ten minutes by adding the person to the folder's permissions. And each was raised after the person had already lost an hour finding out who to ask. Tomas, who had run the desk for two years, had always treated them as access requests, which is what they were called. He lined up a year of them for the department cut. Every one was a new project folder created by the design team from scratch, with the design team's group on it and nobody else. The folder template everyone assumed existed did not exist, and each designer created the folder by hand. Tomas took the count, the hour lost per ticket and three examples to the engineering manager. Her first words were that she had assumed IT created the folders. Tomas asked for one thing: a project folder created from a template with the workshop group already on it. The template took the desk an afternoon to build. The following year the desk closed six. The cost of the two years before was roughly a hundred and twenty desk hours. There was also something like a working week of the workshop's time, spent standing by a machine waiting for a folder. It was all for a process whose owner had never seen a single one of the tickets. The desk had been the manual step in another department's process, and had been so reliable at it that nobody knew the step was missing.

The Process-Fault Brief

The brief below is one page, written for the process owner rather than for IT. It carries the four pieces of evidence in the order the owner will want them. First comes what the process is and when it runs, then what the desk sees per run. Next comes what it costs their team and then the desk, then what the desk has already done. Last comes the one ask with a date for the re-count. Fill it from the tickets, strip every name except your own, and keep it to the page. The owner should be able to read it between two meetings and say yes before the second one.

PROCESS-FAULT BRIEF — ONE PAGE
To (role): ______________________   From: ______________________   Date: ____________

1. THE PROCESS
   Name, in your words: ______________________________________________
   Runs: per starter / per month-end / per move / per order / other: ______
   The step we see fail (the step, not the person): _________________________

2. WHAT THE DESK SEES, PER RUN
   Runs in the period: ______   Runs that produced tickets: ______   Tickets: ______
   The stall (from the ticket history): median ____ working days; worst ____
   Three example tickets, names removed:  #______  #______  #______

3. WHAT IT COSTS
   Your team's time per run (waiting, chasing, re-doing): ____ to ____ hours
   The desk's time per run: ____ to ____ hours
   Over the period: ____ to ____ hours in total

4. WHAT THE DESK HAS ALREADY DONE ON ITS SIDE
   [ ] ______________________________________________
   [ ] ______________________________________________

5. THE ONE ASK
   Change: ________________________________________________________
   Small enough to try for: one run / one month / one quarter
   We will count again on ____________ and send you the result either way.

6. WHAT WE ARE NOT ASKING
   Not a redesign of the process; not a change to who approves; not blame.

Priya sent the Ashgrove brief to the HR manager on a Wednesday with the nine-of-fourteen count and three tickets attached. The reply came the same afternoon and said, in full, "I had no idea. Date field added. Send me the number next quarter." The number next quarter was two of twelve, and one of those was a start date that had moved. The desk had not changed anything about how it created accounts. It had changed when it was asked to.

Frequently Asked Questions