Escalation packet
Objective. Package a technical, security, commercial or metric-dispute issue so the receiving specialist can act without a second round of questions.
A fill-in-the-blanks template that turns 'can someone help with this' into a clean handoff. It forces you to state the issue, what you already checked, the business stakes, who owns the next step and by when - so the specialist does not bounce it back for missing context. Use it the moment you hit something outside approved facts.
What it is and when to use it
An escalation packet is a short, structured note you raise when you reach the edge of what you can say or do confidently. Use it whenever the question touches security, compliance, data residency or contractual specifics (never guess these), when a customer disputes a figure you cannot reconcile, when an integration or packaging question goes past approved facts, or when an account risk needs an owner above you. It is not a vent or a forward of a long email thread - it is the one artifact that lets the right specialist pick up and act. Raise it early: a half-formed escalation with the business stakes stated beats a late one that was 'still being investigated'.
The packet - copy this
Escalation packet
- Account / customer:
- Raised by / role / date:
- Category: [ security | compliance / data residency | commercial / packaging | integration | metric dispute | adoption risk | other ]
- Issue in one sentence:
- What the customer actually asked or claimed (their words):
- Why it matters (business stakes, deadline, who is watching):
- What I already checked / ruled out: (sources, dates, scope, denominator, timezone, freshness if a metric)
- What I believe but cannot assert: (clearly separated from fact)
- Exact decision or answer needed:
- Proposed owner for the next step:
- Needed by (date) and consequence if missed:
- Attachments / evidence links:
How to fill it
Write the one-sentence issue last, after you have the rest - it forces clarity. In 'what I already checked', be specific: for a metric dispute, list the definition, scope, denominator, exclusions, timezone and data freshness you verified (this is the same discipline as the metric investigation workflow). Keep 'what I believe but cannot assert' honestly separate from fact - the specialist needs to know where your knowledge stops. Always name a proposed owner even if you are not sure; a wrong guess is faster to correct than a blank. State the real consequence of missing the date (renewal slips, sponsor loses confidence, blocker stalls the pilot) rather than a generic 'urgent'. Never put credentials, personal data or sensitive figures in a channel wider than it needs.
Honest caveat
An escalation packet routes a question - it does not answer it. Do not relay a specialist's answer to the customer as more certain than it is, and do not pre-commit the customer to an outcome while the packet is open. Security, compliance, data-residency and contractual specifics always go to security or product and are returned as 'confirmed by' statements, never your own assertion. If the issue is a metric the customer disputes, the packet does not prove them wrong - it asks for a reconciliation; the resolution may be that the customer is right or that a definition needs changing.
Interpretation check
An escalation is a routing tool, not a verdict. Separating 'what I checked / know' from 'what I believe but cannot assert' is the point: it tells the specialist exactly where certainty ends so they do not have to re-derive it.
Practical task
Take a real open question from a current account that you cannot fully answer, and write the full escalation packet for it. Have a peer confirm they could act on it without asking you a single follow-up question.
Self-check
Which categories of question must always be escalated rather than answered from your own knowledge?
Security, compliance, data residency and contractual specifics - never guess these. Package the question and return the specialist's confirmed answer.
For a metric-dispute escalation, what belongs in 'what I already checked'?
The definition, scope, denominator, exclusions, timezone and data freshness you verified - so the specialist reconciles from your checks rather than starting over.
Why state the consequence of missing the date instead of just marking it urgent?
Because 'urgent' is noise; a concrete consequence (renewal slips, pilot stalls, sponsor confidence) lets the owner prioritise honestly against other work.
The specialist returns an answer. How do you relay it to the customer?
As a confirmed statement attributed to the source, no more certain than given, and without having pre-committed the customer to an outcome while the packet was open.
Verified vs demo. This is a process tool, not a product claim. Nothing in it asserts an entitlement or metric; its whole job is to separate what you verified from what must be confirmed by a specialist.