Customer support

The escalation list, written before you get in

Every weekday morning, a cited list of the escalated cases that have gone quiet: how long each has waited, what it needs, and which ticket is holding it up.

Join the waitlist See what it produces

Escalation watch

Watch your escalations

Who it is for: A support lead who runs a morning escalation review, and the ops lead who owns the board those cases are stuck on.
What starts it: Weekdays at 08:30 in your workspace's time zone, one document per morning; On a schedule

Turn it on in Aestus

An escalation is rarely waiting on the support team. It is waiting on a ticket somewhere else — and that ticket is on a board the support lead does not open, owned by someone who has not been asked, sitting in a column nobody has looked at since Tuesday. So the morning review becomes an archaeology exercise: open the queue, open the chat, open the board, and try to work out which of these twelve cases is actually about to become a phone call.

Aestus reads both halves, because it already holds both. This use case writes one document every weekday morning: the escalated cases that have gone quiet, ordered by the one closest to being dropped, each with how long it has been ignored, who owns it, what it needs next, and the ticket that has to move first — with its own column and its own age beside it.

The part that decides whether it is worth opening is what it leaves out. Being escalated puts a case under watch; it does not put it on the page. A case reaches the list only when it has gone quiet for long enough by the same rule the rest of the product uses, so a case somebody replied to this morning is counted and never listed. Weekend days are not counted at all, which is why a Monday list is not two days of false alarms. And a ticket with nothing recorded against it is never reported as overdue, because inventing an alarm out of missing data is how people learn to close a report unread.

Every number comes from the same place. The list is computed before the model is asked to write anything, and each figure is checked against that list afterwards; a wait time the model produced on its own fails the run rather than reaching the person who is about to reply to the customer. Names work the same way: a case with nobody accountable says "no owner", never a plausible guess.

It changes nothing it reads. The model that writes the watch has no tools at all, so an instruction typed into a ticket by a frustrated customer has nothing to reach. The only thing that leaves Aestus is one message to one channel you choose, behind the same approval step every external send goes through. A ticket owned by a team you cannot see is left out of the list and counted in a number the document prints, so the list is never quietly shorter than it looks.

What you get

The artifact this use case produces, in the product view you would read it in.

Example — fictional team and data. Not a live run or customer result.

Worked example

document

Escalation watch — Friday 11 September 2026

Produced by: Run NW-RUN-3312 · read-only · document artifact · demo values

Needs an answer today: NW-830 has been silent for 105 working hours in Triage and still has nobody accountable for it. Overdue means 72 counted weekday hours of silence — the same rule the rest of Aestus grades a waiting ticket by, so a case that is overdue here is overdue in the standup too.
Nobody is on this: NW-812 has been silent for 105 working hours and has sat in Waiting on engineering for 345. Two clocks, graded on one ladder: "nobody has touched it" and "it has not moved" are different questions, and the worse answer is the one reported.
Blocked on us: NW-812 is held up by PLAT-204, which has been in In Review for 465 working hours. This is the half a support desk cannot see: the blocking ticket, its column and its own age, on the line with the case.
No owner: NW-830 needs an owner. What a case needs is chosen from a fixed set, never written as free text, so the column a reader acts on is never a sentence a model composed.
Waiting on you: NW-812 — the cases the reader personally owns, already written out with a source on each line. Everything else on the list belongs to somebody else and says whose.
Sources: One numbered row per ticket behind the lines above. The headline also states that 2 escalations are under watch and moving and that 2 were withheld from a team this reader cannot see, so 2 overdue reads as good news rather than as a report that lost half its rows.

How it runs

Each step is one node in the workflow graph the interpreter runs. Nothing here is a prompt chain hidden in a route handler.

Workflow steps

