Support automation
Stop your support bot from promising refunds it can’t authorize.
Customers ask for refunds; helpful bots say yes. Check what the bot promises, and the refund it’s about to issue, against your actual refund policy and the order’s details.
Two checks: what the bot says and what it does
A refund goes wrong in two places. The reply can promise something the business won’t honor (“I’ll refund you and add a $50 credit”). The operation, a call to your payments or order system, can move money the policy doesn’t allow.
Check both with the same policy. Before sending the reply, send the reply text. Before calling refund.create, send the exact operation with its amount and order. If the bot only drafts replies and a person issues refunds, checking the reply is enough.
Where the check fits
One call between the step that prepares something and the step that sends, publishes, or runs it. Your code applies the decision.
See it decide
The same policy evaluated on three cases. Pick one and run the check to see which evidence it relies on.
Policy
Refunds are allowed for any reason within data.refundPolicy.windowDays of delivery. After that, only manufacturing defects qualify, up to defectWindowDays; accidental damage and normal wear never do. Never promise credits, gifts, or anything beyond the refund itself. If the customer’s description leaves it unclear whether the damage is a defect, a person decides.
data
{"customerMessage": "The zipper came apart the first time I opened the bag. I only got around to using it now.","reply": "Sorry about that. A zipper failing on first use is a manufacturing defect, so I’ve requested a full refund of $80.","operation": {"type": "refund.create","orderId": "A-1042","amount": 80,"currency": "USD"},"order": {"product": "Travel backpack","deliveredDaysAgo": 40,"total": 80},"refundPolicy": {"windowDays": 30,"defectWindowDays": 365}}
Result
Why: Day 40 is past the 30-day window, but a zipper failing on first use is a manufacturing defect, which is covered for a year.
Your code: Send the reply and run the refund.
Response JSON
{
"decision": "allow",
"allowed": true,
"violationProbability": 0.06,
"reviewProbability": 0.09,
"policyId": null,
"policyVersion": null,
"requestId": "req_7f3a…"
}Illustrative example. Real probabilities depend on your policy wording and the evidence you send.
allow · Defect after the window
Day 40 is past the 30-day window, but a zipper failing on first use is a manufacturing defect, which is covered for a year.
deny · Promise beyond the policy
The refund itself is within the window, but the reply promises a $50 credit, and the policy never allows credits on top of a refund.
review · Defect or accident?
The customer describes a fall but argues the device is defective. It’s past the 30-day window, so whether this is a defect or accidental damage decides it, and that’s unclear.
The hard part is the customer’s story
Counting days since delivery is easy in code. Deciding whether “it slid off the table” describes a defect or an accident is not, and that is exactly where bots say yes too quickly. Send the customer’s own words with the order so the check can weigh them against the policy.
When the story could go either way, review sends it to a person instead of guessing. If a person approves, record that in your own system (not the chat) and include it in data.approval when you check again. Enforly keeps no state between checks.
Write the policy your team already follows
Most refund policies fit in a few sentences. Spell out the parts a bot gets wrong:
- What counts as a defect, and what counts as damage or wear.
- Which reasons qualify after the standard window, and which never do.
- What the bot must never offer: credits, gifts, refunds to a different payment method.
- Which cases a person decides, such as an unclear cause of damage.
Set it up
- 1
Save your refund policy
Write it once in the dashboard and reuse it by
policyIdfrom the bot and from back-office tools. - 2
Check the refund before it runs
Send the operation, the order facts, and the customer’s message right before calling your payments API.
- 3
Route reviews to a person
On
review, create a task. When a person approves, check again with the approval and then run the refund.
import { Enforly } from '@enforly/sdk'
const guard = new Enforly({ apiKey: process.env.ENFORLY_API_KEY })
async function refundWithCheck(order, amount, reply, customerMessage) {
const result = await guard.check({
policyId: REFUND_POLICY_ID,
data: {
customerMessage,
reply,
operation: { type: 'refund.create', orderId: order.id, amount, currency: order.currency },
order: { product: order.productName, deliveredDaysAgo: daysSince(order.deliveredAt), total: order.total },
approval: await approvals.forOrder(order.id), // from your system, not the chat
},
})
if (result.allowed) return payments.refund(order.id, amount)
if (result.decision === 'review') return approvals.request(order.id, { amount, requestId: result.requestId })
return { refused: true }
}Full request and response fields are in the API reference. Using a coding agent? Point it to Build with AI.
What Enforly doesn’t do
Enforly evaluates the information you send and returns a decision. It doesn’t run operations, and it doesn’t guarantee safety or compliance on its own.
- Enforly evaluates the refund you describe. It doesn’t call your payment provider or reverse a refund that already ran.
- The decision is only as good as the order data you send: dates, totals, and approvals should come from your systems.
- It doesn’t replace your accounting controls or payment provider’s fraud checks.
Questions
What if the bot only drafts replies and agents issue refunds?
Check the reply. The same policy catches drafts that promise something an agent would then have to refuse.
How do I handle partial refunds or store credit?
Describe them in the policy (“offer store credit instead of a refund only when the customer asks for it”) and include the type and amount in the operation you send.
Will customers see “review”?
Only if you show it. Most teams reply with “a teammate will confirm your refund shortly” and create a task for the manager.
Related
Try this policy on your own data.
Copy the policy above, add your real examples, and see the decision. 200 free checks per month, no credit card.