Refund exception review for approval

Use one approval sheet for every refund request that sits outside your standard policy. This gives the approver the claim, evidence, policy wording and proposed outcome in one place, rather than asking them to reconstruct the case from ticket notes.

This workflow is for support operations managers and senior agents who prepare or approve non-standard refunds and goodwill credits. The model drafts the sheet. Your named approver remains responsible for the decision and any amount authorised.

1. Define the sheet before reviewing the queue

Create a fixed approval-sheet template in your case system, spreadsheet or internal document. Do this once, then use the same headings for every exception. A fixed structure makes incomplete cases obvious and makes later quality review possible.

Use these fields:

Field	What to record
Case reference	Ticket or case ID, customer name or internal customer reference
Customer claim	What the customer says happened, in neutral language
Order facts	Order reference, items, delivery status, payment and fulfilment facts relevant to the request
Contact history	Dated summary of material contacts, promises and prior outcomes
Policy wording	The exact relevant policy clause or approved internal guidance
Exception reason	Why the case is outside the normal route
Recommended outcome	Approve, decline, partial refund, replacement, or another permitted route
Proposed goodwill	Amount, currency and reason, or None proposed
Evidence still needed	Missing documents, system checks or owner confirmation needed before approval
Approver decision	Pending, approved, declined, or returned for more information

Keep customer claim separate from order facts. The first records the customer's account. The second records what your systems show. Blending them is a common source of inaccurate summaries.

2. Prepare a safe queue extract

Export or copy only the records needed for the review. Give each case a stable reference, then include the relevant order timeline, ticket messages, prior agent commitments and applicable policy text.

Remove information that does not help an approver decide the exception. Do not include payment card details, passwords, authentication answers, full identity documents or unrelated conversations. Follow your organisation's data-handling rules before placing customer information into any tool.

For a large queue, split the work into batches that a reviewer can check properly. The size that works is version-dependent. Check the current product guidance in the xAI documentation overview before designing a high-volume process.

Use a consistent input block for each case:

Case reference: REF-1042
Customer claim: [verbatim or concise neutral summary]
Order facts: [facts from order and delivery systems]
Contact history: [dated material events]
Policy wording: [exact approved text]
Known exception reason: [why standard policy does not resolve it]
Missing evidence already identified: [if any]

Do not tell the model that a refund is deserved before it has separated claim, facts and policy. That instruction biases the review towards the result you expect.

3. Ask for a structured draft, not a decision

Paste the batch and ask for one approval sheet per case. Require the model to quote or identify the source for each material statement. It should state uncertainty rather than fill gaps with likely details.

Use this prompt:

For each case below, produce an approval sheet using exactly these headings:
Case reference
Customer claim
Order facts
Contact history
Applicable policy wording
Why this is an exception
Recommended outcome
Proposed goodwill amount and rationale
Evidence still needed before approval
Conflicts or uncertainties

Rules:
- Separate customer statements from verified system facts.
- Use only the supplied material.
- Quote policy wording exactly, or write "Policy wording not supplied".
- Do not infer dates, delivery events, prior promises, eligibility or amounts.
- If evidence is missing, set the recommended outcome to "Pending evidence" unless the supplied policy clearly permits a decision.
- For a goodwill proposal, state the operational rationale and label it as subject to approver authorisation.
- Keep each sheet concise enough for an approver to review.

Cases:
[paste cases here]

This method is deliberately restrictive. You need a review record, not a polished customer reply. A concise sheet also lets the approver compare similar exceptions without reading the entire ticket thread.

4. Check the draft against the source records

Review every approval sheet before it reaches the approver. Start with fields that can change the outcome: order status, delivery evidence, prior commitments, policy exclusions and the proposed amount.

Use this check in order:

1. Open the order record and confirm every order fact in the sheet.
2. Read the cited ticket messages and confirm the contact-history dates and promises.
3. Compare the policy section word for word with your current approved policy source.
4. Check that the exception reason is genuinely outside the standard route.
5. Confirm that the proposed goodwill amount follows your internal approval bands, if you use them.
6. Make sure missing evidence is named as a specific item and owner, such as carrier delivery scan, Logistics rather than check delivery.
7. Mark the sheet Ready for approval only when the evidence supports a decision.

5. Spot output that is going wrong

Treat these as defects, not minor wording issues:

If you see this	Likely problem	What to do
A confident delivery date not in the order record	The model inferred a fact	Delete it, add the source fact, then redraft
Policy wording is paraphrased	The policy source was not controlled	Replace it with the exact clause and rerun that case
Approve despite missing proof	The instruction did not enforce a pending route	Change the outcome to Pending evidence and name the missing proof
A goodwill amount has no rationale	The proposal cannot be reviewed consistently	Add the relevant internal band or request a no-amount draft
Contact history says several times	The summary hides material sequence	Require dated contacts and prior commitments

Sample a small group of completed sheets each week, especially approved cases and cases returned by approvers. Compare the draft with the original records and log recurring errors, such as invented fulfilment facts or omitted prior promises. Update the prompt or the input template when the same defect appears more than once.

6. Route the completed sheet and retain the reason

Send the final sheet with its source references to the authorised approver. Record their decision, approved amount where applicable, conditions and decision date in the case record. Then draft the customer response from the approved decision, not from the earlier recommendation.

If the workflow does not work, stop processing the batch. Take one failed case, identify whether the fault came from missing source material, unclear policy wording, an over-broad prompt or an unclear approval rule. Fix that single point, test it on a small set of previously reviewed cases, and only then return to the live queue.