Incident records, escalation and service requests

Why an incident record is worth more than the fix it describes, what decides where an incident goes when the service desk cannot resolve it, and what the service request management practice is for.

Lesson 2 of 12 in objective 7. Seven ITIL practices in detail, part of ITIL 4 Foundation.

What a well-kept incident record is worth after it is closed. In order: Logged with real detail (symptoms, timing, what was tried), then Classified (the category drives priority and routing), then Routed by category (to the team with the relevant expertise), then Resolved and recorded (what was actually done, not "fixed"), then Trend data for problem management (the value that outlives the incident). Logged with real detail symptoms, timing, what was tried Classified the category drives priority and routing Routed by category to the team with the relevant expertise Resolved and recorded what was actually done, not "fixed" Trend data for problem management the value that outlives the incident
What a well-kept incident record is worth after it is closed.

The record is not paperwork

A team that fixes incidents over the phone and writes only "fixed" in the record has closed each incident correctly and destroyed something else. Incident records in aggregate are how problem management sees patterns — the same failure recurring across weeks, the same component behind unrelated-looking symptoms — and a record with no detail carries none of that signal.

That is the consequence the exam wants named. Not that reporting suffers, not that audit fails, though both are true: the significant loss is that trend analysis has nothing to analyse, so recurring causes are never identified and the incidents keep coming back.

Where an incident goes next

When the service desk cannot resolve an incident with the information available, it is routed to a support team with the relevant expertise, and what normally decides which team is the incident's CATEGORY. Categorisation is doing real work here, which is another reason a scheme with a hundred and forty meaningless categories is a problem rather than a nuisance.

Two things this is not. It is not automatically routed to the most senior available person, and it is not routed by who happens to be free. It is also worth keeping "escalation" honest: moving an incident to a team with more relevant expertise is one thing, and notifying management because a target is at risk is another; questions sometimes offer the second where the first is meant.

Where an incident goes when the service desk cannot resolve it, and where it never goes. A column of 5 states: With the service desk (It cannot be resolved with the information available); With a team that has the expertise (Escalation in one sense: the incident changes hands); Management is notified (Escalation in the other: nothing changes hands); With the most senior person available; With whoever happens to be free. You get from With the service desk to With a team that has the expertise by the incident's category, which normally decides the team; from With the service desk to Management is notified by a target is at risk. 2 arrows are drawn crossed through, because those moves do not exist: With the service desk to With the most senior person available — never: seniority does not decide the team; and With the service desk to With whoever happens to be free — never: nor does availability. With the service desk It cannot be resolved with the information available the incident's category, which normally decides the team With a team that has the expertise Escalation in one sense: the incident changes hands Management is notified Escalation in the other: nothing changes hands With the most senior person available With whoever happens to be free a target is at risk never: seniority does not decide the team never: nor does availability
Where an incident goes when the service desk cannot resolve it, and where it never goes.

Service request management

Service request management holds a service at its agreed quality by dealing with every request users raise — all of them pre-defined — effectively, and in a way people find easy to work with. Three qualifiers are in that: pre-defined, user-initiated, and handled in a way users find workable — the last one being why self-service portals belong to this practice's territory.

A user asking for a standard laptop of the type the organisation already offers to people in their role is a service request. Nothing failed; the thing being asked for was agreed in advance as a normal part of delivery. And because requests are pre-defined and repeatable, ITIL says they should be standardised and automated as far as possible — a known workflow can deliver them consistently and quickly with minimal handling, which is an argument about repeatability rather than about cost.

The three qualifiers of a service request, and what follows from two of them. Service request management contains Every request is pre-defined (agreed in advance as part of normal delivery), So standardise and automate (because requests repeat, not to save money), Every request is user-initiated (a user asks, and nothing has failed), Handled in a way users find easy (effective on its own is not enough), So self-service portals sit here (ease of use is what they serve). Service request management Every request is pre-defined agreed in advance as part of normal delivery So standardise and automate because requests repeat, not to save money Every request is user-initiated a user asks, and nothing has failed Handled in a way users find easy effective on its own is not enough So self-service portals sit here ease of use is what they serve
The three qualifiers of a service request, and what follows from two of them.

Worth carrying in

Incident record
Detail here is what problem management analyses later. "Fixed" is not detail.
Categorisation
Drives prioritisation and routing. Not administrative tidiness.
Routing
To the team with relevant expertise, normally decided by category.
Service request management
Pre-defined, user-initiated requests, handled effectively and user-friendly.
Standardise and automate
Requests are repeatable, so a known workflow can deliver them consistently.

What the exam does with this

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 Incident records, escalation and service requests

Questions in this lesson

Practise Incident records, escalation and service requests

The rest of objective 7