LearnGrokUse this pack to review a queue of proposed customer replies before they are sent. It gives support leads and quality reviewers a repeatable record of what is wrong, what to send instead, and what the team needs to practise.
Start with the actual approved documents. A tone guide without policy notes can produce polite but unsafe replies. Policy notes without a tone guide can produce technically correct replies that sound cold, vague, or inconsistent.
Prepare the review file
- Export or copy the proposed replies into a working sheet called Proposed Reply Batch.
- Give every row a stable Case ID. Include the customer's issue and the full proposed reply.
- Paste the current Approved Tone Guide and Policy Notes beneath the batch. Keep their headings intact so the review can point back to them.
- Remove customer details that the reviewer does not need, such as account numbers, full addresses, and payment details.
- Decide who can answer an escalation. Name the policy owner or specialist queue before you begin.
Key point
Review the claim, not just the style
A warm reply is still risky if it promises an outcome, deadline, exception, or action that the policy notes do not support.
If you run this through an API workflow, accepted inputs and other implementation details are version-dependent. Check the xAI documentation overview before you build the workflow around a particular file format.
Run the batch decision first
Use Batch reply review matrix for the whole queue. Do not begin by asking for rewrites. The decision table separates replies that are ready to send from those requiring wording changes or a human decision.
Treat the three decisions differently:
| Decision | What it means | What you do next |
|---|---|---|
| Approve | The reply follows the supplied material. | Spot-check it, then release it through your normal process. |
| Revise | The reply can be corrected from the supplied material. | Use Revised reply drafts. |
| Escalate | The material does not support a safe answer. | Use Escalation summary sheet and route it to the named owner. |
Watch out
Do not turn an unknown into a promise
If eligibility, timing, or a remedy is not confirmed in the case record or policy notes, the reply must ask for confirmation or be escalated.
Produce replacement copy
Paste only the Revise rows into Revised reply drafts. The prompt produces customer-facing text, not a list of edits. That matters when the original reply has several issues, such as an unsupported promise and an overly blunt phrase.
Read the revised reply alongside the original customer issue. Check that it answers the actual question. A reply can match the tone guide and still fail because it addresses a different problem from the one the customer raised.
Use Escalation summary sheet for every Escalate row. Its purpose is not to solve the policy question. It gives the policy owner a precise question, the source of the uncertainty, and a safe holding reply where one is possible.
Stop
Do not send the draft marked for escalation
A holding reply is not permission to answer the unresolved question. Send it only if it is safe under the supplied notes and your normal approval process.
Turn findings into team coaching
After the queue is complete, use Recurring coaching points. Keep the input as the completed review record, including the flagged words and the reason for each change. This prevents the coaching summary from becoming generic advice such as “be more empathetic”.
Use the resulting one-week focus in the next quality session. Assign one reviewer to sample new replies for the three named behaviours. Record examples of both correct and incorrect wording. If a pattern is actually a policy gap, send the question to the policy owner rather than coaching agents to guess.
When reviewers disagree, use Calibration disagreement check. Run it on the disputed cases only. Save the final review rule in the quality rubric, with the relevant policy or tone reference. This keeps the next reviewer from reopening the same argument.
Check that the output is reliable
Check a sample before you act on the full batch. Select at least one approved reply, one revised reply, and every high-risk or escalated reply. Compare each output against the source documents, not against what seems reasonable.
Look for these failure signals:
| If you see this | Treat it as wrong | What to do |
|---|---|---|
| A new deadline, refund, exception, or action | It may be an unsupported commitment. | Remove it and return the case to escalation or rewrite it from the notes. |
| A policy reference that you cannot find | The evidence is unreliable. | Re-run with the full policy section and require a direct quote. |
| A generic reply that ignores the customer's issue | The draft is not case-specific. | Add the customer issue and relevant case facts, then rerun the draft prompt. |
| A coaching point with no Case IDs or quoted evidence | It is an opinion, not a review finding. | Re-run the coaching prompt with the completed review rows. |
Check
A good review is traceable
You should be able to point from every decision to exact reply wording and to a supplied tone or policy reference.
When the pack does not work
Stop and fix the source material if the output repeatedly escalates ordinary cases, cites vague guidance, or produces nearly identical replies for different issues. Usually the batch lacks case facts, the tone guide is too broad, or the policy notes omit the decision the customer needs.
Add the missing case field or policy clarification, then rerun only the affected prompt. Do not quietly accept a plausible draft. Keep unresolved cases in the escalation queue until the responsible person has made the decision.
