/sla-escalation-playbooks

name: "SLA Escalation Playbooks"
description: >
  A cross-PSA escalation framework for SLA pressure: how each PSA family
  (Autotask, HaloPSA, ConnectWise Manage, Syncro, Kaseya BMS) models
  SLA/priority state and where breach risk lives in each, a normalized
  breach-risk state model (healthy, at risk, breached-response,
  breached-resolution) with the default escalation action per state, how
  notification audience shifts by contract tier, and the evidence to gather
  before paging anyone.
when_to_use: >-
  When a ticket is approaching or has breached its SLA response or resolution
  target and the operator needs to know how — and to whom — to escalate it.
  Use when: SLA breach, SLA at risk, escalate this ticket, who do I notify,
  breach notification, response time risk, resolution target missed, "what's
  about to breach".

SLA Escalation Playbooks

Overview

SLA breaches are the single most reliable predictor of a client escalation call. This skill is the judgment layer on top of whatever SLA/priority data your connected PSA returns: it tells you when a ticket's breach risk crosses a threshold that warrants action, who should be notified at that threshold, what evidence to attach to the escalation, and how the response changes for a Platinum client versus a break-fix client on the same board.

This skill does not re-teach any single PSA's ticket API. It assumes you already know how to fetch a ticket and its SLA fields via the connected vendor's tools (or via `conduit__search_tools` if you don't yet know which tools are available) — what it adds is the cross-vendor decision logic for what to do with that data once you have it.

Anti-triggers

• **A platform's SLA policy configuration** — policy fields, business-hours

calendars, and how a vendor computes its own due dates are that connector's surface; use `freshdesk-sla-business-hours`, `autotask-tickets`, or `halopsa-tickets`.

• **Engineering error budgets** — SLO burn rate against an uptime or

error-rate target is a different measurement from a contractual response time; use `error-budget-tracking` in devops-pack.

Key Concepts

How each PSA family models SLA state

Every PSA expresses "how close is this ticket to breaching" differently. Resolve the concrete field/tool names for the connected instance before relying on any of this — these are the *shapes* to expect, not literal API contracts:

| PSA family | SLA/priority model | Where breach risk lives | |---|---|---| | **Autotask** | Numeric ticket priority (1–4) plus a Service Level Agreement linked to the client's contract, driving separate first-response and resolution due-date fields on the ticket | `autotask__get_ticket_details` / `autotask__search_tickets` — look for resolution plan / due-date fields; `autotask__list_ticket_priorities` resolves the priority label | | **HaloPSA** | SLA profile assigned per ticket (often derived from client + priority), with explicit response and resolution target timestamps and a breach flag | `halopsa__tickets_get` returns `deadlinedate` / SLA hold state; `halopsa__tickets_list` can be filtered/sorted by SLA proximity | | **ConnectWise Manage/PSA** | SLA record tied to board + priority, combined with Impact/Urgency fields; boards often carry their own escalation status flag | Ticket record's SLA/status fields — confirm the board's escalation flag naming, it is board-configurable | | **Syncro** | Lighter-weight: ticket "Due Date" plus priority, no separate formal SLA engine in most instances | Ticket due-date field and priority; treat due-date proximity as the SLA proxy | | **Kaseya BMS** | Service Desk SLA tied to the client's Service Level Agreement, with response/resolution timers per ticket | Ticket SLA timer fields exposed by the connected Kaseya BMS tools |

If the org has more than one PSA connected (rare, but happens during a PSA migration), scope explicitly to one board/instance per run and say which one you used.

The common escalation decision framework

Regardless of which PSA is behind the numbers, normalize every ticket to a single **breach-risk state** before deciding what to do:

1. **Healthy** — comfortably inside both response and resolution targets. 2. **At risk** — inside target but less than ~25% of the allotted window remains (tune this threshold to the org's own norms if documented; state the threshold you used). 3. **Breached — response** — first-response target missed; no technician has substantively engaged yet. 4. **Breached — resolution** — resolution target missed; ticket has had engagement but is not resolved.

Escalation action scales with state:

| State | Default action | |---|---| | Healthy | No action | | At risk | Internal nudge to the assigned technician (or to the dispatcher if unassigned) | | Breached — response | Escalate to team lead/service manager; internal note logged on the ticket | | Breached — resolution | Escalate to service manager and, per contract tier below, to the client |

Evidence to gather before escalating

Never escalate on the SLA timer alone — attach the context a manager or client contact will actually need:

• Ticket age and full status-transition history (when did it last move, and to what)
• Assigned technician (or confirmation it's unassigned) and their current open-ticket

count, if the PSA exposes technician workload

• Last client-visible communication timestamp and its content
• Whether the ticket is waiting on the client (see `board-hygiene` skill) — a breach

caused by a non-responsive client is a different conversation than one caused by an idle queue

• Contract/SLA tier for the client (see below)

Escalation by contract tier

Contract tier changes *who* gets notified and *whether the client is proactively contacted*, not whether the breach itself matters:

| Tier (typical naming) | On "at risk" | On "breached" | |---|---|---| | Premium / Platinum / fully-managed | Team lead notified at "at risk"; account manage