Refund handling is one of the few chatbot tasks with direct financial consequence. The way companies build it reveals how little discretion the model is usually given.
The decision is separated from the conversation
In most deployments the model does not approve anything. It gathers the order number, the reason and the date, then calls a policy service that returns an allowed or denied result.
That service is ordinary deterministic code holding the return window, the product exclusions and the customer's history. Its answer does not vary between identical requests.
The separation exists because a refund must be auditable. A finance team needs to explain any approval to an auditor, and a model's reasoning is not an acceptable explanation.
Thresholds control how much automation runs
Companies typically set a dollar threshold below which an approved refund executes automatically. Above it, the case routes to a person even when policy clearly allows it.
The threshold is a risk decision rather than a technical one. It reflects what the business is willing to lose to a mistaken or fraudulent claim in exchange for faster resolution.
Many operations also cap automated refunds per account per period. That limit is what stops a systematic abuse from scaling before anyone notices.
The model's real job is eligibility framing
What the model actually contributes is extracting structured facts from unstructured complaint text. A customer describes a damaged item in a paragraph, and the model turns that into a reason code.
Errors here are consequential in a subtle way. A miscoded reason produces a technically correct policy decision on the wrong facts, which looks like a policy failure rather than a model failure.
Denials are the harder conversation
Approving is easy. Explaining a denial requires stating the specific policy clause that applies without inviting an argument the bot cannot win.
Well designed systems return the reason from the policy service verbatim rather than letting the model paraphrase it. Paraphrase is where invented exceptions appear.
They also make the escalation offer immediately and without friction, because a denied customer who cannot reach a person is the case that becomes a complaint to a state consumer office.
The architecture generalizes
The same pattern appears in appointment changes, account closures and warranty claims. The model handles language, deterministic code handles consequence, and a threshold decides where humans enter.
Teams that skip the separation and let the model decide usually rebuild it after the first incident. The rebuild is expensive because the audit trail has to be reconstructed retroactively.
Understanding this split explains why chatbot refund experiences feel rigid: the rigidity is deliberate, and it is where the accountability lives.