LearnGrokUse this workflow when a case needs product, technical, billing or policy review. You will produce one internal escalation summary that states the problem, the evidence, what support has already done, and the decision or action needed.
It is for support agents preparing a handover and team leads checking that a specialist will not need to reconstruct the case from the queue.
Key point
Write for the next team, not for the ticket
A useful escalation lets a specialist understand the issue and take the next action without reading the whole conversation.
1. Confirm that escalation is needed
Before you summarise, check the case against your team’s escalation rules. Escalate when the remaining work needs access, authority or technical judgement that the queue does not have.
Common reasons include:
- a reproducible product fault after standard troubleshooting
- a billing discrepancy that needs account or payment review
- a policy exception or interpretation that requires an authorised decision
- account behaviour that needs investigation by a specialist team
- significant customer impact, such as blocked work, repeated failures or a time-sensitive deadline
Do not escalate merely because the customer is unhappy. State the unresolved issue that requires specialist action.
Watch out
Do not turn a long ticket into a shorter transcript
Remove greetings, repeated explanations and internal discussion that does not change the next action.
2. Collect the case record in one place
Open the ticket, account record and any linked cases. Copy the material into a working note before asking the model you are using to draft anything. This lets you check the source record against the output.
Collect these fields:
- Case ID and account or organisation identifier
- Customer and contact: role, plan or account relationship where relevant
- Issue: what fails, what the customer expected, and what happens instead
- Start point: when the issue first occurred or was first reported
- Scope: affected users, transactions, devices, locations or workflows
- Impact: what the customer cannot do and any stated deadline
- Evidence: exact error text, timestamps, reference numbers, screenshots or logs available to the specialist
- Actions completed: each troubleshooting step and its result
- Relevant account context: recent changes, entitlement status or linked cases, only where it affects the investigation
- Requested action: the question the specialist team must answer or the work they must do
Keep customer statements separate from confirmed facts. For example, write Customer reports that invoices are duplicated rather than Invoices are duplicated until the record confirms it.
Stop
Do not include secrets or unnecessary personal data
Remove passwords, authentication codes, full payment details and unrelated personal information. Use the approved internal reference where a specialist needs to retrieve protected data.
If your workspace sends case material to a model, follow your organisation’s data-handling rules first. Configuration and product behaviour can vary, so check the current xAI documentation before relying on a particular setup.
3. Separate facts, attempts and unknowns
Sort your working note into three groups. This prevents the draft from presenting assumptions as evidence.
| Group | Include | Example wording |
|---|---|---|
| Confirmed facts | Records, timestamps, exact error messages | Two failed attempts are recorded at 09:14 and 09:18 UTC. |
| Customer report | What the customer says happened or needs | Customer reports the failure began after changing team permissions. |
| Unknowns | Questions the specialist must investigate | It is not yet confirmed whether the permission change triggered the failure. |
List completed troubleshooting in time order. Include the result of each action. Cleared browser data is not enough. Write Cleared browser data, issue remained in a private browser session.
This is especially important for repeat contacts. State what changed since the previous interaction, rather than making the specialist compare several old replies.
4. Draft the summary from a fixed structure
Give the model the organised case record and ask for an internal escalation only. Tell it not to invent missing details, recommend customer-facing wording or repeat information that is not relevant to the specialist.
Use this instruction:
Create a concise internal escalation summary from the case record below.
Use the headings: Issue, Customer impact, Confirmed evidence, Troubleshooting completed, Relevant context, Unknowns, Requested specialist action.
Distinguish confirmed facts from customer reports. Preserve exact error text, dates and reference numbers. Do not invent causes, outcomes or missing fields. Use plain language and bullet points.
Then provide the collected record beneath the instruction. Ask for a second pass only if the first draft misses a field or is too long. Do not ask it to decide a policy, approve a refund or diagnose a defect as fact. Those decisions belong to the authorised or specialist team.
A good finished summary usually follows this shape:
Issue
- [One sentence describing the unresolved problem.]
Customer impact
- [Who is affected, what is blocked, and any stated deadline.]
Confirmed evidence
- [Exact error, timestamps, IDs and reproducible conditions.]
Troubleshooting completed
- [Action]: [result]
Relevant context
- [Only account, product or case history that changes the investigation.]
Unknowns
- [What is not established.]
Requested specialist action
- [Specific investigation, decision or correction needed.]
5. Check the draft against the source case
Read the draft beside the ticket, not on its own. The output is wrong if it changes a date, omits a failed step, turns a customer claim into a confirmed fact, or asks the specialist to infer the actual task.
Check
Test the handover
A specialist should be able to answer three questions from the summary: what is wrong, what has been tried, and what do you need me to do next?
Check these points before sending:
- Every identifier, timestamp and quoted error matches the source.
- The opening issue statement names one unresolved problem.
- The impact is specific, without exaggeration.
- Completed actions include results.
- Unknowns remain labelled as unknowns.
- The requested action begins with a clear verb, such as
Investigate,Confirm,RevieworCorrect. - The draft contains no promises to the customer and no unsupported cause.
If a case has several unrelated problems, create separate escalations. A specialist team can route and resolve one defined problem more reliably than a combined account history.
6. Send and record the handover
Paste the checked summary into the approved escalation field or internal note. Attach or link the evidence that the specialist needs, such as the relevant log reference, screenshot or related case. Do not attach a large set of material without identifying which item supports which claim.
Add a brief ticket note recording the destination team, the requested action and the handover time. Set the case status and follow-up ownership according to your queue process. If the customer needs an update, use your approved reply process separately from the internal summary.
When the draft does not work
If the draft is vague, do not keep rephrasing the same incomplete record. Return to the source and fill the missing field: usually impact, exact evidence, troubleshooting result or requested action. If facts conflict between the ticket and account record, state the conflict under Unknowns and escalate it for review rather than choosing one version yourself.
If the case is too large to review safely in one draft, summarise the ticket history first in dated events, verify that timeline, then use it as evidence in the final escalation. Send the summary only after a human check confirms it matches the case record.
