Incident or Request? The Daily Call and Its Gray Areas

Tuesday, 08:55, at Redbrook Engineering, a design consultancy with sixty staff and a two-person desk. Ticket 7702, from Lars in the structures team: "Our CAD licence has expired and none of us can open drawings. Can we get it renewed please?" Nia, on triage, reads it twice. It says "renewed", it says "please", and it says "can we get". Those are the words of somebody asking for something, so it looks like a request. Requests for licences go to purchasing for approval. It also says "none of us can open drawings", which is four engineers at four desks doing nothing. That is the shape of an incident. The form has one box for the type and she has to pick one before the ticket will save. (The form does not have a box for "both, and in that order".)

The incident-or-request call is the decision, made at first touch on nearly every ticket, between "something that worked has stopped" and "someone wants something they do not have yet". It is the most frequent judgement on the desk, and it is made in seconds. It decides which clock the ticket runs on, which path it takes and which line of the report it lands in. The four types and their definitions are in The Four Work Types in Plain Words. This article is part of our Incidents, Requests, Problems & Changes series. It is about the two that get confused and how to stop confusing them.

It covers why the call is harder than the definitions make it look, then the one question that settles most tickets. Next come the gray areas, worked through one at a time, from licences to lost folder access, and the decision table to copy. Then it covers who makes the call and what happens when two people disagree, followed by the ticket that is both, in order. Next is changing the type after the fact without resetting anything you cannot explain. The words to use with the requester and a short war story finish the article.

Why the Call Is Harder Than It Looks

The call is hard because the requester does not describe a type. They describe what they want, and what they want sounds the same either way. "Can I have access to the finance share?" is a request if they never had it and an incident if it vanished overnight. "I need the label printer working" is an incident if it printed yesterday and a request if it has never been set up. The verbs are no help. "Can I have", "please", "I need" and "could you" appear on both kinds of ticket in about equal measure. People are polite to help desks, which is kind of them and useless for classification.

The form is not much help either. Most intake forms ask the requester to pick a type. The requester picks the one that sounds most urgent, or the first one in the list, or the one they picked last time. A form with "incident" at the top of the list produces a desk with a great many incidents. Treat the requester's choice as a hint from somebody who has never read the definitions, which is exactly what it is. The triager decides, the form suggests, and nothing about that should be visible to the requester except a better reply.

And the call is hard because getting it wrong costs in both directions, and the two costs land on different people. A request logged as an incident breaches the incident clock and makes the desk look slow, which the desk notices in the monthly report. An incident logged as a request waits in an approval queue while somebody cannot work. The desk does not notice at all. The ticket is sitting quietly in "waiting for approval" doing exactly what that status says. The person who notices is the one with the borrowed laptop. Both costs, with numbers, are in Why Separating Them Matters.

The One Question That Settles Most Tickets

The question is: could they do this last week? If yes, and they cannot now, it is an incident. If they could never do it, it is a request. The question works because it ignores everything that misleads: the verb, the politeness, the seniority of the requester, how urgent it feels and how many people are shouting. It asks only whether something has been lost, and that is the whole definition of an incident in nine words.

Ask it in those words, to the requester, when the ticket does not answer it. "Was this working before?" is the plain form, and nobody has ever been offended by it. The answer takes them two seconds and takes the triager from guessing to knowing. On a form, the same question is one optional line, "Was this working before? When did it stop?" A form that asks it produces tickets that triage themselves. It is the single most useful line an intake form can carry, and most forms do not carry it. That is a fact about forms and not about the people who fill them in.

The second question, for the tickets the first one does not settle, is: is anything broken? Not "is anybody unhappy" and not "is this urgent". Is there a thing, a device, a service, a setting, that is in a state it should not be in? If there is, it is an incident, even if the person is asking for something new as the fix. If there is not, it is a request, even if the person needs it by lunchtime. Urgent requests exist. They stay requests. Their urgency changes their place in the fulfilment order, not their type.

Most tickets fall to those two questions in the time it takes to read them. The desk's job is not to agonise over the gray cases. It is to make the easy call fast on the many and a consistent call on the few. Consistency on the few comes from having worked them through once, written the answer down, and stopped revisiting it. That is what the next section and the table are for.

The Gray Areas, Worked Through

The expired licence, subscription or certificate is the classic. Lars could open drawings on Monday and cannot on Tuesday, so something has been lost: incident. The fix happens to be a purchase, which looks like a request, and it is one, but it is a request that follows the incident rather than replacing it. The desk's first job is to get four engineers working. That might take a trial licence, a borrowed seat, a vendor's grace period or a phone call. That is the incident. The renewal is a linked request with its own approval. An expired thing is a broken thing that happens to have a known cause.

"My laptop is slow" is an incident if it was fast last month. It is a request if it has always been this slow and the person would like a better one. The question to ask is when it changed. A laptop that degraded is a thing that has stopped working properly, and the desk owes it diagnosis. A laptop that is five years old and has always been this way is a replacement request, with an approver and a budget, and the honest reply says so. Many "slow laptop" tickets are a bit of both, and the tie goes to incident. Look at it first, and if nothing is wrong beyond age, retype it and say why.

Access is the largest gray area on most desks, and it splits cleanly on the one question. "I need access to the finance share" from somebody who has never had it is a request, and it goes to the data owner for approval. The same words from somebody who had it on Friday and lost it on Monday are an incident. Access that vanished is a thing that broke. Usually, it broke in a group membership, a migration or a leaver process that removed the wrong person. Ask whether they had it before. The ticket that reads "I need access" and means "I lost access" is the most common incident-in-request-clothing there is.

The password reset and the locked account are a policy choice, and the choice matters less than writing it down. A forgotten password is, strictly, a request. Nothing on the desk's side has broken, and the person needs a credential they do not have. The steps and time are the same every time, which makes it listable. An account locked by a fault, an expired certificate or a directory error is an incident, because it worked and stopped. Most desks treat all resets as requests for the sake of a single clock and a single report line. That is fine, as long as the desk has written down that a lockout the person did not cause is an incident. Pick one. Write it on the card. Stop discussing it.

The new starter whose account does not work on day one is a request that has not finished, not a new incident, if the account was never set up correctly. The request is reopened or its fulfilment is completed, and the desk learns something about its new-starter checklist. If the account was set up, tested and worked on Friday, and does not on Monday, it is an incident. The question is the same as always: did it ever work? The difference matters for the report, because a day-one failure counted as an incident hides a request process that is dropping steps.

The report that shows wrong numbers, the form that will not submit, the e-mail that arrives late: all incidents, if the thing was right before, however the person phrases it. "Can you fix the sales report?" is an incident. "Can you add a column to the sales report?" is a request. "Can you fix the sales report, and while you are in there add a column?" is both. The desk does the first one on the incident clock and the second one as a linked request. The requester is told so in one sentence. Toner, paper and consumables are requests: nothing broke, something was used up. When the only printer on a floor has no toner and twenty people are waiting, it is an urgent request, fulfilled first, and still a request. (The printer is fine. It is just hungry.)

The Decision Table

The table below is the gray areas as a lookup, in the order they tend to arrive. Read the left column for the words the requester used, ask the question in the second column, and take the row's answer. It is written to be copied into the knowledge base and read by whoever is on triage, including the person who started last week. It is deliberately free of judgement about urgency. The type is decided here. The priority is decided afterwards by impact and urgency, which has its own article in Impact Times Urgency in Practice.

The table will be wrong for your desk in two or three rows, because every desk has a policy choice or a local oddity, and that is fine. Change those rows, date the table, and keep it. What the table must not do is grow a row for every ticket anyone ever argued about. Twelve rows cover most of the calls; thirty rows cover the same calls and stop being read.

Who Makes the Call

The triager makes the call, at first touch, and nobody else. Not the requester, whose form choice is a hint. Not the requester's manager, who will say "incident" because it sounds faster. Not the technician who will eventually work it, who is not reading the queue at 08:55. One person, reading each new ticket once, asks the two questions and writes the type on the ticket. That act is part of the first touch described in First-Touch Discipline. On a desk of two, the triager is whoever has the queue that morning. On a desk of one, it is you, and you still do it as a separate step from fixing anything.

When the triager genuinely cannot tell, the tie goes to incident. The reasoning is that the cost of a wrongly-typed incident falls on a person who cannot work. The cost of a wrongly-typed request falls on a report, and people outrank reports. Log it as an incident, have somebody look at it on the incident clock, and if the look shows nothing is broken, retype it with a note. The look usually takes ten minutes. The ten minutes is the price of never leaving a broken thing in an approval queue, and it is cheap.

When two people on the desk disagree, the lead decides, in under a minute. The decision goes on the ticket and in the table if it is a kind that will come back. Disagreements about type are useful exactly once, when they add a row; after that they are a sign the row was not read. I have sat through a twenty-minute discussion of whether a replacement mouse was an incident or a request. The mouse was broken. The discussion was not necessary. The row now says so.

When It Is Both, in Order

Some tickets are an incident and a request at once, and the rule for those is: restore first, request second, link the two. The expired licence is the clean example. The incident is "four engineers cannot open drawings", resolved when they can, by a trial key, a borrowed seat or a vendor's grace period. The request is "renew the licence", with its approver and its expected time. It starts after the incident is restored. The restoring is what stops the bleeding and the renewal is what stops it recurring. Two tickets, one link, two different clocks. Most tools can link tickets; where yours cannot, the number of the other ticket in the first line of each is enough.

The failure to avoid is holding the incident open until the request completes. "Fixed when the new licence arrives" leaves four engineers in a ticket that breaches on Thursday while purchasing approves something on Friday. It reports a slow incident when what actually happened was a fast workaround and a slow purchase. Close the incident when people can work. Open the request for the permanent thing. If the workaround fails before the permanent thing arrives, that is a new incident, linked to both. The report will show a true picture of a desk that restored twice while an approval took a week.

The same pattern covers the rebuild that needs software reinstalled, the broken device that needs a replacement ordered, and the lost access that needs a permissions review once it is restored. In each case the desk's first job is the person, the second is the thing. The ticket that records the person's problem should close when the person's problem is gone. What stays open is the request, which is honest, because what is still outstanding is something somebody wants and does not have yet.

Changing the Type Later

Changing the type after the fact is allowed, expected and useful, and the only wrong way to do it is silently. A ticket typed at 08:55 on the words in the form may look different at 09:20 when somebody has read the second paragraph or looked at the laptop. Retype it. Most tools let the type be changed by editing the field, moving the ticket to the other form or department, or changing the category or subject prefix. It depends on which of those your desk uses to carry the type. The conventions are compared in Implementing Four Types in an Ordinary Help Desk Tool. Whichever it is, the retype is four steps.

• Change the type in whatever field, form, category or prefix carries it.
• Add a one-line internal note: what it was, what it is now, and why.
• Check the clock, and if the tool reset it, note the original logged time in the ticket.
• Tell the requester in one sentence what the new type means for them.

The clock is the step people skip, and it is the one that corrupts the report. Some tools recalculate the due time when the type, priority or form changes, which may be right or wrong depending on which way the retype went. A request wrongly logged as an incident should probably get the request expectation from the time of the retype. An incident wrongly logged as a request should get the incident clock from the original logging time. The person has been unable to work since then, not since the desk noticed. Test what your tool does by retyping a test ticket both ways and reading the due time. Then write the rule down, and where the tool's behaviour is wrong, note the real time in the ticket so the monthly report can be corrected by hand.

Count the retypes once a month, by direction, because they are a free diagnostic. Many retypes from request to incident mean the form or the triager is defaulting to request and broken things are waiting in approval queues. Many from incident to request mean the form defaults to incident and the breach count is inflated with laptop orders. A handful in each direction is a desk that is making the call carefully and correcting itself, which is the best a desk can do. A retype is a data point, not a failure, and a desk with zero retypes is not a desk with perfect triage. It is a desk where nobody is looking twice.

The Words to Use With the Requester

The requester does not need to know the word "incident" or the word "request". The reply that says "I have reclassified your ticket as a service request" has told them nothing they can use. What they need is what the type means for them, in three sentences: what the desk thinks is going on, what happens next, and when they will hear. For an incident: "It looks like the licence expired overnight, which is why none of you can open drawings. I am getting you working again now on a temporary key, and I will update you by 10:30 either way." For a request: "Nothing is broken on our side; this needs approval from your manager before we can order it. I have sent that to her now, and once she approves we normally have it done within three working days. I will chase her on Thursday if we have not heard."

Notice what the request version does. It names the approver, so the requester knows who is holding it. It gives the expected time from approval, not from now, so the promise is one the desk can keep. And it commits to a chase on a day, which is the part that stops the requester chasing instead. The same sentence structure works for the retype: "Having looked at this, nothing is actually faulty with the laptop; it is simply five years old. I have logged it as a replacement request, which goes to your manager for approval, and I have told her what it will cost." Honest, specific, and the requester has not been told they filled in the form wrong, because they did not. They described what they wanted. Sorting it was the desk's job.

A Short War Story: The New Version at Bellweather Logistics

Bellweather Logistics was a haulage firm with thirty drivers and a desk of two. It received a ticket from the transport office that read "We need the new version of the manifest software installed on the handhelds." It was logged as a request, because it asked for software. It went to the operations director for approval, who was travelling and approved it eleven working days later. What the ticket had not said, and nobody on the desk had asked, was why. The customs portal the handhelds submitted manifests to had changed its format the previous Friday. The old version had stopped submitting. For those eleven days, thirty drivers had been typing each manifest into a laptop in the yard office by hand. That took about twenty minutes a shift each. Priya, the desk lead, found out from a driver at the coffee machine. Priya saw that the ticket had been an incident wearing a request's words. Something that worked on Thursday had stopped on Friday, and the fix happened to be a version. Bellweather added one line to its intake form, "Was this working before? When did it stop?" The next ticket of that shape was restored the same morning on a vendor's interim build while the upgrade went through approval behind it. The test is what they could do last week, not the verb they used.

Back at Redbrook, Nia asked Lars one question, "Could you open drawings yesterday?" She got "Yes, until about five", and logged 7702 as an incident at 08:58. By 09:40 the structures team was working on a thirty-day trial key from the vendor's website. The renewal went to purchasing at 09:45 as a linked request, with a five-day expectation counted from approval. It arrived on the following Wednesday, which nobody minded, because nobody was waiting for it. The ticket that looked like a request had been an incident with a request behind it. The only thing that had been needed to see that was the one question, asked out loud.

Frequently Asked Questions