SLA

The SLA page brings all of Ascent's service-level-agreement configuration together in one place. It lives under Settings → Ticketing and is available to the Owner and Admin roles (each tab is further gated by its own permission).

Go to Settings → Ticketing → SLA (/settings/ticketing/sla). The page is organized into tabs; only the tabs you have permission for are shown.

Previously in separate places

Before this consolidation, SLA configuration was spread across three locations: default SLA targets under Ticket Customization, SLA Policies under Settings, and SLA Escalation Policies under Settings. Those screens are unchanged — they're now reachable as tabs here. The old links (/settings/sla-policies and /settings/sla-escalation-policies) redirect to the matching tab, so existing bookmarks keep working.

Defaults

The Defaults tab defines your organization-wide first-response and resolution targets, plus the business-hours schedule the SLA clock follows. These defaults apply to tickets that do not have contract- or policy-specific SLA terms.

Viewing and saving defaults requires the organization update permission (the Owner or Admin role). Without it, the tab is hidden.

Response & resolution times by priority

There are four fixed priority levels — Critical, High, Medium, and Low. For each one you set two values:

Setting	Description
First Response	Target time to send the first response to the ticket.
Resolution	Target time to resolve the ticket.

Each value has a number field and a unit selector: Minutes, Hours, or Days. Each priority card also shows a live "Current" summary of the configured response and resolution times.

The starting defaults are:

Priority	First Response	Resolution
Critical	30 minutes	4 hours
High	1 hour	8 hours
Medium	4 hours	24 hours
Low	8 hours	48 hours

Business hours

Use the Business Hours controls to make SLA timers count only during your working hours:

1. Toggle Enable Business Hours on. When it is off, SLAs run 24/7.
2. Set a Start Time and End Time.
3. Select your Business Days using the day buttons (Mon–Sun). The defaults are Monday through Friday, 09:00 to 17:00.

When business hours are enabled, SLA timers pause outside the configured window. Click Save Changes at the top of the Default SLA Settings card to apply the priority targets and business hours.

Policies

The Policies tab manages named, reusable SLA policies — define a set of SLA targets once and assign it to clients and contracts, independently of billing contracts. See SLA Policies for how policies are resolved relative to defaults and contracts.

Each policy has a flat response and resolution target that applies to every ticket priority. You can optionally turn on Per-priority targets to set distinct response/resolution times for Critical, High, Medium, and Low — the same way the Defaults tab does. When per-priority targets are on, a ticket of a given priority uses that priority's value; any field you leave blank falls back to the policy's flat target, and then to the organization's per-priority default. A policy may consist of nothing but per-priority targets (no flat target at all). Existing policies are unaffected — with per-priority targets off, the flat target applies to every priority exactly as before.

This tab requires the SLA Policies → read permission to view, and the create/update/delete permissions to manage policies.

The Default policy

The Policies list always includes a single, pinned Default policy (marked with a Default badge at the top). This is your organization-wide fallback — the per-priority targets and business hours applied to a ticket when no contract or named policy supplies one. It is the same thing the Defaults tab edits, now shown in the same list and the same format as every other policy so there is one consistent place for SLA targets.

You can edit the Default policy's per-priority targets and business hours just like any named policy, but it is always active, its name is fixed, and it cannot be deleted — it must remain the fallback. Editing your existing defaults requires no migration; they carry over automatically and no ticket's due dates change.

Escalations

The Escalations tab manages SLA escalation policies — named, multi-step chains that automatically notify, reassign, and re-prioritise a ticket as it approaches or breaches its SLA, so an ageing ticket never sits silently past its target.

This tab requires the SLA Escalation Policies → read permission to view, and the create/update/delete permissions to manage policies.

How a policy is matched to a ticket

Each policy has three optional matchers — Priority, Client, and Category. A matcher left at Any matches everything; a matcher set to a specific value only matches tickets with that value. A policy applies to a ticket when every non-null matcher matches.

When more than one active policy could apply, the most specific one wins — the policy with the most matchers set. This lets you keep a broad catch-all (for example Any priority · Any client · Any category) alongside a tighter override (for example Critical · Acme Corp), and the tighter one takes precedence for the tickets it matches.

An Inactive policy is kept but never evaluated — use the Active switch to pause a policy without deleting it.

Escalation steps

A policy runs an ordered list of steps. Each step has:

Field	What it does
After (minutes)	How long past the anchor below the step waits before it fires. 0 means fire as soon as the anchor is reached.
Relative to	The anchor the wait is measured from — At-risk (the ticket is approaching its SLA target) or Breach (the target has passed).
Action	What the step does when it fires (see below).

The four actions and their targets:

Action	Target	Behavior
Notify a user	A specific org member	Sends that user a notification (respecting their notification preferences).
Notify a role group	An org role — Owner, Admin, or Member	Notifies every member who holds that role.
Reassign ticket	An org member, or First admin (default)	Reassigns the ticket to the chosen user; left at the default it goes to the first admin.
Bump priority	A target priority, or One level up (default)	Raises the ticket's priority — to the chosen level, or up one level when left at the default.

Steps run in order, and each step fires at most once per ticket — a step that has already run against a ticket is never repeated, even across restarts, so escalations don't double-fire.

How escalations run

Ascent evaluates escalation policies as part of its SLA check, which runs in the background every few minutes. On each pass it finds tickets that are currently at-risk or breached, picks the matching policy for each, and executes any steps that have come due. Every executed step is recorded, both for the once-per-ticket guarantee and in the audit log.

If no policy matches a ticket, Ascent falls back to its built-in default: a breached Critical ticket is reassigned to the first admin. Orgs that never configure a policy keep this original behavior unchanged.

Creating a policy

1. On the Escalations tab, click New Policy.
2. Give the policy a Name and, optionally, a Description.
3. Set the Priority, Client, and Category matchers (leave any at Any to match everything).
4. Add one or more steps with Add step, setting each step's After (minutes), Relative to anchor, Action, and target.
5. Leave Active on to put the policy into effect (or turn it off to stage it for later), then click Create policy.

Edit or delete a policy later with the pencil and trash icons on its card. Deleting a policy cannot be undone.

How SLA targets are resolved

Ascent picks the SLA targets for a ticket in precedence order: a contract's own SLA terms (or assigned policy) override an assigned SLA Policy, which overrides the organization Defaults. This precedence is unchanged by the consolidation — the hub is a navigation convenience, not a behavior change.

Related

• Ticket Customization — ticket statuses and categories, including the Pauses SLA stop-the-clock status flag.
• SLA Dashboard — monitor compliance, breaches, and at-risk tickets against these targets.