Step 1 — Pull the open queue
Read every open, unresolved ticket in Plain. This is a fresh session every
run, so pull the full current state of the queue — don't rely on which
tickets escalated last sweep, since a ticket's SLA clock, account, and
severity can all change between checks.
Step 2 — Check each ticket against the three criteria
| Criteria |
Signal |
Source |
| SLA breach |
First-response or resolution timer has passed the target for the ticket's tier |
Ticket timestamps in Plain vs. {{sla_targets}} |
| VIP account |
The ticket's account name or domain matches the VIP list |
Plain customer/account field vs. {{vip_accounts}} |
| High severity |
The ticket describes an outage, data loss, a security issue, or something blocking a paying customer's core workflow |
Plain tags and ticket body |
Any single match qualifies the ticket for escalation. A ticket can match more
than one criterion — carry every matching reason into Step 5, don't collapse
to just one.
Step 3 — Route to the right team
Tag or assign the qualifying ticket to the team that owns it:
| Ticket is about |
Route to |
| A payment, invoice, or billing dispute |
Billing / Finance |
| A security or data-handling concern |
Security |
| An outage, bug, or product defect |
Engineering (continue to Step 4) |
| A VIP account issue with no technical fault (relationship, contract, expectations) |
Customer Success / Account team |
This tag-or-assign update is the only write the agent makes to the ticket
itself. It is never a status change, and it never closes or resolves the
ticket.
Step 4 — Open a linked Linear issue when engineering is needed
Only for tickets routed to Engineering in Step 3 (outage, bug, product
defect). Before filing, check the ticket for an existing linked issue — never
open a duplicate for the same ticket.
Create the issue in {{linear_team}}:
- Title — a short, specific summary of the reported problem.
- Description — the account, the escalation reason(s) from Step 2, the
relevant details or repro steps from the ticket, and a link back to the
Plain ticket.
- Priority — Urgent for an active outage, data loss, or an already
SLA-breached ticket; High for a VIP account with a real bug; Normal
otherwise, and let the engineering team triage from there.
Attach the created issue's URL back onto the Plain ticket as an internal note
so the two records are linked in both directions.
Step 5 — Post the alert
Post one message per qualifying ticket to {{escalation_channel}}: the
ticket link, the account name, every escalation reason that matched (SLA
breach / VIP / severity), the team it was routed to, and the linked Linear
issue URL if Step 4 created one.
Step 6 — Stop
One pass over the current queue is one run. There is no ledger — the next
sweep, 15 minutes later, re-reads the queue's state at that point and starts
over.
1---2name: escalation-routing3description: The 15-minute escalation-routing runbook for the Plain support queue — detecting SLA breaches against {{sla_targets}}, VIP accounts in {{vip_accounts}}, and high severity, routing each qualifying ticket to the right team, opening a linked issue in {{linear_team}} when engineering is needed, and posting the alert to {{escalation_channel}}. Never closes a ticket or promises a resolution.4---56<skill name="escalation-routing">78<overview>9Every open ticket in the Plain queue gets checked, every 15 minutes, against10three independent escalation criteria: an SLA breach, a VIP account, or high11severity. A qualifying ticket is routed to the right internal team, gets a12linked Linear issue when it's an engineering problem, and generates one alert13in the escalation Slack channel. A scheduled sweep spawns a fresh session with14scoped read/route access to Plain, write access to Linear, and post access to15Slack; this skill is the standard the routing is done to, so the agent doesn't16reinvent SLA math or severity judgment on every run. Nothing customer-facing17ever comes out of this skill — routing, a linked issue, and an internal alert18are the entire output.19</overview>2021<when-to-load>22- The 15-minute escalation sweep fires.23- A human asks why a ticket did or didn't escalate.24- A human asks the agent to re-check the queue on demand.25</when-to-load>2627<workflow>2829## Step 1 — Pull the open queue3031Read every open, unresolved ticket in Plain. This is a fresh session every32run, so pull the full current state of the queue — don't rely on which33tickets escalated last sweep, since a ticket's SLA clock, account, and34severity can all change between checks.3536## Step 2 — Check each ticket against the three criteria3738| Criteria | Signal | Source |39|---|---|---|40| SLA breach | First-response or resolution timer has passed the target for the ticket's tier | Ticket timestamps in Plain vs. {{sla_targets}} |41| VIP account | The ticket's account name or domain matches the VIP list | Plain customer/account field vs. {{vip_accounts}} |42| High severity | The ticket describes an outage, data loss, a security issue, or something blocking a paying customer's core workflow | Plain tags and ticket body |4344Any single match qualifies the ticket for escalation. A ticket can match more45than one criterion — carry every matching reason into Step 5, don't collapse46to just one.4748## Step 3 — Route to the right team4950Tag or assign the qualifying ticket to the team that owns it:5152| Ticket is about | Route to |53|---|---|54| A payment, invoice, or billing dispute | Billing / Finance |55| A security or data-handling concern | Security |56| An outage, bug, or product defect | Engineering (continue to Step 4) |57| A VIP account issue with no technical fault (relationship, contract, expectations) | Customer Success / Account team |5859This tag-or-assign update is the only write the agent makes to the ticket60itself. It is never a status change, and it never closes or resolves the61ticket.6263## Step 4 — Open a linked Linear issue when engineering is needed6465Only for tickets routed to Engineering in Step 3 (outage, bug, product66defect). Before filing, check the ticket for an existing linked issue — never67open a duplicate for the same ticket.6869Create the issue in **{{linear_team}}**:7071- **Title** — a short, specific summary of the reported problem.72- **Description** — the account, the escalation reason(s) from Step 2, the73 relevant details or repro steps from the ticket, and a link back to the74 Plain ticket.75- **Priority** — Urgent for an active outage, data loss, or an already76 SLA-breached ticket; High for a VIP account with a real bug; Normal77 otherwise, and let the engineering team triage from there.7879Attach the created issue's URL back onto the Plain ticket as an internal note80so the two records are linked in both directions.8182## Step 5 — Post the alert8384Post one message per qualifying ticket to **{{escalation_channel}}**: the85ticket link, the account name, every escalation reason that matched (SLA86breach / VIP / severity), the team it was routed to, and the linked Linear87issue URL if Step 4 created one.8889## Step 6 — Stop9091One pass over the current queue is one run. There is no ledger — the next92sweep, 15 minutes later, re-reads the queue's state at that point and starts93over.9495</workflow>9697<guardrails>98- **Route and alert, never resolve.** The agent tags, assigns, opens a linked99 issue, and posts an alert. It never closes a ticket, marks one resolved, or100 changes its status in a way that ends the customer's case.101- **No promises to the customer.** The agent never drafts or sends anything102 the customer can see, and never states or implies a resolution timeline.103 Every output is internal — the routing tag, the linked issue, and the104 escalation channel post.105- **One linked issue per engineering escalation.** Check for an existing link106 before filing; never open a duplicate for the same ticket.107- **Scoped secrets.** The Plain API key is injected at runtime; the Linear108 connector is brokered server-side. No raw credential is ever pasted into chat.109- **Fresh, no memory between runs.** Plain's current queue state is the single110 source of truth each sweep — nothing from a prior run is assumed to still111 hold.112</guardrails>113114</skill>
kortix-ai