Skip to main content
SLA breaches damage customer trust and often trigger financial penalties in B2B contracts. The problem is not that teams ignore SLAs — it is that they only find out about a breach after it happens. By the time a manager notices a ticket has been open for 23 hours against a 24-hour SLA, there is almost no time to act. A proactive system that flags tickets approaching their deadlines gives your team the window they need to prevent breaches, not just report them. This use case deploys a scheduled playbook that scans open tickets every hour, calculates time remaining against SLA targets, and alerts the team about tickets at risk of breaching. Python code handles the time calculations, accounting for business hours, weekends, and holidays. Tickets within 2 hours of their SLA deadline trigger an urgent Slack alert.

​
What you need

Data sources

  • Helpdesk system — Open tickets with creation timestamps, first response timestamps, priority levels, and SLA policy assignments
  • CRM system — Customer contract details with SLA terms (response time, resolution time by priority)

Knowledge spaces

  • SLA policy definitions — Upload your SLA tiers with response and resolution targets by priority and customer tier
  • Business hours calendar — Upload your support team’s working hours, holidays, and timezone rules
Semantic layer: Define these in your ontology before setting up the agent.
ComponentNameDefinition
ObjectTicketMaps to the helpdesk ticket table. Represents an open support request with SLA timer data
ObjectSLA PolicyMaps to SLA configuration records. Defines response and resolution targets by priority and tier
MetricTime to SLA BreachBusiness hours remaining until the ticket’s SLA deadline, calculated in real time
MetricSLA Compliance RatePercentage of tickets resolved within their SLA target over a given period
DimensionPriorityTicket priority: critical (1-hour response), high (4-hour), medium (8-hour), low (24-hour)
DimensionSLA StatusCurrent SLA state: on track, at risk (less than 2 hours remaining), breached
See building a semantic layer for a step-by-step guide.

​
Agent setup

1

Create the agent

Go to Agent Space > New agent.
FieldValue
NameSLA Monitor
RoleSLA compliance analyst
GoalPrevent SLA breaches by tracking deadlines and alerting the team proactively
2

Set the description

You monitor SLA compliance across all open tickets. When asked about SLA status, always show tickets closest to breaching first. Calculate time remaining in business hours, not calendar hours. For each at-risk ticket, show the ticket number, customer, priority, SLA target, time remaining, and assigned agent. If a ticket has already breached, note it clearly and recommend immediate action. Use precise timestamps and never round time remaining — 1 hour 42 minutes, not “about 2 hours.”
3

Scope data access

Grant access to:
  • Helpdesk system data source (open tickets with timestamps)
  • CRM system data source (customer contracts with SLA terms)
  • SLA policy definitions knowledge space
  • Business hours calendar knowledge space
  • Ticket and SLA Policy objects in the semantic layer
4

Add skills

Trigger: User asks about SLA compliance or at-risk tickets
  1. Pull all open tickets with their creation timestamps, first response timestamps, and assigned SLA policies.
  2. Look up the SLA target for each ticket based on its priority and the customer’s contract tier.
  3. Calculate elapsed business hours since ticket creation, accounting for business hours, weekends, and holidays.
  4. Compute time remaining until the SLA deadline for each ticket.
  5. Classify each ticket as on track, at risk (less than 2 hours remaining), or breached.
  6. Sort by time remaining, shortest first, and present a table with ticket number, customer, priority, SLA target, elapsed time, time remaining, and status.
Trigger: User asks for an SLA compliance summary or performance report
  1. Pull all tickets closed in the specified period.
  2. Determine whether each ticket was resolved within its SLA target.
  3. Calculate the overall SLA compliance rate as a percentage.
  4. Break down compliance by priority level and customer tier.
  5. Identify the top three reasons for SLA breaches from resolution notes.
  6. Present a summary with compliance rate, breakdown table, and recommendations.

​
Automation

​
Playbook: Hourly SLA scan

1

Set the trigger

Schedule the playbook to run every hour during business hours (e.g., 8:00 AM to 8:00 PM on weekdays).
2

Build the workflow

The playbook scans all open tickets, calculates SLA time remaining, and alerts the team about at-risk tickets.
  1. Query step — Pull all open tickets with creation timestamps, priorities, and SLA policy assignments.
  2. Python code step — Calculate business hours elapsed and time remaining for each ticket. Account for the business hours calendar (working hours, weekends, holidays). Classify each ticket as on track, at risk, or breached.
  3. Condition step — Filter to tickets that are at risk (less than 2 hours remaining) or already breached.
  4. Format step — Build an alert message with ticket number, customer name, priority, time remaining, and assigned agent.
The Python code step uses a Python code block to compute business-hours elapsed time, factoring in your working hours schedule, weekends, and holidays. You can customize the at-risk threshold (default 2 hours) and the business hours definition.
3

Configure delivery

Send at-risk ticket alerts to the #support-sla Slack channel. For breached tickets, also send a direct message to the assigned agent’s manager with the ticket details and recommended action.
4

Test and activate

Click Run now to test with live data, then toggle to Active.

​
What’s next

Email reply drafting

Draft context-aware customer replies that match your brand voice.

All customer service use cases

See the full list.