Smart Escalations

Escalations ensure that blockers and concerns reach the right people at the right time. Instead of hoping someone notices a problem, Murmurd routes issues through a deterministic chain of responsibility.

How Escalations Work

When you create an escalation, it routes through your team’s leadership:

You (Reporter)
  ↓
Product Manager (PM)
  ↓
Team Manager
  ↓
Division Manager

Note

If someone in the chain is on vacation, they’re automatically skipped.

Creating an Escalation

1. Identify the blocker

   During a check-in or anytime, recognize when something is blocking your work.

2. Choose the team

   Select which team context the escalation belongs to.

3. Describe the issue

   Write a clear, concise description of:

   • What’s blocked
   • Why it’s blocked
   • What help you need

4. Set visibility

   Choose who can see the escalation:

   • Team: All team members
   • Org: Everyone
   • Confidential: Only you and managers

5. Submit

   The escalation is created and routing begins.

Escalation via Slack

If Slack is connected, you can create escalations using:

Slash Command

/escalate

Opens a modal where you can select team, describe the issue, and set visibility.

Quick Action

During check-in prompts, if you indicate a blocker, you’ll see an “Escalate” button.

Routing Logic

Deterministic Order

Escalations follow a predictable path:

1. PM First: The team’s Product Manager receives the escalation
2. Manager Second: If PM doesn’t resolve, it goes to the Manager
3. Division Manager Third: Final escalation point

Vacation-Aware

The routing system checks vacation status:

• If PM is on vacation → skip to Manager
• If Manager is also away → skip to Division Manager
• If all are away → stays with first available person in chain

Fallback

If no one in the chain can be reached:

• Escalation remains open
• Org admins can see unassigned escalations
• Email alerts are sent to admins

Resolution

An escalation can be resolved by:

• The current assignee (PM, Manager, etc.)
• The original reporter (if the issue resolved itself)

Tip

When resolving, add a note explaining how the issue was addressed.

Escalation States

State	Description
Open	Newly created, awaiting attention
In Progress	Assignee is working on it
Resolved	Issue has been addressed
Closed	Resolved with no further action needed

Age Buckets

Escalations are categorized by age to prioritize attention:

Bucket	Age	Color
Fresh	< 24 hours	Green
Aging	1-3 days	Yellow
Stale	3-7 days	Orange
Critical	> 7 days	Red

Dashboard Integration

Your dashboard shows:

• Open escalations: Count of unresolved issues
• Age distribution: Bucket breakdown
• Recent activity: Latest escalation updates

Best Practices

1. Be specific: “API returning 500 on /users endpoint” beats “API broken”
2. Include context: What were you trying to do?
3. Suggest solutions: If you have ideas, include them
4. Use appropriately: Escalations are for real blockers, not minor inconveniences
5. Follow up: If you resolve it yourself, mark it resolved

When to Escalate

Good reasons to escalate:

• Blocked on another team’s deliverable
• Missing access or permissions
• Technical issue you can’t solve alone
• Unclear requirements blocking progress
• Dependencies not met

Not ideal for escalation:

• General questions (use check-in responses)
• Feature requests (use your PM directly)
• Minor annoyances (handle async)

Next Steps

• Track your priorities
• Understand weekly summaries
• Set up Slack for escalations