Use these prompts to make cancellation decisions repeatable before an agent promises an offer. They are for retention leads who approve exceptions and need a clear record of why an offer was approved, declined or escalated.
The aim is not to produce warmer cancellation replies. It is to link the decision to the current policy, verified account facts and the customer’s stated reason. That gives the approving lead something they can defend in the case record.
Key point
Start with the policy
An attractive offer is not an approvable offer unless the case meets the current eligibility and authority rules.
Choose the prompt that matches the case
Use Complete save-offer recommendation for an ordinary case with a usable ticket, account record and policy. It produces the decision, risk rating, recommended terms and reply wording in one pass.
Use Eligibility and evidence check when the notes are long or messy. This is the right first step where the account has several previous offers, conflicting dates or unclear payment status. It separates confirmed evidence from assumptions before anyone chooses an offer.
Use Exception approval decision when the requested concession is outside the normal range. Give it both the standard policy and the authority rules. A lead may agree that the customer is at risk of leaving, yet still lack authority to approve the requested duration or concession.
Use Approved offer reply draft after, not before, the decision. Paste the approved offer record rather than asking the model to reconstruct the terms from a long discussion. This reduces the chance that the customer message adds a benefit that nobody approved.
Use Approval record quality check as the last control. It is especially useful for a proposed exception, a high-risk account or a case handed over between agents.
Prepare the case material
- Copy the full cancellation ticket. Keep the customer’s actual reason, requested timing and latest question. Do not reduce it to a label such as “price objection”.
- Gather dated account notes. Include prior concessions, failed payments, complaints, renewal discussions and earlier cancellation contacts that affect eligibility.
- Paste the current policy in full for the relevant account type. Include the offer table, exclusions, expiry rules and approval thresholds. Do not rely on an agent’s recollection of a policy.
- Add verified account facts separately from free-text notes. State the plan, contract or renewal position, billing state and any flags that the reviewer is permitted to use.
- Remove details that are not needed for a retention decision. Do not paste unrelated support history or sensitive personal details merely because they are available.
Watch out
Notes are evidence, not policy
A previous promise in a case note may explain the situation, but it does not create approval authority or replace the current rules.
If your policy changes by account type, region or support channel, label the version and effective scope in the pasted material. Product behaviour and available configuration can be version-dependent. Check the relevant documentation before setting up a workflow that sends account data to the model you are using: xAI documentation overview.
Read the decision in the right order
Start at Eligibility, not the proposed wording. Every policy rule should be marked met, not met or unknown. An unknown renewal date, previous exception or payment status can change the decision. If the output marks a rule as met but does not identify the source fact, treat it as unverified.
Then read Customer risk. This is a triage label, not a prediction. A useful risk explanation cites the cancellation reason, an unresolved issue, timing or a documented pattern. “Long-standing customer” on its own is not enough unless your policy says tenure changes eligibility.
Read the offer terms next. Check the exact concession, duration, expiry and customer action. These are the fields most likely to drift between the approval note and the outgoing reply.
Check
A usable approval has a trail
You should be able to trace every eligibility finding and every offer term back to a policy clause or a named case fact.
Know when the output is wrong
The output is unreliable if it does any of the following:
| What you see | What to do |
|---|---|
| It invents tenure, spend, product use or a prior offer | Mark the claim unverified and rerun with the missing account record, or remove the claim. |
| It chooses an offer without citing the policy basis | Use the eligibility check first. Do not approve from the recommendation alone. |
| It resolves conflicting notes silently | Find the dated source of each fact. Escalate if the conflict affects eligibility or authority. |
| The reply says “we can” more broadly than the approval | Replace it with the exact approved terms, or hold the reply. |
Do not let polished wording disguise a weak decision. A short response that says “cannot determine” is safer than a complete-looking recommendation built on missing facts.
Stop
Do not send an unapproved draft
The reply draft is customer-ready only when its terms match a recorded approval and all required conditions are present.
When the process does not work
If the result is vague, the source material is usually vague. Do not ask for a more confident answer. Run the eligibility check and supply the missing policy clause, dated account fact or authority rule.
If the result conflicts with the policy, treat the policy as controlling and correct the pasted material if it was incomplete. If the policy itself is unclear, use the exception decision prompt and require escalation rather than an implied approval.
If the same uncertainty appears across many tickets, fix the intake form. Add fields for cancellation reason, current plan, renewal status, prior offer, requested exception and approving role. That gives the next review a record to assess rather than a thread to interpret.