An escalation starts in a Slack thread, moves to a call, and nobody can say later what was promised. Here is the model behind a tracker, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A customer escalation tracker needs four things: a severity definition that maps to a response and communication cadence, a single named owner per escalation, a timeline that captures every update and commitment, and a closure step with a follow-up. The part teams get wrong is communication cadence. Most escalations get worse not because the fix is slow but because the customer stops hearing anything while it is being worked on, and silence reads as indifference.
Escalations
5
Open escalations
2
Updates overdue
3
Commitments due
4.2 days
Median to resolution
Halden Foods, Sev 1
Raised 3 days ago · owner R. Iyer · technical lead M. Sandoval
Timeline, append only
You run customer success, support or an account team. You already know which customers are unhappy. What you want is for every escalation to have an owner, a cadence, and a record of what was promised.
What happens from the moment something goes wrong to the moment the customer agrees it is over.
Not by internal effort. Those two often point in opposite directions, and the severity sets the communication cadence.
Separate from whoever does the technical work. Shared ownership reliably means nobody sends the Friday update.
Not from the last internal activity. Teams feel busy on an escalation while the customer hears nothing, and that is how escalations escalate.
Pre-filled with what changed since the last customer communication, so the owner edits and sends instead of writing from scratch.
A date promised inside a timeline entry is a promise nothing is tracking.
Plus a root cause and a follow-up check-in. Escalations closed unilaterally reopen.
An escalation tracker is not a ticket queue with a priority field. It is four parts, and the first one drives everything else.
Each level defined by customer impact, with a required response time, an update frequency, and who must be informed. The cadence is what the severity is for.
One named person accountable for the escalation, distinct from whoever is doing the technical work. Their job is the customer relationship and the communication, and it cannot be shared.
Every internal update, every customer communication, every commitment made, with timestamps. This is what you read when the customer says you promised something in March.
A resolution record, a confirmation from the customer that they consider it resolved, and a check-in scheduled after closure. Escalations closed unilaterally reopen.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
The definition that drives every other behaviour in the app.
In this Helix project, build me a customer escalation tracker.
Start with severity, because it drives everything else. Put the levels in
a config file, and for each one define the customer impact that qualifies,
the first response time, how often the customer must hear from us, who is
notified when it is raised, and who is notified if it stays open too long.
Define severity by customer impact, never by how hard the problem is
internally. Those point in opposite directions more often than people
expect. Show the qualifying description to whoever is raising it, so they
can assess it themselves, which stops severity inflation without needing a
triage meeting.
Then the escalation itself: account, customer contact, who raised it,
description, severity, a single named owner, the technical lead, status,
and target and actual resolution dates.
Require the owner. Do not let one be created or reassigned without a named
person. Their job is the relationship and the communication, and it cannot
be shared.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.The record you reach for during a contract dispute.
Add a timeline, and make it append-only. Corrections are new entries
referencing the earlier one, never edits. An escalation timeline that can
be edited is worth nothing when it matters.
Each entry has a type: internal note, customer communication, status
change, or commitment. Status and severity changes write their own entry
automatically, with the before and after.
Then keep commitments in their own table, separate from the timeline. What
was promised, to whom, by when, owner, status. A promised date buried in a
note is a promise nothing is tracking, and the customer will remember it
even if we do not.Worth knowing. Append-only is not bureaucracy here. This is the record that gets read during a renewal argument.
Because escalations get worse in silence, not during work.
Now the part that changes outcomes.
Calculate when the next customer update is due from the severity and the
timestamp of the last customer communication. Not the last internal note.
Internal activity is not communication, and teams feel extremely busy on
an escalation while the customer hears nothing for four days.
Show that countdown on every escalation and sort the list by it, so the
most overdue update is the first thing anyone sees. Notify the owner
before it falls due and their manager once it is late.
Then build an update composer that pre-fills a draft with what has changed
since the last customer communication: status changes, commitments made or
met, and any timeline entries marked customer-relevant. The owner edits and
sends, and sending logs a customer communication.
And a daily digest to leadership: open escalations by severity, anything
overdue, anything raised in the last day.And finding the pattern across all of them.
Closure requires four things: a resolution description, a root cause from a
short editable list, confirmation that the customer agrees it is resolved,
and a follow-up check-in date. Create the follow-up automatically and
notify the owner on the day. An escalation closed without one reopens as a
surprise.
Then report: escalations by account, root cause, severity and month. Time
to first response and to resolution against the targets in the severity
config. Repeat accounts and repeat root causes, which are the two lists
worth taking into a product or operations review.
And correlate open and recent escalations with renewal dates. An account
escalating three months before renewal is a commercial risk, not just a
support one, and nobody looks at those two facts together.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Salesforce>. Link the escalation to the account and its renewal date,
which is what makes it a commercial risk and not just a support one.
<Zendesk>. Pull the tickets behind the escalation so the timeline starts
from a record.
<Gmail>. Send the customer update, and log the send as a communication
that resets the clock.
<Slack>. Reach the owner before an update falls due, and their manager
once it is late.
<Okta>. Read the group that separates the account team from everyone else,
since the internal timeline is written far more bluntly than anything the
customer sees.
<PagerDuty>. Wake somebody for a severity one raised out of hours, which
email will not.
<Jira>. Link the escalation to the engineering work behind it and read
status back.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Internal notes on an escalation are franker than anything the customer sees, so set Access Control before sharing to keep that separation reliable.
An escalation is a communication problem, so most of what this connects to is about reaching people.
Salesforce
Link the escalation to the account and its renewal date, which is what makes it a commercial risk and not just a support one.
Zendesk
Pull the tickets behind the escalation so the timeline starts from a record.
Gmail
Send the customer update, and log the send as a communication that resets the clock.
Slack
Reach the owner before an update falls due, and their manager once it is late.
Okta
Read the group that separates the account team from everyone else, since the internal timeline is written far more bluntly than anything the customer sees.
PagerDuty
Wake somebody for a severity one raised out of hours, which email will not.
Jira
Link the escalation to the engineering work behind it and read status back.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working tracker. It holds a candid internal record about unhappy customers and drives communication with them, so how it is run matters.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Internal notes on an escalation are frank in a way customer-facing updates are not. SSO plus scoped visibility on each timeline entry is what keeps that separation reliable.
App Security
Linking escalations to accounts, tickets and renewal dates needs real access to those systems. Granting it to the app rather than pasting keys into it means credentials can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It gives each escalation a severity, a single named owner, a required communication cadence, a timeline of everything said and promised, and a closure step with a follow-up. It is a communication discipline more than a work queue.
By customer impact, with the qualifying description visible to whoever raises it, and with a required response time and update frequency attached to each level. Severity defined by internal effort points the wrong way, because the hardest problems are not always the most damaging.
Silence. Most escalations deteriorate while work is happening but nothing is being communicated. Deriving the next-update countdown from the last customer communication rather than the last internal activity is the fix.
One named person, separate from whoever does the technical work. Their job is the relationship and the communication. Shared ownership on an escalation reliably means nobody sends the Friday update.
Because a promised date written inside a note is not tracked by anything. Commitments need their own record with an owner, a due date and a status, or you will discover you missed one when the customer reminds you.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The judgement call is your severity definitions and their cadences, and getting those right matters more than anything in the code.
Customer Success
Build a health score from signals that actually predict renewal, show the trend rather than the number, and turn a red account into a named action. Prompts to build it, and what it takes to run it.
Customer Success
Volume, resolution and satisfaction in one view, split by what customers actually contacted you about, with NPS or CSAT joined to the ticket that caused it. Prompts to build it, and what it takes to run it.
IT and Operations
Record incidents with a consistent timeline, run postmortems to a fixed template, and track the action items until they are actually done. Prompts to build it, and what it takes to run it.
Customer Success
Work renewals from the notice date backwards, with a stage for each step, an owner, and a forecast leadership can trust. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.