Northwind Health: The Laptop That Wasn't a Request
Northwind Health's service desk handles about 1,300 tickets a month. Its request catalog lists 420 items, including 'Replace laptop' and 'Install Visio'. A 6-hour fulfillment target applies to every catalog item. Last month 38% of 'Replace laptop' tickets were devices that would not boot, and each was routed to procurement before anyone diagnosed it; average resolution was 2.4 days. 'Install Visio' is auto-approved even though finance flags the licence cost, and 12 requests last quarter were fulfilled without a budget check. A request to restore a deleted mailbox waited nine days because the queue owner insisted it was an incident and refused the request target. User satisfaction has fallen from 78% to 64% in two quarters. The service desk manager wants to cut the catalog to 80 items, add a diagnostic question to every entry, and route 'not booting' tickets to incident management. The CIO has asked for a plan before the next audit.
1. Classify each item under ITIL 4 and justify the classification: (a) a laptop that will not boot, (b) a replacement laptop for a new starter, (c) restoring a deleted mailbox, (d) installing Visio for a user whose role requires it. Explain how each misclassification changes the value stream.
Read the worked answer
Use the nature of the demand, not the queue that happens to receive it.
- (a) Laptop that will not boot - incident. This is an unplanned interruption to a service. The first action is diagnosis and restoration, not procurement. Routing it to procurement adds a handoff and delays restoration; a replacement may be an outcome, but it is not the initial classification.
- (b) Replacement laptop for a new starter - service request. It is a normal, foreseeable service action, usually pre-approved by role and start date. Fulfillment can be standardized and scheduled.
- (c) Restoring a deleted mailbox - request if it is a standard, pre-agreed restore within retention and authorization limits. If the deletion resulted from a failure that interrupted service, it is an incident. The judgement hinges on whether the action is a normal service action or recovery from an unplanned interruption; document the rule so queue owners do not decide by preference.
- (d) Visio installation - request, but not automatically approved merely because it is in the catalog. If a licence pool exists and the role is entitled, it can be pre-approved as a standard request. Otherwise it needs budget or licence-owner authorization.
Misclassification changes the value stream: wrong prioritization, wrong targets, wrong roles, and wrong metrics. An incident sent to procurement inflates fulfillment time and hides service instability; a request treated as an incident inflates incident volumes and can bypass financial or access controls. Fix intake rules before cutting the catalog.
2. Assess the proposal to cut 420 catalog items to 80 and add a diagnostic question to every entry. What evidence and governance are needed before cutting items and before auto-approving licence costs?
Read the worked answer
Cutting the catalog can reduce variation, improve navigation, and make automation and reporting feasible. But 420 items are not automatically waste: some may be low-volume, high-consequence requests such as accessibility equipment or regulatory access. Cutting without evidence can push demand into email or shadow channels, which is worse than a long catalog.
Before cutting, gather demand data (volume and trend by item), criticality (regulatory, safety, accessibility, contractual), fulfillment cost and failure rate, user journeys for the top 12 items, and workarounds already in use. Retire items with redirects and a named exception route. Keep a small 'something else' entry so demand is visible rather than lost.
A diagnostic question is useful but insufficient. Use decision trees, mandatory fields, and an 'I don't know' path that routes to the service desk. Forcing users to self-diagnose complex faults creates incorrect tickets and rework.
For Visio auto-approval, define pre-approved criteria: entitled role, available licence pool, budget threshold, and no export-control or security restriction. Finance must own the budget rule; the software owner must own entitlement. Add an exception path, an audit trail, and periodic sampling. Auto-approval without a budget check caused the 12 breaches - that is a control design failure, not a user failure.
3. Define the roles and decision rights needed for the Visio and mailbox cases, and propose measures that would show whether the redesign actually improved the service rather than just the numbers.
Read the worked answer
For Visio, separate request initiation, entitlement approval, budget approval, and fulfillment. The user initiates; the software or application owner confirms role entitlement; finance or budget holder approves only when the licence pool or threshold is exceeded; the desktop team fulfills. No one should approve their own request. For mailbox restoration, the mailbox or data owner sets retention and authorization limits, the service desk can fulfill within those limits, and exceptions go to the data owner and security. The service request management process owner is accountable for the end-to-end flow and catalog design, not for accepting business risk.
Measures should test outcomes and control performance: end-to-end cycle time by request type, percentage auto-fulfilled, first-time-right, reopen rate, CSAT by request type, percentage of requests fulfilled within authorization limits, budget exceptions per 100 licence requests, and audit findings. Avoid a single 6-hour target across all items - it rewards closure rather than fulfillment and hides the 2.4-day laptop delay.
Compare before and after with the same definitions, and include demand shift: if catalog cuts push requests to email, the improvement is illusory. A short post-implementation review should confirm that incidents are handled as incidents, requests are fulfilled within authority, and users can find the right entry.