The Four Work Types in Plain Words, With Three Examples Each

Monday, 08:40, at Meridian Parts, a distributor with a warehouse and forty desks. Three tickets arrived in the same minute. Ticket 3318, from dispatch: "The label printer has stopped again." Ticket 3319, also from dispatch: "Can we get a second label printer, so this does not keep happening?" Ticket 3320, from the IT manager: "That is the fourth label-printer ticket this month. What is going on with it?" Below them, from Friday, sits a note Priya left for herself as a ticket: "Swap dispatch printer for the newer model, Saturday 07:00." Four tickets about one printer. Dev, who has been on the desk for nine days, has been told to work the queue from the top.

Those four tickets are four different kinds of work, and the queue gives no hint of it. One needs fixing in the next hour. One needs somebody's approval and a purchase. One needs somebody to notice it is the fourth. One needs a date, a plan and a way back if Saturday goes wrong. A work type is the kind of work a ticket is asking for. The four that cover nearly everything a help desk does are the incident, the request, the problem and the change. This article is part of our Incidents, Requests, Problems & Changes series. The series covers the four types, why separating them matters, and the daily incident-or-request call. It covers implementing the types in an ordinary tool, approvals, and reporting by type. This article is the vocabulary.

It covers where the four words come from and why a desk of three should bother with them. Each of the four follows in turn, with a plain definition, three examples and the one-line test that identifies it. Next come the pair you will confuse most and the pair you will forget to record. Then come the four side by side, in a table and a picture, and why the names matter. A short war story and a definition card to pin above the desk follow, in that order.

Where the Four Words Come From

The four words come from ITIL, the Information Technology Infrastructure Library. It is a long set of practices for running IT services. Most small desks have met it as a certificate on somebody's wall. You do not need the rest of it to use the four words. ITIL has a plain-words introduction in ITIL in Plain Words. The four work types are the part of it that a desk of any size gets value from on the first day. That is because they answer a question the desk is already asking forty times a day without noticing: what does finished look like for this ticket?

That question is the whole idea. Every ticket ends, and the thing that ends it is different for each type. An incident ends when the thing works again. A request ends when the person has what they asked for. A problem ends when the desk knows why something keeps breaking and has done something about it. A change ends when the alteration is made, checked and written down. Four kinds of finished, four kinds of work. If two tickets end the same way they are the same type, however different they look at the start.

A desk of three should bother because the four types have different clocks, different paths through the desk and different places in the monthly report. A desk that keeps them in one pile measures itself wrong in all three. The full argument is in Why Separating Them Matters. The short version is that a request for a second printer, measured against the clock for a broken one, will breach every time. The report will say the desk is slow. The desk was not slow. It was being timed for the wrong race.

The names are a vocabulary, not a filing system, and you do not need a field in the tool for them to be useful. The desk can say "that is a request" out loud, in triage, in a reply, in a meeting, and get most of the benefit. Where to put the word in the tool is answered in Implementing Four Types in an Ordinary Help Desk Tool. The word lives in the team before it lives in the tool.

Incident: Something That Worked Has Stopped

An incident is an unplanned interruption to something that was working, or a drop in how well it works. The word "unplanned" is doing the work: nobody chose this, and somebody wants it back the way it was. It does not have to be big. One person's mouse that stopped is an incident. The whole building's e-mail that stopped is also an incident, a larger one, and the size changes the priority, not the type.

Three examples. Ticket 3318, the dispatch label printer that has stopped: it printed on Friday and does not print today. Dana in finance, whose laptop shows a black screen and a cursor when she turns it on: it booted yesterday. The sales team, who can receive e-mail but cannot send it since about 09:15: it sent at 09:00. In each case something existed, worked, and now does not, and the person at the other end would like the clock turned back.

The one-line test is: was this working before, and is it not working now? If both halves are yes, it is an incident. The test deliberately ignores how it broke, whose fault it was, whether it will happen again and whether anyone is shouting. Those are questions for later, and some of them belong to a different type.

Finished, for an incident, means the person can work again. That is a lower bar than it sounds, and the bar is low on purpose. A workaround, a way of getting the job done that avoids the broken part, counts. Dispatch printing labels on the printer in goods-in is an incident resolved, even though the dispatch printer is still broken. Finding out why it broke is not part of finishing the incident. The incident wants the person working; the reason can wait for a problem record, which is the next type but one.

