# SLA Policies

Service Level Agreements (SLAs) set the response and resolution targets your team commits to, and warn you before you miss them. This article is for admins configuring policies. Open **Helpdesk → SLA Policies**.

## What an SLA Policy Controls

Each policy defines, **per priority** (Low / Normal / High / Urgent), up to three targets in minutes:

- **First response** — time to the first public reply from your team
- **Next response** — time to reply after the customer writes back
- **Resolution** — time to mark the ticket Solved

You don't have to set all three or every priority — leave a target blank to skip it.

## Creating a Policy

1. Click **New policy** and give it a name (e.g. "Standard", "Premium").
2. Fill in the per-priority targets. A common starting point:
   - **Urgent** — 60 min first response, 480 min resolution
   - **High** — 240 / 1440
   - **Normal** — 480 / 2880
   - **Low** — 1440 / 5760
3. Configure business hours (below) if you don't run 24/7.
4. Leave **Pause while waiting on the customer** enabled.
5. Mark one policy as the **tenant default** — it applies to any ticket not covered by a more specific policy.

## Business Hours

By default, SLA clocks run in real (wall-clock) time. Turn on **Count business hours only** to make targets respect your working schedule:

- **Timezone** — an IANA name (e.g. `America/New_York`)
- **Working days** — pick the days you're open (windows default to 9:00–17:00)
- **Holidays** — dates (`YYYY-MM-DD`) when the clock doesn't run

With business hours on, "4 hours to respond" means four *working* hours — a ticket that arrives at 4:30pm on Friday isn't overdue Monday morning.

## Pausing on the Customer

When a ticket is set to **Pending customer**, its clock pauses (if the policy allows). When the customer replies, the clock resumes and remaining due dates shift forward by the paused time. This keeps you from being penalized for time you're legitimately waiting on the customer.

## At-Risk and Breach

Each policy has an **at-risk threshold** (default 80%). As a ticket approaches its due time:

- At the threshold, an **at-risk** event fires — use it in an orchestration to nudge the owner or notify a lead.
- If the due time passes, a **breach** event fires and the ticket's SLA chip turns red.

Both are real platform events (`crm.ticket_sla_at_risk`, `crm.ticket_sla_breached`), so you can automate escalations, notifications, or reassignments off them in **Orchestrations**.

## VIP / Per-Company Policies

To give specific accounts tighter targets, scope a policy to one or more **companies**. When a ticket's company has a scoped policy, it wins over the tenant default. This is how you deliver a "Premium" SLA to contract customers without changing everyone else's.

## How the Customer Sees It

Customers never see your internal SLA mechanics. In the portal and in ticket emails, they see a friendly **expected response time** ("Expected first response by 4:00 PM today"), derived from the first-response target.

## Editing Policies

Changing a policy affects **new** tickets and future recalculations; tickets already in flight keep their current due dates until something recomputes them (e.g. a priority change). Deleting a policy leaves existing tickets' due dates intact.