Fix patterns

Cost-to-serve: the metric that justifies the whole rebuild

TL;DRCost-to-serve is the fully loaded cost of producing one delivered order, computed per channel. A self-service app usually beats telesales on capture cost — but it only counts as saving if you also track reorder rate and the friction pushed onto the retailer. Expect roughly five years to break even.

Cost-to-serve is the fully loaded cost of turning one customer into one delivered order — telesales minutes, rep visits, keying errors, credit notes, redeliveries — divided by the orders that result. Compute it per channel, honestly, and a self-service app almost always wins on capture cost. But the number only justifies a rebuild if you also count the friction you push onto the retailer and the reorder rate you get back. Expect roughly five years to break even.

What is cost-to-serve, and why does it justify the rebuild?

Cost-to-serve is the total cost your business absorbs to get one order from one outlet, from first contact to a settled invoice. It is not the price of the beer and it is not marketing spend. It is the operational tax on every transaction: the telesales agent's time, the rep's windscreen, the errors a human introduces transcribing an order, the credits that follow, and the redeliveries when the pallet was wrong.

It matters because a route-to-market platform rarely sells more beer on day one. Its return is invisible in revenue and obvious in cost-to-serve. If you cannot express the rebuild as cents removed from every order, finance will treat it as an IT project with no payback — and they will be right to. This is the one metric that connects an event bus and an order-capture app to a line the CFO already tracks.

How do you compute cost per order honestly?

Start with a fully loaded cost per channel, not a blended average across all orders. Take the annual cost of running each capture channel — salaries, tooling, error rework, and the slice of logistics cost caused by bad orders — and divide by the orders that channel actually produced. The gap between a telesales order and an app order is usually large, and usually flattering to the app. That is exactly why you should distrust it until you have adjusted for the two things the headline hides: whether those orders come back, and who ends up doing the work.

Half the reason the figure is hard to produce at all is that the inputs live in systems that were never meant to reconcile — capture in one, logistics in another, credits in finance. That reconciliation effort is itself a cost, and it is the same integration bill Conway's law hands you when the org chart rather than the data decides your architecture. Landing capture, fulfilment and credits on one event bus is largely how you make the number cheap to compute in the first place.

Component (illustrative)Telesales / rep orderSelf-service app order
Human capture timeAgent minutes, or a rep visit amortisedNear zero
Transcription errors and creditsMaterial; humans mistypeLow; validated at entry
Marginal cost of one more orderHighLow
Reorder ratePropped up by the relationshipDepends entirely on the UX
Work shifted to the retailerLow; you do it for themHigh if the app is slow

The table is deliberately illustrative — your real figures come from labour and error rates you can pull from your own systems. The point is the bottom two rows. Capture cost is what every deck models; reorder rate and the work pushed onto the retailer are where the savings quietly leak back out.

Where do the savings actually come from?

Not where most business cases claim. The real prize is not shifting your best accounts to self-service; those reps were already productive and those orders were already clean. It is the long tail of small, infrequent outlets. McKinsey's analysis of eB2B for consumer-goods manufacturers makes the point directly: digital capture lets you profitably reach customers who were otherwise too costly to serve, because a rep visit or a call-centre minute can never be justified against a tiny basket ordered twice a month.

The scale is real when the programme is. A top-3 global brewer reported more than €3 billion in gross savings over five years from a continuous productivity programme, is targeting a further €400–500 million in annual gross savings, and is pushing a €1 billion-plus digital backbone across more than 70 markets (figures as of October 2025). Those are not order-capture numbers on their own, but they show where the money comes out: standardised, digitised operations, not heroics.

What do teams get wrong about the number?

They measure capture cost and stop. An app order that never reorders is dearer than a telesales order that reorders every week, because you paid to acquire a habit you never built. Cohort reorder rate by channel, or the model simply lies to you.

They count cost they moved, not cost they removed. A slow or confusing app does not delete the ordering work; it pushes it onto the retailer, where it surfaces as abandoned baskets and quiet churn rather than a line on your P&L. Cost-to-serve that ignores the retailer's minutes is cost-to-serve you have flattered.

They book savings on the wrong accounts. Migrating your biggest, best-run outlets first books a saving on customers who were never expensive to serve, while the long tail — where the money actually is — stays on the phone. It photographs well and moves almost nothing.

They ignore the payback curve. Platforms are not cheap to stand up. McKinsey puts break-even for this kind of manufacturer platform at around five years once infrastructure, activation incentives and inventory are counted. Model the J-curve or you will over-promise in year one.

How to fix it: a cost-to-serve model you can defend

Build the model so it survives both a finance review and a sceptical OpCo GM. Six moves get you there.

  1. Instrument capture as events. Emit an event for every order, credit, redelivery and channel touch, so cost is derived from what happened rather than reconstructed from month-end averages. An immutable event stream doubles as the audit trail that makes the numbers defensible when finance pushes back.
  2. Allocate fully loaded costs, per channel. Pull labour, tooling, error rework and order-driven logistics into each channel and divide by that channel's real order count. No blended averages, because the average hides exactly the tail you care about.
  3. Cohort reorder rate and net order value. Track whether app-acquired outlets keep ordering, and at what basket size, against matched telesales cohorts. Capture cost without retention is half a metric.
  4. Measure the retailer's side. Time-to-order, abandoned baskets and support contacts are your early-warning system for cost you have shifted rather than saved.
  5. Roll out per OpCo and re-measure. Turn the new channel on market by market and compare before and after in each, so you are reading a real delta rather than a fantasy baseline. Treating rollout as a config change across OpCos keeps the comparison clean and reversible.
  6. Set the board's expectation to five years. Put the J-curve in the business case up front. A measured pilot on one OpCo gives you a real cost-per-order delta to extrapolate from, instead of a vendor's slide.

The interesting shift is that cost-to-serve is turning into a per-order, real-time figure rather than an annual finance exercise. Once capture, fulfilment and credits all land on the same event bus, you can watch the cost of an order move as you change the app, price a delivery slot, or re-route a truck — and decide, that week, which outlets are worth serving and how. The rebuild stops being a bet on a five-year payback and becomes a dial you can read. That is the version of cost-to-serve worth building toward.

Frequently asked questions

How do you calculate cost-to-serve per order?

Take the fully loaded annual cost of each capture channel — labour, tooling, error rework and order-driven logistics — and divide by the orders that channel actually produced. Then adjust for reorder rate and any work pushed onto the retailer, so you compare net cost per retained order, not just capture cost.

Does a digital order-capture app actually lower cost-to-serve?

Usually yes on capture cost, because it removes telesales minutes and transcription errors. But the saving is real only if those outlets keep reordering and the app does not shift work onto the retailer. Measure cohort reorder rate and retailer friction before booking the number.

How long before a route-to-market platform pays for itself?

Plan for roughly five years to break even, per McKinsey's eB2B analysis, once infrastructure, activation incentives and inventory are counted. The payoff arrives sooner if you target the long tail of small outlets that were too costly to serve by phone or rep, not your already-cheap large accounts.

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