Perspective
Free Your Plan Catalogue From the Billing Core and Sell the Plans Your Market Wants
A billing system can decide which plans you sell without anyone choosing it. We map what you run, then modernise in stages so that new plans reach customers sooner.
4-minute read5 November 2026
In Brief
- Plans get reshaped, delayed or never proposed because the billing system cannot split an allowance or build a revenue share. The cost sits in decisions never taken, so no report shows it.
- We see four actions: separate the catalogue from the billing core, rate new plans in shadow on real usage, migrate by cohort, and reconcile daily, including customers at the edge of the lifecycle.
- Thinqmesh maps what you run, decides whether to keep, modernise, replace or retire each application, and works in stages while the business keeps operating.
Commercial teams rarely describe their billing system as a constraint on strategy, yet many of them plan around one. A family plan with a shared allowance becomes a simpler plan, because the system cannot split the allowance across lines. A streaming bundle waits for the next release window. After a few years, product managers stop proposing what they know the system cannot rate.
The Limit Accumulates Quietly
Plan rules build up inside rating code and configuration over years, along with discounts, proration, taxes and the treatment of plans withdrawn from sale. Each new plan has to coexist with all of them, on every combination a customer might hold, and the test effort grows with the combinations.
The cost is hard to see because it sits in decisions never taken. A delayed launch can be counted, while the plan that was never put forward leaves no trace. Replacing everything in one programme concentrates the risk, and public regulatory cases show that errors gather at the edges of the customer lifecycle. We would separate the catalogue first, prove new plans in shadow, and move customers in stages.
Four Actions That Move the Limit From Billing to the Business
They reduce the risk taken at any one time, and the first of them delivers value before any customer moves.
Separate the Plan Catalogue From the Billing Core
Product managers define plans in a catalogue, and the billing core calculates what they define.
Plan rules that accumulate inside rating code and configuration take months to change. A separate catalogue gives commercial teams a place to build a plan, and gives engineers one defined interface to the core.
Get started
- List the plans you proposed and later reshaped because of system limits.
- Identify where each plan rule lives today.
Rate New Plans in Shadow First
Run a new plan against real usage, alongside the live bill, before any customer is on it.
A shadow run shows what the plan would have charged and exposes the combinations that do not work. Customers who hold mobile, broadband and a partner service together are where the surprises sit.
Get started
- Choose one new plan and a sample of real usage.
- Compare the shadow bill with the live bill and explain each difference.
Migrate by Cohort, and Test the Edges
Move a small group first, and include the customers at the edge of the lifecycle.
Expired SIMs and final bills for customers who are leaving are where ordinary tests pass while errors continue. Include them in every cohort, so that problems at the edges are found while the cohort is small.
Get started
- List the unusual states a customer account can be in.
- Add each one as a test case before the first cohort moves.
Reconcile Every Day During the Move
A daily comparison catches a difference while it affects a few accounts.
Compare billed amounts, usage and customer counts every day between the old system and the new. Agree in advance who investigates a difference and how quickly, so that nothing waits for the month end.
Get started
- Pick the three totals to compare each day.
- Name the person who investigates a difference the same day.
How Thinqmesh Solves This
We begin by mapping what you run, what it costs and what it connects to, because a clear view of dependencies lets one system be improved well. Each application then receives a decision, and the work proceeds in stages.
- Week 1
Your Portfolio, Mapped
We map the applications you run, their costs and their connections, so that dependencies are visible before anything changes.
- Week 2
A Decision for Each Application
Each application receives a decision to keep, modernise, replace or retire, with costs and risks stated in one place and the order of work agreed.
- Week 3
The First Application, Built in Stages
One application or integration of defined scope is built, with the existing system still running.
- Week 4
A First Version in Use, Documented
The first version is working, with documentation and named owners, so that your team can maintain it.
You finish with a decision for every application, one modernised application or integration working, and documentation your team can maintain. Later stages follow in the order you agreed.
