← All posts Operations

What a good escalation actually contains

Most escalations fail because they are a forwarded email. Four things to include so the person receiving it can decide immediately.

SP Sofia Pereira1 July 2026 · 5 min read
ESCALATIONOrder #1042What happenedWhat is neededEverything the next person needs, and nothing else.

The forwarded-email problem

The most common escalation in ecommerce is an email chain forwarded upward with the words "can you take a look at this". It fails for a specific reason: the person receiving it now has to reconstruct the situation before they can make a decision, and reconstruction is the expensive part.

A good escalation is not a longer message. It is a message that contains the four things a decision needs.

1. The decision you are asking for

Lead with it. "I want to approve a refund outside our window" is an escalation. "This customer is upset" is a status update wearing an escalation's clothes.

If you do not know what decision you want, you are not escalating, you are sharing, and that belongs in the channel, not in someone's direct notifications.

2. What you already tried

Two lines. This prevents the single most demoralising response in support, which is being told to do the thing you did an hour ago. It also tells the decider how much runway is left.

3. The context that changes the answer

Not all of it. The parts that would change the decision:

  • How much this customer has spent, and how often. A first-time buyer and a fourteen-order regular are not the same question.
  • Whether this has happened to them before.
  • Whether it is happening to other people right now, which turns one refund into a pattern worth investigating.
  • What it costs to say yes.

4. Your recommendation

This is the one people leave out, usually out of politeness. Say what you would do. The person above you is nearly always going to agree, and when they do not, the disagreement is where the useful conversation is.

An escalation without a recommendation asks someone else to do your thinking. An escalation with one asks them to check it.

The shape it ends up being

"Asking to approve a $178 refund four days outside our window. I offered store credit, they declined. Six prior orders, no returns, first complaint. Cost to say yes is $178 and about ten minutes; cost to say no is probably the customer. I would approve it."

Four sentences. The decision takes about fifteen seconds, which is the entire point.

Why the tool matters here

All four of these are easier when the order, the customer history, and the previous threads are already attached to the conversation instead of living in three systems. That is most of what we built Store Huddle to do: not to make people write better escalations, but to make the context free so they can.

The forwarded email problem

Most bad escalations are a forwarded thread with three words on top. The sender has all the context and assumes the reader does too, so the reader spends ten minutes reconstructing a situation the sender could have summarised in two sentences.

That cost is invisible to the person escalating, which is why it persists. They experience the escalation as fast; the recipient experiences it as homework.

The fix is not more effort, it is a fixed shape. When the format is known, filling it in takes less time than writing a vague message, because there is nothing to compose.

What to leave out

As important as what to include, and rarely discussed.

The full history. Whoever you are escalating to does not need every message. They need the current state and the decision required.

Your own uncertainty, at length. "I am not sure if this is right but I thought maybe" costs the reader time and tells them nothing. If you are unsure, say so in three words and state what you would do.

Blame. How the situation arose matters at a post-mortem, not while it is live. Escalations that assign fault get read defensively and answered slowly.

Say what you would do

The single change that most improves an escalation: include your recommendation.

An escalation that ends "what should I do?" makes the reader generate options from scratch. One that ends "I would refund and reship, but that is above my limit, so confirming" converts the task from analysis into a yes or no.

This is worth encouraging explicitly, because junior staff often think proposing a course of action oversteps. It does the opposite: it demonstrates judgement, and it is much faster for everyone. It also surfaces gaps in your decision thresholds, because a recommendation that turns out to be within their authority means the limits were unclear.

Escalating badly is usually a system signal

If escalations arrive consistently vague, resist reading it as carelessness. Usually one of three things is true.

People do not know what the reader needs, which is a template problem. They are escalating things they could have decided, which is an authority problem. Or they are escalating at the last possible moment because raising things early has previously been treated as bothering someone, which is a culture problem and the most expensive of the three.

A shape that works

Four lines, in this order. The order matters because readers scan from the top and the decision is what they are looking for.

What is happening, in one sentence, current state only. "Customer wants a refund on order 1042, outside the returns window, item unworn."

