Customer support

Every ticket arrives with the answer you already gave

Each morning the tickets waiting in your triage inbox get an owner, a priority and labels — copied from the ticket your team already resolved.

Join the waitlist See what it produces

Support triage

Triage the support queue

Who it is for: The support lead who works the same inbox every morning and knows somebody already answered half of it.
What starts it: Every weekday morning in your workspace's time zone, and on demand from the catalog; On a schedule

Turn it on in Aestus

A support inbox is not hard because the tickets are hard. It is hard because most of them have been answered before, by somebody who is now busy answering another one, and the only place that answer lives is a closed ticket nobody thinks to search. So every morning starts with the same work: read it cold, wonder whether this is the export bug from July, guess who would know.

This use case does one narrow thing with that. It reads the tickets waiting in a project's triage inbox, finds the resolved ticket each arrival actually matches, and fills the card in from it — the person who resolved that ticket, the priority it was closed at, the labels it carried. Nothing is inferred from the wording of the new ticket. Every decision is a copy of something your team already did, and the document names the ticket it was copied from.

The interesting question is not how it decides. It is what it does when it cannot. Triage is deciding, and a wrong decision here lands silently on a colleague's plate: they lose a day on the wrong area, the customer loses that day waiting, and nobody finds out until somebody looks. So the bar for acting is high and the bar for declining is low. A resolved ticket only becomes a candidate when the two tickets visibly share something a person could go and check — the same label, or the same run of words repeated between them — and that shared thing is printed in the document beside the decision. A ticket with no candidate is left exactly as it arrived and listed under "Could not tell" with what was missing. An undecided card costs you one glance at something you were going to open anyway.

Nothing this run does hands work to anybody. A decided ticket stays in the triage inbox, which is intake rather than board work: it appears in no board, no filter and no count until a person accepts it. The run fills the card in and stops there. The three things it changes — who owns it, how urgent it is, what it is labelled — are the three things a person would have set by hand, and each one is recorded against the run that made it.

Repeating is the other way a tool like this goes wrong. A second pass that re-decides yesterday's tickets would quietly revert whatever you corrected in between, and you would have no way to see it happen. So every decided ticket is marked with a label you choose, and the next run excludes every ticket carrying it before the model sees anything at all. Taking the label off is how you ask for a second opinion. A ticket it could not decide is deliberately left unmarked, so a later run can try again once your team has resolved something like it.

The tenancy rule does real work here, and in an unusual direction. A ticket owned by a team you are not in is dropped from the queue entirely and counted, never named — and so is a resolved ticket on such a team, because a precedent is printed in the document as the reason a colleague was given work. Every count in the document is stated as a minimum whenever anything was withheld.

What it does not see is stated plainly, in the catalog, in the settings and in the document's own first section: there is no support-desk connection in this product. A conversation that never became an Aestus ticket is not in the queue, and no page here will imply otherwise.

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

Support triage — 11 September 2026

Produced by: Run EXAMPLE-ST-01 · triage inbox · document on the day's review ticket · demo values

Scope: 6 tickets were waiting in this project's triage inbox: 2 an earlier run had already decided, 1 on a team this reader cannot see, and 3 for this run. Resolved tickets were read 180 days back, and 2 of them had a person on them — one more was closed by an agent, which can never be an owner, so it is not a candidate. No support desk is connected: this queue is Aestus tickets, and a conversation that never became one is not in it. Because a ticket was hidden, every count here is a minimum.
Routed: 2 of the 3 tickets matched something this team had already resolved, each one a row with Ticket, Owner, Priority, Labels added, Resolved ticket and What they share. SUP-4182 went to the person who closed SUP-3907 at priority 3, and the row prints why: the two tickets share the exports label. Computed from the tickets, not asserted — so you can open both and disagree.
Could not tell: 1 ticket was left alone, with the reason printed: nothing this workspace has resolved matches it, so there is no owner to name and no priority to copy. It is still in the triage inbox exactly as it arrived. A section that only ever reported what it found would read as complete; this one says what it could not tell.
What this run changed: Only what the tool results show: 2 tickets given an owner, a priority and their labels, and any write the tool refused with the reason it gave. Then the sentence that makes the rest of it safe to run every morning — no ticket was accepted out of the triage inbox, moved, closed, retitled or re-described by this run. Each decided ticket also carries the label you chose, which is how tomorrow's run knows not to undo what you corrected today.

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 one project's triage inbox
The tickets waiting to be accepted in the Aestus project you name. It reads no support desk: the queue has to be arriving as Aestus tickets already, and triage is a per-team setting, so a team that has not turned it on has no inbox to read.
02The server finds the tickets you already resolved
Closed tickets in the same project, inside the window you set. A resolved ticket becomes a candidate for an arrival only when the two visibly share something — the same label, or the same run of words — and the shared thing is printed so you can check it.
03A model picks among candidates, or declines
It chooses one of the candidates the server offered, or answers that it could not tell. It is never asked to decide that two tickets are related, because that is the judgement this cannot afford to get wrong.
04A check reads the plan before anything is written
Every id has to appear in what the run was given, the owner has to be the person who resolved that ticket, and the priority has to be that ticket's priority. On a second failure the run fails and the inbox is exactly as it was.
05It fills the cards in and stops
One write per decided ticket: owner, priority, labels. Nothing is accepted out of the inbox, moved, closed or rewritten. The document is written; the Slack post waits for a person.

