SLA policies and breach notifications

Ochre's SLA layer is a single first-response target per workspace, configured at Settings → Routing. When a conversation goes too long without a first reply, an in-app notification fires to the assignee, the org owners, and admins.

This is intentionally minimal. The interesting decisions happen in routing — who the conversation goes to, what priority it lands at — and the SLA layer just stamps a deadline on top.

How it works

When a new conversation is created, its created_at is the start of the SLA clock. The clock stops when a teammate or the AI in autopilot sends the first outbound reply (this is recorded as first_response_at).

A cron job sweeps periodically. For each conversation that is still open, has no first_response_at, and is older than the configured first-response window, Ochre emits one sla_breach notification and stamps sla_breach_notified_at so the same breach isn't notified twice.

There is no separate "warning at 75%" event. Breach is the only signal.

Configuring the targets

Two numbers and a toggle, all under Settings → Routing:

• First-response SLA — minutes from creation to first reply. Default 60.
• Resolution SLA — hours from first message to closed. Used in reporting; not enforced as a notification today.
• Business-hours-only timing — when on, the SLA clock pauses outside the workspace's business-hours window.

The targets apply uniformly. There is no per-priority target. If you want urgent conversations on a tighter clock, model that with routing actions (assign urgent to a senior agent, route urgent traffic to a smaller team) rather than expecting a separate priority-tier SLA. There is no /settings/sla page; the controls live under Routing.

Business-hours-only

The toggle pauses the SLA clock outside business hours. A 60-minute target on a message that lands at 4:55pm with the workspace closed at 5pm won't breach at 5:55pm — the clock resumes at the next opening.

See Office hours for how the schedule is configured.

What counts as a "first response"

A first response is the first outbound message from a teammate or the AI in autopilot mode. Internal notes don't count. Status changes don't count. Auto-replies don't count, by design — they're a courtesy acknowledgement, not an answer.

Who gets pinged

Breach notifications go to the assignee (if any), the workspace owners, and admins, via the in-app notification channel. Per-user channel preferences (email, Slack DM) follow the user's Notification preferences.

Idempotency

Each conversation can fire one breach notification. Once sla_breach_notified_at is stamped, the cron skips that row on future ticks even if it stays open.

What's not in v1

• No per-priority targets. One number, applied across the board.
• No 75%-of-the-way-there warning event.
• No automatic priority bumping or reassignment on breach.
• No standalone SLA settings page; everything lives under Routing.

If you need any of these, the workaround is routing rules: bump priority for VIP conversations on ingest, assign urgent traffic to your fastest responder, and watch the breach feed for the rest.

Reading SLA performance

Reports show first-response time and a list of recent breaches with conversation links. If breaches cluster on one assignee, the fix is usually capacity (rebalance) or routing (don't over-route to that person).

Related

• Routing overview.
• Routing rules for setting priority on ingest.
• Office hours for the business-hours toggle.