01It reads the whole board
Every open ticket, not just the ones on a queue: an escalation is usually waiting on a ticket somewhere else, and a dependency the read cannot see would look like nothing blocking it.
02It decides what is overdue in code
Each case is graded against the same staleness rule the rest of Aestus uses. Weekend days do not count. A case somebody answered this morning is counted and not listed.
03It writes the list
One model call, no tools, working only from the computed roster: the cases that need an answer today, the ones nobody is on, the ones blocked on us, and the ones with no owner.
04It checks itself before anyone sees it
A review step rejects the draft if any number is not in the roster, any line is uncited, or any person named is not an owner. One repair attempt, then the run fails rather than publishing a guess.
05It files the document and links to it
The watch is saved on that day's watch ticket and you are notified. If you named a channel and approved the send, a short version goes to Slack.

By hand, and on Aestus

The same job, on either side.

By hand
Sort the queue by oldest and hope the sort matches the promise you made.
On Aestus
Ordered by the case closest to being dropped, on the same rule the rest of the product uses.
By hand
A case that sat over the weekend looks three days old.
On Aestus
Weekend days are not counted, so a Monday list is not two days of false alarms.
By hand
Ask engineering, in chat, whether the blocking ticket moved.
On Aestus
The blocking ticket, its column and its own age sit on the line with the case.
By hand
Discover at five o'clock that a case had no owner all day.
On Aestus
"No owner" is stated on the line, never guessed into a name.
By hand
Re-type the list into your standup notes.
On Aestus
The "waiting on you" list is already written, with a source on every line.
By hand
Trust a number because it was in yesterday's message.
On Aestus
Every number is checked against the computed list before the document is published. A number that is not there fails the run.

What Aestus records

Every run is auditable after the fact, which is what makes handing the job over survivable.

The run
Cost, tokens, duration and whether the review step passed, on the same ledger as every other run in the workspace.
The document
Each morning's watch is a document on that day's watch ticket, with its own revision history. Closing the ticket records the morning as dealt with.
What it read
The run records the date, how many cases were overdue, how many were under watch and moving, and how many were withheld — so a quiet list can be told apart from a broken one.

What it connects to

Only the tools this workflow actually uses. Each one has a setup guide.

slackOptional

Questions teams ask

Does this need Zendesk?

No, and it does not read one. It reads the escalations as they exist on your Aestus board, including issues synced from Linear and Jira. A direct Zendesk or Intercom read is not connected yet.

Where do the clocks come from?

From the same staleness rule every other Aestus report uses, applied to your workspace. The document says so on every run. It is not a support desk service-level policy, and it never calls a case a breach of one.

Will it be a daily list of things that are fine?

No. Being escalated puts a case under watch; only going quiet for long enough puts it on the page. The headline says how many escalations are under watch and moving, so a short list reads as good news rather than as a broken report.

Will it post to Slack on its own?

Only to a channel you name, and only after an approval step. Without that approval the watch stays in Aestus as a document and a notification.

Can it see work my team cannot?

No. A ticket owned by a team you cannot see is left out of the list entirely and counted in a number the document states, so the list is never quietly shorter than it looks.

All use cases How access is governed

Sources

docs/runbooks/use-case-workflows.md

Hand over Watch your escalations.

Tell us how your team does this today and we will set it up with you.

Talk to us

Questions teams ask

Does this need Zendesk?

No, and it does not read one. It reads the escalations as they exist on your Aestus board, including issues synced from Linear and Jira. A direct Zendesk or Intercom read is not connected yet.

Where do the clocks come from?

Will it be a daily list of things that are fine?

Will it post to Slack on its own?

Only to a channel you name, and only after an approval step. Without that approval the watch stays in Aestus as a document and a notification.

Can it see work my team cannot?

No. A ticket owned by a team you cannot see is left out of the list entirely and counted in a number the document states, so the list is never quietly shorter than it looks.

Sources

docs/runbooks/use-case-workflows.md

The escalation list, written before you get in

Watch your escalations

What you get

Escalation watch — Friday 11 September 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The document

What it read

What it connects to

Questions teams ask

Other use cases

Hand over Watch your escalations.

The escalation list, written before you get in

Watch your escalations

What you get

Escalation watch — Friday 11 September 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The document

What it read

What it connects to

Questions teams ask

Other use cases

Hand over Watch your escalations.