Why Separating Incidents, Requests, Problems and Changes Matters

The monthly report at Stonebridge Insurance said twenty-three breaches, and the IT manager had circled the number in red before the meeting started. Hana, who ran the four-person desk, had already read the twenty-three. Nineteen of them were new-starter setups: a laptop, an account, a mailbox and a folder. HR logged them a week before each start date. All were marked as incidents because the form's default was incident. All were given the four-hour clock that incidents get. All had breached by the time HR confirmed which Monday the person was actually starting. The desk had restored every broken thing that month inside its target. The report said the desk was failing. Both statements were true, and only one of them was being read.

Separating the work types means giving each of the four kinds of work its own clock, path through the desk and line in the report. Those kinds are incident, request, problem and change. Each gets its own, instead of one clock, one path and one line for everything. The four types themselves are defined with examples in The Four Work Types in Plain Words. This article is part of our Incidents, Requests, Problems & Changes series. This one is the case for keeping them apart, made with numbers.

It covers what a desk gets when it keeps everything in one pile. Then come the three things that genuinely differ between the types: the clock, the workflow and the report. Next is one month at one desk shown both ways, followed by the four things that go wrong when the types are mixed. Then it covers how little separation costs on a small desk. A short war story and a per-type expectations table to copy finish the article.

What One Pile Gives You

A desk that does not separate the types still has all four of them; it just cannot see which is which. Every ticket arrives through the same door, gets the same default priority, runs on the same clock, moves through the same statuses and lands in the same monthly total. That is tidy, and it is the tidiness of a drawer with everything in it. The clock is right for incidents and wrong for the rest. The statuses are right for incidents and meaningless for a change. The total is right for nothing, because it adds a laptop order to a server outage and reports the sum.

The usual symptom is a desk that feels fine and reports badly, or reports fine and feels terrible, and cannot explain either. Hana's desk felt fine: broken things got fixed quickly, people were polite, the queue was short on Fridays. It reported badly because the clock that measured it had been designed for broken things and was being run against orders. On the opposite desk, every request is closed in a day because it was done without approval. Every incident is marked resolved on the first reply. That desk reports beautifully and has three departments that have stopped raising tickets. One pile means the desk is being graded on the average of four different exams.

Separation is not a big change. It is one word written on each ticket at triage, two clocks instead of one, and two short lists kept by the desk about its own work. The rest of this article is about why those small things change what the desk promises and how it works. They also change what it can say about itself at the end of the month.

Different Clocks

An incident runs on a clock that starts when it is logged, because every minute of a broken thing is a minute somebody cannot work. The clock has two targets. A response target is the time by which a human has replied. A resolution target is the time by which the person can work again. Both are set by priority. That is the clock most help desk tools are built around, and the design of its targets is covered in Response vs Resolution Targets. It is a good clock. It is a good clock for incidents.

A request runs on a clock that cannot honestly start until somebody has said yes. A laptop for a new starter needs a manager's approval and a start date; folder access needs the data owner's agreement; a software purchase needs a budget holder. Until that person acts, the desk is waiting. A clock that runs while the desk waits measures the approver's diary and reports it as the desk's speed. So the request clock is an expected fulfilment time, counted from approval: "once your manager approves, we normally have this done in three working days." Before approval there is still a promise, but it is a different one: that the desk will chase the approver, and tell the requester when it has.

A problem has no clock in the target sense, because investigation does not run to a stopwatch. A desk that puts one on it will stop investigating at the deadline. What a problem has is a review date: a day, two or four weeks out, when somebody opens the record and asks what has been found. A change has a scheduled date, agreed in advance, and the promise is that the change happens on that date and the morning after is ordinary. Neither of those is a response target, and neither should be reported as one.

Whether your tool can run two clocks is the first thing to find out, and the honest answer varies. Some tools attach targets to priority only, so a request and an incident at the same priority get the same clock. The workaround is a lower priority band reserved for requests with a longer target. Some tools let a form or a department carry its own targets, which is better. Some pause the clock in a waiting status and some do not. Test yours: log a request, put it in whatever "waiting for approval" status you have, leave it over a weekend, and read the due time on Monday. Then write down only what the tool actually does. A clock exclusion that exists in the policy and not in the tool is a promise the report will break for you.

Different Workflows

A workflow is the sequence of states a ticket moves through from logged to closed. The four types have four different sequences, which is why one set of statuses fits one of them. The incident path is short and fast: logged, triaged, being worked, perhaps escalated, restored, confirmed by the person, closed. Every state is about getting the thing working again. There is no approval in it, because nobody approves a fix for a broken mouse, and there is no scheduling in it, because the schedule is now.

