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?
ITIL 4 Foundation, objective 7. Seven ITIL practices in detail hard
Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.
Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.
How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.
The options
Not correct Requests cannot be measured against agreed targets, so mixing them makes incident reporting inaccurate
Requests can and should carry clear expectations about fulfilment times. The reporting distortion is real, but the reason given here is wrong — it is not that requests are unmeasurable.
Not correct Requests always have a higher priority than incidents, so they must not be logged as low priority
There is no such rule, and priority is not the issue. The objection is about using the wrong kind of workflow, not about ranking requests above failures.
Not correct Incidents may only be logged by the service desk, whereas requests may be logged by users
Both may be initiated by users, including through self-service. The distinction between incidents and requests is about whether something has failed, not about who raises the record.
Correct Requests are agreed, repeatable parts of normal service delivery and need their own pre-defined fulfilment workflows, which incident handling does not provide
Correct. Incident handling is built for unpredictable failures: diagnose, escalate, restore. Requests already have known steps, approvals and fulfilment targets, and forcing them through a diagnostic workflow wastes effort and hides them from request reporting.
Why
The two practices are separated because the work is genuinely different in kind. An incident is unplanned and unknown, so it needs diagnosis and escalation; a request is planned and known, so it needs a standardised, automatable fulfilment procedure. Collapsing them forces one kind of work into the wrong machinery and corrupts the measurement of both.
Where this comes from
- Cited
- ITIL 4 syllabus clause 7
Practise this
Reading one question is not practice. The trainer will draw a short set from objective 7 and space the ones you get wrong.
More questions on this objective
- Which statement best describes what the incident management practice is intended to achieve? machine-checked
- How is an incident defined in ITIL? machine-checked
- Several incidents are open at once and the support team must decide which to work on first. On what basis should the order be decided? machine-checked
- A difficult incident is worked on by pulling several specialists from different teams into the same session at the same time; once it becomes clear who is best placed to continue, the others step away. What is this technique called? machine-checked
- Why does an organisation define a separate procedure for major incidents rather than handling them exactly like all other incidents? machine-checked
- A support team routinely fixes incidents by phone and updates the incident record only with the word 'fixed'. What is the most significant consequence of this? machine-checked