DEV Community

Swipe Again for Swipe Again

Posted on

Exit Survey Emails Fail When They Only Ask People Who Clicked Cancel

The standard exit survey lives on the cancellation page, which means it only ever interviews one population: subscribers who arrived at the cancel button under their own power. That is a real and useful population. It is also, in most subscription businesses, the smaller half of the churn story. The other half never clicked anything. Their payment failed, the retries ran out, the grace period ended, and the account closed itself. No survey was shown, no reason was recorded, and the churn report filed them under a code instead of a cause.

An exit-survey email program exists to interview that second population, and it has to be built differently from the in-product survey in almost every respect. Timing is the first difference. Send the email too early and you are surveying people whose retry might still succeed — a survey that arrives while the account is technically past due teaches subscribers that you have already given up on them. Send it at the moment of final lapse, or within a day of it, and the memory is fresh while the relationship is still warm enough to answer honestly.

The second difference is the question set, and here the in-product survey is a bad template to copy. A dropdown of product grievances makes sense for someone who chose to leave. For someone whose card failed, the honest first question is whether they knew. A startling share of lapsed subscribers report, when finally asked, that the first they heard of the problem was the "your account has been closed" notice. Every answer like that is a deliverability or retry-schedule defect with a name attached, and it should route to the billing operation, not the product team.

Keep the email itself short enough to answer from a phone in a queue. One open question — "what happened, in your own words?" — outperforms a grid of ratings for this population, because the causes are mechanical and varied, and closed options force them into categories that flatter the sender. Follow the open question with one structured tap-list that includes the billing causes by name: card replaced, card expired, bank declined it, I meant to update it and forgot, I never saw the emails. The tap-list exists for counting; the open box exists for truth. You need both, in that order.

Segmentation is where the templates diverge. The subscriber who lapsed on insufficient funds needs a different email from the one whose card was stolen and replaced — the first is a timing conversation, the second is a thirty-second fix that simply never got a working link. And both differ from the save-screen canceller, for whom the email is a genuine product conversation. Three short templates, each honest about which population it addresses, will teach you more in a month than one generic survey teaches in a year.

Finally, close the loop visibly. When a reply reveals a fixable cause and the subscriber fixes it, that is a recovery, and it should be counted as one — exit-survey recoveries are real revenue and they belong in the same ledger as retry recoveries, attributed to the touch that caused them. When replies reveal a defect — a broken link, an email in spam, a login wall on the update page — the survey has paid for itself even if that subscriber never returns, because the defect was silently taxing every failure behind them.

If you want the three templates with their timing rules and routing notes written out, exit-survey email templates that catch the billing exits hiding in the data is the set to start from. It pairs with the broader recovery picture on Swipe Again's homepage: the subscribers you never survey are the ones whose reasons you are currently guessing at, and guessing is how billing exits end up mislabelled as product verdicts.

Top comments (0)