The anatomy of a combo promo that took two quarters to ship

A combo promo is a few days of engineering that ships in two quarters. In a bought route-to-market suite, one new mechanic crosses four vendors' roadmaps — rules engine, catalog, loyalty and returnables — so the launch date is set by the longest backlog, not by the code. Enterprise loyalty programs already run 6 to 18 months once integration is counted; the moment a promo touches deposit accounting, it inherits that math.

What counts as a combo promo, and why does it touch everything?

Call it a combo promo, a mechanic, a compound offer — the shape is the same. “Order fifteen cases of the core lager and one keg of the seasonal, and we waive the keg deposit and pay double loyalty points.” Trivial on a slide. On the stack it is four things at once: a multi-product qualifying basket, a returnable-deposit waiver, a bonus points accrual, and a redemption path.

Every one of those lands in a different system. The qualifying rule lives in the rules engine. The combo has to exist as a group in the catalog and survive checkout. The points hit the loyalty ledger and, behind it, points-liability accounting. The deposit waiver touches the returnables ledger and the finance postings. Fraud controls have to stop reps splitting baskets to double-claim. The rep app has to render the offer at the point of sale. Analytics has to prove the lift afterwards. Seven surfaces, one promo.

In a platform you own, that is one pull request against one event stream. In a bought suite, those seven surfaces belong to three or four vendors, each with its own release train, its own backlog, and its own definition of “next quarter.” A focused, single-program loyalty rollout can be delivered in 12 to 16 weeks when it is greenfield and owned by one implementation partner. A promo dropped into a live, multi-vendor estate does not get greenfield economics.

Where did the two quarters actually go?

Here is the calendar from a representative build, compressed. Almost none of the elapsed time is coding; nearly all of it is waiting for someone else's release train.

The pattern is not incompetence. Each vendor did roughly what its contract said, on roughly its normal cadence. The problem is that the promo has no owner. It is a guest in four backlogs, and the slowest host sets the date.

Why does “deposit netting is not supported natively” stop the clock?

The phrase that eats a month is always some variant of “not supported natively.” For a combo promo it is usually deposit netting. Waiving a keg deposit is not a discount; it is an adjustment to a returnable-liability ledger that has to reconcile against physical assets in the field and against the SAP financial core. The loyalty product can zero a line. It cannot, on its own, net a deposit against a promotional credit and keep the empties ledger honest.

So an integrator specs middleware to map the promo event onto a deposit adjustment, and now you are debugging the seam between two vendors who each assume the other owns reconciliation. We have written before about designing a returnables ledger that actually reconciles and about why the ERP still cannot tell you who is holding your kegs; a combo promo is where both problems arrive at once, under a launch deadline. The deposit does not care that trade marketing already promised the offer for the tournament window.

Why does the phased OpCo rollout add the second quarter?

Build finishes in one pilot operating company. Then the second quarter begins, because every other OpCo carries its own deposit values, tax treatment, price lists and rep-app version. The mechanic that passed UAT in market A has to be re-configured, re-tested and re-signed for markets B through F, one at a time, because nobody will risk every market on a single release. This is also where the promo meets the messiness of real field data: if you have not reconciled which distributor sells to which outlet, the qualifying basket misfires, which is its own version of the distributor data your own systems cannot reconcile.

What would make it two weeks instead of two quarters?

Diagnosis, not prescription: the two quarters are an architecture bill, not a talent problem. When the seven surfaces share one event bus, a new mechanic is a rule and a subscriber, not four change requests routed through four vendors. The public record already shows the shape of the payoff. AB InBev's own engineers told investors that a custom platform of more than 1,200 developers, running 200-plus microservices behind ten applications, changed what was buildable:

This modern architecture also drastically reduced the platform's dependencies on our legacy ERP systems, which would have been a barrier to providing many of the most valued and utilized features on BEES.

That is the whole difference — owning the event flow versus renting seven products and paying an integrator to sew them together at launch time. It is the reasoning behind how we think about single-event-bus architecture, with the SAP financial core deliberately left exactly where it is.

The combo promo is a canary. The next request will be a tiered rebate, then a returnable-linked subscription, then whatever the trade team dreams up after the next competitor move — each one crossing the same seven surfaces. Teams that spend this year collapsing those surfaces onto one bus will ship the following mechanic in the time it takes to write the rule. Teams that keep renting will keep booking two quarters, and keep explaining to marketing why “just add a promo” is a roadmap item rather than a config change.