Fini for cancellations and subscriptions

Fini handles subscription cancellations end to end in a deterministic Intent Rule: it confirms the customer actually wants to cancel, identifies their account, captures the reason, calls your billing API through an Action, and replies with the effective date, refund amount and confirmation id your system returned. The same pattern covers pauses and plan changes, and high-value accounts can be held for human review with an internal note instead of a direct reply. The step-by-step build lives in the Cancellation flow walkthrough, which is Fini’s canonical end-to-end example. This page covers the decisions around it: what to automate, what to keep with your team, how to confirm before acting, and what to measure.

What Fini handles and what it hands to your team

Fini handles	Your team handles
Cancellation policy questions (notice periods, what happens to data, refunds on cancel), answered from Knowledge articles.	Accounts you’ve reserved for people, for example Enterprise contracts or customers with an active balance.
Confirming intent before anything irreversible runs.	Retention conversations you want a person to have, such as a call before a large account leaves.
Identifying the customer and their plan (User Attributes).	Cancellations the billing API refuses for reasons that need judgment.
Capturing the cancellation reason, free text (Read) or structured (Form).	Reversing a cancellation, which is an operation in your billing system, not in Fini.
Cancelling, pausing or changing the plan through Actions, and confirming the real effective date and amounts.	Disputes about charges already made (see Disputes and chargebacks).
Nudging a customer who went quiet mid-flow, with an inactivity follow-up.

How it works in Fini

Building block	What it does for cancellations	Where
Tags	A `cancel_request` tag in a custom Rulebook-enabled group (the example uses `Topic`; default groups such as Type of Issue have a locked tag list), with a “when not to apply” section that separates a request from a policy question (`cancellation_inquiry`) or venting. Optionally a confirmation group (Action confirmation with `user_confirmed`, `user_denied`, `not_applicable`) that the rule reads before cancelling.	Tags
User Attributes	`Customer Identity`, exposing `customer_id`, `plan` and `is_vip`. Turn on Use in Rulebooks for all three; turn on Visible to AI only for `plan`.	Attributes
Actions	`Cancel Subscription`, with `customer_id` required and `reason` optional, returning `confirmation_id`, `refund_amount` and `effective_date`. Add `Pause Subscription` or `Change Plan` the same way if you offer them.	Actions
Intent Rule	Gates on intent, confirms, cancels and replies.	Intent Rules
Reply Rules	Internal Comment for `is_vip Equals True` AND `Topic Equals cancel_request`, the walkthrough’s review gate (the walkthrough uses the value `Cancellation`).	Reply Rules
Knowledge	Articles for the policy and the fall-through paths: account not found, account already closed, what happens if the cancel call fails.	Knowledge

Example behavior tree

The walkthrough’s tree cancels as soon as the intent matches. The variant below adds an explicit confirmation step, the first defensive pattern the walkthrough recommends. It’s an example to adapt: tag names and fields are placeholders.

Steps  (root)
├── Check: Topic Equals cancel_request
├── Check: customer_id Is Not Null
├── Read:  extract `reason` (String)
└── Fallback
    ├── Steps  (customer confirmed)
    │   ├── Check: Action confirmation Equals user_confirmed
    │   ├── Tool:  Cancel Subscription
    │   │     in:  customer_id, reason
    │   │     out: confirmation_id, refund_amount, effective_date
    │   └── Reply: confirm effective_date, refund_amount and confirmation_id
    ├── Steps  (customer changed their mind)
    │   ├── Check: Action confirmation Equals user_denied
    │   └── Reply: acknowledge, confirm the plan stays active
    └── Reply: summarize what cancelling the current plan means
               and ask the customer to confirm

How it runs: on the first message, the confirmation tag isn’t user_confirmed yet, so the Fallback reaches the last Reply and asks the customer to confirm. Each customer message re-runs the rule from the root, so when the customer replies “yes, cancel it”, the confirmation tag is applied during tagging (before the rule runs) and the first branch cancels. If the customer goes quiet after the confirmation question, a Follow up after inactivity setting on that Reply can send one reminder while the conversation is Waiting for customer. If you prefer an explicit button, use a Form with a single confirmation field before the Tool instead, as the walkthrough describes. Pair either approach with an idempotency key in the Action body built from values you have before the call (for example ${customer_id}-cancel; effective_date is a Tool output, so it isn’t available yet) so a duplicate message can’t cancel twice.

Pauses, downgrades and retention offers

Common adaptations, each a sibling branch under a Fallback root (the multi-intent shape from the Order status and changes walkthrough):

