--- title: "Escalation" slug: admin/escalation url: https://projectri.com/docs/admin/escalation section: admin audience: admin app_route: "/[slug]/admin/escalation" permissions: [support.view, settings.workflow] mobile: false updated: 2026-09-08 source: Projectri documentation --- # Escalation Ladders that decide who is told when a support SLA is missed, how long each rung gets before it climbs, and on which channels. ![Escalation](https://projectri.com/docs-shots/admin-escalation.png) ## What it is An SLA is the promise made to the customer. An escalation ladder is what happens internally when the promise has already been broken. Each rung names somebody and how long they get before the next rung is told. Before ladders existed, a breach notified the assigned agent and stopped — which is precisely the person who has already not answered. ## How to get there **Work → Escalation** in the admin console rail, at `//admin/escalation`. Reading the ladders needs `support.view`. Who a breach reaches is not a secret from the people it might reach, and the ticket timeline renders the same words. Creating, editing and deleting a ladder needs `settings.workflow` — an escalation chain decides whose phone rings at 3am, which is a policy decision about people rather than a preference. ## How to use it ### Read a ladder 1. Each card leads with the severity it applies to, or **Any** for the fallback ladder, and is tagged **Default** when it is the one used for every breach at that severity. 2. The rungs are drawn as the sequence they are, numbered, each naming who is told and when: **as soon as the SLA is missed**, or after a wait measured from the breach. 3. A rung using a channel that is not yet delivering is marked as pending. 4. The card says how many times the ladder has been climbed. ### Write one 1. Press **New policy**. 2. Name it, and choose the severity it **applies to**. Leaving it on the any-severity option makes it the fallback ladder. Severity is fixed after creation. 3. Build the rungs. Each has a **wait after the breach** — typed as `30m`, `4h`, `2d` or a bare number of minutes — and a **tell**: - **Assigned agent** — whoever the ticket is assigned to right now. - **Team lead** — the maintainers of the team the ticket sits with. - **Line manager** — the assigned agent's manager on the org chart. - **Account manager** — the owner of the client the ticket belongs to. - **Customer success** — workspace admins, the rung of last resort. - **A specific person** — always the same person, whatever the org chart says. 4. Pick the channels for each rung. **In-app and push** and **Email** deliver today. WhatsApp, SMS and Microsoft Teams are stored and shown as pending rather than silently dropped. 5. The form validates as you type. A rung that waits less than the one above it, and a named person left unchosen, are both invisible until you read the whole ladder and both produce a policy that looks saved and quietly misfires. 6. **Use for every breach at this severity** makes it the default. If another default already holds that severity, the form names the one it will displace. 7. At most ten rungs. ### Pause or remove one - **Pause** keeps the ladder and stops it being used. The card dims and is tagged. - **Remove** deletes it. The confirmation says how many escalations it has already fired, because that history goes with it. ## What it affects - **The clock starts at the breach, not at the ticket.** A ticket answered inside its target never escalates at all. "After 0m" on level one means the instant the SLA is missed. - **Acknowledging does not stop the ladder.** It moves the anchor: the next rung waits its own interval from "I have it" rather than from the breach. Otherwise acknowledging would be the cheapest way to silence a missed SLA. - **Editing a ladder takes effect immediately, including on tickets already open.** This is the opposite of the SLA screen next door, and deliberately so — an SLA is a promise and is frozen at creation; an escalation chain is an operating procedure, and a procedure fixed this morning should apply to the ticket it was fixed for. - **A rung is resolved to real people when it fires**, not when it is written. Five of the six targets are roles for exactly that reason: a ticket that escalates next month reaches whoever holds the role next month. - **A rung that resolves to nobody still fires, to the admins.** The org chart is incomplete in every real company. Skipping the rung would make the ladder quietly shorter than the one written down. - **Suspended and removed members are excluded** from every rung. Escalating to somebody who cannot open the ticket is escalating to nobody, except that it looks like it worked. - **Escalations reset when the SLA is re-stamped**, so a ticket does not resume at level three against a promise that was never broken. - Each firing appears on the ticket's timeline. ## On mobile This screen is web only. The escalations themselves arrive on the phone as push notifications for any rung whose channels include in-app. ## Limits and gotchas - The ladder chosen for a breach is the narrowest match: the default at that severity, then any policy at that severity, then the default any-severity ladder, then any any-severity ladder. No ladder at all is a real answer — the breach notifies the assignee and stops. - Only one ladder may be the default for a given severity, and turning on the default switch displaces the existing one. - WhatsApp, SMS and Teams rungs are recorded and skipped. They are offered because a support lead thinks in those terms, and hiding them would make the ladder look less capable than it is. ## Related - [SLAs](/docs/admin/sla) — the promise this ladder exists to protect. - [Customer status](/docs/admin/status) — what the customer is told while it runs. - [Support](/docs/workspace/support) — where the tickets themselves live. - [Notifications](/docs/features/notifications) — how each rung is delivered. ## Related - [SLAs](https://projectri.com/docs/admin/sla.md): Response and resolution targets per ticket severity, counted against the workspace's own working week or around the clock. - [Customer status](https://projectri.com/docs/admin/status.md): What customers are told a ticket or a task is doing, mapped from the internal status your own team works in. - [Support](https://projectri.com/docs/workspace/support.md): The internal ticket queue — raise, triage, reply to and resolve support tickets, with SLA state, escalations, work orders and a route into the knowledge base. - [Notifications](https://projectri.com/docs/features/notifications.md): What Projectri tells you about, on which of the five channels, what you can turn off, and the difference between a channel and a subscription.