Raising Hosting Prices Without Losing Customers
Most providers carry legacy customers below cost because raising the price feels more dangerous than absorbing the loss. It usually is not — and it usually only needs to reach forty people.
Most providers carry legacy customers below cost because raising the price feels more dangerous than absorbing the loss. It usually is not — and it usually only needs to reach forty people.
Hosting has spent two decades training customers to expect the price they signed up at to last forever. Power costs, hardware costs, transit costs and staff costs have not co-operated, and a lot of providers are now carrying legacy customers below cost because raising the price feels more dangerous than absorbing the loss.
It usually is not. Here is how to do it without the churn event you are afraid of.
Before touching a price, sort your customer base by margin. Not revenue — margin. Most providers who do this discover the distribution is far more extreme than expected: a tail of legacy accounts on prices set years ago, consuming current-cost resources.
That list tells you the shape of the increase. If the problem is forty legacy accounts, a blanket rise across two thousand customers is an enormous amount of risk taken to solve a small problem. Targeted beats blanket almost every time.
For infrastructure businesses, revenue per kW and revenue per rack unit are the numbers that matter, because those are the resources you actually run out of.
The mechanics of the increase matter less than the notice. Two things make it defensible:
Check your terms first. Whatever your contract says about price changes and notice periods is the floor, and for consumers in many jurisdictions there are statutory notice and cancellation rights on top. Confirm before you announce, not after.
Give more notice than you have to. Thirty days is a legal minimum in many places and it feels abrupt. Sixty to ninety days on the annual anniversary reads as planning rather than opportunism, and it gives customers time to budget — which is what business customers actually need in order to say yes.
Most price-increase emails fail on tone, not economics. The pattern that works:
Raise new-customer prices first. Move the list price and grandfather existing customers for a defined period. Costs you nothing in churn, improves margin on every new sale, and narrows the legacy gap over time by attrition.
Build in an escalator. A defined annual adjustment written into new contracts converts a confrontation into a clause. Standard in colocation and increasingly reasonable elsewhere — see billing colocation.
Change what is included rather than the number. Adjusting the bandwidth allowance or IP allocation on new plans moves effective pricing without a headline increase. Legitimate when transparent, and corrosive if done quietly to existing customers.
Retire legacy plans on renewal. Migrate to the nearest current plan at the anniversary, with notice. Slower, far less dramatic than a mass increase.
Some customers will leave. That is not failure, it is the mechanism working — the ones most likely to leave are usually the least profitable, which is why you are doing this.
Model it before you commit: at what churn rate does the increase stop being worth it? If a 15% rise loses 5% of those customers, you are ahead. If it loses 40%, you have mispriced. Knowing that break-even in advance turns the decision from a nerve question into an arithmetic one, and stops you reversing a correct decision after the first three angry emails.
Make sure the increase actually applies. A price change on the product catalogue does not always propagate to existing subscriptions — in many platforms, active services carry their own price and keep charging the old one indefinitely. Test on one account before announcing to two thousand.
Then check the mid-cycle behaviour, the proration on the first invoice at the new rate, and that anyone on an annual cycle is picked up at their anniversary rather than immediately. See proration for mid-cycle changes.
And send the notice from the same system that will issue the invoice. Announcements sent from a marketing tool while invoices come from the billing platform is how customers get told about an increase that then does not happen, or worse, one that happens without the email.
FluxBilling supports scheduled changes that apply at renewal rather than immediately, and the daily lifecycle run applies pending changes before renewal invoices are generated — so a scheduled price change lands on the next invoice rather than one cycle late. Products carry their own pricing and upgrade configuration, and services can be moved between plans with proration handled by a single calculation path.
Renewal reminders and invoice reminders run in the same daily pass, so the notice and the invoice come from the same system and the same customer records.
See billing features.
Sort the customer base by margin this week. You do not have to act on it — but almost every provider who has never done it finds a tail of accounts they would not accept at that price today, and discovers the increase they were dreading only needs to reach forty people.
The first datacenter is simple. The second breaks the assumption that an IP address, a price and a piece of hardware are properties of a service rather than properties of a place.
The gap between a signed colocation contract and a customer who is racked, powered and billing correctly is where operators lose time and sometimes the revenue entirely.
Colocation breaks generic billing software because you are selling physical space, a power envelope and a set of hands. Four or five recurring lines, each measured differently.