Incidents have the fastest clock of the four, because something is wrong right now. They are also the type the desk is best at, because they are the type the desk was built for. Most technicians, handed a broken thing, will fix it without being asked twice. Handed a request for a thing, the same technician will put it off until Thursday, which is a fact about requests and not about technicians.

Request: Someone Wants Something That Is Not Broken

A request is a person asking for something they do not have yet. Examples are an account, a device, access to a folder, a piece of software, a question answered, and a second printer. ITIL calls it a service request, and the two terms mean the same thing. Nothing is broken. Nothing was working yesterday and has stopped. The person simply needs something the desk can provide. The desk's job is to provide it, correctly, in a reasonable time, with the right person having said yes.

Three examples. Ticket 3319, the second label printer for dispatch: the first one is a different ticket; this one is a thing dispatch does not own and would like to. A new starter in sales, beginning on Monday, who needs a laptop, an account, a mailbox and access to the sales share: four things that do not exist yet. Tomas in marketing asks "how do I set up an out-of-office reply?" That is a question. A question is a request for an answer, which is a thing he does not have.

The one-line test is: is anything broken, or does someone want something they do not have yet? If nothing is broken, it is a request. Notice that the test does not ask whether the request is urgent, reasonable or in budget. A request can be very urgent. The new starter arrives Monday whether the laptop does or not. Urgent and broken are different words, and a desk that merges them ends up with everything marked as an incident and nothing meaning anything.

Finished, for a request, means the person has the thing and has confirmed it works for them. Delivered is not quite finished; delivered and confirmed is. On the way there a request usually passes through a step incidents never have: somebody other than the requester has to agree. A manager approves the laptop, a data owner approves the folder access, a budget holder approves the purchase. That approval step has its own article later in this series, because it is where requests stall.

Requests have a slower clock than incidents and a more predictable one. A broken printer might be fixed in five minutes or five days. A new laptop takes the same three days every time, because the steps are the same every time. That predictability is the gift requests give the desk. Requests can be listed, each with its approver and its expected time, and most of the arguing stops.

Problem: The Cause Behind the Incidents

A problem is the underlying cause of one or more incidents, usually noticed because the same incident keeps coming back. The incident is the label printer stopping on Monday. The problem is whatever makes it stop every Monday. Fixing the incident gets dispatch printing again. Fixing the problem means the incident stops arriving. These are different jobs and they take different amounts of time. A desk that only ever does the first one is on a treadmill with a queue attached.

Three examples. Ticket 3320, the IT manager asking why the printer keeps failing: that is a problem being noticed out loud. The sales e-mail that stops sending at 09:15 on Mondays, for the third week running: three incidents, each fixed by a restart, one problem. The laptop model whose battery gives up at eighteen months produces a steady trickle of "my laptop won't hold charge" incidents. That is twenty incidents, one problem, and the fix is a different model on the next order. The word problem in ordinary English means "anything wrong", which is exactly why the help desk meaning takes a sentence to explain. (It is also why the intake form should not say "describe your problem". More on that at Tollgate Foods, below.)

The one-line test is: have we seen this incident before, and do we know why it keeps happening? If the first answer is yes and the second is no, there is a problem. In that case, it needs a record of its own, separate from the incidents. A problem is not an incident that got worse. It is the thing underneath several incidents, and it exists whether or not anyone has written it down. Writing it down is the entire difference between a desk that has problem management and one that does not.

Finished, for a problem, means the cause is known and one of two things has happened. It has been fixed for good, or a workaround has been written down so that the next incident takes four minutes instead of forty. A problem can be finished with the cause known and the fix not done, if the fix is too expensive this year and the workaround is good enough. What it cannot be is finished with the cause unknown. Problems have no requester, which is the strange thing about them. Nobody asks for one. The desk opens it for itself, on its own evidence, which is why problems are the type most desks never open at all.

Problems have the slowest clock, or no clock, because they are investigation rather than repair. The practice of finding and working them has a series of its own, starting with Problems vs Incidents. For this article, the point is that the fourth printer ticket this month is not a fourth incident. It is a problem that has been politely introducing itself since the second one.

Change: A Planned Alteration to Something Live

