Complaint response review for manager approval

Use this workflow when an agent has drafted a response to a sensitive complaint and you need a manager-ready version. You will compare the draft with the case record and the applicable policy, then produce a revised reply, approval points and a clear handover.

This is for support managers handling exceptions, disputed outcomes, repeat contacts or complaints that may need senior review. It helps you separate verified facts from assumptions before a message reaches the customer.

Inputs to collect

Collect the following in one review pack before you ask the model to draft or revise anything:

• The customer’s latest message and the original complaint.
• The full case timeline, including contact dates, agent notes, prior replies and attachments.
• The current proposed response.
• The relevant policy text, including the exact clause or internal procedure that applies.
• Any approved exception, refund, remedy or goodwill decision already recorded.
• The required approver, if the case needs legal, safety, privacy, billing or senior support review.
• Your tone rules, including banned phrases, required sign-off and any local language requirements.

Remove or minimise personal data that is not needed for the review. Do not put passwords, payment card details, identity documents, access tokens or private health information into a prompt.

1. Build a fact sheet

Read the case record yourself first. Create a short fact sheet with only material points. Mark every item as one of these:

Label	Use it for	Example
Confirmed	A fact shown in the record	The replacement was dispatched on 12 May.
Customer claim	Something the customer says happened	The customer says they did not receive the dispatch email.
Policy position	What the supplied policy permits or requires	A replacement is available after delivery failure is confirmed.
Unknown	A point not evidenced in the pack	Whether the parcel was left at the stated address.

Keep confirmed facts separate from customer claims. Do not write a claim as though your team has verified it.

If the policy is unclear, record the uncertainty rather than trying to resolve it through wording. The model can identify a gap, but it cannot authorise an exception.

2. Give the model a bounded review task

Paste the fact sheet, the relevant policy extract and the proposed response. Then use a prompt that requires traceable output.

You are reviewing a proposed customer-support response to a complaint.

Use only the case facts and policy text below. Do not infer missing facts, invent remedies or make commitments not stated in the material.

Return these sections:
1. Record check: each material statement in the proposed response, marked supported, unsupported, unclear or conflicts with policy.
2. Risks: inaccurate claims, missing acknowledgements, promises, deadlines, admissions, privacy concerns and escalation triggers.
3. Revised customer response: plain British English, calm and respectful. State only supported facts. Clearly distinguish confirmed information from matters still being checked.
4. Approval points: decisions or wording that require a manager or named specialist to approve before sending.
5. Missing information: questions that must be answered before a final response can be sent.

Case fact sheet:
[PASTE]

Policy extract:
[PASTE]

Proposed response:
[PASTE]

Tone rules:
[PASTE]

Use the output as a review document, not as a send-ready answer. Model behaviour and available controls can vary, so check the current guidance in the xAI documentation overview before setting up a regular process.

3. Check the revised response line by line

Compare every sentence in the revised draft with the fact sheet. Check these points in order:

1. Confirm that names, dates, order references, contact history and actions match the case record.
2. Check that the reply acknowledges the complaint without accepting an unverified account of events.
3. Check that it says what has happened, what will happen next and who owns the next action.
4. Remove any unapproved remedy, refund, replacement, deadline, compensation or exception.
5. Replace absolute language such as will be resolved where the record only supports we are reviewing this.
6. Check that any policy reference is accurate and understandable. Do not paste internal language that the customer cannot act on.
7. Read it aloud for tone. It should be direct, respectful and specific, not defensive or overly apologetic.

4. Turn the approval points into a decision list

Do not hand over a vague note saying “please approve”. Convert the model’s approval points into a short list that identifies the decision needed.

Use this format:

• Decision: Approve or decline the requested exception.
• Evidence: The case record shows two prior contacts and no recorded delivery confirmation.
• Policy position: The supplied policy allows an exception only after a specified review.
• Customer impact: The reply cannot confirm a replacement until this decision is made.
• Owner: Support manager, or the named specialist team.
• Deadline: The next promised customer update, if one is already approved.

Only include deadlines that are already recorded or explicitly approved. Do not create a deadline to make the response sound more helpful.

5. Prepare the handover

Save or paste three separate items into the case:

1. Revised customer response, marked Draft, pending approval.
2. Approval points, with the owner and the exact decision required.
3. Review note, listing the policy source used, unresolved facts and any material changes from the original draft.

Assign the case to the approver or escalation queue. Set a follow-up task for the customer update only when the timing is authorised. If no response timing is approved, ask the owner for one rather than implying a commitment to the customer.

Signs the output is wrong

Treat the output as unreliable if it does any of the following:

If you see this	Why it is a problem	What to do
A precise date or amount not in the pack	It may be invented or copied from an irrelevant note	Delete it and return to the record.
A firm promise where policy needs approval	It creates an unauthorised commitment	Replace it with the approved next step.
“We understand” followed by an asserted customer claim	It can turn an allegation into a stated fact	Reword as the customer’s report.
A policy conclusion without a cited clause	The reasoning cannot be checked	Add the relevant text or escalate the interpretation.
A calm but vague reply	It may fail to answer the complaint	State the specific issue, action and next owner.

When the workflow does not work

Stop the drafting process if the case record is incomplete, the policy conflicts with an earlier promise, or the requested outcome needs a decision outside your authority. Mark the response as pending, list the missing facts or decision, and send it to the correct approver.

If the model repeatedly merges claims with facts or misses policy limits, reduce the input to a cleaner fact sheet and one relevant policy section. If that still fails, complete the review manually and use the model only for tone editing after the decision is settled.