A realistic take on pricing architecture: the 2027 view

Spotting which part of your pricing is wrong is one job. Changing it on a live company, with customers on the old structure and a sales team quoting it, is another. That second job goes badly.

This page covers that second job: the order of operations for a pricing change, from the two documents you need before you start to how you would undo it.

What to take away

• You cannot change a structure you have not written down. The first task is finding out what you actually charge, which is rarely what the price page says.
• Decide what would count as evidence before you change anything. Afterwards, every result can be read as a success.
• The change lands in five internal systems and three teams. Plan that handover or your customers will find the gaps for you.

The two documents you need first

A realized price list. Take a defined period of invoices and, for each account, divide what you actually collected by units of your billing metric. You now have the real distribution of prices your company charges. Most teams doing this for the first time find a spread they did not know existed, several accounts on structures nobody remembers agreeing, and at least one customer paying under an arrangement that ended years ago.

An exception register. Read the contracts, not the invoices, and list every departure from standard: price locks, capped increases, most-favored-customer clauses, unusual notice periods, bundled items granted verbally and honored ever since. Each of those constrains what you are about to do, and each is invisible in a billing report.

These two documents take a week and they set the boundary of the whole project. Separating what a thing costs from where the cost is recorded is the ordinary discipline of managerial accounting, worked through in MIT's financial and managerial accounting course. Skipping them means designing a change against a structure that exists only in a slide.

Choosing which layer to change first

If more than one layer is wrong, and it usually is, order the work by reversibility rather than by severity.

Two things at once means you learn nothing from either. That is not a rule about caution, it is a rule about attribution: if you move packaging and the scaling rule in the same quarter, no result you observe can be assigned to either. Which layer causes which symptom is set out in the pricing architecture overview.

Decide what would count as evidence, in advance

Write it down before the change goes out, in one sentence per measure, with the direction and the period.

The honest part is admitting what you cannot learn: a pricing change on a live book is not a controlled experiment. Your mix moved, the season moved, sales effort moved, and a competitor did something you did not see.

Pre-register a small number of things you will look at, and name the confounders you already know about. Accept a directional answer rather than pretending to a precise one.

Treating an observed pattern as a hypothesis rather than a finding is the standard caution in MIT's data mining course.

Pre-register two measures in most cases: realized price on newly signed accounts, where a change lands first, and discount distribution, not its average, because the tail moves.

Before computing each, write down who is included. Otherwise, the definitional traps in business model types metrics will show the same change twice.

Also write down what would make you stop. A change without a stop condition tends to be defended long past the point where the person who proposed it stopped believing in it.

The internal handover nobody plans

A price change is a content change in five systems and a knowledge change in three teams. Work through this before the announcement, not after.

The billing row is the one that most often blocks everything else. If your system cannot hold two price structures at once, the project is a software task before it is a pricing task, and finding that out in week one is worth the hour it takes.

The rollback question

Ask it plainly before you start: if this is wrong, what does undoing it cost?

Some changes are cheap to undo, like resetting a discount threshold. Others cannot be undone: a customer quoted a lower structure will not accept the old one, and a metric change billed against has already produced invoices.

For those, the mitigation is not a rollback plan. It is a smaller first step: one segment, one region, new business only, with an explicit end date on the trial.

Where you cannot roll back and cannot narrow the group, that is worth naming out loud as the reason the decision needs more evidence than the others did.

The sequence, in order

1. Build the realized price list and the exception register.
2. Name the single symptom you are solving and the single layer you are changing.
3. Write the evidence statement, the confounders, and the stop condition.
4. Check the billing system can hold both structures at once.
5. Decide who is exempt, for how long, and write it where the renewal team will see it.
6. Brief the internal teams before anything reaches a customer.
7. Change it for a bounded group with a stated end date.
8. Read the pre-registered measures, and write down what you concluded and what remains unknown.
9. Record the change, the date, the exemptions, and the outcome, so the next debate starts from a record rather than from memory.

Step nine is the one that gets dropped and the one that pays for itself. Every company reprices more than once, and the second attempt is far cheaper when the first one left notes. What the change does to your cost side, which is the other half of the decision, follows the arithmetic in unit economics.

Common questions

How long before we can tell whether it worked?

Long enough for a full sales cycle and at least one renewal cohort to pass. Reading a pricing change in the first fortnight mostly measures how quickly your sales team adapted, which is a different question.

Should we tell customers who are not affected?

If the structure is published, yes, in plain terms, including that nothing changes for them and when that protection ends. Customers who discover a change through a rumour assume it applies to them.

What if the exception register turns out to be enormous?

Then that is the finding, and the project is now about exception control rather than about the price. A structure with more exceptions than standard accounts is not a structure, and rebuilding one is a model decision rather than a pricing decision: the business model types checklist is the better starting point.

Who should own the change?

One person with the authority to say no to a discount. Pricing owned by a committee produces a structure that satisfies the committee.