Somewhere in your company, your product and engineering team is looking at a list of forty bugs and deciding which ones don't happen this quarter.
Your escalation is item nineteen.
That's why saying "the customer is furious" and "this is critical" won't help you. The list is full of unhappy customers. Telling someone how angry they are gives them no way to compare your request with the other thirty-nine.
Bug trackers often split that decision in two. Severity asks how broken the thing is, and someone answers that by looking at the system. Priority asks when it should get fixed, and that's decided in triage by product, because it depends on what else is shipping and what your company has promised whom.
You don't set either one. Both depend on information that comes from you. And priority isn't fixed once it's set. A bug moves up the queue when someone discovers it's affecting an enterprise account, or that the workaround everyone relied on has stopped working. You're usually the only person who knows either of those things.
A strong escalation proactively answers four questions before anyone has to ask them:
- How many customers does this affect, and what is it costing them?
- Has anyone reported this already?
- Can someone confirm it without starting over?
- What's the smallest thing that would help the customer this week?
Answer all four in the document, and nobody has to come back to you. Leave one open, and your escalation sits until someone has time to follow up on it.
TL;DR
- Words like "critical" and "ASAP" don't move anything. Use them enough and people stop believing you, including on the one that was real.
- One account shows the problem happened once. Four accounts with the same bug makes a much stronger case, and it usually takes an hour or two to find them.
- Nobody acts on your opinion of how bad it is. They act on your steps to reproduce it, your timestamps, your account IDs, and a clear sentence about what the customer can't do anymore.
- Ask for the smallest thing that helps. Someone can approve two days of investigation this week. "Fix this" sounds like months, so it goes to the bottom.
- Silence usually means it went to the wrong person, not that someone turned you down. When people say no, they say it fast.
Show it's happening to more than one customer
A bug that hits one customer ranks below a bug that hits nine. Whoever ranks your escalation makes that comparison first, before they read anything else you wrote.
Some problems are serious enough on their own that a second account changes nothing: security, compliance, data loss, safety, and anything that stops the customer from running their business. You don't need four examples of possible data loss before you raise the first one. If your issue is one of those, skip the rest of this section and send it now.
Everywhere else, start in the bug tracker. Search it before you write anything, because one search answers two of your four questions. If someone already filed this, add your account to that ticket instead of opening a second one. If nobody has, you've started the count.
Then widen the search. If you can query across the book, filter for accounts on the same plan, the same integration, or the same product version, and check whether the same behavior shows up there.
Spend twenty minutes looking before you spend two hours writing.
If you can't run a query across your book, or you can't see support tickets, here are three other ways to find out:
- Post the exact issue in your CSM channel instead of the general topic. "Anyone else seeing SSO sessions drop at 30 minutes?" gets answers. "Anyone having SSO issues?" gets silence.
- Search closed tickets for the error message itself, not the feature name.
- Ask your support lead what's crossed their desk this month. A working relationship with support is worth building for many reasons. This is one of them.
- If you use Notion, then you might be able to use their AI to search across your Slack messages and other connected documents.
When it really is one account, you still have a case. You build it from details instead of numbers. Name the segment, the workflow, and how many of their users are stuck. "Our third enterprise customer to hit this during onboarding" signals that it will happen again. "Our customer is blocked" only tells them it happened once.
Leaning on the size of the account works, up to a point. Triage guides warn teams against letting big logos and executive names jump the queue, and nobody writes a warning about something that isn't happening. It also means someone eventually asks why the backlog is full of one customer's problems.
Then describe what the customer's team actually did on Tuesday morning. The numbers get you ranked, and the story is why someone bothers to pass it along.
Write it so they can reproduce it without you
Before any of this, check that it's a bug. Support and product close a steady stream of reports that turn out to be someone using the product in a way it wasn't built for. Escalating one of those costs you more than a weak escalation does, because the next thing you send gets read by someone who remembers the last one.
You can call the problem critical in ten seconds, and that's exactly why nobody weighs it. Anyone can say a problem is bad. The person reading your escalation has already read that sentence a hundred times this quarter.
Nicolas Bettenburg and colleagues asked 156 developers what makes a bug report useful. They said steps to reproduce, stack traces, and test cases. The 310 reporters in the same study said those were the hardest things to give them.
That was open-source volunteers in 2008. The same gap shows up between CSMs and product teams today.
You can't make anyone believe a software bug is severe, but you can make confirming it take ten minutes instead of two days.
Give them all of this:
- The exact steps, in order, that produce the behavior
- What you expected to happen, and what happened instead
- Whether it happens every time or only sometimes
- The account ID and the user who hit it
- Timestamps with the time zone attached
- Browser, version, and environment
- Screenshots or a short recording
- What you already ruled out, because "it happens on Chrome and Safari, and on a fresh account with no custom fields" saves someone the first hour
How many of those did your last escalation carry?
If you don't know one of them, write that you don't know instead of leaving it out. A blank looks like you forgot. Saying you don't know tells them where to start.
Nobody expects you to figure out why it's happening. Your part is the context an engineer can't see: which customer, what they were trying to do, and what it's costing them while this sits open.
Reproduction steps prove the problem is real. They don't explain why it should push something else out of the quarter or get prioritized, and that takes its own paragraph. Name the workflow that's blocked, how often it happens, what the workaround costs, and the deadline that makes it urgent.
Put the ARR in there too, and don't stop there. "This is a $500,000 customer" doesn't tell anyone what the product is stopping them from doing.
Most people lead with how angry the customer is, and that has the same weakness. "The customer is furious" asks the reader to trust your read on someone they've never met. "Their VP paused the rollout, canceled training for 200 users, and asked for an executive call before Friday" is a list of things that happened, and anyone can judge it for themselves. Mention the anger when it has changed what the customer does.
Leave no open question in the document. Anything they have to ask you about gives them a reason to close the tab, and once they close it, they have to start over. Read your draft, mark every place someone would have to come back to you, and answer those before you send.
Sometimes you can't reproduce it. The environment is theirs, the customer won't grant access, or it happens twice a week at an unpredictable hour. Say so, and say what you tried. "I couldn't reproduce this in our sandbox, and here are the four things I tried" is real information, and it beats a document that goes silent right where the reader's questions start. The same rule holds when you're translating customer feedback to product.
Shrink the ask until someone can say yes today
Check the path before you write the ask. An account escalation and a request to bump a ticket's priority are two different requests, and picking the heavier one can cost you time you might not be able to afford. GitLab's public handbook keeps them apart and tells staff outright not to open an account escalation to raise a ticket's priority. Which of those two paths does your company have, and who receives each one? Find that out.
"Fix this" is an open-ended project, and the reader has to guess how many weeks you just asked for. Guessing high is safer for them, so they guess high and your item drops. Ask for something smaller that still keeps your customer moving.
You're sizing the request, not designing the fix. How to solve it is for the people who know the code, and a CSM who arrives with a proposed solution is usually wrong in front of the people best able to tell. Instead, ask.
Ask for things one person can approve on their own:
- A temporary unblock for this account, if one exists
- A documented workaround your team can walk the customer through
- A two-day investigation that ends in a yes or no rather than a fix
- Moving a feature request already on the roadmap forward by one cycle
- A straight answer that the permanent fix isn't happening this year, so you can stop telling the customer it's coming
Sometimes even the small ask gets declined. Ask what would change the answer. It might be volume, a customer tier, or whether the workaround holds up under real use. Whatever they name is what you go collect next, and it's worth more than a date that slips anyway.
A small ask gets the problem into someone's hands. Once an engineer has reproduced it, you're no longer the only person arguing for the permanent fix.
Treat day five as a routing problem
Silence feels like a no, and it rarely is one. Five days of nothing usually means your item is sitting with someone who doesn't own it, or it landed the week of a release, or someone acknowledged it in a channel you're not in.
People say no quickly. A message in the wrong queue sits there for weeks.
Five days is the right wait for a normal product bug. It's far too long for an outage or a security issue, and your company's process should already say so.
Treat your follow-up as a routing check. "Any update on this?" gives the reader nothing to do and reminds them they owe you something, which they can avoid by not replying. "Is this with the right team, or should I be talking to someone else?" is a question they can answer in eight seconds without taking on the outcome.
Change the channel before you repeat the message. A ticket that got no replies for a week won't get any on the eighth day. Ask your product counterpart in a DM, raise it in a standing sync, or ask your manager to mention it to theirs.
While you wait, tell your customer something true and specific. "It's been raised, I'm following up with the appropriate team, I'll have a routing answer by this week" holds better than a vague promise, and it doesn't commit you to a service-level agreement that nobody inside your company has signed off on. Do you know what you'd tell them on day ten? Decide now, not then.
Following up feels politically risky in your first year, and it can be. Threatening churn costs you credibility. You get to say "they'll churn over this" once, and if you spend it on something the customer doesn't leave over, the escalations you send afterward get discounted by someone who remembers.
Save it for the escalation where it's true.
------
The escalations that get acted on rarely look urgent. They look boring and complete: a count, a business consequence, a reproduction, a small request. The people who write them usually spend a week gathering evidence nobody asked for before anything catches fire. You can start this week, on an account that isn't in trouble yet.
Frequently asked questions
How long should an escalation be?
Short enough that someone reads it in one sitting: a paragraph of context, a bulleted list of reproduction details, one paragraph on business impact, and one sentence naming the ask. Attachments carry the rest. If the reader has to scroll twice before finding what you want, the ask is buried too deep.
What if my company has no formal escalation path?
Then your first job is finding the receiver, not writing the document. Ask a product manager who owns the surface area, ask support who they route bugs to, or ask a tenured CSM who they message. Write the escalation the same way. The structure matters more than where you send it.
Should I set the severity myself?
Set it if your tracker asks you to, using whatever definitions your company has written down, and expect it to get changed. Severity is a technical read and product owns priority regardless. Marking everything critical is the fastest way to have your labels ignored, including on the one that deserves it.
Should I loop in my manager, and when?
Copy them when the escalation carries a revenue claim, when a strategic account is at risk, and when you're about to change channels after a stall. Skip them on routine bug reports. A manager who sees every escalation stops reading them closely, and then the one that really needs them gets skimmed like the rest.
What do I tell my customer when product acknowledges the issue but won't commit to a date?
Tell them what's true: acknowledged, unscheduled, and here's the interim plan. Then give them a date for your next update rather than a date for the fix, because you control the update and you don't control the fix. A customer who knows when they'll hear from you next will wait longer than one holding a deadline you can't keep.
.png)
