Set them in layers: a ceiling per refund, a ceiling per customer per period, a daily total across all customers, each tied to conditions the agent checks against the system of record. A named owner signs them off. The agent starts by drafting refunds for a person to approve and earns the right to issue them within the limits.
Why does one limit per refund not work?
Because it is easy to stay under. An agent allowed to refund up to 50 per request can refund 49 five times to the same customer in a week, and nothing in a per-refund limit stops it. Customers who learn the threshold will split requests. A fault in the agent, or a prompt that tricks it, can issue many small refunds before anyone notices.
Layered limits close those gaps. Each layer catches a different failure: the per-refund cap limits a single mistake, the per-customer cap limits abuse by one person, and the daily total limits a systemic fault.
What are the steps, and who does each?
- Finance and support lead: list refund types. Late delivery, damaged item, missing item, service outage, duplicate charge. Each has different evidence and different risk. Evidence: a refund type list with the condition each requires.
- Support lead: define conditions per type. A missing-item refund needs a delivery scan showing non-delivery or a carrier confirmation. A duplicate charge needs two matching ledger entries. Conditions must be checkable from sealed records, not from what the customer says. Evidence: conditions written per type.
- Finance: set the three layers. Per refund, per customer per period, and a daily aggregate. Start low. Evidence: a limits table, versioned.
- Named owner: sign off. The person accountable for refunds approves the table. Evidence: dated approval.
- Agent, depth 2: draft first. The agent prepares each refund with the type, conditions met and amount, and a person approves. Evidence: drafts with approval decisions.
- Agent owner: certify. Replay the agent against past refund cases. Only when it clears every test does it issue refunds within limits at depth 3. Evidence: the test result.
- Finance: review monthly. Compare refunds issued with conditions met, look for clusters, adjust limits. Evidence: the review and any changes.
What does a limits table look like?
| Refund type | Condition the agent checks | Per refund | Per customer per 90 days | Above the limit |
|---|---|---|---|---|
| Duplicate charge | Two identical ledger entries | Full duplicate amount | Two | Held for finance |
| Late delivery | Delivery scan later than promised date | 10 | Two | Held for support lead |
| Missing item | Carrier non-delivery confirmation | Item value up to 60 | One | Held for support lead |
| Damaged item | Photo received and return booked | Item value up to 60 | One | Held for support lead |
| Goodwill | None | Not allowed for the agent | Not allowed | Person only |
A daily aggregate sits on top: say, a total of 2,000 across all customers, above which every further refund is held. A fuller version with credits included is in the refund and credit limits matrix for support agents.
The goodwill row is deliberate. Refunds that need no evidence are judgement calls, and judgement is where agents should not be set loose. The same logic applies to retention, covered in making retention offers within set limits, and to arrears, in agreeing repayment plans within set limits.
An illustrative example
Take an online homeware shop using the table above. A customer reports a missing lamp worth 45. The carrier record confirms non-delivery. The customer has had no missing-item refunds in 90 days. The agent issues the refund and files it with the carrier record attached.
A week later the same customer reports a missing rug worth 55. The carrier record again confirms non-delivery, but the customer has used their one missing-item refund for the period. The agent drafts the refund with both cases attached and holds it. The support lead sees the pattern, checks with the carrier and finds a fault with one driver's scans. She approves the refund and flags the route. The limit did its job: not to refuse the customer, but to make a person look.
Which controls keep the limits real?
- Limits enforced outside the model. The refund system rejects anything above limits, whatever the agent was told.
- Counts across channels. A customer's refunds in chat, email and phone count together.
- Conditions from sealed sources. A customer's statement that an item was missing cannot by itself trigger a refund.
- The lowest bound wins. If the type limit, the customer cap and the daily total disagree, the strictest applies.
Finance teams setting payment approval limits will recognise the same structure; see how to set approval limits for an AI agent in finance. Whether an agent should approve refunds at all is covered in whether an AI agent can approve a refund.
Where Pryme fits
In Pryme, your refund limits sit in the minimum chain beside role scope, certificate, sources and platform guardrails, and the lowest wins. Each verdict names which bound decided. See the AI support agent that knows when to say no.
Questions people ask
How low should we start?
Low enough that a week of mistakes would be affordable. Raise limits only on evidence from drafts and replay results.
Should limits differ by customer?
They can, by tier or tenure, if the rule is written down and applied the same way to everyone in that tier.
What if a person keeps approving the agent's held refunds?
That is evidence the limit may be too low. Review it, but keep the change deliberate and signed off.