Blog · Board and management reporting
How to compute customer lifetime value from data a B2B company actually holds: contribution per year per customer from the ledger and cost to serve, expected remaining life from the company's own churn by segment and tenure, and the two together, with the range rather than a point, the identity that ties it to the ledger, and the four assumptions that turn an honest figure into a marketing one.
Customer lifetime value is quoted at every board with a confidence the arithmetic does not deserve. The ledger and the company's own churn history can produce an honest version: contribution, not revenue; life from this company's churn by segment and tenure; a range, not a point. This guide sets out the computation and the four assumptions that inflate it.
Per customer:
Annual contribution = revenue − cost of goods − cost to serve, trailing twelve months Expected remaining life = from the segment's churn rates by tenure band, at the customer's current tenure Lifetime value = annual contribution × expected remaining life, discounted at a stated rate Range = the same at the stated confidence bounds of remaining life
Per segment: the median, and the range.
Customer identifiers only.
Σ customers' annual contribution = ledger contribution for the period
If it does not hold, the lifetime figures are built on a contribution total that is not the company's.
| Segment: mid | Tenure band | Annual churn |
|---|---|---|
| Year 1 | 24% | |
| Years 2 to 3 | 11% | |
| Years 4 to 7 | 6% | |
| Year 8+ | 9% |
A year-three customer's expected remaining life follows from those rates, and so does the range. A year-one customer's is shorter and wider, which is what the acquisition-cost decision needs to know.
| Customer | Segment | Tenure | Revenue | Contribution | Expected life | LTV, discounted | Range |
|---|---|---|---|---|---|---|---|
| 2207 | Mid | 3 yrs | $410,000 | $48,000 | 7.2 yrs | $290,000 | $140,000 to $470,000 |
| 4471 | Mid | 3 yrs | $380,000 | $9,000 | 7.2 yrs | $54,000 | $26,000 to $88,000 |
| 9034 | Small | 1 yr | $60,000 | $14,000 | 3.1 yrs | $38,000 | $9,000 to $71,000 |
Customers 2207 and 4471 have similar revenue and the second is worth a fifth of the first, because of what it costs to serve. A revenue-based lifetime value would have called them equal.
| Assumption | Effect | Honest version |
|---|---|---|
| Revenue instead of contribution | Every customer worth more; ranking wrong | Contribution |
| One churn rate for the base | Young customers overvalued; old undervalued | By segment and tenure |
| Infinite horizon | The tail carries most of the value | Cap at a stated horizon |
| Zero discount rate | Year twelve worth as much as year one | Stated rate |
A single company LTV. Describes nobody; used everywhere.
Point estimate. Read as a promise; the range is the honesty.
Cost to serve ignored. The expensive large customer is the most valuable.
Churn from a benchmark. Someone else's customers' lives.
Mapped once, the ledger, the cost-to-serve rates and the customer master produce contribution, the churn bands, expected life and lifetime value with its range per customer and segment every quarter. Covirage builds this from the exports as they are. The board reporting solution describes the setup, and the B2B churn guide covers the churn rates that expected life comes from.
Because a customer's lifetime revenue is not what the customer is worth. A large account with daily drops and heavy returns can have a high revenue lifetime and a low contribution lifetime, and decisions about acquisition cost and service level are made on the second.
From the company's own churn by segment and tenure band: a customer in year three of a segment with 8 percent annual churn at that tenure has an expected remaining life computable from that rate and the later bands. Not from a rule of thumb, and not from one rate for the whole base.
Because expected life is an expectation over a distribution, and a customer's actual life will be shorter or longer. The range at a stated confidence, from the same churn data, is what stops a point estimate being read as a promise.