Pause instead of cancel. A pause_request branch calling Pause Subscription and replying with the resume date it returns.
Downgrade. A plan_change branch with a Check on plan, then a Change Plan Tool.
Retention offer. If your billing system exposes an offer endpoint, a Tool that fetches the offer for this customer runs before the confirmation question, and the user_denied branch applies it. Keep offer logic in your system, so the agent only presents what your API returned.
Different review rules. Replace is_vip Equals True with plan Equals enterprise, or switch the Reply Rules card to No Reply to leave those customers entirely to your team.

What you need

What	Why	Where
A billing API	A lookup for the customer and a cancel endpoint (plus pause or plan-change endpoints if you offer them). Endpoints you build should follow the API contract.	Your billing system, called through an Action
Customer identification	Email or a customer token passed by the widget JWT, UI metadata, or the connected helpdesk, used as the attribute input.	Widget, Attributes
Credentials scoped to subscription operations	Stored in the Data Step Headers JSON (for example an `Authorization` header).	Actions
Idempotency support	Each message re-runs the rule; a repeated cancel must return the same result.	Your billing API
Tags	The intent tag, and the confirmation group if you use it, both with Tag Group available in Rulebooks on.	Tags
A sandbox	Test Suite runs don’t dry-run your Actions, and Execute live actions fires the cancel Action for real. Use Simulate rule execution, or point the Action at a sandbox.	Test Suite

Guardrails and escalation

Situation	Recommended behavior	How to configure it
VIP or Enterprise customer cancels	Run the flow, draft the confirmation as an internal note so a human can follow up first.	Internal Comment card in Reply Rules. The cancel Tool still runs; if it must not, stop the tree before the Tool for these customers with a Check on `is_vip`.
Account with an active balance or contract term	Hand to a human.	A Check in the rule that routes to a hand-off Reply, or an Escalation Topics entry such as “account closure with active balance” in the Planning Prompt.
Customer threatens to leave for a specific reason	Let the planner escalate on judgment.	Escalation Topics for fuzzy patterns; Reply Rules for hard predicates. The walkthrough recommends layering both.
A human is already on the conversation	Stay silent.	No Reply with `Human Agent Assigned Equals True`.
Customer can’t be found	Ask for the registered email, don’t call the API.	The `customer_id Is Not Null` Check, wrapped in a Fallback with an asking Reply.
Reply quotes a date or amount the API didn’t return	Rewrite or escalate.	A Custom rule in Guardrails, plus Main Guidelines guardrails against fabricated commitments.

What to measure

Scope Analytics to cancellations with the Tags filter or the Intent rule filter.

Metric	Where	What it tells you
AI resolution rate for the intent	Conversation Status doughnut, share Resolved by AI	How many cancellation conversations the agent completed. Conversations waiting on a confirmation count as deflected, not resolved, so watch the Waiting for Customer share too.
AI Resolve Rate and Escalated Rate	Intent rule breakdown row for your cancellation rule	Whether the rule completes or leaks to humans. If the escalated rate climbs while the rule keeps firing, the issue is in the Reply, the Action or Reply Rules.
Human escalation rate	KPI card, filtered	Your team’s cancellation workload, including the VIP review gate.
Escalation reasons	Escalation reason filter	API or System Failure for billing errors; Escalation Constraint for your own policy branches.
CSAT	Average CSAT and the CSAT filter	How customers felt about the experience of leaving, which affects whether they come back.

If you collect reasons with a Form, the structured values give you consistent reasons to report on.

Cancellation flow walkthrough

The step-by-step build: attribute, Action, Intent Rule, Reply Rules gate, testing and troubleshooting.

Order status and changes

A Fallback-rooted rule handling several related intents, the shape for pause and downgrade branches.

Intent Rules

Node types, inactivity follow-ups and the Form pattern.

Refunds and returns

When the customer wants money back rather than to stop the subscription.

Escalation and handoff

Where escalated cancellations land and what your team sees.

For a comparison of tools for subscription cancellation, see the guide on usefini.com.

Use cases

Walkthroughs

Industry setup

How-tos

Fini for cancellations and subscriptions

What Fini handles and what it hands to your team

How it works in Fini

Example behavior tree

Pauses, downgrades and retention offers

What you need

Guardrails and escalation

What to measure

Cancellation flow walkthrough

Order status and changes

Tags

Intent Rules

Refunds and returns

Escalation and handoff

​What Fini handles and what it hands to your team

​How it works in Fini

​Example behavior tree

​Pauses, downgrades and retention offers

​What you need

​Guardrails and escalation

​What to measure

​Related

Cancellation flow walkthrough

Order status and changes

Tags

Intent Rules

Refunds and returns

Escalation and handoff

What Fini handles and what it hands to your team

How it works in Fini

Example behavior tree

Pauses, downgrades and retention offers

What you need

Guardrails and escalation

What to measure

Related