Fini for refunds and returns

Fini handles refunds and returns end to end inside a deterministic Intent Rule: it identifies the customer, looks up the order or charge in your system through an Action, checks eligibility against your policy, submits the refund or creates the return through a second Action, and replies with the real amount, reference and timeline your API returned. Anything outside policy, above the amount you allow the agent to approve, or marked as sensitive goes to your team as an internal note or an escalation with the conversation history, and the AI Steps trace in the Inbox shows every step the rule ran. The agent never decides on its own whether a refund is allowed. Your API and the Checks in your rule make that decision, the agent collects what’s needed and explains the outcome. Policy questions that aren’t requests (“what’s your return window?”) are answered from your Knowledge articles without running the rule at all.

What Fini handles and what it hands to your team

Fini handles	Your team handles
Refund and return policy questions, answered from your Knowledge articles.	Exceptions to policy and goodwill refunds outside your rules.
Identifying the customer and the order or charge (User Attributes, plus a Read for the order id).	Refunds above the auto-approve limit you set in the rule.
Checking eligibility by calling your eligibility logic through an Action.	Refunds you’ve routed to review with Reply Rules (for example, Enterprise customers).
Submitting the refund, or creating a return and returning the label or instructions, through an Action.	Cases where the customer disputes a charge they don’t recognize (see Disputes and chargebacks).
Confirming the refund amount, reference and expected timeline, using the values your API returned.	Anything your Planning Prompt’s Escalation Topics send to a human, such as legal threats.
Explaining why a request isn’t eligible, using the reason your API returned.	Conversations where an Action failed and the agent escalated.

How it works in Fini

A refund flow is the same four-piece shape as the Cancellation flow walkthrough: a User Attribute for context, Actions for the work, an Intent Rule for orchestration, and Reply Rules for overrides. Returns add a branch, which is the multi-intent pattern from the Order status and changes walkthrough.

Building block	What it does for refunds and returns	Where
Tags	A Rulebook-enabled tag group with tags such as `refund_request` and `return_request`. The example uses a custom `Topic` group: turn on Tag Group available in Rulebooks, set Tag Selection to “Exactly one tag is selected”, and assign the group to your agent. (Default groups such as Type of Issue have their tag list and Rulebook availability locked.) Use each tag’s “when not to apply” section to separate a refund request from a refund policy question.	Tags
User Attributes	A `Customer Identity` attribute that exposes `customer_id`, `plan` and any flags you route on (for example `is_vip`). Turn on Use in Rulebooks for fields Checks and Reply Rules read; keep internal ids off Visible to AI.	Attributes
Actions	A read-only `Check Refund Eligibility` (or `Lookup Order`) Action, then a `Submit Refund` or `Create Return` Action. Each declares typed inputs and outputs, so Checks downstream can compare amounts with numeric operators.	Actions
Intent Rule	The behavior tree: an intent Check, a customer Check, a Read for the order id and reason, the eligibility Tool, then a Fallback that either submits the refund or explains why not.	Intent Rules
Reply Rules	Optional overrides. The documented pattern is Internal Comment with `Type of Issue Equals refunds`, so the agent drafts the reply for your team instead of sending it. Scope it with a User Attribute (for example `plan Equals enterprise`) if you only want review for some customers.	Reply Rules
Knowledge	Articles for the refund and return policy, timelines, and the fall-through paths (order not found, outside the return window). These answer policy questions and back up every path where the rule stops.	Knowledge
Guardrails	Reply checks before delivery, for example a Custom rule that fails replies promising a refund the rule didn’t confirm, or a URL allowlist limited to your own and your carrier’s domains for return labels.	Guardrails

Example behavior tree

The tree below is an example to adapt, not a template that ships with Fini. Rename tags, fields and Actions to match your system, and set the auto-approve limit to your own policy (100 is a placeholder).

Steps  (root)
├── Check: Topic Equals refund_request
├── Check: customer_id Is Not Null
├── Read:  extract `order_id` (String) and `reason` (String)
├── Tool:  Check Refund Eligibility            (read-only)
│     in:  customer_id, order_id
│     out: eligible, refund_amount, blocker_reason
└── Fallback
    ├── Steps  (auto-approve path)
    │   ├── Check: eligible Equals True
    │   ├── Check: refund_amount Less Than or Equal To 100
    │   ├── Tool:  Submit Refund
    │   │     in:  order_id, refund_amount, reason
    │   │     out: refund_id, refund_eta_days
    │   └── Reply: confirm refund_amount, refund_id and refund_eta_days
    ├── Steps  (eligible, above the auto-approve limit)
    │   ├── Check: eligible Equals True
    │   └── Reply: tell the customer the request is with the team,
    │              who will follow up directly
    └── Reply: explain blocker_reason and link the refund policy article

How it runs:

The intent Check is a deterministic backstop on the planner’s routing. If the conversation isn’t tagged refund_request, the Steps short-circuits, the rule does nothing on this message, and the agent falls through to its default reply from Knowledge.
The customer Check stops the rule cleanly if the customer couldn’t be identified. To ask for the account email instead, wrap the rule in a Fallback whose second child is a Reply, the graceful-recovery pattern in Intent Rules.
The eligibility Tool runs before anything with side effects. Its outputs sit outside the inner Fallback, so every branch below can use blocker_reason and refund_amount.
The Fallback tries the auto-approve path first. If the refund is eligible but above your limit, the second branch tells the customer a teammate will follow up, which Conversation Status records as Escalated to Human Agent. If the refund isn’t eligible, the last Reply explains why using the reason your API returned.

