Escalation path
The agreed sequence of people and steps for getting a blocked decision in front of someone with the authority to resolve it.
See it
What it is
An escalation path names who gets contacted, in what order, and after what trigger when a normal project conversation cannot resolve a blocker. It is a pre-agreed route from the working team to people with enough authority to decide, fund, reschedule, or accept risk.
Set it during kickoff for decisions that can stop delivery: missed approvals, security access, disputed scope, nonpayment, and production incidents. Give each level a response window and a communication channel. On-call engineering already automates the shape: a PagerDuty escalation policy pages the primary, and if nobody acknowledges within the set window it moves to the secondary without anyone deciding to be annoying. Borrow the timer, so escalation is a clock expiring rather than a judgement call about someone. The first escalation should be factual: decision needed, owner, deadline, impact if missed, and the recommendation.
Gotcha: using escalation as a threat or a surprise copy to someone's boss. That burns trust and may still fail to produce a decision. A good path is agreed before trouble, uses objective triggers, and skips a level only when the impact or urgency clearly warrants it.
Ask AI for it
Write a three-level project escalation path using a RACI matrix. For each level name the trigger, first contact, backup contact, response window, channel, authority required, and the next level if no decision arrives. Cover late approvals, missing access, scope disputes, nonpayment, and launch-blocking incidents. Add a Slack message template with five fields: decision needed, accountable owner, deadline, delivery impact, and recommendation. Finish with kickoff language that gets the path approved in advance and a rule preventing routine disagreements from jumping straight to an executive.