Case note: the console that retired the printed call sheet

We replaced the printed call sheet with a console that shows the telesales agent the same live customer timeline the outlet's own app runs on: recent orders, empties balance, credit headroom and eligible promotions on one screen, plus a suggested order sized for that outlet. The call stopped being transcription and became exception handling and outbound suggestion. The honest part: none of it moved a number until we changed how agents were paid.

Why did the printed call sheet stop working?

Because it is a snapshot printed overnight and stale by the time the agent dials. The outlet may have ordered on the app at six that morning, paid down its balance, or already burned through the promo the sheet is telling the agent to pitch - and the paper knows none of it. So the agent re-establishes context on every call, reads a credit position that is a day old, and handwrites an order that a night shift then re-keys into the core. Meanwhile the reason for the call is shrinking. On AB InBev's own numbers, 40% of BEES orders arrived outside business hours (its figure, as of 2021), because a retailer can order before it opens or after it closes without phoning anyone. When self-service absorbs the routine reorder, the call that remains is the hard one - the exception, the lapsed outlet, the upsell - and a stale sheet is precisely the wrong tool for it.

What does the console put in front of the agent?

One customer timeline on one screen, fed by the same event bus as the app rather than a nightly extract, so it is current to the second: recent orders and deliveries, the returnables (empties) balance, live credit headroom, and only the promotions this outlet actually qualifies for. Because credit rides the same spine, the agent sees a real limit instead of yesterday's, the same real-time check we used to stop credit blocking the order flow. And capture itself is quick: the order the agent confirms travels the same sub-second capture path the app uses, not a separate telesales system that reconciles into the core overnight.

On top of the timeline sits a suggested order, generated per outlet - sized against that outlet's depletion, gated on its listing and credit, and filtered to the promos it is eligible for - with a one-line reason next to each SKU. The agent is no longer reading a static list top to bottom. They are working a ranked queue of outlets where the system already has a proposal, and their job is to judge it, adjust it and close it.

The scale this pattern runs at is on the public record. AB InBev's BEES reports more than 3.1 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. And McKinsey's eB2B analysis makes the commercial case: digital capture profitably reaches the long tail of small outlets a call-centre minute could never justify - which is exactly the population where a warm, pre-sized suggestion beats a cold call down a paper list. The console is how you keep telesales useful once the routine orders have left the phone: point the humans at the exceptions and the upsell, and hand them a proposal to react to instead of a blank line to fill.

How do you build a telesales console that replaces call sheets?

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

1. Put the timeline on the shared bus, not a nightly extract. Model orders, deliveries, empties movements, credit changes and promo eligibility as events on the same spine the app reads, so the agent sees state, not a report. A console that reads a batch table will be wrong by the first coffee break.
2. Generate the suggested order per outlet. Size each line against real depletion, gate it on the outlet's listing and credit headroom, filter it to eligible promos, and attach a reason. A suggestion the agent cannot explain to the retailer is one they will skip.
3. Surface exceptions inline, not as lookups. Empties disputes, credit blocks and lapsed-order flags belong on the timeline so the call resolves them, rather than the agent tabbing into three other systems mid-conversation.
4. Keep capture on one path. The confirmed order should travel the same route as an app order into the shared event spine - validated at entry, posted to the SAP core as usual - not re-keyed by a night shift into a second system of record.
5. Measure the right things. Instrument handle-time, lines and value per order, and suggestion acceptance - not calls per hour. What you meter here decides what the console is for, the same discipline that let us answer the value question the same afternoon instead of waiting a quarter for a report.
6. Change the commission model, or none of it lands. This is the step that actually moves adoption, and the one we underestimated. See below.

What did not go smoothly?

The commission model. We shipped the console, the timeline was live, the suggested orders were good - and for weeks the agents largely ignored the script. They were not being difficult; they were being rational. They were paid on calls handled and orders logged, so the winning move was to keep every call short and transactional: confirm the obvious reorder, hang up, dial the next number. The suggested upsell added handle-time and rejection risk to a metric that rewarded neither. In our own instrumentation of the pilot, suggestion acceptance sat stubbornly low while call volumes stayed high - the technology had changed and the behaviour had not.

It only moved when the commercial team re-based commission on order value and basket size rather than call count. Within a few weeks of that change, our pilot instrumentation showed median lines per order climbing and handle-time settling higher but against materially larger baskets - agents were now happy to spend the extra ninety seconds because they were finally paid to. The console made the better call possible; the compensation change made it happen. Anyone who tells you a data layer alone changes a sales floor has never had to meter one.

The console is not the destination; it is the socket. Once the timeline and the suggested order sit on the shared bus, the next thing to plug in is a model that drafts the whole call - which outlets to ring today, in what order, with what proposal and what fallback - and leaves the agent to approve, adjust, and build the relationship the software still cannot. The phone call stops being where the order is captured and becomes where a human decides whether the machine's proposal is the right one. The open question is no longer what the agent can see; it is how much of the call we let the system plan before anyone picks up the handset.