In this, we'll cover the absolute bottom of the funnel. I suggest starting here for steady-state businesses because the best practices are pretty established, and there are not a lot of product development risks/unknowns. Also, you likely spent a lot of money in marketing and/or product development to get paying users, so the highest ROI work you can do is set up the basics to ensure you don't lose them, especially for preventable reasons. There are two basic scenarios in which people will try to leave your product, which should be handled differently. Intentional Churn - Someone actively canceling, either happily or unhappily.  Unintentional Churn - A technical problem that breaks service; these are likely payment-related problems but not always. Intentional Churn - Someone actively canceling, either happily or unhappily. Unintentional Churn - A technical problem that breaks service; these are likely payment-related problems but not always. Before we go down this rabbit hole, here are a few lessons I learned the hard way. The best way to decrease churn is by building a better product. Once someone has decided to cancel, it's very hard to change their mind.  You should implement all of the applicable best practices here but don't get lost here for too long, as the product itself is what matters.  Depending on the use case of your product, there will be an unavoidable "natural" churn based on the use case you're solving. Most users will not say around longer than that use case/problem exists for them. The best way to decrease churn is by building a better product. Once someone has decided to cancel, it's very hard to change their mind. You should implement all of the applicable best practices here but don't get lost here for too long, as the product itself is what matters. Depending on the use case of your product, there will be an unavoidable "natural" churn based on the use case you're solving. Most users will not say around longer than that use case/problem exists for them. INTENTIONAL CHURN INTENTIONAL CHURN This is where the user actively cancels the product. I would split this into two sub-scenarios: Happy churn  Unhappy churn Happy churn Unhappy churn "Happy" churn is when that user uses your product to solve a problem, the product solves the problem, and they leave happily. A good example is an interview prep product. A user came to you to prepare for an interview; they got the job and now don't need your product anymore. There are honestly not a lot of things you can do for this user in the short term; the best thing is to make cancellation easy so that they remember their experience here fondly and recommend it to their friends. Try to capture reviews on the way out and make re-activation easy if/when their need for this re-occurs. In the longer term, you can build secondary products that keep them engaged with you until they have the problem again (in the interview example, you could create a salary monitoring tool or something to that effect). Zillow's primary use case is home buying/selling, but as that doesn't happen often, there are many secondary use cases (such as price monitoring) that give you a reason to keep using the product whenever you're not in the market for a house. How/when to do that is a different topic, and I would first focus on making your main product make as much money as possible. "Unhappy" churns are where something went wrong, either within your control or outside of your control, and the user is leaving because of that. There are basically two steps here: 1. Get good at understanding why they are leaving. 1. Get good at understanding why they are leaving. Many companies have a cancellation survey, but the key is ensuring you have the full universe of reasons that a customer is actually leaving so that data is useful.  There is a very high likelihood that the reasons that you would guess that they are leaving are not the full list of reasons that they are out there.  The best way of finding that is by starting with an open-ended text field and manually compiling this every month.  Once you see a consistent grouping of answers, build a multiple-choice quiz at the end.  I suggest you always keep an open-ended question in there, as these reasons might evolve. Many companies have a cancellation survey, but the key is ensuring you have the full universe of reasons that a customer is actually leaving so that data is useful. There is a very high likelihood that the reasons that you would guess that they are leaving are not the full list of reasons that they are out there. The best way of finding that is by starting with an open-ended text field and manually compiling this every month. Once you see a consistent grouping of answers, build a multiple-choice quiz at the end. I suggest you always keep an open-ended question in there, as these reasons might evolve. 2: Take mitigating steps right before cancellation within that survey 2: Take mitigating steps right before cancellation within that survey I am too busy right now -> Can they pause their subscription and have it auto-restart in 1, 2, or 3 months?  Your product costs too much - Can you discount the next two months and then revert to full price?  I had technical problems -> Can you book the user time with a support team to get this fixed?  I no longer need X feature that I am paying for -> Can you down-sell them to a cheaper plan that only has what they need? I am too busy right now -> Can they pause their subscription and have it auto-restart in 1, 2, or 3 months? Your product costs too much - Can you discount the next two months and then revert to full price? I had technical problems -> Can you book the user time with a support team to get this fixed? I no longer need X feature that I am paying for -> Can you down-sell them to a cheaper plan that only has what they need? If you want to see this in action, the NY Times runs this version of the cancellation flow. It's always unclear from the outside if it's working, but I suspect it is. Needless to say, make sure you're using this data in your product development roadmaps to fix anything fixable. Unintentional Churn Unintentional Churn Unintentional churn is when something breaks, and users can't use the service anymore. In the subscription world, hands down, the most common scenario is payment failures. The more individual transactions that make up your revenue base, the more payment failures will be a problem and a big opportunity. They are scenarios like: Cards don't have enough balance on them  Credit cards expire and don't get updated  API's time out before transactions get completed  The fraud detection models that a payment processor uses throw a false positive and block a legitimate transaction Cards don't have enough balance on them Credit cards expire and don't get updated API's time out before transactions get completed The fraud detection models that a payment processor uses throw a false positive and block a legitimate transaction Payments are hands down the most boring but practical place to work for companies of any real size to invest in. There is literally no user intent to manage; people are already trying to pay you money. You just have to collect it. Every failing payment that you don't save might be a user who would have stayed with you for two more years. The upside is always hard to measure, but it's definitely there. If you have ever thought you bought something on Amazon only to get an email 20 minutes later that you need to update your payment method, you are seeing this at work. What is likely happening behind the scenes is that they are trying your card through multiple payment processing systems to maximize the chance that the transaction goes through, then not initiating the order until it does. For a small % of transactions, this will help the payment go through, and at their scale, this likely adds up to hundreds of millions of dollars. There are a few major levers you can pull here: Systematically re-trying failed cards for active users Systematically re-trying failed cards for active users This process in the industry is called "Dunning" and is a feature that you can enable in most subscription management platforms and a lot of payment providers (such as Stripe). Most of the platforms have an algorithm that will do things like: When you fail to charge a credit card, this process will wait a few days and recharge it.  If the CVV number is wrong, then it will try to guess a new one  When a card expires, it will try to guess the new number, expiration date, etc. When you fail to charge a credit card, this process will wait a few days and recharge it. If the CVV number is wrong, then it will try to guess a new one When a card expires, it will try to guess the new number, expiration date, etc. We got some great advice to set this up early, and it really paid off. Eventually, this was winning back hundreds of thousands of dollars a month. "Update Your Payment" - Emails and on-platform messaging "Update Your Payment" - Emails and on-platform messaging The best implementation of this has as little friction as possible and doesn't force the user to log back in to do it, especially when they open emails on their phone. Ideally, you also have the product itself show a user that they need to update payments. The ROI here will be driven by how often users return to the product. If you can pair this by getting them to add a secondary payment method as a backup, that will also greatly help. Testing new payment gateway combinations (Stripe, Adyen, Braintree, etc.) by transaction type Testing new payment gateway combinations (Stripe, Adyen, Braintree, etc.) by transaction type If you watch companies evolve, they use many different payment gateways as they grow. Of all of the areas in this guide, this is the deepest and the place where my understanding is the shallowest, so take that into account. (also, if you deeply understand this, I would love to talk to you) The overall goal is to prevent false positives in the risk models banks/processors use. These models take inputs like your location, your user's location, your legal entity, your bank location, the customer's payment method location, etc.  No one really can tell you what the right combination of all of these factors is for your business, but some processors are generally accepted to be more effective in certain countries. If you have a lot of users there, then this could be worth it.  We also got the guidance to set up legal entities in countries we were focused on and update the providers; we couldn't A/B test this, so it's tough to say if that worked.  We didn't get statistically significant results when we split test processors at around 50M in ARR, so this is likely a move that has to happen after that state. These models take inputs like your location, your user's location, your legal entity, your bank location, the customer's payment method location, etc. No one really can tell you what the right combination of all of these factors is for your business, but some processors are generally accepted to be more effective in certain countries. If you have a lot of users there, then this could be worth it. We also got the guidance to set up legal entities in countries we were focused on and update the providers; we couldn't A/B test this, so it's tough to say if that worked. We didn't get statistically significant results when we split test processors at around 50M in ARR, so this is likely a move that has to happen after that state. Also, using at least two payment processors is a good idea, as one will inevitably go down. They all claim 99.99% uptime, but across a long enough timeline, you'll have a few hours/days of outages. You might as well not lose that money. Conclusion Conclusion Payment processing is by far the least understood but one of the most effective levers you have for growth. Its technical and kinda painstaking ot work on, but the money is there. You just have to figure out how to collect it.

Stripe

Braintree

The Real Reason Big Companies Spend $10M+ on Checkout

Why Successful Companies Like Netflix Always Kill the Free Tier

Newsletter

Read My Stories

Founder

Head of Growth

Product 

Too Long; Didn't Read

Subscription Revenue Playbook, Part 2: Payments & Churn

Subscription Revenue Playbook, Part 2: Payments & Churn

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Annual Plans as a Churn-reduction Lever

What Are Convolution Neural Networks? [ELI5]

The Noonification: Have U Been Pwned? (1/12/2023)

Goldman Sachs, Data Lineage, and Harry Potter Spells

People are still crazy about Python after twenty-five years

10 Questions to Consider when Setting up a Corporate A.I project

Annual Plans as a Churn-reduction Lever

What Are Convolution Neural Networks? [ELI5]

The Noonification: Have U Been Pwned? (1/12/2023)

Goldman Sachs, Data Lineage, and Harry Potter Spells

People are still crazy about Python after twenty-five years

10 Questions to Consider when Setting up a Corporate A.I project

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps