Requests versus incidents, and finding problems
Why service requests need their own workflows instead of a low-priority slot in the incident queue, what does not belong in the request practice, and the two directions problems are identified from.
Lesson 3 of 12 in objective 7. Seven ITIL practices in detail, part of ITIL 4 Foundation.
Requests do not belong in the incident queue
Putting service requests into the incident queue as low-priority incidents is a tempting simplification and the exam expects you to be able to argue against it precisely. The strongest objection is not that it distorts the incident statistics, true though that is. It is that requests are agreed, repeatable parts of normal service delivery, so they need their own PRE-DEFINED FULFILMENT WORKFLOWS — and incident handling, which is built to restore something that broke unexpectedly, provides nothing of the kind.
That is also why the two practices measure different things. An incident is judged on how fast normal service came back; a request is judged against the fulfilment target agreed for that kind of request. One queue cannot serve both without losing one of the measures.
What is not a service request
Requests cover the normal, agreed things users ask for: access, information, a standard item, advice, a routine provisioning. What does not belong is anything that reports a failure. A user saying a service they rely on has become noticeably slower than usual is reporting degraded quality, which is an incident by definition, and it is the option planted in these questions precisely because "the user asked us something" makes it look like a request.
The test is what triggered the contact rather than the form of words. Something broke or degraded, unexpectedly, is an incident. Something normal and agreed was asked for is a request.
How problems come to be identified
Problem identification is the first phase of problem management, and the answer the exam wants covers both directions. Reactively, by analysing incident records and looking for trends — an analyst reviewing several months of incidents and noticing a repeating pattern of similar failures that were each resolved individually is doing problem identification. Proactively, by examining other information — monitoring data, supplier notifications, testing and project findings — which can surface a problem BEFORE any incident has occurred at all.
An answer that describes only the reactive half is incomplete, and it is the most common wrong option here because it matches how most organisations actually behave. The definition of a problem includes potential causes, and this phase is where that word earns its place.
One term to have ready: a known error is an analysed problem that still has no permanent fix. It is not a problem with a workaround, not a problem that has been closed, and not an incident of any kind.
Worth carrying in
- Pre-defined fulfilment workflow
- What a request needs and an incident queue cannot provide.
- Degraded quality
- An incident, even when the user phrases it as a question.
- Problem identification
- First phase. Reactive from incident trends, proactive from other data.
- Proactive identification
- Monitoring, supplier notifications, testing — before any incident.
- Known error
- An analysed problem with no permanent fix yet.
What the exam does with this
- The objection to requests-as-incidents is the missing pre-defined fulfilment workflow, not the reporting distortion.
- "Slower than usual" is an incident however politely it is asked. Sort by what triggered the contact.
- Problem identification is reactive AND proactive. An option covering only incident trends is the plausible wrong one.
- Objective
- 7. Seven ITIL practices in detail
- Share of the exam
- 47.5% (the whole objective)
- Questions in this lesson
- 5
- Signed for by a person
- 0
Partly checked. None of the 5 questions here has been read against the cited source by a person. 5 questions have been checked against their cited clause by an automated pass — which is not the same thing, and is not a signature.
Only questions a person has signed for are used in mock exams here. That is the whole difference between the two kinds of checking above.
How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.
Drill this lesson
A lesson is one sitting: the trainer draws a short run from these questions alone and spaces the ones you get wrong.
Practise Requests versus incidents, and finding problems
Questions in this lesson
- An organisation logs service requests as low-priority incidents so that everything sits in one queue. What is the strongest ITIL-based objection to this? machine-checked
- Which of the following would NOT normally be handled through the service request management practice? machine-checked
- A problem management team is asked how problems come to be identified in the first place. Which answer best reflects the practice as ITIL describes it? machine-checked
- An analyst reviews several months of incident records and notices a repeating pattern of similar failures that had each been resolved individually. Which phase of problem management is this activity part of? machine-checked
- What is a known error? machine-checked
Practise Requests versus incidents, and finding problems
The rest of objective 7
- Incident management, priority and major incidents
- Incident records, escalation and service requests
- Requests versus incidents, and finding problems — you are here
- Workarounds, known errors and problem control
- Change enablement and the three types of change
- Change authorities and the change schedule
- Authorisation routes and what a service desk is
- Service desk channels and user experience
- Service level agreements and honest targets
- Measurement, engagement and underpinning agreements
- Continual improvement and its model
- Who improves, which principles apply, and the value chain