The escalation path review
Pull up the written escalation path for a critical client issue, the one that says who to call when the first engineer is stuck. There is a good chance it still names someone who left, a number that goes to voicemail, or a manager title that disappeared in a spring restructure.
Nobody notices, because escalations mostly happen by shouting across the office. It works until the night an on-call engineer follows the document to the letter at two in the morning and wakes nobody. Documents written once and read only in emergencies decay quietly, and this one is read about once a year.
Gather first: your escalation documents and the current team list with out-of-hours numbers.
The prompt:
Check our written escalation paths against the team we have today, and fix every broken link before the night someone needs it.
What experienced service delivery managers know:
Escalation documents are written once and read only in emergencies, so they decay quietly. Leavers, changed numbers and renamed roles pile up unnoticed.
During the day, escalation happens by shouting across the office. The document only gets tested at two in the morning, by the person least able to improvise.
Every level needs a named backup, because the first contact will be on holiday the night it matters.
Our escalation documents for service desk, security incidents and major outages: [paste]
The current team list with roles, phone numbers and out-of-hours cover: [paste]
Client-specific escalation agreements: [details]
Do this:
List every name, number or role in the documents that no longer matches the current team.
Rewrite each escalation path with a primary and a backup contact at every level, and the trigger for moving to the next level.
Write a five-minute quarterly test: one call per level, during working hours, to confirm each contact answers and knows they are on the path.
Where a client agreement and our internal path disagree, show both and ask me which wins instead of choosing.