To confirm (internal, remove before publish): Is a Reply that tells the customer “a teammate will follow up” the recommended way for an Intent Rule to escalate (so Conversation Status tags it Escalated to Human Agent and the helpdesk handoff fires), or is there a dedicated escalate step we should document instead?

For returns, make the root a Fallback with one Steps branch per intent: the refund branch above, and a return branch with its own intent Check (Topic Equals return_request) that calls a Create Return Action and replies with the return label or drop-off instructions it returns. One rule with a Fallback root handling several related intents is the shape the Order status and changes walkthrough builds step by step.

Make the submit Action idempotent. A customer can send the same message twice before the first reply arrives, and each message re-runs the rule from the root. Pass a deterministic idempotency key in the Submit Refund body (for example ${order_id}-refund) so a duplicate Tool call doesn’t refund twice.

What you need

What	Why	Where
A way to identify the customer	The rule needs `customer_id` before it calls anything. Use a signed JWT in the widget, UI metadata, or the connected helpdesk’s user identifier as the attribute Source.	Widget, Attributes
An eligibility endpoint	Read-only. Returns whether the order is refundable or returnable, the amount, and a human-readable reason when it isn’t. Keep the policy logic in your system so it has one source of truth.	Your order, billing or payments system
A refund or return endpoint	The write call. Returns a reference id and timeline (and a label URL for returns). Should accept an idempotency key.	Your order, billing or payments system
API credentials scoped to these endpoints	Credentials go in the Data Step Headers JSON (for example an `Authorization` header). Scope the key to refund and lookup operations only. Endpoints you build should follow the API contract.	Actions
A Rulebook-enabled tag group	The intent Check and any Reply Rules read it.	Tags
Policy articles	Answer policy questions and back up the paths where the rule stops.	Knowledge
A sandbox for testing	Test Suite runs don’t dry-run your Actions, and Execute live actions calls your real systems. Use Simulate rule execution, or point the Actions at a sandbox while you iterate.	Test Suite

Guardrails and escalation

Decide up front which refunds the agent may complete on its own, and encode each boundary in the layer built for it.

Situation	Recommended behavior	How to configure it
Refund above your auto-approve limit	Don’t submit; tell the customer the team will follow up.	A numeric Check on the eligibility output inside the rule, as in the example tree.
High-value or Enterprise customers	Run the rule, but post the reply as an internal note for review.	Internal Comment card in Reply Rules with `plan Equals enterprise` (or `is_vip Equals True`) AND your refund tag. Note that the Tools in the rule still run.
Customer doesn’t recognize the charge	Route to your dispute or fraud process, not the refund rule.	Add the pattern to the Planning Prompt’s Escalation Topics, or a separate dispute rule. See Prompts.
Refund policy is changing	Escalate instead of quoting the old policy.	A time-bound instruction in Incident Info in Main Guidelines.
A human is already on the ticket	The agent stays silent.	No Reply with `Human Agent Assigned Equals True`.
The reply promises something the rule didn’t confirm	Rewrite, or escalate if the rewrite still fails.	A Custom rule in Guardrails, plus a “no fabricated commitments” rule in Main Guidelines Guardrails.

Reply Rules gate the reply, not the Tools. When an Internal Comment rule matches, the rule still runs and Submit Refund still fires; only the customer-facing confirmation is held. If a human must approve before money moves, stop the tree before the submit Tool (as the above-limit branch does) and let your team complete the refund in your own system.

What to measure

Open Analytics after a week of production traffic and scope it to this use case with the Tags filter (your refund and return tags) or the Intent rule filter.

Metric	Where	What it tells you
AI resolution rate for the intent	Conversation Status doughnut, share Resolved by AI, with the Tags filter applied	How many refund conversations the agent fully resolved. Deflection also counts conversations still waiting on the customer, so read resolution first.
AI Resolve Rate and Escalated Rate per rule	Intent rule breakdown row for your refund rule	Whether the rule is leaking conversations to humans.
Human escalation rate	KPI card, with the filter applied	The share your team picks up. Expect a floor from the above-limit branch.
Escalation reasons	Escalation reason filter and doughnut	API or System Failure points at an Action; Escalation Constraint is your own policy at work; the Customer requested human reasons show where customers lost confidence.
CSAT	Average CSAT card and the CSAT filter	Whether customers are satisfied with the outcome, including denials.

When a number moves, open the conversations behind it in Inbox and read the AI Steps trace. The first red dot shows where the rule stopped.

Order status and changes

Step-by-step build of a multi-intent order rule with eligibility checks, a cancel Action and blocked-path replies.

Cancellation flow

The canonical intent, identify, act, confirm walkthrough that refund flows share.

Intent Rules

Node types, Fallback patterns and chaining Tools, including a refund chain.

Reply Rules

Internal Comment, No Reply and Direct Reply, and how priority works.

Actions

Typed inputs and outputs, Data Steps and testing with Play.

Disputes and chargebacks

When the customer contests a charge instead of requesting a refund.

For a comparison of refund automation tools, see the guide on usefini.com.

Use cases

Walkthroughs

Industry setup

How-tos

Fini for refunds and returns

What Fini handles and what it hands to your team

How it works in Fini

Example behavior tree

What you need

Guardrails and escalation

What to measure

Order status and changes

Cancellation flow

Intent Rules

Reply Rules

Actions

Disputes and chargebacks

​What Fini handles and what it hands to your team

​How it works in Fini

​Example behavior tree

​What you need

​Guardrails and escalation

​What to measure

​Related

Order status and changes

Cancellation flow

Intent Rules

Reply Rules

Actions

Disputes and chargebacks

What Fini handles and what it hands to your team

How it works in Fini

Example behavior tree

What you need

Guardrails and escalation

What to measure

Related