In looking at this issue across several companies, I’ve noticed a disturbing trend / missed opportunity in how many SaaS companies classify the reason for customer churn. Roughly speaking, if companies were hospitals, they’d too frequently be reporting the cause of death as “stopped breathing.”
Yes, the patient who died stopped breathing; the question is why did they stop breathing. In churn-speak, “yes, the customer who churned issued a churn notice and chose not to renew.” The question is why did they choose not to renew?
Many people have written great posts on reasons customers churn and how to prevent them. These reasons often look like hierarchies:
Uncontrollable:
- Got acquired
- Went bankrupt
- Corporate edict
- New sponsor
Controllable:
- Failed implementation
- Product functionality
- Product ease of use
- Oversold / poor fit
These hierarchies aren’t a bad start, but they aren’t good enough, either. A new sponsor isn’t an automatic death sentence for a SaaS product. He or she might be, however, if the team using it had a rough implementation and was only half-satisfied with the product. Similarly, a failed implementation will certainly reduce the odds of renewal, but sometimes people do have the will to start over — and why did the implementation fail in the first place?
Physicians have been in the “churn” business much longer than SaaS companies and I think they’ve arrived at a superior system. Here’s an excerpt from the CDC’s Physicians’ Handbook on Medical Certification of Death — not a publication, I’d add, linked to by most SaaS bloggers:
For example, you might see:
I have not built out a full taxonomy here; classifying churn in this way remained a future item on my to-do list at the time we sold my last company. Nevertheless, while I know it’s not easy, I believe that companies should start trying to find a way to richly encode churn reasons using this “chain” concept so as to not lose critical information in encoding their data. Otherwise, we risk believing that all our customers churned because they sent us a churn notice (or some easily blamed “uncontrollable” event).
As one example:
- Churned, due to
- New sponsor, due to
- Failed implementation, due to
- Partner problem, due to
- Partner training
Or, another:
- Churned, due to
- Corporate edict, due to
- M&A, due to
- Product dissatisfaction, due to
- Oversold, due to
- Sales training
These aren’t perfect, but I’m trying quickly demonstrate the real complexity behind why customers churn. For example, happy customers might challenge a corporate edict issued after an acquisition — so you can’t just blame the edict. You have to look more deeply. If you knew that the customer fought the edict and failed, you might stop the chain there. But if you knew they were never terribly happy with the system because they were overpromised capabilities at the start, then you should code that into the chain, too.