What I have done, so nobody repeats it. "Checked the order, confirmed the date, told them we are looking into it."

What I need, stated as a decision. "Approval to refund, or a reason to decline I can give them."

By when, as an actual time. "Before five, or they will have waited two days."

Add your recommendation if you have one. Four lines, thirty seconds to write, and it converts a piece of homework into a reply.

Escalating upwards versus sideways

Not every escalation goes up. A meaningful share should go sideways, to whoever holds the relevant knowledge, and treating everything as an upward escalation puts the owner in the middle of things they know least about.

The test is what kind of gap you have. Missing authority goes up. Missing knowledge goes to whoever has it, regardless of seniority. Missing capacity goes to whoever can take the work.

Teams that route everything upward usually do so because sideways routing was never named as an option. Saying it out loud once is generally enough to change the pattern.

Acknowledging is not answering

The most common failure on the receiving end is silence while thinking. The recipient reads it, decides it needs consideration, and returns to it an hour later. Meanwhile the sender does not know whether it arrived.

A ten-second acknowledgement solves this entirely. "Got it, answer within the hour." The sender can now tell the customer something, stop worrying, and get on with other work.

This matters more than it seems because the alternative is not patience, it is chasing. An unacknowledged escalation produces a follow-up message, which costs both people more time than the acknowledgement would have.

Escalations that should have been decisions

Track, informally, how many escalations you answer with something close to "you could have decided that."

A high proportion is not a training problem. It means your delegated limits are either unclear or set too low, and people are behaving sensibly given what they believe they are allowed to do.

The fix is to raise the limit and say so explicitly, by name, out loud. Written thresholds alone are not enough; people need to hear that a specific decision is theirs before they will act on it without checking.

Keeping the record

Escalations resolved in a direct message vanish. The same question arrives three months later and gets answered from scratch, sometimes differently, which is how two customers end up with different outcomes for identical situations.

Resolving them somewhere searchable means the second occurrence takes ten seconds. It also builds the raw material for your policy: after a handful of similar escalations, the pattern is obvious and the threshold can be written down permanently.

The template, ready to copy

Pin this somewhere the team already looks. The value is in it being identical every time, so nobody has to compose anything.

Situation: one sentence, current state.
Done so far: what has already been tried or said.
Need: the specific decision, stated as a question with a yes or no answer where possible.
By: an actual time, and what happens if it passes.
I would: your recommendation, if you have one.

Five lines. Most escalations take under a minute to write in this shape, which is less time than a vague message takes to compose because there is nothing to decide about the wording.

Common questions

What should an escalation always contain?

The current state, what has already been tried, the specific decision needed, and the deadline. Adding your own recommendation makes it dramatically faster to answer.

Should I include the whole email thread?

No. Summarise the current state in two sentences and link the thread for anyone who wants it. Forwarding raw history moves your work onto the reader.

Is it presumptuous to suggest what should happen?

The opposite. A recommendation turns an open question into a yes or no, and it shows judgement. It also reveals when someone had the authority to act and did not realise it.

How urgent should I say something is?

State the actual deadline rather than a label. "Needs an answer before the courier collection at two" is far more useful than "urgent", which everybody discounts.

What if escalations keep arriving vague?

Look for a cause before assuming carelessness. Usually the template is missing, the authority limits are unclear, or people have learned that raising things early is unwelcome.

Keep reading

Operations

A daily operations routine for a three-person store team

Three fixed points in the day, about twenty minutes total. Built for teams too small to have a manager and too busy to have meetings.

3 July 2026·10 min read
Operations

Who owns what: a RACI for small Shopify teams

A one-page ownership map that takes an hour to build and prevents the most common category of dropped work. Includes a starter grid you can adapt.

1 July 2026·10 min read
Operations

How to run a store team standup in ten minutes

Most standups fail because they are status theatre. Three questions, a hard time limit, and an async version for teams that never overlap.

29 June 2026·10 min read

Run your store team in one room.

Free for teams up to five, and about two minutes to connect your store.