Case note: closing the loop from rep visit to next order

We closed it by putting rep-visit events on the same event bus as orders. When a rep logs an out-of-stock SKU, a cooler photo or a complaint, that is an event, not a note filed in a CRM. A rules service reads it and, the same day, pushes a suggested order or a task, instead of waiting for the next visit cycle to notice. The loop is code, not a hand-off between two products.

Why do visit notes never become orders?

Because the visit and the order live in different systems, owned by different teams, with nothing joining them. The rep's field app writes an observation - cold shelf empty of the 500ml, promo POS missing, two crates of empties uncounted - into a CRM as free text or a checkbox. The order is placed later, somewhere else: by telesales on the phone, or by the outlet itself on a B2B app, with no reference back to what the rep saw. There is no join between what happened on the visit and the order that follows two days later. The observation has no downstream consumer, so it decays into a compliance artefact: the area manager gets a dashboard, and the outlet gets nothing.

The frontier looks different, and it is on the public record. AB InBev's public materials describe its rep app, BEES Force, as equipping sales teams with what its BEES product materials call:

algorithmically driven tasks

The intent is exactly right - a visit should generate action, not just a record. But a task engine only closes the loop if the task and the order sit on the same spine. Bolt a smart rep app onto an ordering system it cannot write to and you have automated the observation while leaving the hand-off precisely where it was.

What does closing the loop actually look like?

Every visit interaction emits a typed event onto the same bus that already carries orders, stock movements and returnables: a stock observation, a shelf photo, a complaint, a planogram gap. A small rules service subscribes to those events and evaluates declarative conditions against live state. A zero-stock observation on a SKU the outlet is listed to sell, with no open order in the last few days, becomes a suggested order line. The suggestion lands the same day - pre-filled and sized against actual depletion - in both the rep's next-order screen and the outlet's B2B app, one tap to confirm.

Two things make the suggestion trustworthy rather than noise. Stock is current, because it flows on the bus in real time rather than arriving in a nightly batch we retired, so the suggested quantity reflects what is actually on the floor. And returnables ride the same spine, so an empties count taken during the visit reconciles against the balance instead of starting next month's argument. The visit stops being a data-entry chore and becomes the trigger for the next commercial action.

The mapping from observation to action is deliberately boring - that is the point.

The scale this runs at is not hypothetical. On the public record, AB InBev's BEES reports more than 3 million monthly active users and 32 billion US dollars of gross merchandise value in 2022, up around 60% year on year, across roughly 20 markets - millions of visits and orders in which the gap between a closed and an open loop compounds daily. The prize is a cost one: McKinsey's analysis of eB2B for consumer-goods manufacturers makes the point that digital capture lets you profitably reach customers a rep visit or a call-centre minute could never justify, and a visit that produces its own follow-up order is that arithmetic in its purest form.

How do you build the visit-to-order loop?

The pattern is repeatable. In the order we would do it again:

1. Make the visit emit events, not save records. Model each interaction - stock observation, photo, complaint, empties count - as a typed domain event on the shared bus. If the only artefact of a visit is a row in a CRM table, there is nothing for a rule to react to.
2. Put stock, orders and returnables on the same bus. A suggestion is only as good as the state it reads. This is the whole argument for one event spine rather than four integrated products: the loop needs current stock and open orders in the same place it reads the observation, or it will suggest things already on a truck.
3. Keep the rules as configuration. A market's suggestion logic - listing rules, cooldown windows, minimum confidence - is data, not code. That is what lets a second OpCo go live by changing config, not shipping a release, and lets a commercial lead tune the rules without a deployment.
4. Gate every suggestion with confidence and a cooldown. Suppress a suggestion where an order already exists, cap the frequency per SKU, and set a minimum confidence below which the rule stays silent. This is the step we got wrong first, below.
5. Close the loop visibly. The suggestion must be pre-filled, one tap to accept, and it must show its reasoning - empty shelf logged Tuesday, no order in 14 days. A rep who cannot see why will not trust what.
6. Measure acceptance and time-to-order, not visit compliance. The health metric is the share of suggestions accepted and the median hours from observation to confirmed order, not how many boxes the rep ticked.

The honest part: our first cut over-fired. We turned every zero-stock observation straight into a suggested order, with no dedupe and no confidence gate, and the reps drowned. In our own instrumentation of the pilot, suggestion acceptance fell sharply over the first fortnight as reps learned to swipe the whole feed away - and a suggestion a rep is trained to ignore is worse than no suggestion, because it poisons the ones that follow. We added the cooldown, the confidence threshold and the already-has-an-order suppression, which cut suggestion volume by well over half, and acceptance recovered to a level we were comfortable extrapolating from. The loop's value is precision, not recall; we had optimised for the wrong one.

The suggested order is only the first thing a rule can do with a visit event, and the cheapest. The same stock observation that today pre-fills one line can tomorrow open the returnable reconciliation, brief the account manager on the planogram gap, and let an agent draft the whole order for a human to wave through. Once the visit is an event on the shared bus, the loop stops being a feature we shipped and becomes a socket where the next rule, and the next model, plugs in. The remaining constraint is not capturing what the rep saw - it is how much we let the loop act on it before anyone taps confirm.