The request path has a step the incident path never has: approval. Logged, sent for approval, approved or declined, being fulfilled, delivered, confirmed by the requester, closed. The "waiting for approval" state is where requests spend most of their life. It is where they stall, because the approver is not on the desk and does not see the queue. A request also has a state the incident path cannot have, which is declined: the manager said no, the ticket is closed, and nothing was broken or fixed. Closing a declined request as "resolved" is the kind of thing a one-pile desk does every day without noticing.

The problem path is investigation: opened by the desk, incidents linked to it, cause being investigated, cause found, workaround written or fix scheduled, closed. Nobody confirms it from outside, because there is no requester. The change path is a plan: proposed, reviewed, scheduled, announced, made, verified, recorded, closed. Its most important state is "scheduled", which is a date rather than a status, and its most important field is the rollback. The full change path, kept to one page, is in the change management series.

Many small-team tools ship a fixed set of statuses, and you may not be able to add "waiting for approval" or "scheduled". That is less of a problem than it sounds, because the meaning of a status lives in the team's written definition rather than in its label. "On Hold" can mean "waiting for approval" on a request if the team has written that down and the approver's name is in the ticket. What does not work is using the same status to mean three things depending on the type, with nobody having written any of them down. The workflow and status series in this library is about writing them down. I once ran a desk where "pending approval" was available on incidents. Somebody used it on a down server. The server did not get approved for several hours.

Different Reports

The report for incidents answers "how fast do we restore things, and what keeps breaking?" Its numbers are the count, the split by category, the time to restore against target, and the repeats, which are the problems-in-waiting. The report for requests answers "how reliably do we deliver what people ask for?" Its numbers are the count by kind of request, the time from approval to delivery, how long requests sit waiting for approval, and how many were declined. Those are different questions with different numbers, and a single "tickets closed within target" figure answers neither.

The report for problems is a short list: how many open, how many closed this month, and for each closed one roughly how many incidents it will stop. The report for changes is also short: how many made, how many went wrong, and how many incidents in the month trace back to a change. Both lists are the desk's evidence that it is doing more than bailing. The bailing is in the incident report; the lists are the pump. The last article in this series builds the whole monthly page; for now the point is that none of it can be produced from a pile.

And the total is the number everybody reads first, which is why it deserves a sentence. Three hundred tickets in one pile says "busy". Three hundred split into a hundred and ten incidents, a hundred and eighty requests, four problems and six changes says "mostly delivering things, with a steady background of breakage and a desk that is starting to fix causes." The second sentence is a conversation with management. The first is a shrug with a number on it.

One Month at One Desk, Two Ways

Here is a month at the Harbourview Clinic desk, three technicians supporting a clinic and two satellite surgeries, reported first as a pile and then by type. The numbers are invented and the shape is not; it is the shape of nearly every small desk I have seen do this for the first time. The pile version is what the clinic's practice manager had been reading for a year. The split version took Tomas, the desk lead, one afternoon with a spreadsheet and a column called "type".

Read the breaches row twice, because it is the row that changed the conversation. Twenty-seven breaches in a pile is a desk in trouble. Three incident breaches out of a hundred and eighteen is a desk doing well. Eight late requests is a list of eight things to look at. Sixteen requests breaching a clock that should never have been on them is a settings problem. Same month, same tickets, same three people. The practice manager had been asking the desk to be faster for a year. The desk had needed a second clock and a word.

What Goes Wrong When They Are Mixed

The first thing that goes wrong is requests disguised as incidents, which breach the incident clock and make the desk look slow. This is the Stonebridge pattern. The form defaults to incident, or the triager picks the higher priority because the requester's manager is senior. A thing that takes three days from approval is measured against four hours from logging. The report fills with breaches that nobody on the desk could have prevented. After two months of it, the breach count stops meaning anything, which is the real cost. A breach report that is mostly noise is a breach report nobody reads, and then the real breaches hide in it.

The second is the reverse: incidents disguised as requests, which wait politely in an approval queue while somebody cannot work. "Can I have the CAD licence reinstated?" sounds like a request and is an incident if the engineer had a licence yesterday. "Please set up my e-mail on the new phone" is a request, unless the old phone broke this morning and the person has no e-mail at all. The desk sends it for approval, the approver is in meetings, and the person works around it for three days with a borrowed laptop. The cost here is not in the report; it is in the department that quietly stops trusting the desk with anything urgent.

