Support · Escalations
Escalations that do not go quiet after the handoff
The customer's question is not what the bug is. It is whether anyone is still looking at it.
What the worker does
Escalation tracking in Polaris means an escalation workstream where each customer issue is a task, linked to the engineering issue in Linear or GitHub. An AI worker posts a daily status comment: what moved, what has had no update past your threshold, and who is waiting on a reply. Support decides what to promise the customer; the worker makes sure nothing goes silent.
- Connections
- Linear · GitHub · Slack
- Cadence
- Daily status comment
- Lives in
- One escalation workstream, Focus-pinned
The handoff is where trust is lost
A support agent escalates a bug, engineering picks it up, and the thread ends. Two weeks later the customer asks for an update and the honest answer is that nobody knows. Not because anyone is hiding anything, but because the escalation existed in a Slack thread that scrolled away.
The fix is boring and it works: every escalation is a task, in one workstream, with a customer attached and a status somebody is responsible for refreshing every day.
What the daily comment says
Moved
Escalations where the linked engineering issue changed state, with what it changed to.
Silent
Escalations with no update longer than your threshold, named with the number of days and the engineer who owns them.
Waiting on us
Issues resolved in engineering where nobody has told the customer yet, which is the most embarrassing category and the easiest to fix.
Ageing
Open escalations sorted by how long the customer has been waiting rather than by severity, because those are different lists.
Two ways an escalation ends
In a chat thread
- Reported once, discussed for an afternoon
- No owner after the discussion
- Status is whatever the last message said
- The customer chases you for it
As a tracked task
- One task per customer issue, linked to the engineering issue
- An owner and a date, like all work in Polaris
- A daily status comment from the worker
- Nothing resolved in engineering stays untold
Questions people ask
+Does this replace our issue tracker?
No. Linear and GitHub are both connections, and the engineering issue stays where engineers work. The escalation task in Polaris is the customer-facing side of it: who is waiting, what they were told, and when.
+Can the worker update the engineering issue?
Its deliverable is a status comment for a person to act on. Changing state in an issue tracker is a decision an engineer or a support lead makes, and Polaris keeps that boundary.
+What threshold should we use for silent?
Start with two working days and adjust in the skill file once you see how noisy that is. The threshold is a line in a document, so tuning it takes a minute and leaves a history.
+How do we see the history of one escalation?
It is a task, so the comments, the deliveries and the activity feed hold the whole record in one place, including which person closed it and how the delivery was rated.
Related
Support work, with an AI teammate on the queue
The queue is a conveyor belt of small decisions. Sorting them is mechanical; making them is not.
Ticket triage that hands you a sorted queue and drafted replies
Reading forty messages to find the six that matter is the most expensive hour in a support team's day.
Forty new issues on Monday, half of them the same bug
Every new issue checked for duplicates, version and repro before an engineer opens it.
Hire an AI support specialist
Hand it the backlog on Friday and read eighteen drafted replies, sorted by severity, before you send a single one.
Connect Linear to Polaris
A Linear API key carries one person's visibility, so the account you make it on decides what every worker can see.
Connect Slack to Polaris
Six scopes, no access to direct messages, and a bot that only reads the channels somebody invited it into.
Focus lane
A commitment for a horizon, not a filter over everything you have.