Recipe — Escalate SLA breaches to senior agents

When a conversation is approaching an SLA breach, three things should happen at once: (1) reassign to someone who can actually fix it, (2) make the leads aware so they can prioritize, (3) tag it for downstream reporting. One rule, three coordinated actions.

What this rule does

• Trigger: SLA at risk (the lead time you configure on the SLA target).
• Actions: Reassign to a senior agent, post to a Slack channel for leads, tag as Escalated.

Before you start

• An SLA policy configured with at-risk lead time
• A “Senior Support” agent or team configured in Settings — Teams
• A Slack integration configured for posting to a leads channel (Settings — Slack)
• An Escalated tag created in Tag Management

Build it

• 1 — Trigger — SLA at risk
• 2 — Condition — (none — every at-risk SLA escalates)
• 3 — Branch — Always
• 4 — Action 1 — Assign conversation → Team: Senior Support
• 5 — Action 2 — Send Slack message → channel #support-leads, body: :rotating_light: SLA at risk on {{conversation.human_id}} ({{contact.name}}). Conversation: {{conversation.url}}
• 6 — Action 3 — Add tag → Escalated
• 7 — Schedule restriction — Inside business hours (avoid 3am pages)
• 8 — Throttle — Per conversation, 1 per 30 minutes (avoid duplicate Slack pings if the SLA enters and leaves at-risk repeatedly)

Why these specific actions

• Assign first. The conversation gets in front of someone capable before the breach actually happens.
• Slack second. Visibility for leads who may need to coordinate (call the customer back, surface to the on-call manager, etc.).
• Tag last. Reporting and downstream rules (“anything tagged Escalated needs a 24-hour follow-up”) read from the tag.

The order matters because actions run in sequence. If action 1 fails (the team doesn’t exist), the rule still runs the Slack ping and tag — Atender doesn’t bail on first error. You want the visibility regardless.

Variants

• Different escalation targets by tier. Use branches: If contact.customer_level = VIP → assign VIP escalation team and ping #vip-leads; Else → assign general senior team and ping #support-leads.
• Escalate after breach, not just at-risk. Add a second rule with trigger SLA breached that does a stronger version (page on-call, tag as Critical).
• Don’t escalate during low-priority hours. Tighten the schedule restriction to specific weekday windows if your “leads” channel is only watched then.
• Add an internal note. Action: Add note with body “Auto-escalated due to SLA at-risk. Original assignee was {{conversation.assigned_agent.name}}.” Useful for audit and handoff context.

Verify it worked

Force a test SLA at-risk: pick a conversation, set its SLA target’s at-risk threshold to 1 minute, and watch what happens. The conversation should reassign, the Slack channel should receive a ping, and the Escalated tag should appear — all within a few seconds.

Open Manual Executions and confirm all three actions show success. If Slack failed, the run record will include the response from Slack’s API (usually a 401 or 404 indicating the integration’s webhook URL is stale).

Troubleshooting

• Symptom: Slack ping arrives twice for the same conversation. Fix: Throttle scope is global or per-tenant. Switch to per-conversation.

• Symptom: Reassignment happens but Slack doesn’t post. Fix: Check the Slack integration’s webhook URL hasn’t been rotated. Re-authenticate the Slack integration.

• Symptom: Rule never fires even though SLAs are breaching. Fix: The trigger is SLA breached (post-breach), not SLA at risk. If you want both, build two rules.

See also

• SLA System
• Slack integration
• Throttle a rule to prevent spam