The five-approval laptop request
A public-sector agency with 4,200 staff across 11 sites publishes a service catalogue of 214 items. The item Standard laptop for new starter requires five sequential approvals: line manager, HR, finance, security and IT asset management. Median end-to-end fulfilment is 11 working days against a 3-day target, and 34% of requests bounce back at least once because the cost centre code is missing or wrong. A six-week sample shows that 22% of catalogue submissions are actually faults. Examples include my printer will not connect and Outlook keeps asking for my password. These arrive as requests, so they never receive an incident priority and are queued behind laptop builds. First-contact resolution is 51%. The new CIO wants the catalogue cut to 40 items and all approvals removed. HR objects that the audit trail would be lost. Finance objects that cost centre sign-off must happen before spend.
1. How would you decide which catalogue items to keep, and what would you do with the 22% that are really faults?
Read the worked answer
The catalogue should be designed around demand, not around how the IT department is organised. Start with a Pareto analysis of request volume over 12 months, not a survey of what people think exists. In most organisations a small number of items, perhaps 15 to 25, account for the large majority of volume: new starter, leaver, access to a standard application, mobile device, software already licensed, and a handful of hardware standards. Keep those, plus any low-volume but high-risk item that genuinely needs a controlled path. Retire the long tail by removing it from the portal and routing residual demand through the service desk with a recorded justification. If an item is used ten times a year, it does not need a workflow; it needs a person.
The second criterion is standardisation. A catalogue item should be something the user can choose without a decision being made on their behalf: fixed specification, fixed price band, known lead time, predictable approval. Items that require design work are projects or changes, not requests.
The 22% misclassification is a design fault, not a user fault. The portal presents a single door. The fix is at intake: the first question should be is something broken or do you need something new, with routing to incident or request accordingly. Add symptom-based entry for the top fault types so a user who types printer sees the printer fault route. Monitor the misclassification rate as a metric in its own right. Until it falls below roughly 5%, the service desk will keep absorbing fault demand into a fulfilment queue, which is exactly why laptop builds are slow.
2. The CIO wants all approvals removed. HR and Finance object. Set out a defensible design and justify how you would answer each objection.
Read the worked answer
An approval is not a control. It is a mechanism intended to satisfy a control objective, and the right question is what each of the five approvals actually protects against. Once that is written down, several of them collapse.
Line manager approval usually establishes need and budget ownership. HR approval usually establishes employment status and start date. Finance approval usually establishes that spend is authorised against a cost centre. Security approval usually establishes that data access and device configuration meet policy. Asset management approval usually establishes that stock exists and an asset record will be created.
Most of these are data checks, not decisions. Start date and line manager can come from the HR system feed. Cost centre can be derived from organisational data rather than typed by the requester, which also removes the 34% rework. Security requirements belong in the standard build specification, not in a per-transaction click. Asset records can be created on delivery. That leaves one genuine decision: whether the request is within an entitlement the person already holds. That can be handled by a pre-approved entitlement matrix by role, so the vast majority of standard requests require no approval at all.
On the audit objection: the audit trail is the workflow record, the timestamp and the identity of who did what. An approver clicking a button adds a name, not evidence. Auditors typically want to see that the control operated consistently, and an automated rule operates more consistently than a tired manager. On the finance objection: sign-off should happen where spend is committed, which for a pre-priced standard item is budget setting, not each laptop. Keep an exception route with real approval for anything outside the standard, above a value threshold, or requiring privileged access.
3. Define how you would measure whether the redesigned catalogue actually improved the service, including measures that would catch unintended consequences.
Read the worked answer
Measure the end-to-end experience first, because that is what failed. Median and 90th percentile fulfilment time from submission to usable device or working access is the primary outcome measure, with a target of three days and a tail target that is explicitly tracked rather than hidden by the mean.
Measure rework separately. The proportion of requests returned for missing or invalid data should fall from 34% to under 5%; if it does not, the intake design has not been fixed, only the workflow has.
Measure classification quality. The share of submissions that are actually faults should fall from 22% to under 5%. If fault volume instead reappears as tickets on the service desk, you have moved the work rather than eliminated it, so track service desk contact volume per 100 employees alongside it.
Measure the catalogue itself. How many items are live, and what proportion of total demand do they cover? A 40-item catalogue covering 92% of volume is a success; a 40-item catalogue pushing 30% of demand into informal channels is not. Track exceptions: how many requests bypass the catalogue, and why.
Measure user perception with a single ease-of-request question at completion, since speed alone does not capture frustration.
Finally, measure the control outcome, not the control activity. Count audit exceptions actually found and privileged access actually reviewed, rather than counting approvals. If the number of approvals drops by 80% and the exception rate stays flat, the redesign removed bureaucracy without removing control. Add a periodic sample audit of 30 completed requests to test that the entitlement rules are being applied correctly.