The third is problems never opened, because in a pile every repeat is just another incident. The printer fails seven times, seven technicians fix it seven ways, and the eighth failure is a surprise to everyone. Problems do not chase. Problems wait, and a desk that measures itself only on incident speed is rewarded for fixing the same thing quickly forever. The remedy is cheap, a list and a threshold, and the practice is in Finding the Repeat Tickets.

The fourth is changes made as incident fixes, with no record. A technician fixing an incident on Friday afternoon updates a driver, alters a firewall rule, or moves a share, and writes "fixed" in the resolution note. On Monday four incidents arrive from people whose printing has stopped, and the desk spends the morning diagnosing from scratch a thing it did itself on Friday. In a pile there is no place for "what changed" to live, so it does not live anywhere. A change record of three lines would have turned Monday morning into a four-minute rollback.

What Separation Costs on a Small Desk

Separation costs about thirty seconds per ticket at triage. That is the time it takes to ask "is anything broken, or does someone want something?" and write the answer on the ticket. That is the whole of the daily cost, and the person who pays it is whoever triages, which on a small desk is often everybody in turn. The call is not always easy, and the gray cases, with a decision table, are worked through in Incident or Request? The Daily Call. But most tickets are not gray. Most tickets are a broken thing or a wanted thing, and the thirty seconds is mostly spent typing.

The setup cost is a morning. Decide where the type is recorded in your tool: a form per type, a subject prefix, a category branch or a field. Each works in a different kind of tool. All are compared in Implementing Four Types in an Ordinary Help Desk Tool. Set the second clock, or the lower priority band that stands in for it. Write the expectations table at the end of this article and pin it up. Start a list of problems and a list of changes in whatever the desk already uses for lists. That may be the ticketing tool, the knowledge base or a shared document. None of this needs a module. A full ITSM suite has a module for each type, and a three-person desk gets the same benefit from a form, a prefix and two lists.

The ongoing cost is the two lists, which somebody has to read. Problems want a look once a week. Changes want a look before each one is made and once after. The person doing the looking is usually the desk lead for about an hour on a Friday. That hour is the most productive hour on the desk, and it is the first one cut when the week is bad. That is why it belongs on the calendar rather than in somebody's intentions. I have cut it myself, for a month, and spent the following month fixing a printer eleven times. The hour was cheaper.

What separation does not cost is a bigger tool, more statuses or a committee. The desk does not need a change advisory board to write down that it is swapping a printer on Saturday. It needs a line in a list, a date, and the name of someone who was told. Keeping the process the size of the desk is the whole trick.

A Short War Story: Nineteen Breaches at Stonebridge Insurance

Stonebridge Insurance's desk reported twenty-three breaches a month for a quarter. By the third month, the IT manager had drafted a request for a fifth technician, with the breach count as its first line. Before it went to the finance director, Hana split one month's breaches by type. Nineteen were new-starter requests logged as P2 incidents, breaching a four-hour clock. That clock had started the moment HR submitted the form, a week before anyone knew the start date. The desk's actual incident performance that quarter was four breaches out of about three hundred and fifty incidents. The cost was three months of being graded as failing. It was a hiring case built on a number that was measuring HR's calendar. It was also a manager who had stopped believing the report by the time it was right. Stonebridge changed the form default to request and gave new-starter setups a five-day expectation counted from a confirmed start date. The next report showed two breaches. A request measured by an incident clock will fail every time, and it will take the desk's reputation with it.

The Per-Type Expectations Table

The table below is the four clocks, paths and report lines on one page, written as what the requester is told and what the desk commits to. Fill the blanks with your own numbers, which should come from what the desk already achieves rather than from what sounds good. The way to find those numbers is in What to Promise and What Never to Promise. Then pin it where the triager sits, because it is the triager who says the first sentence to the requester, and the first sentence is the promise.

Two cells in the table earn their place more than the rest. One is "A workaround counts" under incident. It stops an incident being held open for a week while someone hunts for a cause that belongs in a problem record. The other is "clock from approval" under request, because it is the line that would have saved Stonebridge a quarter. Everything else in the table is detail. Those two are the argument.

Hana pinned the table above the triage screen the week after the hiring request was withdrawn. The desk did not get a fifth technician, and by the next quarter nobody thought it needed one. The twenty-three breaches had been real tickets, logged by real people, worked by a desk that was doing well. They had simply been counted in the wrong column, and a wrong column, read for long enough, becomes the only thing anyone knows about the desk.

Frequently Asked Questions