Churn, Before It Happens
Product concept · researched and developed, not built · never validated · everything shown is recreated in an invented booking tool
What did “at risk” actually mean?
Two different things, so I drew them separately.
- Sets up the business
- Adds services
- Sets availability
- Connects a calendar
- Publishes the booking page stalls here
- First booking
- Repeat bookings
The risk is that they never reach the first booking. Watch the path. If they stall, help with setup.
They've already walked the path, so the steps tell me nothing. Watch for their own normal breaking. If it breaks, find out what changed.
One definition of “at risk” would have produced one generic response. Two definitions meant two sets of signals and two different things to do.
What might indicate it?
Three of the candidates, each with the way it could be wrong.
- Setup finished, booking page never published.Wrong if customers who stay often publish late too.
- Regular bookings, then none.Wrong, often, for seasonal businesses. A quiet fortnight doesn't mean the same thing for everyone.
- Nobody logs in.Wrong if silence means it's working.
These were candidates, not predictors.
They came from patterns I'd seen working with customers, not from a validated analysis of churn behaviour. Every threshold in the prototype was a placeholder.
How long the first step took left out
I explored it, then left it out. It helps explain a cancellation afterwards. It doesn't tell anyone what to do about a customer today. Not every useful metric belongs in a risk model.
Flags, or a score?
Version one: flags
- Booking page not published
- No login for six days
Version two: a score
42/ 100
What does 42 mean if you haven't proved the weighting?
The score is easier to sort by, and easier to believe than it deserves. I left it as an open question.
What I'd test before using any of it
Look back
Take customers who left and customers who stayed. Did these behaviours actually differ, and how early?
Shadow run
Flag live accounts and contact nobody. Count the false alarms and the real warning time.
Intervene
Only then act on some flags and not others, and compare what happens.
The dashboard wasn't the thing to validate. The signals were.
Where it stopped
Researched and developed into a product concept. It wasn't prioritised for implementation, so none of these signals were ever tested against real outcomes. It has no connection to the retention figures elsewhere on this site.
What I'd do differently
Start with the historical data before drawing a single screen. The interface was the least uncertain part of the whole idea.