SLA and Escalations

Applies to the MSP, organization and platform portals.

What it is

Escalation is what happens when a ticket needs someone else: another team, the platform, or a paid third-party specialist.

The two are connected but separate. A ticket can breach its SLA without being escalated, and can be escalated without ever having breached.

Concepts

The two clocks

Every SLA-tracked ticket has two independent clocks:

• Response — runs from ticket creation until the first response is recorded. Stops permanently once recorded.
• Resolution — runs from ticket creation until the ticket is resolved.

Each is separately met or breached. A ticket answered in two minutes and then left for a week has met response and breached resolution.

Priorities

Targets are set per priority: CRITICAL, URGENT, HIGH, MEDIUM, LOW. A priority with no target in the policy gets no deadline at all — the ticket is simply untracked rather than defaulted.

Escalation types

Escalation modes

Set per organization under Settings → Support:

Who receives an escalation

An escalation is addressed to the account that services the organization raising it:

1. The primary manager (Account.managedByAccountId) — the account that bills and brands the client.
2. Otherwise a single active management link, where exactly one MSP holds one.
3. Otherwise the platform — which covers an unmanaged tenant, and a co-managed client where no primary exists and picking one MSP would be a guess.

The recipient sees the escalation in its own portal and is notified; the organization that raised it keeps visibility throughout. Escalating onward to a third-party provider is a separate, deliberate step.

Roles and permissions

SLA policy and calendar administration is scoped by account: you only ever see and edit policies belonging to organizations in your own account. Platform admins span all accounts.

Writing SLA policies and calendars is additionally gated on plan tier — see section 6. Reads and deletes are never gated, so a downgrade leaves existing configuration visible and removable.

Pause and resume are bounded by ticket visibility rather than by role: anyone who can open the ticket can stop its clock. The control is surfaced on the MSP ticket detail; the organization portal shows the clock state read-only, on the principle that pausing a commitment is the servicing party’s call.

Escalation visibility

An assignment legitimately spans two accounts, so it is visible from either the requesting side or the provider side.

Walkthroughs

Define service levels

1. Go to Settings → SLA.
2. Choose the client organization the policy belongs to (MSP portal only).
3. Select New policy, name it, and add a target row per priority you want tracked, in minutes.
4. Mark it Default if new tickets in that organization should use it.

Only one policy per organization can be default; setting a new one clears the previous automatically.

Set the working calendar

1. Go to Settings → SLA → Business Hours.
2. Pick the client (MSP portal only) and set the time zone.
3. Enable the working days and set start and end times.
4. Save changes.

The API requires all seven days on every save, so the form always submits the full week and uses the enabled flag to mark non-working days. Copy to weekdays fills Monday’s hours across Tuesday to Friday.

The time zone is not cosmetic. Start and end times are wall-clock times in the zone you pick, so changing the zone moves every deadline computed against this calendar.

If no business hours exist at all, or none are enabled, clocks run 24/7.

Add holidays

1. Go to Settings → SLA → Holidays.
2. Pick the client (MSP portal only) and the year.
3. Add holiday, or use the bulk action to add the Canadian statutory holidays missing for that year.
4. Tick Recurring for a day that falls on the same month and day every year.

A recurring holiday only needs entering once — it applies in every subsequent year. A non-recurring one applies only to the exact date stored.

Work a ticket against its SLA

1. Open the ticket in the MSP portal.
2. The banner under the header shows First response and Resolution, each with the time remaining, the policy name, and a met/breached/at-risk state.
3. If you are waiting on the customer, select Pause SLA. The clock stops and the paused minutes are excluded from remaining time.
4. Select Resume SLA when work restarts.

Paused tickets are excluded from breach marking and from at-risk warnings while they stay paused.

Escalate a ticket

1. Open the ticket and choose the escalation action.
2. Enter a reason.
3. The ticket is flagged escalated, its original account and assignee are recorded, and an escalation record is created.

The organization’s Settings → Support must allow escalation; otherwise the request is refused. To reverse it, de-escalate — optionally restoring the original assignee. Both directions are written to the ticket’s activity trail.

Dispatch an escalation to a provider

2. Create an assignment against a provider. The rate is snapshotted from the provider’s rate card at that moment, so later rate-card edits do not change an in-flight assignment.
3. The provider accepts or declines, starts work, logs time, and completes with resolution notes.
4. The requester reviews with a 1–5 rating.
5. Billing is calculated from logged time and the snapshotted rate, then finalised.

Configuration

Managed-client fallback

A managed client usually keeps no SLA configuration of its own — the MSP cannot create policies or calendars inside the client’s organization. So when a client organization has none, both the policy and the calendar fall back to those of the account servicing it.

The client’s own configuration always wins where it exists, and the managed relationship is directional, so one client’s policy never lands on another’s ticket. Hours and holidays are resolved together from the same organization, so the two halves of a calendar can never come from different places.

Events emitted

Plan tiers

slaManagement is a graduated feature: absent, then BASIC, then ADVANCED.

• BASIC unlocks SLA policy management — response and resolution targets.
• ADVANCED additionally unlocks business-hours calendars and holidays.

Gated routes answer 403 FEATURE_NOT_ON_PLAN with a structured upgrade offer. A managed client inherits its managing MSP’s tier when its own account has none. Platform admins and accounts with no resolvable tier are never blocked.

Escalation itself carries no plan gate.

Troubleshooting

Deadlines look wrong by several hours

Check the time zone on Settings → SLA → Business Hours. Start and end times are wall-clock times in that zone; a calendar saved under the wrong zone shifts every deadline by the offset between them.

A holiday was ignored

A non-recurring holiday matches only its exact stored date. If you meant it to repeat annually, edit it and tick Recurring.

The clock did not stop overnight

Business hours only apply if at least one day is enabled. A calendar with every day disabled is treated as 24/7, not as permanently closed.

Limits and known behaviour

• Response is recorded once. After the first response the response clock stops permanently; later replies do not reopen it.
• Deadlines recalculate from creation. Changing a ticket’s priority recomputes both deadlines from the original creation time, not from now. A ticket escalated to CRITICAL late in its life may be immediately overdue.
• Recalculation needs an existing policy. A priority change on a ticket with no SLA policy attached does nothing; it does not retro-assign one.
• Pause is a manual action. Nothing pauses a clock automatically when a ticket moves to a waiting-on-customer status.
• Paused time is subtracted, not shifted. Pausing does not move the stored deadline; it adjusts remaining time.
• Escalation is never auto-dispatched to a provider. Both modes hand the ticket to the servicing MSP (or the platform). Offering it to an external provider is always a deliberate act, so nobody incurs a third-party bill without choosing to.
• A co-managed client with no primary manager escalates to the platform. With several MSPs holding active links and no managedByAccountId, there is no basis for choosing one, so the platform triages it.
• Provider capacity filters suggestions, it does not block dispatch. A provider at maxConcurrentEscalations is excluded from suggest-provider and from automatic selection, but naming it directly on an assignment still works.
• Holiday matching is date-based. A holiday excludes the whole calendar day in the calendar’s time zone; partial-day closures are not modelled.
• The calendar walk is bounded at 3,650 days. A target that cannot be satisfied inside that window falls back to elapsed time and logs a warning.