Case note: a price-ladder change, every channel, same day

We changed a national price ladder and it landed in the ordering app, the telesales console, the rep app and the invoicing projection on the same effective date - one change, no re-keying, no drift between channels. The move was to stop treating a price change as four updates in four systems and instead publish it once as an event every consumer applies atomically. Here is the old dance, the new shape, and the migration that bit us.

Why did a price change used to take days to reach every channel?

Because the change was entered once and then re-entered everywhere else by hand. The pattern we inherited is depressingly standard: a new price ladder is keyed into the ERP, exported overnight to the commerce platform, re-keyed a second time into the loyalty and promotion rules so points and deals stay consistent, and finally flattened into a PDF and emailed to the field so reps quote the right number. Each hop is a different team, a different release window and a fresh chance to fat-finger a decimal.

The gap between the first system and the last is where money leaks. Price is the single most powerful profit lever a brewer has: McKinsey's long-running analysis finds that a 1% rise in realised price flows through to roughly an 8% increase in operating profit, around three times the impact of a 1% gain in volume. So for every day the app is still selling at last week's ladder while the ERP believes the increase is already live, you are handing that lever back - quietly, at scale, across every route.

This is not a fringe concern. Pack-price architecture sits at the centre of revenue growth management, which McKinsey's September 2022 analysis credits with a 4 to 7 percent gain in annualised gross margins for companies that run it well. AB InBev, the world's largest brewer, made the discipline public more than a decade ago: its investor materials describe a "3P" framework of price-to-consumer, promotion optimisation and pack-price, as documented in its 2013 revenue-management seminar. If the strategy is engineered that carefully, the plumbing that executes it should not be a PDF.

What does "one price event, every channel" actually mean?

It means a price change is published once, as a single event on the shared bus, carrying its own effective date - and every downstream consumer subscribes to that event and applies it independently. The ordering app, the telesales console, the rep app and the invoicing projection each hold their own copy of the price they need, all rebuilt from the same stream. There is no export, no re-key, no attachment. When a commercial lead schedules the March ladder for the fifth, all four channels flip on the fifth, together, because they are reading one instruction rather than four hand-copied translations of it.

Two properties make this safe. The event is effective-dated, so a change can be published days ahead and still take effect at the right minute; and consumers are idempotent, so replaying the stream cannot double-apply a change. The financial core is untouched: SAP stays the book of record for pricing conditions and revenue, exactly as when we replaced the commerce layer without touching SAP FI. We are not moving the ledger; we build fast, effective-dated read models beside it and feed the channels. The shape of that split is our platform architecture.

How do you move price onto the bus without a pricing outage?

Carefully, and with the old exports still running until the new path has earned trust. The sequence we would repeat:

1. Model the price change as an effective-dated event. The event carries the SKU or list, the new value, the currency and - non-negotiably - the effective date and time. If effective date is an afterthought, you have only built a faster way to make the same mistake.
2. Build each channel's price as a read model. The app, telesales, rep app and invoicing each consume the event into their own projection. Keep every consumer idempotent and replayable, and store the offset so you can rebuild a channel's price from scratch whenever you doubt it.
3. Run the event beside the export. Publish price events in parallel with the existing ERP export and the PDF for a few cycles. Compare what each channel would charge under the new path against the old one, every day, before anyone relies on it.
4. Reconcile invoicing against SAP daily. The invoicing projection must agree with the pricing conditions in the financial core. Diff them every day so finance is never surprised at period-end and the ledger stays the arbiter.
5. Cut over one channel, then fan out. Switch the lowest-risk channel - usually the app - to the event first, watch the reconciliation, then bring telesales, the rep app and finally invoicing across. Retire the export only when nothing reads it.
6. Keep the ladder itself as configuration. A market's price ladders, rounding rules and effective dates are data a commercial lead schedules, not code an engineer ships - the same principle that lets a new market go live as configuration rather than a project.

What did we observe, and what went wrong?

Framed as our own monitoring rather than any client's claim, the direction was clear. On the pilot, a price ladder that used to take the better part of a week to become consistent across channels reached all four on its effective date, and the reconciliation gap between what the channels charged and what SAP expected shrank to near zero within the day. The margin that used to leak in the skew window simply had nowhere to go.

Now the honest part. The whole promise rests on every consumer honouring the effective date, and at first one did not. We scheduled a ladder a day ahead, as intended, but the invoicing projection applied the new value the moment the event arrived instead of waiting for the effective date - so for a few hours a batch of invoices went out at the next day's price. Nobody was overcharged for long, because the daily reconciliation against SAP caught the divergence the same evening and we re-issued, but it was an uncomfortable call to make. The bug was ours and it was mundane: a consumer that read the value and ignored the date. We pulled effective-date handling into a single shared, tested library rather than something each consumer re-implemented, and added an alert that fires the moment any channel disagrees with the ledger. The failure was a good teacher: an effective date only means something if every reader treats it as mandatory.

The next thing to disappear is the manual ladder itself. Once every channel reads the same effective-dated event, a promotional price, a temporary regional cut or an agent's proposed move is the same shape as a routine increase - publish once, let it fan out - and a commercial lead can watch a change land across all four channels while its margin effect surfaces in the same view we use to answer the CFO's question the same afternoon. We are not there yet, but the PDF is gone, and nobody has asked to bring it back.