LearnGrokThese prompts produce a reviewable record for refund requests that sit outside the published policy. They are for the support lead or service manager who prepares the case, then sends it to an authorised manager for a decision.
Start with the case record, then use the timeline where timing matters. Compare precedents only when you have actual previous decision records. Draft the decision brief once the evidence is assembled, and run the final review before asking for approval.
Key point
Keep the policy rule and the proposed exception separate
A manager needs to see why the request falls outside policy before they can decide whether an exception is justified.
1. Assemble the source material
Collect the records before pasting anything into a prompt:
- The complete customer conversation, including the original request and any agent commitments.
- The order, invoice or subscription record.
- The relevant published policy wording, not a paraphrase from an internal note.
- Account notes covering earlier contacts, refunds or related issues.
- Product, delivery, cancellation or usage evidence where it bears on the request.
- Previous exception decisions, with their recorded rationale, if you intend to cite precedent.
Use Extract the exception case first. It converts scattered material into fields that a reviewer can scan. Do not treat its policy position as a decision. Its job is to identify the rule and show the apparent gap between that rule and the request.
Watch out
Do not paste a partial ticket and call the result customer history
A missing earlier complaint or previous refund can materially change the recommendation. Mark the history incomplete if you cannot retrieve it.
Minimise customer data. A customer identifier and order reference are usually enough for the brief. Remove addresses, payment details and unrelated account notes. If your workspace supports file or document handling, the available behaviour can vary by version. Check the current xAI documentation overview before relying on a particular workflow.
2. Establish what happened, and when
Use Build a dated evidence timeline if any of these are disputed or relevant:
- The purchase, renewal or delivery date.
- When the customer first reported the problem.
- Whether the service was used, cancelled or renewed.
- Whether an agent made a promise before the case reached you.
- Whether the policy changed between purchase and request.
A timeline is useful because it separates a documented event from a customer statement. It also stops a persuasive final message from hiding an earlier event that points the other way.
Check
The timeline is ready when every material event has a source
You should be able to trace each date back to a ticket message, account event, order record or policy document. An unknown entry is acceptable. An invented date is not.
3. Use precedent carefully
Use Compare relevant refund precedents only with records that include facts and a reason for the outcome. A list of refund amounts is not precedent. It cannot show whether the customers faced the same policy position, evidence or service failure.
Compare the cases on the facts that matter to your policy. These often include the elapsed time, what the customer received or used, the evidence of a fault, prior contact history and whether an agent created a reasonable expectation. Treat a prior outcome as context, not as an automatic rule.
If previous decisions point in different directions, keep that inconsistency visible in the brief. Do not select only the cases that support the outcome you prefer.
4. Put one decision in front of the manager
Use Draft the manager decision brief after the case record and timeline are complete. Paste the authority limits and permitted remedies as well. This prevents a draft from recommending an amount or remedy that the receiving manager cannot authorise.
The brief should make a single recommended path easy to find. It should also make the alternative clear: decline, request evidence, or route to a different approver. Keep the customer-facing reply out of this document unless the manager asks for it. The decision brief is an internal record, not a reply draft.
The manager decision record matters after approval as much as before it. Name the follow-up owner, record any conditions, and retain the rationale. That gives the next reviewer a usable precedent rather than a bare outcome.
5. Check where the draft can be wrong
Run Test the brief before approval against the original sources. Pay particular attention to policy quotations, dates, currency and prior-refund claims. These are easy for a draft to flatten or misstate.
| If you see this | Treat it as | What to do |
|---|---|---|
| A customer says an item never arrived | A statement, unless delivery evidence confirms it | Ask for or attach the delivery record |
| The policy excerpt lacks an effective date | An unresolved policy question | Find the wording that applied at the relevant time |
| A prior case has the same amount but different facts | Low-value comparison | Do not present it as a close precedent |
| The recommended amount appears without a source | A blocking issue | Check the transaction record and authority limit |
Stop
Do not send the draft as an approval decision
The model can organise evidence and expose gaps. The authorised manager must make and record the actual exception decision.
When it does not work
If the output is vague, paste the exact policy clause, transaction record and missing account events rather than asking for a more confident answer. If it merges claims with evidence, rerun the extraction prompt and require source labels. If the recommendation exceeds the stated authority or precedent is thin, select obtain more evidence or route the case to the appropriate manager. A short brief that shows uncertainty is safer than a complete-looking brief built on missing facts.
