I recently worked through a product question: how would you use voice AI to automate customer support calls about subscriptions? When I first answered it, I had a point of view. This post is about what happened when I pressure-tested it, and where my thinking sharpened.
So I went back to the problem. I stress-tested my first take, and a few things broke.
The leaky bucket
Subscriptions are roughly a $600 billion market, up about 80% in three years, according to Juniper Research. Physical subscription boxes alone are over $100 billion. This is how a huge share of e-commerce revenue is now structured.
But underneath that number there's the tension that subscriptions are just as easy to cancel as they are to start. At 5% monthly churn, you're losing roughly half your subscriber base every year just to keep the lights on. You're not growing, but you are refilling a bucket with a hole in it. And the hole can be the phone call or customer success. Cancellation is the biggest single reason subscribers call. A brand losing 500 subscribers a month at a $40 average order value is losing $20,000 a month before you even factor in lifetime value.
My first take was that cancellations are a revenue event, not a support problem. The phone call should work like a retention engine, built in three layers, each depending on the one before it:
Earn trust: Does the caller stay engaged long enough to tell us why they called? Most automated systems make the customer do all the work, "Press 1 for this, state your order number," and the moment callers hit that resistance, they shout "Agent!" So the first question isn't how to detect intent. It's how to earn the right to. You earn it by proving you know them before you ask anything: "Hi Sarah, I've got your account pulled up. Your order arrives Thursday. What can I help you with?"
Match the account: Do we know who we're actually talking to? A phone number is your opening bid, not your final answer. People call from work or a partner's phone, and numbers change. You layer on signals like recent orders and shipping status, then close the gap with one lightweight confirmation. Verification should feel like personalization, not interrogation.
Solve the problem: Can we automate the right action for the right person? For cancellations, that meant a save flow: skip, then pause, then discount, then cancel. Brands set the order, and the system runs the conversation.
I still believe most of that. The one piece I'd change is the save flow. What I missed was what sits underneath it. The engine I described would run the same way on every call and never get smarter. And that comes down to one problem.
The problem, reframed
But then when I pressure tested this again, my perspective changed. The past few months I’ve been so deep into the data weeds that I now feel like I can see things so much more differently than before. So, when I re-read the question, I really went from “let’s fix the bucket” to “hey, we don’t know anything yet and we need better rigor.”
My assumption I’m working with is that subscription brands struggle to keep subscribers who call to cancel because they never learn why those subscribers are leaving, so they can't offer anything that fits. This results in lost subscribers and recurring revenue the brand could have kept, which leaves brands in the dark and callers feeling unheard.
It has two sides. The brand never finds out why someone is leaving, so it can't offer anything that actually fits. And the caller feels unheard, because the call acts on what they said, not why they said it.
Everything after this solves one or both of those. The follow-up question and the matched offer are for the caller. The logging is for the brand.
Before getting into the new thinking, I want to be honest about four things I'd change from my first pass. I felt that I wasn’t very perscriptive as I could have been as a PM. I tend to lean more on data and using those insights to help me form my opinion more, but as I’ve grown, I’ve learned that while that might be helpful with long discovery periods, but now I’ve realized a few things: my unknowns were all questions and no decisions, so, I’d probably attach an assumption to debunk. Another thing I noticed was, and this is the biggest one, I was measuring outcomes but not the journey. Did they cancel or not? Without tracking each step of the call, the save flow runs the same sequence every time and never learns. So, my rethinking around this was solely focused on: “what do I need to find in order to better understand all of the nuances within this data?” Lastly, I assumed save flows were the missing piece. When I looked at how automated cancel flows typically work, most already route calls by a few fixed reasons, and the main save offer is a skip. So the foundation is often there for these AI companies. My argument is about what comes next. A few fixed reasons is a coarse view of why people leave. Skip is one offer for many problems. And nothing tells you which offer actually worked.
Start with status, not cancel
In my first pass, I put cancellations first, simply because they were the most common call and carried the highest dollar stakes. But reflecting on what it actually takes to build reliable voice agents in production, that was the wrong starting point. If you start with cancellation, you're building complex save logic, follow-up questions and brand-specific offer rules on top of tracking you haven't tested yet. Instead, I'd build subscription status first. It has low ambiguity and a clear success metric: did the caller get accurate subscription info, like their next charge date, items and price? It lets you test the account lookup, the phone line's response time and the call logging end to end, with very little risk to the brand.
Then, I’d run the cancel data work in parallel. While status is live and proving the plumbing, you pull transcripts, find the most common reasons people cancel, and map how each brand wants its offers ordered. By the time you write the first line of cancellation logic, the data underneath it is solid.
From there, simpler actions like shipping now or updating details plug into the same setup, and any other long-tail queries get an audit first, to make sure you aren't miscategorizing new kinds of calls before committing engineering time.
Generative vs. agentic
Also, now I want to talk about how I feel about generative vs. agentic AI after seeing it a bit more up close. A purely generative system is great when the customer's intent is clean and everything goes to plan. But voice calls rarely work that way. When an AI hits ambiguity, like an unexpected life event or vague hesitation, it either makes up an offer, dead-ends the caller, or dumps them into a fallback loop. I saw this exact issue break in an AI agent I built. It would reach a point where it didn't have enough information to act, and it had no rule for what to do next, so the user was left stuck.
That's why you need an agentic setup because generative prompts absolutely fall flat every time. Users aren’t even using AI that way anymore - they’re asking for it to do more than that. The AI understands the caller, but clear rules decide what happens next. It knows how to ask a targeted follow-up question, and it knows what to do when the answer is unexpected. Here's what those rules look like for intent:
Above 80% confidence: act.
Between 50% and 80%: ask one confirming question. Not three, one.
Below 50%: hand off to a person, with everything captured so far, so the caller never repeats themselves.
And confidence isn't only about what someone wants. What wasn't clear is the why. That's where the follow-up question earns its place, and you'll see it below.
What I'd validate, and the defaults I'd set until then
In my first take, this was a laundry list of open questions. But a PM's job is to make sensible bets until the data proves otherwise. So here's each question, paired with what I'd do in the meantime.
What does the current save rate look like? Until I know, I'd use about 10% as the baseline and aim for 15–20% with offers matched to the reason. Without a benchmark, you can't tell if the save flow is helping.
How nuanced are cancel reasons, really? I'd start with the four or five most common reasons from real transcripts, and log the detail underneath each one. Otherwise you over-engineer edge cases and under-serve the majority.
Where do callers disengage? I'd track hesitation and drop-off from day one, so we don't miss the moment a caller checks out.
What order should offers come in? Match the offer to the reason. If the reason is unclear: skip, then pause, then discount, then cancel, with one offer max. Get this wrong and you serve the wrong offer first, hurt the brand, and risk breaking state renewal laws.
The 10% came from Recharge, a subscription platform, launched pause, merchants saved about 9.6% of would-be cancellations with that single option, across more than 1,700 merchants. That's one generic offer. Matching the offer to the reason should do better.
On drop-off: in voice, people rarely hang up out of nowhere. Long pauses and confusion come first. If you don't measure those small moments, you can't fix them.
On offers: discount is the lowest priority, and only appears when the brand turns it on. And it's capped at one save attempt. The FTC's click-to-cancel rule was struck down in court, and the FTC has since reopened it. But state auto-renewal laws, like California's, already require that a caller be told they can still cancel, and that the cancellation happen promptly once they say no. So the rule is one offer, clearly optional, then cancel. That keeps every brand compliant today and holds up if a federal rule comes back.
Proof of concept: Sarah's call
I didn't want to just describe this. So I built it.
Sarah calls to cancel. She's moving internationally, and she doesn't know a pause option exists. The prototype shows what happens when the system asks one follow-up question instead of acting on what she first said. On the left is the conversation. On the right is what that conversation produces in real time: the events firing, the learning loop updating, the metrics moving. That's the argument. Not the call itself, but what the call teaches the system.
Here’s the prototype
Moment 1: The greeting. Before Sarah says a word, we've already matched her account from her phone number. The first few seconds are when a caller decides whether to talk to a bot or hit zero. If she hears her name and her actual order, she has a reason to stay. And because every step is logged, we can measure that too: how often callers ask for a human in the first ten seconds.
Moment 2: Sarah says cancel. A generative system takes that and processes the cancel. The intent is clear, so why wouldn't it? But cancel is what she asked for, not why. And the why decides what we offer.
Moment 3: The follow-up question. One question is all it takes. She's moving abroad. The reason is logged as relocation, international. That's a data point we didn't have a second ago.
Moment 4: The routing decision. The default order would offer a skip first. But skipping one order doesn't help someone who's leaving the country. That offer would feel tone-deaf, and she'd hang up. So the system skips the skip and goes straight to a six-month pause. The default order only kicks in when we don't know why someone's leaving. And since we only get one offer, picking the right one is the whole game.
Moment 5: Saved. "I didn't know that was an option. Yes, perfect." She didn't know a pause existed. Most callers don't. That's a subscriber we keep, and a known date when she's likely to come back.
Moment 6: What the call teaches. This is the part I care about most. The outcome is logged: pause offered, accepted, subscription moved from active to paused. Once enough relocation callers take the pause, it becomes the default offer for that reason. No guessing needed.
Where this goes: from saving revenue to finding it
Everything above is built on an assumption: I don't know what any one brand's data looks like yet. That's why so much of it is defaults.
But tracking every step of the call changes that. Every offer, every hesitation, every reason becomes a new data point, stored at the call level. Each default becomes a measured number, and every call checks a bet. Once that exists, that's where I'd start digging, not only into how we save the subscriber on the call, but into where the revenue is.
A few places I'd look first:
Are "ship now" callers really people who need a bigger plan?
Who would have stayed without the discount, so we're not giving away margin we don't need to?
Do skips or detail changes show up before a cancel? If so, a brand could reach out before the customer ever calls.
And it closes the loop for the brand. Instead of a cancellation count, they get a running view of why subscribers leave and which offers keep them.
I can't tell you today what we'd find. But I know where I'd look first.
