Writing a Support Agent's Refund Policy into Its Prompt

Read the policy with a highlighter in hand and mark four categories of sentence: numbers, dates, required evidence and prohibitions. Those are the only sentences that become rules. Everything else is context the agent may quote but must not act on.

Numbers. Refund caps, approval limits, restocking fees, shipping reimbursements. Every number needs a unit and a comparison direction. "Up to 50 dollars" becomes "if the refund amount is 50 dollars or less, approve at step 4."

Dates. Delivery windows, processing times, warranty periods. Pin the clock to a specific event. "Within 30 days" is ambiguous until you write "counted from the delivery confirmation timestamp in the order record, not the order date." A worked example helps here: an order placed on the 1st and delivered on the 6th has a window that closes on the 5th of the following month, not the 31st.

Evidence. Photo for damage, tracking number for non-delivery, receipt for anonymous purchases. State whether the evidence is required or merely preferred. If a photo is required, the agent must not approve before it arrives.

Prohibitions. Final sale items, gift cards, digital downloads, hygiene products. These are hard stops that override everything else, so they belong near the top of the procedure.

Prompts for refund and return agents lays out a five-stage flow that mirrors how experienced representatives work: classify the intent, gather the facts, check the rules, choose the outcome, communicate clearly. Use it as your skeleton. The classification stage matters more than it looks, because "I want my money back" covers at least four different requests (refund, exchange, warranty claim, chargeback threat) that follow different paths.

One decision rule worth adopting from the ecommerce automation literature: if the policy text cannot answer a case, the prompt must not guess. Automating refunds in ecommerce notes that manual returns handling produces errors precisely because representatives improvise on exceptions the written policy never anticipated. Your prompt should convert those gaps into escalation, not into model creativity. Returns-related inquiries often make up 30 to 50 percent of support tickets according to that same source, so every gap you close removes a recurring decision from the human queue.

Sequence is a policy decision, and models do not infer it. If the window check comes before the defect check, a legitimate defective-item claim filed on day 45 gets denied. If the final-sale check comes after the refund approval, the agent has already promised money it cannot send. Write the procedure so that the most restrictive and the most protective rules run first.

A workable default order:

1. Identify the request type (refund, exchange, warranty, dispute).
2. Apply hard exclusions (final sale, gift cards, digital goods).
3. Check the time window.
4. Check the refund amount against the approval threshold.
5. Check required evidence.
6. Apply the defect and damage exception.
7. Decide the outcome and state it with the exact wording.
8. Apply the escalation rule if any step was unclear.

The order above encodes one judgment call: exclusions before the window, because a final-sale item is ineligible no matter when it arrives. The window before the amount, because the amount check only matters for eligible items. The defect exception after both, because it overrides them. Write that reasoning into the prompt as a comment line so the next person who edits it understands why the order is what it is.

The AI in customer service guide describes the wider principle: an agent should read intent and context, then either resolve or route with full context attached. The procedure above is that idea applied to a single policy. Every branch either ends in a resolution the agent is authorized to perform or in a routing decision.

Call out dependencies explicitly. "Do not ask for a photo until you have confirmed the order is inside the window and not excluded" prevents the agent from collecting evidence it will not use, which wastes the customer's time and signals incompetence.

Exceptions are where prompt quality is decided. A policy with six rules and eleven exceptions is really an eleven-rule policy with a short general clause. Treat it that way.

The most common ambiguous cases in refund support, and how each should read in the prompt:

Defective item outside the window. The general rule denies. The exception overrides. The prompt should read: "If the customer reports the item is defective, damaged in transit or not as described, do not deny on the basis of the time window. Ask for a photo, then follow rule D. State: I can see this arrived damaged, so I am treating it as a defect claim rather than a late return."

Partial refunds. Where the policy allows a partial refund, specify the calculation, not the principle. "Deduct the shipping charge and a 15 percent restocking fee, rounded to the nearest dollar, and state the figure before confirming."

Multiple items in one order. Rules apply per item. The prompt should instruct the agent to evaluate each line separately and to summarize the combined outcome.

The customer has already been promised something. If a previous representative or the agent itself made a commitment, honor it and escalate for review rather than reversing it.

Repeated refund requests. A pattern of returns on one account is a risk signal, and the prompt should route it to a human rather than decide on it. The workflow recipe for AI agent escalation shows why: the agent's job in that pattern is to collect the facts cleanly, not to adjudicate.

