Escalation packet for engineering triage

Use this workflow when a customer report may be a product defect, but the ticket history is too long or unclear for engineering to act on directly. You will produce one issue packet that separates observed facts from assumptions, records what has been tried, and asks engineering for a specific decision.

Do this before moving a case into an engineering queue. It is for support specialists who own the customer conversation but need engineering to reproduce, assess or prioritise the issue.

1. Collect the case record

Open the support ticket and create a working note called Engineering escalation packet. Do not start with a free-form summary. First collect the source material that could establish what happened.

Record these fields:

• Case ID and support queue.
• Customer impact: who is affected, what they cannot do, and the operational consequence.
• Scope: one user, one account, a plan type, a region, a device family or a wider pattern.
• First known occurrence and most recent occurrence, including time zone where known.
• Expected behaviour: what the customer reasonably expected the product to do.
• Actual behaviour: what happened instead, using visible messages or states.
• Environment: product area, account settings relevant to the issue, browser or app version if supplied, device, locale and network conditions if relevant.
• Evidence: screenshots, screen recordings, request IDs, error text, logs available to your team, and exact customer wording.
• Steps already attempted: support actions, customer actions and their results.
• Related cases: linked tickets only where the symptom and conditions genuinely match.

Remove unnecessary personal data before you paste material into the model. Replace names, email addresses, phone numbers, payment details and access tokens with labels such as [customer email removed]. Keep the values needed to reproduce the issue, such as feature settings or error codes.

2. Build a fact sheet before drafting

Write a short fact sheet in the working note. Use four headings: Observed, Reported, Tried, and Unknown.

• Under Observed, put evidence your team can see or verify.
• Under Reported, put statements made by the customer or another team.
• Under Tried, record each action and its result. Include failed workarounds.
• Under Unknown, list missing conditions that block reproduction or impact assessment.

This distinction stops a polished draft from making the ticket sound more certain than it is. It also makes gaps visible before the issue reaches engineering.

If the conversation is long, give the model the fact sheet and only the relevant excerpts from the ticket. Ask it to organise, not infer.

Use this prompt:

Create an engineering escalation packet from the material below.

Rules:
- Use only the supplied information.
- Separate observed evidence, customer-reported information and hypotheses.
- Do not claim root cause, severity or a fix.
- Preserve exact error text, identifiers and timestamps where provided.
- Mark missing reproduction conditions as Unknown.
- Write concise sections using the packet template below.

Packet template:
1. Issue statement
2. Customer impact and scope
3. Expected behaviour
4. Actual behaviour
5. Reproduction steps
6. Evidence
7. Attempted support steps and outcomes
8. Unknowns and hypotheses
9. Decision needed from engineering

Material:
[paste fact sheet and relevant redacted excerpts]

For available product and API behaviour that may vary, check the xAI documentation overview before you set team instructions around the model.

3. Turn the draft into a triage packet

Read the draft and edit it into the following format. Keep headings even when a section is incomplete. An explicit unknown is more useful than a blank that looks accidental.

Section	What to include	What engineering can do with it
Issue statement	One sentence naming the product behaviour, affected condition and result	Decide where to route it
Impact and scope	Affected users, blocked task, frequency known from evidence	Assess urgency and blast radius
Reproduction steps	Numbered actions, starting state and expected versus actual result	Attempt reproduction
Evidence	Exact errors, timestamps, request IDs and attachments	Investigate the relevant event
Attempted steps	Each workaround or support action and its outcome	Avoid repeating work
Decision needed	One bounded question	Reply with an actionable outcome

Write reproduction steps as instructions, not a narrative. For example, use Sign in with an account where [setting] is enabled, then Open [product area], then Select [action]. State the result after the final action. If you cannot reproduce the issue, write Reproduction not confirmed by support and list the customer conditions that still need checking.

The decision needed must not be “please investigate”. Ask for the next decision that changes the case. Examples include:

• Is this behaviour expected under the recorded account condition?
• Can engineering reproduce this using the attached request ID and steps?
• Is there a known issue or existing tracked item to link?
• Is a product change, data correction or customer workaround appropriate?
• What information must support collect before this can be investigated?

4. Check the output against the source

The most common failure is not bad writing. It is a draft that joins separate details into a convincing but false explanation. Check every sentence that states a condition, sequence, count, date, account setting or conclusion against the ticket and attachments.

Treat the packet as wrong if you find any of these:

If you see this	Why it is wrong	Do this
A stated root cause with no engineering evidence	It turns a hypothesis into a finding	Move it to Unknowns and hypotheses or remove it
Steps that omit the starting condition	Engineering cannot reproduce reliably	Add account state, product area and prerequisite action
“Multiple customers affected” based on one ticket	Scope has been overstated	State the known scope and link verified related cases
A workaround described as successful when it was not confirmed	The customer may be sent back to a failed action	Record the result as unconfirmed or failed
A broad request to investigate	It does not define the handover	Replace it with one decision needed

Then check tone. The packet should be neutral and specific. Remove blame, frustration and phrases such as “obviously broken” or “engineering needs to fix this”. Keep the customer impact, but do not use it to claim a priority level that your process has not assigned.

5. Hand over and update the customer record

Submit the packet through the engineering intake route used by your team. Include the case ID, attachments and any linked issue reference returned by that route. Set the support case status to show that it is awaiting engineering triage, if that is your queue convention.

Add a customer-facing internal note with only what is known: the issue has been escalated, the evidence sent, and the next update point required by your support policy. Do not promise a fix, a diagnosis or a delivery date.

If the draft is incomplete, do not send a longer prompt and hope for certainty. Return to the fact sheet. Ask the customer for the single missing detail most likely to enable reproduction, such as the exact action sequence, the time of the error, or a redacted screen recording. If evidence is unavailable, hand over a packet that says so plainly and ask engineering whether they need a specific next data point.