AI exit interviews: the new way to understand churn

An AI exit interview is a short spoken question asked at the moment a customer cancels, transcribed and classified automatically rather than read by a human. The customer says why they are leaving in their own words, and software turns that recording into a transcript, a churn reason, a sentiment, and a one-line summary, fast enough that a save offer can appear before the cancellation finishes.

Companies have run exit interviews for decades, usually by having someone senior call the departing customer. What changed is that transcription and classification stopped requiring a person, so the format works at self-serve volume, on customers paying $29 a month, where nobody was going to schedule a call.

What separates an interview from a survey

A survey asks the customer to classify themselves. You hand them five categories and they pick the one that fits worst-least. That is optimised for your reporting, since radio buttons are trivial to count.

An interview asks the customer to describe their situation instead, so nothing gets rounded off. Here is a real spoken answer from a test run of the flow described below.

"the price is honestly the whole problem for us, we are a team of three and the next tier up costs more than our entire tooling budget for the quarter."

A dropdown records that as "Too expensive" and you file it under price sensitivity. The sentence says something more useful, which is that the jump between two of your tiers is too steep for a three-person team. That is not a discount problem. It is a pricing-page problem, and it is probably costing you customers who never reached the cancel button. The dropdown could not have told you, because that option was not on the list.

Why voice, specifically

Text boxes already exist on most cancellation pages and they are mostly empty. The reason is effort. A customer who has decided to leave is spending their remaining goodwill, and composing three sentences is more work than they want to do for a company they are exiting.

Speaking is a lower-effort format for the same content. Most people talk more freely than they write, self-edit less, and include the incidental detail that makes an answer actionable, such as team size, budget cycle, or which competitor they moved to. A free-text field gets "too expensive" typed into it. A microphone gets the paragraph.

Some customers will not talk to a microphone at all, which is why the format only works if skipping is genuinely free.

The mechanics, step by step

Here is the flow as it actually runs, using Outro as the reference implementation since the screenshots come from it.

1. The customer clicks cancel in your app and lands on a branded page at outro.so/c/<slug>, or on an inline embed inside your own UI.
2. They record one voice answer, or type instead, or skip entirely.
3. ElevenLabs transcribes the audio. OpenAI translates it if needed and classifies it.
4. A retention offer matched to the detected reason appears before the final cancel step.
5. If they accept, the offer applies to their subscription automatically, with one provider caveat noted below.
6. Either way they return to your return_url with outro_response_id, user_id, and outro_offer appended, so your app knows what happened.

Two details matter more than the layout. The structured radio buttons are still there, because aggregate reporting is easier with them and some customers prefer clicking to talking. And the line stating that the voice will be transcribed by AI sits directly above the record button, not in a footer or a tooltip.

A third detail is where most flows go wrong.

Skip has not moved. It is there before recording starts, during, and after. There is a visible elapsed timer and an explicit stop control, so the customer always knows the microphone is on and for how long. A flow that hides its exit once recording begins has turned a research tool into a dark pattern.

Be precise about what is retained, because this is the part people get wrong. The recording is transcribed on the fly and is not kept as a playable audio file, so there is no library of voice clips to manage. What is stored is everything derived from it, meaning the transcript, the translation, the sentiment scores and the classification. That derived text is personal data and it persists, so it belongs in your privacy policy and your data-retention thinking exactly like any other customer record.

The practical difference is that you have no recording to revisit, so the transcript is the record. If a customer asks you to delete what they said, the transcript is what you delete.

What the output looks like

The classification produces two separate things that are easy to confuse.

The churn reason comes from a fixed taxonomy, which makes it countable across months. Seven values, stored as these exact identifiers, which is what you will see in a CSV export rather than the display labels:

too_expensive     price, cost or budget is the driver
missing_features  they need a capability the product lacks
not_using         low usage, no longer needed, forgot about it
too_complex       hard to use, confusing, steep learning curve
technical_issues  bugs, errors, performance, reliability
switching         moving to a competitor or alternative
other             no clear product reason, or one outside these

Fixed on purpose, since a taxonomy that drifts cannot be trended. The other bucket matters more than it looks: without it, a classifier forced to choose among the six real reasons will file unintelligible or out-of-scope answers under whichever fits least badly, and you will read that as signal.

The feedback classification describes what kind of message the response is, independent of why the customer left. Responses come back tagged as Bug report, Feature request, Praise, Question or Other, each with a sentiment of Positive, Neutral or Negative. A customer can leave over price and still file a bug report on the way out.

Alongside those you get a one-line summary. These three are real, from live runs.

• Summary one : "The user expresses concern about pricing being a significant issue for their small team."
• Summary two : "The user experienced a bug with the dashboard not loading and slow support response, impacting their confidence."
• Summary three : "The user experienced confusion during setup and struggled with widget embedding and offer configuration."

Those are compressions of what the customer said, not diagnoses. Summary three tells you setup confusion exists around embedding and offer configuration, but not which of the two was the blocker. You still have to think.

In the dashboard, the responses that need a human get pulled forward.

This panel earns its keep. It filters to negative sentiment and bug reports, the subset where a human reply might still change the outcome, or at least stop the same bug churning the next customer.

Across responses, recurring words get counted.

Those counts come from sixteen responses on a test account, nine spoken and seven typed, spread over a handful of dates. That is the honest caveat for a screenshot like this. Sixteen responses is not a trend, whatever a line chart drawn through them looks like. The panel shows the shape of the output, not evidence about a real business. With a quarter of real cancellations behind it, the interesting rows are the middle ones, since "team size" and "budget" together is a more specific signal than "pricing" appearing a lot.