A change is a deliberate alteration to something people depend on: a server, a network, a piece of software, a setting that everybody's laptop reads. The word "deliberate" separates it from an incident. Nobody chose the incident; somebody chose the change, which means somebody can also choose when, how, and what to do if it goes wrong. A change is the desk altering the world on purpose, and the whole discipline around it exists because the world does not always take it well.

Three examples. Priya's Saturday note, swapping the dispatch printer for a newer model: a working thing, replaced on purpose, with forty people depending on it from 07:00 Monday. A new rule on the firewall to let the finance system reach its supplier: a setting altered, with the finance system depending on it. Moving the shared drive to a new server over a weekend is the biggest of the three. It is the one with the longest list of people who will notice if it is wrong. All three are planned. All three can be scheduled, announced and reversed. None of them is anyone's fault yet.

The one-line test is: are we about to alter something people depend on, on purpose? If yes, it is a change, and the fact that it is small does not stop it being one. Small changes cause a surprising share of Monday-morning incidents. That is mostly because small changes get made at four on a Friday by someone who did not think they counted. The size of the change decides how much review it needs, and the change management series next door has a tidy rule for that.

Finished, for a change, means it has been made, checked to see that it did what was intended, and recorded. The aim is for the next person who asks "what changed on Saturday?" to get an answer in a minute rather than an afternoon. The record is not bureaucracy. It is the single most useful thing an incident investigator can be handed, because most diagnosis starts with "what changed?" A desk that writes changes down can answer. A desk that does not can only guess, and guessing takes longer and is wrong more often.

Changes have a clock in the shape of a date rather than a target time. Nobody is waiting for a change to be done in four hours. They are waiting for it to be done on Saturday, as announced, and for Monday to be ordinary. Most small-team tools have no change module, and the convention that works without one is in Tracking Changes Without a Change Module.

The Pair You Will Confuse and the Pair You Will Forget

Incident and request are the pair the desk will confuse, every day. That is because both arrive from a person who wants something and both are urgent to that person. "My laptop is slow" is an incident if it was fast last week and a request if it has always been slow and they would like a better one. "The scanner won't read this barcode" is an incident if it read barcodes yesterday and a request if it has never read this kind. The deciding question is always the incident test: was it working before? The article on the daily call works through the gray cases one by one. For now: when in doubt, ask the requester what it did last week.

Problem and change are the pair the desk will forget, because nobody asks for them. Every incident and request arrives with a requester attached, which means it arrives with somebody who will chase it. A problem has to be noticed by the desk, from the evidence of its own tickets. A change has to be declared by the desk, about work the desk was going to do anyway. Both are the desk's own work, created by the desk about itself. Anything the desk creates about itself is the first thing dropped on a busy Tuesday. Problems and changes are not forgotten because they are unimportant. They are forgotten because they are quiet.

I ran a desk for two years that recorded incidents and requests carefully and recorded problems and changes nowhere. The incident count was steady, the request count was steady, and the same six things broke every month, each one fixed from memory by whoever caught it. We had, in effect, a very well-documented treadmill. The first problem record we opened took an hour to write and removed eleven incidents a month from the queue. That is a return no change of tool has ever matched.

The Four Side by Side

The table puts the four types in one place with the five things that differ between them. Those are what the type is, who starts it, what finished looks like, the kind of clock it runs on, and the one-line test. Read the finished column first. It is the column that decides the other four, and the one a junior technician can use on a ticket without knowing anything else.

The picture below shows the same idea as a building. Four doors, one for each type, open onto one queue. Every ticket that comes through a door carries its type with it, the way a visitor carries the badge they were given at reception. The badge is what decides, later, which clock the ticket runs on and which column of the monthly report it lands in. On the right of the picture is what finishes each one, because that is the thing that makes the four doors four and not one.

One queue is right, and this is worth saying because the first instinct on learning about the four types is to build four queues. Do not. The desk still has one list of waiting work, and the type is a label on each item in it, not a separate room. Four rooms means four places for a ticket to hide. The doors are for sorting on the way in. Inside, everything waits together.

Why the Names Matter