Currency and tax. Refund exactly what was charged, in the original payment method, including tax but excluding any amount the customer never paid.

Write each exception as a complete rule with the same three parts as the main rules: condition, action, wording. Then add a line at the end of the exception list: "If a case matches two exceptions, apply the one that is more favorable to the customer and note both in the handoff summary." That single sentence resolves most collisions before they reach a human.

Refusals are the highest-risk output. A vague refusal reads as a brush-off; an over-specific one creates a commitment. Give the agent the exact sentence.

Refusal template: acknowledge the request, state the specific rule that applies, offer the one alternative the policy permits, then stop. For example: "I can see why you expected a refund here. Our policy covers returns within 30 days of delivery, and this order was delivered on the 3rd of March, so it falls outside that window. I can offer store credit for the item value instead. Would you like me to set that up?"

Three things make that work. It names the rule rather than "our policy." It gives the date so the customer can check it. It ends with a question rather than a dead end.

Escalation needs the same treatment. The prompt should contain a final instruction along these lines: "If any condition in this procedure is unclear, if the customer disputes a fact in the order record, or if the requested refund exceeds your approval threshold, stop. Tell the customer: Let me bring in a colleague who can review this for you. Then create a handoff note containing the order number, the requested outcome, the rule that did not resolve it and the customer's exact words."

The Zendesk escalation workflow recipe shows the operational version: the agent collects structured information in a form, tells the customer the request is being sent to the team, and notifies human agents with the details already attached. Whether you escalate through a form, a ticket or a message, the handoff note should carry the same fields every time, because a vague handoff just moves the work.

The guide to AI in customer service frames the customer expectation behind this: people care less about whether the first responder is a person or a system than about being resolved quickly and not repeating themselves. A refusal that arrives in one turn with a clear alternative beats three turns of clarification followed by the same answer.

Build a case file. Twenty to forty cases is enough for a refund policy: fifteen straightforward, fifteen taking a rule to its boundary, and ten that are genuinely ambiguous. Run every case against the prompt, record the outcome, and compare it to what a senior representative would do. Fix the prompt, not the test, unless the senior representative is wrong.

Judge the run on resolution, not deflection. The distinction between deflection and resolution is that deflection counts requests kept away from humans and says nothing about whether the problem was solved. Verifying AI help agent metrics adds the practical test: track whether the same customer returns with the same issue within 24 to 48 hours, and sample deflected conversations for accuracy. Realistic deflection expectations reports that basic scripted bots handle roughly 10 to 30 percent of inquiries while systems with live data access and the ability to act reach far higher, which is the difference between answering a policy question and executing a refund.

A worked example for the arithmetic. An order totals 400 dollars, including 25 dollars of shipping. The customer requests a refund of 500 dollars. The agent's procedure says to check the requested amount against both the order total and the approval threshold. Both fail, so the agent does not negotiate the figure and does not approve a partial amount on its own initiative. It states what it can see, offers a refund of 400 dollars if the return is otherwise eligible, and escalates the gap for review. That is one rule producing one outcome, and the customer learns why.

Treat the prompt as production code. It should live in version control, carry a changelog and have a named owner in policy or support operations. Every refund policy change lands as a numbered edit, not a paraphrase, and the case file grows by one case for each change.

Practical rules that keep it healthy:

• One rule per line, with a stable identifier so test results can reference it.
• The exact customer-facing wording in quotation marks, so reviewers can edit the sentence without touching the logic.
• A comment at the top stating the policy version and the date the procedure was last verified against it.
• No rule that requires the agent to judge tone or intent. Convert those to observable conditions or move them to escalation.
• A final line that makes uncertainty an escalation rather than a decision.

The verification loop is where most teams underinvest. The deflection dilemma describes a deployment where an evaluation process caught the agent fabricating dollar amounts and merging details from unrelated products, errors that would otherwise have counted as successful resolutions. Those are exactly the failures a refund prompt produces when a threshold is described in prose rather than stated as a comparison.

The IBM guide to customer service automation makes the maintenance point at the level of the whole system: automation works when the layers are connected so context from one step carries into the next instead of starting over. A refund prompt is one of those layers, and it fails the same way if the escalation step drops the order context the agent already gathered.

When the procedure is stable, the remaining work is operational: routing escalated cases to people with the authority to decide them, and reading the handoff notes to find the next gap in the policy. If your refund rules sit across several systems and you want one place to run and test them, our team can walk through the setup on a free discovery call.