One price increase, sent to everyone, treats a loyal customer and a switcher as the same person. Only one of them is still there next month.
German energy customers arrive through price comparison portals, where the headline tariff decides the sale. Providers acquire at a loss on purpose and attach a price guarantee to win the click.
The loss is recovered after the guarantee expires. That makes the first price increase the moment the acquisition either pays for itself or is written off.
A price increase in German energy supply carries a Sonderkündigungsrecht: the customer may leave on the spot. It is not a billing change, it is an invitation to leave, sent to the whole book at once.
The usual answer is one percentage for everyone, shaded down until it feels survivable. It is too large for the price-sensitive, who go back to the portal they came from, and too small for those who were never going to move.
Churn prediction alone does not help. Knowing who might leave says nothing about what to do, because what makes them leave is the number you are about to send.
The model predicts a price elasticity curve per customer: how their probability of leaving moves as the increase grows. A churn score describes a person. A curve describes the relationship between a decision you control and a behaviour you do not.
Predicted churn risk is crossed with the increase a customer would actually receive, producing a grid of cells. Each cell carries its own observed cancellation rate, share of base and headcount, so a pricing manager can see what a given increase does to a given group before it is sent, rather than after.
The grid exists because the pricing system could not send an individual price to an individual household. Elasticity was estimated per customer; execution had to be per cell, because the rollout had to be something the billing and pricing teams could run. That gap between what the model knows and what the system can act on is where most of the engineering in a project like this actually sits.
The groups set how large each increase is, not whether one happens. Price-insensitive customers carry more of the uplift; the ones whose curves turn sharply get less, or none. The business collects the revenue it planned for, from the people who stay to pay it.
The two books behave differently. Bill sizes and seasonality differ, and dual-fuel households weigh one against the other before deciding whether switching is worth the afternoon it costs them.
The two numbers are one mechanism seen from both ends: the customers who would have left kept their supply, and the customers who were never going to leave stopped being under-charged for it.
The grid also settled an argument. The lowest-risk group barely moved across the whole range of increases; the highest-risk group rose sharply past the top band.
That asymmetry is the business case. There is headroom on one group and a cliff on another, and a single percentage sees neither.
This needs a history of real price changes and what customers did next. If every increase you have made was the same for everyone, there is no variation to learn from, and the honest first step is a varied increase on one segment rather than a model.
Then find out what your pricing system can actually execute before anyone estimates a curve. Ours could not price per household, which set the shape of the whole solution. The model is the easy part.
Delivered by our founding team in a senior role at a leading consultancy.
Let's talk about what's achievable for your specific context.
Start the Conversation →