Customer retention is the share of the customers you had at the start of a period who were still customers at the end of it.
That is the whole definition and it takes one line. The interesting part is what the number cannot do, which is tell you anything about a customer who has not decided yet. Every retention report is written about people whose minds are already made up.
What is customer retention?
The customers you kept, divided by the customers you started with.
Count who was paying you on the first of the month, count how many of those same people were still paying on the last day, and divide.
It is the same measurement as churn rate read from the other end, and the two always add up to one. Whichever you quote is a matter of which direction you want the graph to point.
Retention curves get more elaborate than that. You can hold a cohort constant, measure by revenue rather than by logo, or track the same group over a year. None of the elaboration changes the thing that limits it, which is that every number in it describes a decision somebody has already taken.
There is a working version of this on the demo board, which is open without an account.
Why is a retention rate a lagging number?
Because you can only compute it after the leaving is finished.
By the time somebody appears in the churned half of the fraction, the sequence that produced them is months old. They wanted something, they did not get it, they stopped asking, they left.
The number arrives at the end of that and tells you the total, and it tells you nothing about which part of it you could still have interrupted.
That is a reason to keep a second metric beside it rather than a criticism of the first, and the second one has to be about people who are still here.
What does a feedback board know that a retention report does not?
Who is still paying you, what they asked for, and whether it shipped.
A board with billing attached can answer that directly. Open a request on ours and its voters list names everybody who voted for it, with what each one pays a month on their own row, so the count and the amounts are both sitting in front of you.
Both of those are about people who have not left, which is the half a retention report structurally cannot see.
The half that has left is a separate question and a colder one. The churn cost calculator puts a figure on that half, and is careful about what the figure is allowed to mean.
You can also ask it the plain question. The voters endpoint takes a churned filter, and sending false gives you the people who voted for something and are still customers. It needs the PRO plan and it refuses the published embed key outright, because it is the one part of the interface that is money.
The distinction that matters is between a request supported by people who already left and one supported by people who are still paying.
Those two rows look identical on an ordinary board, and they are not remotely the same object. The first is a post mortem. The second is a list of reasons somebody might stay.
How long have your paying customers been waiting?
Longer than you think, and the board can tell you exactly.
Every vote carries the date it was cast, and every paying voter carries the date their subscription started. Put those two together and you get the thing no retention report contains, which is how long a customer who is still paying you has been waiting for the thing they asked for.
A year old vote from somebody who has renewed twice since is not a quiet customer. It is a patient one, and patience is a resource that runs out without warning.
This is where a board earns its place next to a dashboard. The dashboard tells you the rate. The board tells you the names, the amounts, and the dates, and it does that in the same list your team already looks at.
What do you actually do with that?
Close the loop, which is the part almost everybody skips.
When a request ships, the people who voted for it should hear about it from you rather than finding out.
Publishing a release on ours emails the voters on the requests inside it, and that message is different from a general announcement because it is about a thing that person specifically asked for. There are limits on it worth knowing before you rely on it, and the changelog entry covers them.
The order you build in should also change. If two requests have similar vote counts and one of them is carried by customers who are still paying while the other is carried by people who left, they are not tied.
A vote can carry the weight of the customer who cast it, and that is the mechanism rather than the advice.
Retention work usually gets described as a set of habits. Send the check in email, run the survey, watch the usage graph. Those are fine.
What actually moves the number is shipping the thing a paying customer asked for and telling them you did, and the only way to do that reliably is to know which request came from whom.
The product is nine dollars a month, the revenue endpoints in the API need the higher plan, and a card is required for the fourteen day trial.
14 days, a card at signup, then $9 or $39 a month.
