Beer route-to-market
Suggested orders: the 26% revenue lever in your order flow
A suggested order is only as good as its data. The world's largest brewer reported that outlets fully engaged with its BEES app — the ones ordering from the recommendation — stocked 10% more beer SKUs and drove 26% more net revenue per delivery versus pre-pandemic levels, per its December 2021 investor transcript. The algorithm reads current stock, order history, regional sell-out and live promos at once. Split those into nightly silos and it decays into a static template.
What does a suggested order algorithm actually compute?
For every outlet, on every visit or login, it predicts the next order: which SKUs to stock and how many of each. That is two problems in one — an assortment problem (what should be on this shelf that isn't) and a reorder-quantity problem (how much of the usual moves before the next drop). Get both right and the rep or the app proposes a fuller, better-weighted order than the outlet would have typed unaided. That is the whole mechanism behind the headline numbers: engaged outlets stocking more beer SKUs at higher revenue per delivery, with more than 80% of customers ordering from the recommendation.
Four inputs decide whether the prediction is any good, and each carries a different freshness requirement:
| Input | Where it usually lives | Freshness it needs |
|---|---|---|
| Outlet order history | Order capture / CRM | Complete, updated per order |
| Current stock (depot and outlet) | Warehouse / stock system | Real-time |
| Regional sell-out patterns | Analytics / BI | Daily |
| Active promos and combos | Trade-promo / pricing engine | Live, to the hour |
Why do suggested orders decay into static templates?
Because in a fragmented stack those four inputs sit in four systems stitched together by an overnight batch. By the time a rep opens the app at 9am, the stock feed is yesterday's, the promo that started at noon isn't in the pricing table yet, and a new outlet with two weeks of history gets the generic regional template. Each stale input produces a visible miss: the algorithm suggests a SKU the depot can't ship, or omits the combo the rep knows is running, or pads a slow mover nobody sells.
Reps notice misses faster than hits. After a handful of bad suggestions they stop reading the recommendation and fall back to the outlet's fixed 'usual order' — at which point the algorithm is decoration. This is the failure mode behind most disappointing rollouts: not a weak model, but stale inputs that quietly erode trust. The public contrast is the point — nearly 30% of eligible retailers reached 'fully engaged' precisely because the recommendation stayed worth trusting. That trust is also what makes low-touch channels pay: a good suggestion is the difference between a self-serve app that grows baskets and one that just digitises the same list, which is why it matters so much for the economics of every order-capture channel you run.
higher volume in wider assortment for orders placed with our recommendations
The promo input is usually the first to rot, because promotions change intraday and are the hardest thing to keep live across systems — a problem we walked through in detail in the anatomy of a combo promo that took two quarters to ship. If that feed lags, the algorithm confidently recommends yesterday's prices.
How do you fix it?
Treat this as a data-architecture problem first and a data-science problem second. In order:
- Put the four inputs on one event bus, not a nightly batch. Stock movements and promo activations should land as events the moment they happen, so the model reads a current view rather than a snapshot from 2am.
- Compute at request time. Generate the suggestion when the rep opens the outlet, against current stock and current promos — not a list pre-baked overnight that ages all day.
- Make every line explain itself. Show the reason: 'sells on this street, not stocked here', 'combo active until Friday', 'reorder — three weeks since last'. Reps override far less when they can see why.
- Enforce hard guardrails. Never suggest an out-of-stock SKU, never a line that breaches the outlet's credit limit or an unresolved returnables deposit balance, never a promo past its end time. One embarrassing suggestion burns more trust than ten good ones earn.
- Measure incremental lines, not clicks. Track lines accepted above the outlet's own template and net revenue per delivery against a held-out control — the same ROI discipline that separates promotions that pay from the ones that quietly don't, given how much trade spend loses money.
- Roll out narrow, with a control group. One region, one segment, a holdout kept on the old template. If engaged outlets don't stock wider and spend more per delivery, the model or the pipeline is wrong — find that out on 5% of the base before 100%.
The algorithm is the comparatively easy part. The hard part is a single, current view of stock, history, promos and orders that a request-time model can actually read, which is the shape of the single event bus we build the suite on.
Reorder-and-assortment is the floor, not the ceiling. As consumer pull data — digital coupons, loyalty redemptions, sell-out at the shelf — lands on the same bus, the suggestion stops being 'what you usually buy' and edges toward 'what your street is about to drink'. The distributors wiring that path now will spend the next few years quietly widening the gap on the ones still syncing four systems overnight.
Frequently asked questions
What data does a suggested order algorithm actually need?
Four inputs in one current layer: complete outlet order history, real-time depot and outlet stock, daily regional sell-out patterns, and live promotions. History and sell-out shape what to suggest; current stock and promo state decide what is safe to suggest right now.
Why do our suggested orders feel like static templates?
Usually because the inputs live in separate systems joined by a nightly batch. By morning the stock and promo data are stale, so the model suggests unshippable SKUs or missed combos. Reps lose trust and revert to the fixed usual order, leaving the algorithm as decoration.
How do we measure whether suggested orders work?
Not by click-through. Track incremental lines accepted above the outlet's own template and net revenue per delivery against a held-out control group on the old flow. If engaged outlets stock wider and spend more per delivery than the control, the model is earning its place.
Stuck with exactly this?
BrewOS builds the full route-to-market stack for global brewers — order capture, stock, loyalty, returnables, delivery and analytics on one event bus, run by a team of ~20 engineers. Bring us the feature that’s been stuck the longest and we’ll show you how we’d ship it in days.
Book a 30-minute walkthrough