How Do You Build a Blocker Escalation Process?
Same blocker — different Monday.
Build a blocker escalation process by defining when an issue should move beyond its current owner, who has the necessary authority or expertise, and what the request must contain. State the blocked work, attempts so far, decision or help needed, consequence of waiting, and response date. After the decision, check that the dependency can actually proceed.
If the same blocker returns next Monday, don't just give it a fresher due date. Check whether the person carrying it can actually remove the constraint. Work can stay stuck while everyone involved is doing exactly what their authority allows.
Recurring blockersThe estimate still needs an approved scope
CS needs an estimate. Product needs scope. Sales is waiting for the estimate.
- Missing move
- Authorize scope or decide package terms
- Previous attempt
- Requirements compared; terms remain unresolved
- Next owner
- Person authorized to settle the commercial choice
Follow-up preserves the unresolved constraint instead of relabeling it as a new task.
Is work blocked now, or might it be later?
A blocker prevents a defined next step from proceeding now. A risk is a possible future problem. A dependency is work or a decision needed from elsewhere; it becomes a blocker when its absence stops the next step.
The distinction changes the request. “The onboarding plan may need more support” is a risk to investigate. “CS cannot approve the onboarding plan until the commercial owner decides what support is included” identifies a current blocker.
Neither label should be a judgment about a person. Escalation routes a problem to the person who can act on it.
What triggers escalation of recurring blockers?
Agree on the triggers before the issue returns. A weekly review is a backstop; urgent customer commitments need a decision sooner.
| Trigger | What it means | Route |
|---|---|---|
| Same blocker appears in the next weekly review with no effective next step | The earlier action did not resolve the underlying dependency | Review authority, evidence, and attempted fixes |
| Owner lacks authority to make the tradeoff | Work depends on a choice outside the owner's remit | Authorized decision maker |
| Two functions have incompatible approved commitments | Both cannot proceed as planned | Shared executive sponsor |
| Necessary evidence or expertise is missing | A choice would be premature | Relevant specialist with an investigation date |
| Existing customer obligation is at immediate risk | Weekly cadence is too slow | Relevant urgent escalation process now |
Security incidents, outages, and other urgent events need their established response processes. This article addresses recurring operating dependencies; it does not replace incident management.
What belongs in a blocker escalation matrix?
Maintain a compact record with the affected functions. “Owner” should mean a person who accepts the next action, not a department name pasted into a column.
| Blocker | Work and teams affected | Attempts so far | Consequence of waiting | Decision or help needed | Authorized owner | Response needed by |
|---|---|---|---|---|---|---|
| [Specific missing condition] | [Defined next step] | [Actions and results] | [Known obligation or work at risk] | [One answerable request] | [Person or role until assigned] | [Date and reason] |
If the consequence is unmeasured, describe it without a fabricated dollar amount. “The customer scope review cannot be finalized” is useful. “This costs us thousands every day” needs evidence and a definition.
What should a blocker escalation request include?
An escalation request should state the blocked work, the dependency, what has already been tried, the decision requested, and who can make it. Include a recommendation, a response date, and what happens after the decision.
Suppose CS asks Product for a migration estimate. Product needs to know whether the customer has purchased standard onboarding or a custom service. Sales is waiting for an estimate before confirming the package.
Faster updates can move the same unanswered question around the company with impressive efficiency. Someone needs to authorize a provisional scope or choose the commercial terms that make estimation possible.
Use this request format:
Subject: Decision needed before Thursday's customer scope review
Blocked work: CS cannot finalize the migration plan.
Dependency: Product needs an approved support scope to estimate it.
Already tried: CS and Product compared the proposed requirements;
the remaining difference is what the package includes.
Decision requested: Can we use standard onboarding scope for the
estimate, or should Sales propose a separately scoped service?
Recommendation: Estimate standard scope first and identify exclusions.
Decision maker: The commercial owner authorized to approve scope.
Needed by: Wednesday, before the customer review is prepared.
After the decision: CS updates the plan; Sales confirms the promise;
Product verifies whether any estimate assumption remains unresolved.Tie the response date to the customer commitment and the time needed to prepare the next step.
Escalate the constraint, not the character.
Where practical, share the escalation with the affected owner before routing it upward. Give them a chance to correct the facts and contribute options. If urgency prevents that, make the urgency explicit and follow up with the context.
Escalate the constraint: “Neither function can approve the package terms.” Avoid assigning motives: “Product refuses to help.” The first statement points toward authority; the second invites an argument about intent.
Atlassian's clean escalations play offers a collaborative approach to unresolved issues. Use your company's actual authority boundaries rather than assuming every issue belongs with the CEO.
An executive reply isn't an unblocked plan.
An executive reply is not the same as an unblocked dependency. After a decision, confirm who changes the plan, who tells the affected teams, and what evidence will show the next step can proceed.
If the blocker returns, preserve the history. Check whether the decision was implemented, whether the assumptions changed, or whether the original action treated a symptom. A new due date alone will not explain the recurrence.
What is Decided?
Decided is an AI operating alignment layer for fast-moving SaaS companies. Clara runs recurring private 1:1 AI voice check-ins about priorities, blockers, decisions, and commitments. Decided compares the answers and prepares an alignment map, a weekly leadership brief, and context for follow-up.
Follow-up preserves the unresolved constraint instead of relabeling it as a new task.
People review the context and make the decisions. Before rollout, explain what is captured, who sees the output, how it is used, and whether participants can review notes. Private 1:1 describes the format, not anonymity. Decided is not hidden monitoring, employee scoring, or an automated employment decision system.
Explore Decided for CEOs and COOs. Try a live voice check-in to see how it works.
Sources.
Atlassian's clean escalations play describes a collaborative approach to unresolved issues. Its incident escalation guide distinguishes escalation by expertise and seniority.