By hand, and on Aestus

The same job, on either side.

By hand
You open every new ticket cold.
On Aestus
The card already names an owner, a priority and the ticket they came from.
By hand
You search old tickets for "have we seen this".
On Aestus
The closest resolved ticket is named, with the label or the exact words the two share.
By hand
You guess who knows this area.
On Aestus
The owner is the person who resolved that ticket, and nobody else is ever proposed.
By hand
An AI guesses confidently and a colleague loses a day.
On Aestus
A ticket with no match is left exactly as it arrived and listed under "Could not tell".
By hand
Work lands in somebody's queue before a person has looked at it.
On Aestus
Nothing leaves the triage inbox: a person still accepts every ticket.
By hand
A second pass overwrites the corrections you made after the first.
On Aestus
A decided ticket carries a label, and the next run skips every ticket carrying it.

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 check passed, on the same ledger as every other run in the workspace.
The document
Each morning's document is an artifact on that day's review ticket, with its own revision history, so last week's can still be reopened.
The card changes
The owner, the priority and the labels on each decided ticket, each one recorded against the run that made it.
What it would not decide
Every ticket it left alone, with what the evidence did not say, so a gap has a reason rather than a silence.

What it connects to

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

slackOptional

Questions teams ask

Where do the tickets come from?

An Aestus project's triage inbox — the intake list a team turns on to review work arriving from outside it. This use case does not read Zendesk, Intercom, Freshdesk or a shared mailbox; there is no connection to one, and the document says so in its first section. If your queue is not arriving as Aestus tickets yet, this has nothing to read.

What stops it routing a ticket to the wrong person?

There is only one thing it is allowed to do: copy a ticket your team already resolved. The server picks the candidates, and only when the two tickets share a label or repeat the same run of words. The owner is that ticket's owner exactly — a different name, however sensible, is refused before anything is written.

What happens when nothing matches?

The ticket is left exactly as it arrived — no owner, no priority, no label — and listed under "Could not tell" with what the evidence did not say. An honest "I could not tell" costs you one glance at a card you were going to open anyway. A confident wrong answer costs the person it lands on a day.

Does it hand work to my team on its own?

No. A decided ticket stays in the triage inbox, which is not board work and shows up in nobody's queue. A person still accepts it. The run fills the card in; it does not hand the work over.

Will it undo a correction I make?

No. Every ticket it decides is marked with a label you choose, and the next run skips every ticket carrying that label. If you want a ticket looked at again, take the label off.

All use cases How access is governed

Sources

Triage — "the process of determining the priority of patients' treatments by the severity of their condition". https://en.wikipedia.org/wiki/Triage (read 2026-09-12)
Precedent — a decision that "establishes a principle or rule" later cases are decided by. https://en.wikipedia.org/wiki/Precedent (read 2026-09-12)
Google SRE, Being On-Call — on the cost of alerts and queues people learn to skim. https://sre.google/sre-book/being-on-call/ (read 2026-09-12)

Hand over Triage the support queue.

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

Talk to us

Questions teams ask

Where do the tickets come from?

What stops it routing a ticket to the wrong person?

What happens when nothing matches?

Does it hand work to my team on its own?

No. A decided ticket stays in the triage inbox, which is not board work and shows up in nobody's queue. A person still accepts it. The run fills the card in; it does not hand the work over.

Will it undo a correction I make?

No. Every ticket it decides is marked with a label you choose, and the next run skips every ticket carrying that label. If you want a ticket looked at again, take the label off.

Sources

Triage — "the process of determining the priority of patients' treatments by the severity of their condition". https://en.wikipedia.org/wiki/Triage (read 2026-09-12)

Precedent — a decision that "establishes a principle or rule" later cases are decided by. https://en.wikipedia.org/wiki/Precedent (read 2026-09-12)

Google SRE, Being On-Call — on the cost of alerts and queues people learn to skim. https://sre.google/sre-book/being-on-call/ (read 2026-09-12)

Every ticket arrives with the answer you already gave

Triage the support queue

What you get

Support triage — 11 September 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The document

The card changes

What it would not decide

What it connects to

Questions teams ask

Other use cases

Hand over Triage the support queue.

Every ticket arrives with the answer you already gave

Triage the support queue

What you get

Support triage — 11 September 2026

How it runs

By hand, and on Aestus

What Aestus records

The run

The document

The card changes

What it would not decide

What it connects to

Questions teams ask

Other use cases

Hand over Triage the support queue.