The Password Reset Avalanche
A 1,200-user logistics firm logs 640 password-reset tickets last month, 41% of all service desk volume. The desk has 6 agents; average handling time is 9 minutes, and the service desk is the only team with reset rights. Agents report that 70% of callers simply forgot a password they had changed after a forced 90-day expiry. The IT manager proposes buying a self-service reset tool (licence cost roughly equal to 1.5 agent salaries annually) versus adding one more agent. Meanwhile, first-contact resolution overall sits at 58%, and user satisfaction for the reset category is 2.9/5 while other categories average 4.1/5. The CIO wants a recommendation in two weeks and has asked whether the problem is capacity or design.
1. Quantify the workload and assess whether the issue is primarily a capacity problem or a design problem. Show your reasoning.
Read the worked answer
Compute the load: 640 tickets x 9 minutes = 5,760 minutes = 96 agent-hours per month, roughly 0.55 FTE of pure handling. That is real but modest against 6 agents, so adding a seventh agent treats a symptom.
Diagnose the design instead:
- 70% of the volume traces to a policy (forced 90-day expiry) that generates demand rather than to genuine incidents. Removing or lengthening expiry, or adopting self-service, attacks the source.
- The 2.9 vs 4.1 satisfaction gap shows the reset journey is a poor experience, not merely understaffed.
- Restricting reset rights to the desk creates a bottleneck by design.
Conclusion: this is predominantly a demand/design problem with a capacity component. The defensible answer is to reduce demand (policy change plus self-service) and only then revisit headcount. A seventh agent absorbs 96 hours but leaves the cause intact and recurs next year.
2. The CIO must choose between the self-service tool and an extra agent on a one-year horizon. Recommend an option and state what evidence would change your mind.
Read the worked answer
Recommend self-service plus a policy review, contingent on adoption. Reasoning: the tool's annual cost equals 1.5 agents, but it removes up to ~70% of 640 tickets (~450/month), far more than one agent (roughly 160 tickets/month at 9 minutes and realistic utilisation). It also shifts the experience from a 2.9-rated phone queue to immediate resolution.
Risks to manage: self-service only pays if users enrol; without enrolment the firm pays for both tool and agents. Set a gate, e.g. 50% of resets self-served within 60 days, else fall back.
What would change my mind: if user population were heavily shared-account or offline (low enrolment feasibility), or if the 70% 'forgot password' figure were wrong and resets were mostly genuine lockouts from a failing SSO, then the tool addresses the wrong cause and capacity or the SSO fix wins.
3. Draft the measurement approach you would use to prove the intervention worked, naming specific metrics and a baseline.
Read the worked answer
Baseline now: 640 reset tickets/month, 41% of volume, 9-min AHT, 58% FCR, reset CSAT 2.9.
Metrics to track monthly:
- Reset ticket volume and % of total (target: down materially within 90 days).
- Self-service resolution rate (target: >=50% by day 60).
- Reset CSAT (target: move toward the 4.1 average).
- Overall FCR (target: rise above 58% as agents are freed for harder contacts).
- Agent-hours released, converted to either cost saving or redeployment to problem management.
Guardrails: watch for a rise in repeat resets (weak policy) and for tickets re-routed rather than resolved. Report against the baseline, not just absolute numbers, so the CIO can see the delta attributable to the change.