The Escalation Timer That Fires After the Deadline
A loan-review process has a service-level target of 2 business days for the initial review task. The model currently has an escalation boundary timer set to 'PT48H' (48 elapsed hours). The team works Monday-Friday, 9-5, and observes that tasks submitted Friday afternoon escalate Sunday night, when no one is working, and that a task submitted Monday 9am escalates Wednesday 9am - but the business considers the deadline to be end of day Tuesday. Complaints say escalations are 'either too late or at 3am.' The escalation path reassigns to a manager group.
1. Explain the mismatch between the timer and the business SLA, and what must change.
Read the worked answer
Two distinct problems:
- Elapsed vs. business time.
PT48His 48 elapsed hours, including nights and weekends. The business SLA is 2 business days (Mon-Fri, 9-5). So a Friday-afternoon task's 48 elapsed hours lands Sunday night, and a Monday-9am task's 48 elapsed hours lands Wednesday 9am - both wrong relative to 'end of day Tuesday.' The timer measures wall-clock time; the SLA measures working time. They will never agree unless the timer uses business-calendar time or the deadline is computed explicitly. - Deadline semantics. 'End of day Tuesday' is a specific point, not '48 hours after start.' The timer should be anchored to the computed due date/time, not a fixed duration from task creation.
What must change:
- Use a business calendar (working days/hours, holidays) for SLA computation, or compute an explicit due date at task creation (start + 2 business days, snapped to end of business day) and set the escalation timer to fire relative to that due date.
- Fire escalation shortly before or at the due moment during business hours, not at an arbitrary elapsed offset.
- Make the due date visible on the task so analysts see the real deadline.
2. The escalation reassigns to a manager group. What additional design decisions does that raise?
Read the worked answer
Reassigning to a group raises several judgment calls:
- Visibility vs. ownership. A manager group means all managers see every escalated task, and none may own it - the same shared-pool problem. Decide whether escalation should assign to a specific manager (e.g., the submitter's manager or a duty manager) versus a pool, and define pickup expectations.
- Does escalation stop the original SLA clock or start a new one? Define a second-level SLA for the manager and a further escalation if that is also breached. Otherwise escalations themselves rot.
- What does the manager actually do? Escalation should carry a decision (approve, reassign, extend with reason), not just visibility. Define the allowed actions and the audit record.
- Timing of escalation. It must fire during business hours per the corrected calendar; a Sunday-night escalation to a group that is offline is the current complaint. Consider escalating at start of next business day if the due moment falls outside working hours.
- Notification content and channel. Managers need a clear signal (what is overdue, by how long, what to do) without exposing sensitive loan detail in shared channels.
- Fairness and load. If many tasks escalate at once (e.g., Monday morning backlog), a single duty manager is overwhelmed - consider load-balanced assignment among managers.
Recommendation: assign escalations to a specific accountable manager (with a backup), give them defined actions, and set a second-level timer so escalations are themselves governed.