Regulatory Dispute SLA with Child Cases
A bank's dispute case type handles 9,000 debit-card disputes per month. Regulatory rules require a final decision within 7 calendar days for unauthorized transactions. The case has three child cases: fraud investigation, merchant contact, and provisional credit. The parent case has a 7-day SLA; child cases have their own 3-day SLAs but are not linked to the parent deadline. Current breach rate is 15%, mostly because the fraud investigation waits on merchant contact. The queue for fraud investigation has 4 analysts and a 2.5-day average wait. The business wants to reduce breaches to below 3% without adding staff. A proposed redesign creates a single stage with parallel processes and a shared urgency value. Another proposes making the parent SLA drive child urgency and auto-escalation.
1. Diagnose why the current SLA design fails.
Read the worked answer
The parent and child SLAs are independent clocks. A child case can consume 3 days and breach its own SLA without increasing parent urgency, and the parent's 7-day deadline does not propagate to the fraud queue. The fraud investigation also has a blocking dependency on merchant contact, so analyst work waits even though the parent deadline is running. With 4 analysts and a 2.5-day average queue wait, the fraud step alone can consume most of the 7-day window. The provisional credit step may be able to proceed in parallel but is not designed to do so. The result is a local-optimization problem: each child manages its own SLA while the regulatory parent deadline is invisible to the work queue. The 15% breach rate is therefore a design symptom, not just a capacity problem.
2. Recommend a case design to meet the 3% target without adding staff.
Read the worked answer
Make the parent deadline the governing clock. Calculate remaining time to the 7-day regulatory deadline and propagate it as urgency to all child cases and assignments. Create a single stage with parallel processes: fraud investigation, merchant contact, and provisional credit can run concurrently where dependencies allow. Make merchant contact non-blocking with a timeout; if the merchant does not respond, proceed with available evidence and document the exception. Add auto-escalation at 60% and 80% of the parent deadline, routing to a senior analyst or supervisor. Prioritize the fraud queue by remaining parent time rather than first-in-first-out. Use a shared urgency value so analysts see the true deadline. Before adding staff, test whether parallel processing and deadline-driven priority reduce the 2.5-day queue wait. If not, rebalance work or add temporary capacity.
3. What data would you monitor after deployment to confirm the redesign works?
Read the worked answer
Monitor breach rate against the 3% target, but also leading indicators: remaining parent time at each child completion, fraud queue wait, merchant-contact timeout rate, and escalation volume. Track cycle time by stage and by child case to see whether parallelism actually reduces the critical path. Monitor provisional-credit timeliness separately, because regulatory breach and customer harm are not the same. Capture root-cause codes for every breach, such as merchant delay, analyst capacity, or evidence missing. Check that auto-escalation is not creating a new bottleneck at the supervisor level. Finally, segment by dispute type and analyst team to detect uneven performance. A dashboard should show both the regulatory deadline and the operational queue so the business can act before the 7-day clock expires.