All use cases

Retain / Save

Cancellation-intercept save flow

A "please cancel my subscription" message is the most common reason members write in — and today it goes straight to a human who just processes the exit.

Close the loopBehavioral triggerRisk triggerChatIn-appPushWellness (B2C apps)Subscription

What it does

In a subscription femtech app, cancel and refund requests are the number-one support driver, and they are handled reactively: the message lands, an agent processes the cancellation, and a paying member is gone with no attempt to understand why. The mechanism here intercepts that request the moment it arrives in support, before anything is confirmed. It asks the one question that matters, listens for the real reason, and routes to the save that fits — a pause for someone short on time, a downgrade for someone watching cost, a human check-in for a member who feels the app stopped working for her. The cancellation still happens cleanly when she wants it; the difference is that the top support queue becomes a retention surface instead of a churn conveyor.

How it works

  1. 1
    Trigger. a cancellation or refund request arrives through support — a chat message, an in-app help thread, or a "cancel my plan" form — and is intercepted before the cancel is confirmed.
  2. 2
    Decision. the agent reads account memory (tenure, what she logged and used, prior tickets) and asks the single reason question, then maps the answer to a policy-bounded save rather than a blanket discount. A judge gates the exchange for tone and for the no-dark-patterns rule.
  3. 3
    Action. the matched save is offered in-thread — pause the plan, step down to a lighter tier, or hand to a human for a member whose reason needs a person — and if she still wants out, the request is passed cleanly to the self-serve cancel step.
  4. 4
    Follow-through. the stated reason and outcome are written back to memory for win-back and product teams; saves are reported as lift over a randomized holdout, and cancellation is always one step away.
Example
CustomerCan you cancel my subscription, I don't want to be charged again.
AgentI can do that. Before I pass it through — what's prompting it? If it's something I can sort out, I'd rather do that than lose you.
CustomerHonestly I've just been too busy to use it the last few weeks.
AgentThat happens. I can pause your plan for up to three months instead of cancelling — no charges in between, your cycle history and predictions stay exactly as they are, and it picks back up when you're ready. Want me to set that up, or still go ahead and cancel?

Configuration

How the agent is wired for this use case.

Triggera cancellation or refund request landing in support — cancel_request from a chat message, in-app help thread, or cancel form — intercepted before confirmation
Tools & actions
  • Messaging channel · intercept the request in the support thread and run the one-reason diagnostic in chat or in-app
  • App backend · read tenure, feature usage, and what the member logged to ground the reason mapping
  • Billing platform · execute the matched save inline: pause the plan or step down the tier
  • CRM · write the stated reason and outcome back for win-back and product teams
  • Memory store · recall prior tickets and offers already made; record the diagnosed reason
Autonomythe diagnostic and the policy-bounded save ladder run unattended behind judge gating; the agent stays in wellness framing and gives NO medical, diagnostic, or clinical advice; pause and downgrade are money-moving and execute within a bounded billing-action policy; the cancellation itself is handed to the self-serve cancel/refund step or a human, never blocked
Channelschat · in-app · push
Escalationa member whose reason needs a person (a complaint, a sensitive situation, a refund dispute) hands off to a human with full context; anyone who restates "just cancel" is routed straight through

What you need

The inputs this use case runs on. Your channels stay yours; the agent supplies the judgment.

Signals

cancellation and refund requests detected in support threads, refund-window status, auto-renewal date

Data

tenure and plan history, feature usage and logging activity, prior support tickets, customer memory of past offers

Guardrails

cancellation always stays one step away — no loops, no dark patterns; save ladder capped by policy and trained off discount-first reflexes; judge gating on the conversation; wellness framing only, no medical or clinical claims; human hand-off for sensitive reasons and refunds; randomized holdout for save-rate measurement; the client keeps owning the send channels

Metrics it moves

  • save-rateup, by turning the top support queue from a cancel conveyor into a reason-matched save before confirmation
  • churndown, as time-pressed and cost-sensitive members take a pause or downgrade instead of leaving
  • ltvup, and even a member who exits leaves a clean reason and a warm path back

Related use cases

Collect / Recover

Self-serve subscription cancel and refund in chat

the connected step that executes the cancel or refund this flow intercepts

Retain / Save

Cancel-flow save conversation

the cancel-button save this specializes for the femtech support queue

Retain / Save

Cancel-flow save for a wellness subscription

the cancel-button sibling for general wellness subscriptions

See it on your own customer journey

Bring one drop-off, one churn cliff, or one silent segment. We will show you what a proactive agent with memory and judgment does with it.

Book a demo