Meridian Freight: Eight Analysts or a Different Desk?
Meridian Freight runs a 24/7 logistics operation with 9,200 endpoints and four service desk locations. The desk handles about 18,000 tickets a month. 44% are password resets, and first-contact resolution is 41%. Mean time to resolve priority-2 incidents is 31 hours against an 8-hour target. There are 220 open problem records, 61 of them older than a year. Change success rate is 87%, and the change advisory board meets twice weekly, reviewing an average of 60 changes per meeting, most of which are low-risk application configuration updates. Last month a middleware patch approved as 'standard' caused a six-hour warehouse management outage that stopped dispatch at 40 sites. The VP of Operations has written to the CIO demanding eight additional service desk analysts, citing the ticket backlog. The CIO has asked for an independent assessment before any headcount decision.
1. Assess the VP's request for eight analysts. What is the biggest lever, and in what order would you act?
Read the worked answer
The eight analysts would treat the symptom and lock in the cost. 44% of 18,000 tickets is roughly 7,900 password resets a month. At six minutes of analyst time each, that is about 790 hours a month - close to five full-time equivalents spent on a problem self-service reset solves. Hiring into that queue guarantees you keep needing those hires. Meanwhile 220 open problems, 61 older than a year, tells you recurring incidents are never root-caused, and that is where the 31-hour MTTR actually lives.
Sequence:
- Self-service password reset with MFA, then an SSO roadmap. Fastest volume reduction available. Target 44% down to under 15% within two quarters. This frees capacity without a hire and gives the VP something visible early.
- Triage the 220 problem records aggressively. Do not work all of them. Pareto by incident volume, close 150 as 'will not fix' with documented acceptance, and put the top ten recurring causes into real investigations with named owners and target dates. A problem record with no owner is a diary entry, not a process.
- Knowledge and first-contact resolution. 41% FCR usually reflects missing or distrusted knowledge articles, not analyst skill.
Answer to the VP: offer a 90-day pilot with a stated baseline, the self-service target, and a commitment to revisit headcount at day 90 using the volume data. Refusing outright with no plan is politically unsustainable; agreeing with no plan is simply expensive.
2. Redesign change enablement for a CAB reviewing 60 changes twice a week. What changes specifically, and why was the middleware patch misclassified?
Read the worked answer
Sixty changes across two weekly meetings means the CAB is a rubber stamp - and a rubber stamp is worse than no CAB, because it transfers blame without adding scrutiny. The 87% success rate is not the problem. The outage was a categorisation failure: 'standard' should mean pre-approved, repeatable, reversible and low-risk, and middleware patching is none of those things.
Changes:
- Define standard changes properly. A standard change requires a documented procedure, a tested back-out and a defined low-risk profile. Publish a closed list of perhaps 15 change types. Anything requiring judgement is not standard. This moves 30–40 of the 60 off the CAB immediately.
- Introduce a normal-change risk assessment with explicit questions: blast radius, reversibility, dependency on middleware or a shared platform, and time since the last change to the same component. Shared-platform and middleware changes get elevated regardless of how routine the vendor calls them.
- Create a genuine emergency path with post-implementation review within five working days, so urgency stops being mislabelled as 'standard' to jump the queue.
- CAB reviews exceptions, not the queue. Its remit becomes the five to ten high-risk changes plus last fortnight's post-implementation reviews.
Measure: percentage of changes through the standard path, change success rate, and - the one the VP of Operations cares about - unplanned change-related downtime.
3. Priority-2 incidents resolve in 31 hours against an 8-hour target. What is likely driving that, and what would you investigate first?
Read the worked answer
A four-fold miss usually has three distinguishable drivers, and you can separate them with data you already have - no tooling purchase needed.
- Clock time versus work time. Measure time-in-queue per assignment group for the last 200 P2 tickets. In most desks, the majority of the 31 hours is waiting: waiting for a handoff, waiting on a third party, waiting for a change window. If hands-on effort is two hours and queue time is 29, more analysts will not help, because the constraint is elsewhere.
- Priority inflation. Calculate the percentage of tickets raised as P2. If it is 30% or more, priority has stopped discriminating and the 8-hour target is being applied to work that was never P2. Fix the definition before fixing the performance.
- Handoff count. Average number of assignment groups per P2 ticket. Each handoff adds queue time and loses context; three or more is a structural problem.
First action: instrument, then attack the largest segment of the measured time. Do not renegotiate the 8-hour target yet - but if the analysis shows the target is unachievable for incidents with third-party dependencies, take that to the service owner with the data and split the target accordingly. Targets renegotiated without evidence are just capitulation; targets renegotiated with a time-attribution breakdown are management.