# How we get urgent support tickets to the right team

Every 15 minutes a Machine agent checks Plain for SLA breaches, VIP accounts and severe tickets, routes each one, links a Linear issue when engineers are needed and posts to Slack. It never closes tickets.

Canonical page: https://themachine.myapps.ai/use-cases/escalation-manager

The ticket that should skip the queue rarely looks special at first glance. You
only spot it when you read carefully: the SLA timer with minutes left, the
sender who turns out to be one of our largest customers, the "small bug" that is
really the whole product being down. On a hectic day, those tickets wait their
turn in arrival order like everything else. And whoever is meant to spot and
route them is busy answering the queue themselves.

So we run an escalation agent on Machine. Every 15 minutes it looks through the
Plain queue, picks out the tickets that match our escalation rules, hands each
to the internal team that owns it, files a connected Linear issue if engineers
need to get involved, and posts the lot to our escalation channel in Slack.
Routing, linking and flagging is the whole job. Closing tickets is not part of
it, and neither is telling a customer how or by when their problem gets fixed.

- **Team:** Machine
- **Runs on:** A check every 15 minutes
- **Connected systems:** Plain · Linear · Slack
- **Mode:** Sorts and flags · closing stays with people

## The problem

Tickets that deserve escalating do not wave a flag. Spotting an SLA breach
means someone actually comparing timestamps. Knowing an account is a VIP means
looking it up in a sheet or your CRM, because the ticket will not tell you.
Judging severity means reading what the customer wrote, not just glancing at the
tags. Any one of these slips by easily when the inbox moves so quickly that
nearly everything is answered first come, first served.

The usual safety net is a teammate who glances over the queue now and then for
anything alarming, while also working through their own tickets. That holds up
until the day gets busy. Then the ticket about to breach its SLA and the VIP's
ticket sit behind ten routine questions, and a bug report that should be a
Linear issue by now is still a few lines in a support conversation no engineer
has opened.

## What we built

Every 15 minutes, a cron job on Machine starts a new agent **session**: a fresh
cloud computer (a sandbox) for that run alone. The agent reads the Plain queue
as it is right now and tests every open ticket against three rules: has it
breached its SLA, is it a VIP account, is it high severity. Anything that passes
a rule goes to whichever internal team owns it. If engineers are needed, the
agent also files a Linear issue tied to the ticket. Then it drops one Slack
message per escalation into the escalation channel, giving the reason, the team
and the issue link. It does not close tickets, and it does not say a word to the
customer.

## How it works

### Start fresh every 15 minutes

A **cron trigger** goes off every 15 minutes, and each time a new **session**
starts with no recollection of the previous run. The agent checks the whole open
queue against Plain as it is now, instead of relying on what it decided a
quarter of an hour ago. No state is carried over, so stale notes can never cause
a miss.

### Write down your escalation rules

What counts as an escalation is kept as a **skill**, the playbook the agent
follows. It holds the SLA target for each severity level, the accounts we treat
as VIPs, where the high-severity line sits, and a lookup that maps each kind of
ticket to its owning team. Tighten an SLA or name a new VIP, edit the skill, and
the very next check picks it up.

### Connect the queue, the tracker and the channel

**Connectors** and **secrets** give the agent scoped access to your tools. The
keys are handled on our servers, so the model never holds a raw credential.
With them the agent:

- **Sorts the Plain queue**: fetches every open ticket, looks at SLA clocks and
account details, and tags or assigns the ones that qualify to the internal
team that owns them. Closing or resolving a ticket is not something it can do.
- **Ties in Linear**: if a ticket calls for engineering, it creates an issue on
that team's board carrying the ticket's background, then cross-links ticket
and issue so either one leads to the other.
- **Flags it in Slack**: one message per escalation in the escalation channel,
naming the ticket, why it was escalated, which team now has it, and the Linear
link if there is one.

### Draw the lines it cannot cross

In Plain the agent can **route, not resolve**. Tagging and assigning a ticket
are allowed. Closing one or marking it resolved is not. It never writes to the
customer or sends them anything, and it never states or hints at when a fix
will arrive. Its output is three things only: the routing change in Plain, the
Linear issue tied to the ticket and the Slack message.

### Route it, link it, flag it

Once this runs, the queue is checked every 15 minutes against the live SLA
clock, the latest VIP list and how severe each open ticket is right now. Any
ticket that passes a rule lands with its owning team, picks up a Linear issue if
engineers should see it, and shows up in the escalation channel along with why.
What happens next is up to your team.

> **The pattern**
> Every 15 minutes a **cron** opens a fresh session that checks the Plain queue
> against SLA targets, VIP names and a severity line, all set in a **skill**.
> Qualifying tickets get routed, engineering ones get a **linked Linear issue**,
> and Slack hears about each. Tickets stay open, and customers are promised
> nothing.

## Guardrails

This agent can make changes in both the support inbox and the engineering
tracker, so we fence its powers in at sorting and flagging:

- **Isolation.** Each run happens in a private sandbox. The session can reach Plain, Linear and the escalation Slack channel, and nothing beyond them.
- **Scoped secrets.** Our Plain key sits encrypted in the **Secrets Manager**
  until a run begins, when it is passed into the sandbox. Linear goes through a
  connector on our servers. Every secret is only handed to the agents you grant
  it to.
- **Routing only, never resolving.** Tagging, assigning and filing a tied Linear
  issue are all it can do. Closing a ticket, marking it resolved or anything
  else that ends the customer's case is beyond it.
- **Nothing promised to customers.** It never writes or sends a message the
  customer will see, and it never names a fix date. All of its output stays
  inside the company: a routing tag, a Linear issue and a Slack message.
- **Everything is code.** SLA targets, VIP names, the severity line and the
  team lookup all live as files in the repo, kept in version control. Changing
  them takes a reviewed **change request**, not a dashboard setting.

## The outcome

- **Every 15 min:** Every open ticket checked against the live SLA clock
- **0 closures:** It sorts and flags, and tickets stay open for people to close
- **1 linked issue:** For each engineering escalation, traceable both ways

Urgent tickets used to wait in line until somebody happened to notice them.
Now they are spotted within 15 minutes of crossing a line, sent to their owners
and, when engineers are needed, already tied to a Linear issue without anyone
asking. The agent sorts, links and flags. How each ticket gets solved is still
your team's call.