Settingsintermediate

Recipe — Escalate SLA breaches to senior agents

When a conversation's SLA is at risk, assign it to a senior support team, ping the leads channel in Slack, and tag it as Escalated. One rule, three coordinated actions.

5 min read

Recipe — Escalate SLA breaches to senior agents

When a conversation is approaching an SLA breach, three things should happen at once: (1) move it to a team that 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: An SLA is about to be breached (the At risk and Urgent thresholds you configure on the SLA policy).
  • Actions: Assign to the Senior Support team, post to a Slack channel for leads, tag as Escalated.

Before you start

Build it

Go to Settings → Automation rules, click Add rule, then Build it by hand instead.

  • When — An SLA is about to be breached
  • Only if — (none — every at-risk SLA escalates)
  • Then — 1. Assign conversation to an agent or team → Team: Senior Support
    2. Send Slack message or DM → channel #support-leads, message: :rotating_light: SLA at risk on {{conversation.id}} ({{contact.name}}). Conversation: {{conversation.url}}
    3. Add tag → Escalated
  • More options — Only during opening hours: on, opening hours: your business hours, Run: Inside opening hours (avoid 3am pages)
    Limit how often it runs: on, At most (times) 1, Every (minutes) 30, Counted: Per conversation (the trigger fires at At risk and again at Urgent; set the minutes to cover the gap between the two so Slack is pinged once)

In the Slack message, type / or click Insert field to add the fields.

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.

One exception: if this rule runs on an escalation side conversation, internal actions such as assignment and the Escalated tag still apply, but external notifications like Slack posts are suppressed on the side conversation for safety. If your team needs Slack visibility for those escalations, trigger the Slack notification from the primary conversation or another non-side-conversation workflow instead of expecting it to fire from conversation B.

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 An SLA is breached that does a stronger version (page on-call, tag as Critical).
  • Don’t escalate during low-priority hours. Under Only during opening hours, choose opening hours that match when your “leads” channel is watched.
  • Add an internal note. Action: Add internal note with body “Auto-escalated due to SLA at-risk. Now with {{team.name}}.” Placed after Action 1, {{team.name}} is the new team. Avoid {{agent.name}} here: Action 1 assigns a team and leaves the assigned agent unchanged, so it still shows the original agent. Atender has no merge tag for the previous assignee.

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 move to the Senior Support team, the Slack channel should receive a ping, and the Escalated tag should appear — all within about a minute.

Open Run History and find this escalation rule in the Rule column. The run row should show action chips for assignment, Slack, and tagging. Use those chips to confirm which actions succeeded; if any action failed, check the failure reason shown under the row to identify whether assignment, Slack, or tagging needs attention. Slack failures are recorded here: a failed Slack post fails the action, so the run shows Failed with a reason that includes Slack webhook failed or Slack post to channel.

Troubleshooting

  • Symptom: Slack ping arrives twice for the same conversation. Fix: An SLA is about to be breached fires once at At risk and again at Urgent. Turn on Limit how often it runs with Counted set to Per conversation and Every (minutes) long enough to cover the gap between the two thresholds.

  • Symptom: Reassignment happens but Slack doesn’t post. Fix: Open Run History and find this escalation rule’s run; a failed Slack post marks the run Failed and shows the failure reason under the row. Re-authenticate the Slack integration or confirm the webhook URL hasn’t been rotated. If the rule ran on an escalation side conversation, the Slack action is suppressed by design; trigger Slack from the primary conversation or another non-side-conversation workflow instead.

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

See also

Tags

Recipe
Back to Settings