SLA Management

SLA (Service Level Agreement) management lets you define response and resolution targets for conversations and track when those targets approach or exceed their limits.

SLA policies

Open SLA Management → Response policies in the dashboard. Do not look for SLA policies under Settings.

A policy defines three targets, in minutes:

• First Response Time: time until the first operator response.
• Next Response Time: time for a later operator response after visitor engagement.
• Resolution Time: time until the conversation is resolved.

Policies can be scoped to departments or tags. Higher priority values are evaluated first, so more specific policies can take precedence over a priority-0 default.

{
  "name": "Premium Support",
  "firstResponseTime": 15,
  "nextResponseTime": 30,
  "resolutionTime": 480,
  "enabled": true,
  "priority": 10,
  "businessHoursOnly": true,
  "departments": ["billing"],
  "tags": ["premium"]
}

Each target must be from 1 to 10080 minutes.

Workspace business hours

When a policy has Business hours only enabled, configure its shared time window under Settings → Scheduling → Workspace business hours.

The shared start/end window applies Monday through Friday. SLA evaluates those hours in each selected site's timezone, configured under Sites. Overnight windows are supported by using an end hour earlier than the start hour.

If no workspace business-hours window has been saved, business-hours-only SLA timers fall back to the legacy behavior: they pause on weekends but count all weekday hours. Use Clear business hours in Settings → Scheduling to return to this fallback.

Workspace SLA business hours are separate from each operator's Weekly Availability and from AI Chatbot → Basics → Operating hours.

Monitoring SLA status

The SLA status API reports one of three states for a conversation:

Get the overview for active conversations:

GET /api/sla/status

Get a specific conversation's current SLA evaluation:

GET /api/sla/status/:conversationId

The per-conversation response includes the matched policy, remaining time values, whether the countdown is currently running, the next transition time when known, and any breached metrics.

Checking a newly breached conversation can trigger the SLA escalation state and publish the updated state to operators.

Breaches

Open SLA Management → Missed targets to work with recorded breaches. Breach records track the conversation, policy, breached metric, assigned operator when present, breach duration, and lifecycle state.

The lifecycle is:

• open
• acknowledged
• resolved

The breach API accepts optional operatorId, policyId, from, and to filters. Authorized cross-site reads can also use the supported all-project scope.

GET /api/sla/breaches?from=2026-08-01&to=2026-08-31

Acknowledge a breach without resolving it:

POST /api/sla/breaches/:id/acknowledge

Resolve a breach:

POST /api/sla/breaches/:id/resolve

Resolving an unacknowledged breach also acknowledges it.

API reference

Policy mutations require admin access. SLA read and breach-workflow endpoints require the applicable authenticated operator access and project scope.

Related

• Conversations
• Analytics
• Team Management