The names matter because a desk that has one word for everything can only do one thing to everything. If every ticket is "a ticket", every ticket gets the same clock, the same path and the same line in the report. In that case, each will be right for one type and wrong for three. Give the types names and the desk can say, at triage, "this is a request, it goes to the approver first and it has a three-day expectation". Then the ticket is on the right path before anyone has touched it.

The names also change what the desk says to people, which is the part that shows. "I have logged this as an incident and somebody will be with you within the hour" is a different sentence from "I have logged this as a request; it needs your manager's approval, and once that is in we normally have it done in three working days." Both are honest. Both set an expectation the requester can hold the desk to. Neither is possible if the desk's only word is "ticket" and the only expectation is "soon".

And the names matter in the report, because the monthly total is a number with nothing to say. Three hundred tickets is a busy desk or a breaking estate, and the total cannot tell you which. Split by type, it can, and the two desks it separates need different conversations with management. The reporting article in this series is that conversation. The split is only possible if the types were named on the way in.

A Short War Story: Two Hundred Problems at Tollgate Foods

Tollgate Foods, a food wholesaler with two depots, ran a help desk whose intake form opened with the words "Describe your problem". So for three years every ticket in the system was called a problem, by the form, the technicians and the monthly report. When a new operations director asked Marta, the desk lead, how many problems were open, the honest answer was 212. When he asked how many of those were the same thing happening again, nobody could say, because the word covered everything. Marta went through the 212 by hand and found that nineteen of them were the depot handheld scanners dropping off the wireless network. Each one was logged, rebooted and closed as a separate problem across four months, at roughly an hour of a picker's shift each time. There had been one problem all along, a wireless access point with a failing power supply. The problem had never been written down because every ticket already had the word on it. Tollgate changed the form to "What do you need?", opened its first real problem record that week, and replaced the access point the following Tuesday. A word that means everything counts nothing.

The Four-Type Definition Card

The card below is the four definitions, tests and finishing lines on one page, in plain text. That means it can be pinned above the desk, pasted into the knowledge base, or handed to the next new starter on their first morning. Fill in the blanks with your own expected times once you have them; until then, leave them blank rather than guessing. The card is deliberately short. A definition that takes a paragraph is a definition nobody will use at 08:40 on a Monday.

THE FOUR WORK TYPES — ONE PAGE
Desk: ______________________   Version date: ____________

INCIDENT
  What it is:    something that worked has stopped, or works worse
  The test:      was it working before, and is it not working now?
  Started by:    a person, or monitoring
  Finished when: the person can work again (a workaround counts)
  Clock:         target time from logging; fastest of the four
  Say to them:   "I have logged this as an incident; someone will be
                 with you within ______"

REQUEST
  What it is:    someone wants something they do not have yet
  The test:      is anything broken, or do they want something new?
  Started by:    a person
  Finished when: delivered and confirmed by the requester
  Clock:         expected time from approval; predictable
  Say to them:   "I have logged this as a request; it needs ______
                 approval, then we normally take ______"

PROBLEM
  What it is:    the cause under one or more repeat incidents
  The test:      have we seen this before, and do we know why?
  Started by:    the desk, from its own tickets
  Finished when: cause known; fixed, or workaround written down
  Clock:         no target time; a review date
  Link to:       every incident it explains

CHANGE
  What it is:    a planned alteration to something people depend on
  The test:      are we altering something live, on purpose?
  Started by:    the desk, or a project
  Finished when: made, checked, recorded
  Clock:         a scheduled date, not a target time
  Needs:         a date, a rollback, someone told beforehand

WHEN IN DOUBT
  [ ] Ask what it did last week          (incident or request)
  [ ] Search for the same thing before   (problem?)
  [ ] Ask whether we are altering it     (change?)
  [ ] Decide, write the type on the ticket, move on

Dev, at Meridian Parts, worked the four tickets that Monday in the order the card suggests rather than the order the queue did. He got dispatch printing on the goods-in printer by 09:05 and closed 3318 as an incident with a workaround. He sent 3319 to the dispatch manager for approval, as a request, with the expected time written in the reply. He linked 3318 and the three printer tickets before it to a new problem record and gave it to Priya. She found a worn feed roller by lunchtime. And he moved the Saturday swap into a change with a date, a rollback and a note to dispatch. A change is where it should have been all along. The queue was the same length at the end of the day. It was just, for the first time, four kinds of work instead of one.

Frequently Asked Questions