How do I build a workflow with SLA alerts and escalation rules

To build a workflow with SLA alerts and escalation rules, think in terms of three layers:

1. Define the SLA
2. Monitor it with timers/conditions
3. Trigger alerts and escalations when thresholds are missed

Here’s a practical approach.

---

1) Define the SLA clearly

Before building anything, decide:

• What is being measured?
  • First response time
  • Resolution time
  • Approval time
  • Assignment time
• When does the clock start?
  • When the ticket is created
  • When it’s assigned
  • When it enters a specific status
• When does the clock stop or pause?
  • When status becomes “Resolved”
  • During waiting-on-customer states
  • Outside business hours
• What are the thresholds?
  • Warning at 75%
  • Breach at 100%
  • Escalate at 120%

Example:

• First response SLA: 15 minutes
• Warning at 10 minutes
• Escalate to manager at 15 minutes
• Escalate to director at 30 minutes

---

2) Model the workflow states

Your workflow should have statuses such as:

• New
• Assigned
• In Progress
• Pending Customer
• Pending Internal
• Resolved
• Closed

This matters because SLA timers often depend on the state.

For example:

• Start timer when status = New
• Pause timer when status = Pending Customer
• Resume timer when status = In Progress
• Stop timer when status = Resolved

---

3) Create SLA rules

Most systems implement SLAs as rules like:

• If priority = High and category = Incident
  Then response SLA = 15 min, resolution SLA = 2 hours

• If priority = Medium
  Then response SLA = 1 hour, resolution SLA = 8 hours

Make the rules dynamic if possible:

• by priority
• by customer tier
• by request type
• by business hours vs 24/7 support

---

4) Add alert thresholds

Use multiple alert points so people have time to react before breach.

Typical thresholds:

• Early warning: 50–75% of SLA time
• Critical warning: 90% of SLA time
• Breach: 100% of SLA time

Example for a 2-hour SLA:

• 1 hour 15 min → notify assignee
• 1 hour 45 min → notify team lead
• 2 hours → escalate and mark SLA breached

---

5) Define escalation rules

Escalation rules determine what happens if the SLA is at risk or breached.

A good escalation ladder might be:

Level 1: Assignee

• Notify the person responsible
• Send email/Slack/in-app alert

Level 2: Team lead

• Notify if no action after X minutes
• Reassign or flag as urgent

Level 3: Manager/director

• Notify if still unresolved after another X minutes
• Create high-priority incident
• Trigger paging/on-call

Level 4: Auto-actions

• Reassign ticket
• Change priority
• Open an incident
• Create a follow-up task

Example:

• 80% SLA: remind assignee
• 100% SLA: notify manager
• 120% SLA: auto-escalate to next tier and page on-call

---

6) Build the workflow logic

At a high level, your workflow should do this:

1. Record ticket creation time
2. Determine applicable SLA
3. Start SLA timer
4. Continuously evaluate elapsed time vs SLA
5. Send alerts at configured thresholds
6. Escalate if unresolved after thresholds
7. Stop or pause timer based on ticket state

Pseudo-logic:

On ticket created:
  determine SLA policy
  start timer

Every minute:
  calculate elapsed time
  if elapsed >= warning_threshold and warning not sent:
      notify assignee
  if elapsed >= escalation_threshold_1 and level_1 not sent:
      notify team lead
  if elapsed >= breach_threshold:
      mark breached
      escalate to manager

---

7) Use business hours and pauses

A common mistake is measuring SLA in calendar time when the business only cares about working hours.

You may need:

• Business hours schedule
• Holiday calendar
• Pause/resume logic for waiting states

Example:

• A 4-hour SLA should count only during Mon–Fri, 9–5
• If the ticket waits on the customer, pause the timer

---

8) Decide notification channels

Alerts can go through:

• Email
• SMS
• Slack/Teams
• In-app notifications
• PagerDuty/Opsgenie
• Webhooks/API

Use different channels for different severities:

• Warning: Slack/email
• Escalation: email + manager notification
• Breach: pager/on-call alert

---

9) Add audit tracking

Log every SLA event:

• SLA start
• Pauses/resumes
• Warning sent
• Escalation level 1/2/3
• Breach
• Resolution time

This helps with:

• reporting
• compliance
• debugging
• performance analysis

---

10) Test with real scenarios

Before going live, test:

• Ticket resolved before warning
• Ticket hits warning but resolves before breach
• Ticket breaches and escalates correctly
• Timer pauses correctly on waiting status
• Business-hours calculation works correctly
• Reassignment doesn’t reset SLA unless intended

---

Example workflow

Here’s a simple example:

SLA policy

• High priority incident:
  • Response SLA: 15 minutes
  • Resolution SLA: 2 hours

Escalation

• 10 min: notify assignee
• 15 min: notify team lead
• 30 min: notify manager
• 2 hours: breach, page on-call

State handling

• Timer starts when ticket is created
• Pauses when status = Pending Customer
• Resumes when status returns to In Progress
• Stops when status = Resolved

---

If you’re building this in software

You’ll usually need:

• A workflow engine or state machine
• A scheduler/timer system
• A rules engine
• Notification integrations
• SLA reporting storage

A simple architecture:

• Database stores tickets, SLA policies, status history
• Background worker checks deadlines
• Rules engine decides alerts/escalations
• Notification service sends messages
• Dashboard shows SLA status

---

Recommended design pattern

Use a rule structure like this:

{
  "sla_name": "High Priority Response",
  "start_condition": "ticket_created",
  "pause_conditions": ["pending_customer"],
  "stop_condition": "resolved",
  "thresholds": [
    {"percent": 75, "action": "notify_assignee"},
    {"percent": 100, "action": "notify_team_lead"},
    {"percent": 120, "action": "escalate_manager"}
  ]
}

---

If you want, I can also give you:

1. a no-code/low-code version for tools like ServiceNow, Jira, or Zendesk, or
2. a technical implementation example in Python, JavaScript, or BPMN.