The feedback classifications aggregate too.

This answers a different question from the churn taxonomy. It tells you whether your cancellation page is functioning as a bug-report channel, a feature-request channel, or neither. If bug reports dominate, your churn problem is a quality problem and no offer will fix it.

Acting on it in the moment

The interview happens before the cancellation completes, so the answer can change what the customer sees next.

That offer was served in response to the pricing answer quoted earlier. A customer who said the tier jump broke their budget gets a discount. A customer who said they were not using it gets a pause, since a discount on a product you never open is not an argument. A customer reporting a bug gets neither.

Billing behaviour differs by provider, and this is a real limitation rather than a footnote. With Stripe connected, an accepted offer applies to the subscription automatically. With Lemon Squeezy, pause and downgrade apply automatically but discounts do not, because the Lemon Squeezy API does not expose that operation. If your retention strategy is discount-led, plan on applying those by hand.

For how offers should be structured and sequenced, cancellation flow examples goes deeper than there is room for here.

Counting a save honestly

A save is easy to fake. Count the moment someone clicks "keep my subscription" and your dashboard looks excellent while revenue does not move, because a share of those customers cancel again three weeks later.

The defensible definition has two conditions. A save counts only after a 14-day grace window has passed, and only if the subscription is still live at the end of it. Anyone who accepts an offer and leaves anyway inside those two weeks was never saved.

The aggregate arrives on a schedule. A digest lands every Monday covering who left and why, MRR at risk, MRR saved, top reasons, and how the offers performed. To work out what a few points of retained churn is worth before investing in any of this, the churn calculator does that arithmetic.

What it costs

Pricing is per month, with voice minutes as the metered resource.

Plan	Monthly	Annual	Voice minutes per month
Free	$0		10
Starter	$29	$290	100
Pro	$79	$790	300
Scale	$199	$1,990	1,000

Voice minutes are the number to size against, not seats or subscribers. Exit interviews run well under a minute, so an allowance covers more cancellations than the raw figure suggests. Work backwards from your monthly cancellation count, assuming a fraction will skip or type rather than talk.

Languages

Two numbers get conflated here. Spoken input is transcribed and translated from 30 or more languages, so a customer in São Paulo can answer in Portuguese and you read it in English. Separately, the interface is available in seven reading locales, which are English, French, Spanish, German, Portuguese, Japanese, and Chinese. A customer can speak a language the interface does not display.

Where AI exit interviews do not help

An AI exit interview does not create demand. If a customer's project ended, their company was acquired, or their role changed, they are leaving, and a well-timed 50% discount is money handed to someone who was going to churn anyway. No amount of classification changes that. Churn splits into the part you can influence and the part you cannot, and exit interviews improve what you learn about the first while doing nothing about the second. For most self-serve SaaS the influenceable share is large, which is why the format pays for itself, but it is a share and not the whole.

A few more limits, stated plainly.

• It does not fix the product : knowing that setup confuses people is not the same as fixing setup. The interview shortens the diagnosis, not the work.
• It is not a substitute for talking to active customers : cancellation is the worst possible moment to learn something you could have learned in month two.
• Small numbers stay small : at eleven cancellations a month, no analysis layer makes that an interesting dataset. Read the transcripts and use the classification for filing, not inference.
• Skips are data : a high skip rate tells you how the page reads, not that customers had nothing to say.

Common mistakes

Making the interview mandatory. Blocking the cancellation until a customer answers generates complaints, chargebacks, and screenshots on social media. Skip must stay visible throughout, recording included.

Burying the consent line. The customer needs to know their voice is being transcribed by AI before they press record, in the same visual block as the button. A privacy policy is technically compliant and practically dishonest.

Treating the taxonomy as the answer. too_expensive is a bucket, not a finding. Six responses tagged too_expensive can be six different problems, and the transcripts are where the difference lives.

Conflating the two classifications. Churn reason and feedback type are different axes. A response can be switching and Praise at once, and merging them into one field loses the more interesting half.

Discounting everything. The same 50% off served to everyone destroys margin and teaches your base to cancel for a discount.

Expecting an API that is not there. Data comes out through the weekly digest and CSV export. There is no public REST API, no webhooks, no npm package, and no Zapier, Make, or Slack integration, so if your plan involves piping responses into a warehouse, plan on exporting CSVs.

Whether it is worth doing

The case is narrow and, within its bounds, strong. At the moment of cancellation a customer is maximally honest, because they have no relationship left to manage, and still technically yours, because the subscription has not ended. No other point in the lifecycle has both. Spending it on a dropdown that returns a category you already guessed is the actual waste.

What you get in exchange is a paragraph instead of a radio button, a classification you can count, and one chance to respond to the specific reason before the customer is gone. What you do not get is a fix for churn you were never going to influence. For the reasons behind the reasons, why SaaS customers cancel is the companion piece, and exit interview question templates covers what to ask once the microphone works.

Outro produced every screenshot above. It replaces your cancel button with one spoken question, classifies the reason, and shows a matched offer before the cancellation completes, on Stripe or Lemon Squeezy. The free plan includes ten voice minutes a month, enough to run the flow on your own account and read the output before deciding whether the format suits your customers. If it does not, that is a cheap thing to have learned, and reducing churn has other routes worth taking.