How smart reordering works

Smart reordering proposes the next order before the customer notices they need it. This article is about where that proposal comes from, so that you can tell a good suggestion from a plausible-looking bad one.

You cannot see consumption. You see purchases.

Start with the honest limitation, because everything else follows from it.

Your order history tells you that Müller Industriebedarf bought 24 filter cartridges 8815-F on 3 February, 24 on 17 March, and 24 on 28 April. It does not tell you that they used them at four a week, that six are still on the shelf, or that eight went to the second site. Purchases are a proxy for consumption, and the proxy is good exactly when the buyer orders what they need when they need it — which is the behaviour you are trying to replace.

That is not a reason to skip the prediction. It is the reason a prediction should arrive as a suggestion with its assumptions visible, not as an order.

The arithmetic

Four numbers, per account and per article.

1. Consumption rate. Total quantity bought over a window, divided by the days in the window. Take 8815-F above: 72 units across the 84 days from 3 February to 28 April is 0.86 units per day. The window matters — too short and one unusual order dominates, too long and last year's behaviour outweighs this quarter's. Six to twelve months is the usual compromise for consumables; for a fast-moving C-Teil, ninety days.

2. Estimated cover remaining. What they still have, assuming they consumed at that rate since the last delivery. 24 units delivered on 28 April at 0.86 per day is roughly 28 days of cover, running out around 26 May.

3. Lead time. How long between the buyer deciding and the goods being on their shelf. This is not only your delivery time. It is your picking and shipping time, plus the customer's own internal delay — an approval that sits two days in somebody's queue, a goods-receipt department that books on Tuesdays. Four days of yours plus three of theirs is seven, and seven is the number that matters.

4. Safety stock, expressed as days of cover. How much buffer the buyer wants between "the prediction was optimistic" and "the line stops". Ten days is a common starting point for a cheap consumable; for something that stops production it is longer, and for something with a shelf life it is shorter.

Put them together:

suggest on = depletion date − lead time − safety days
           = 26 May − 7 days − 10 days
           = 9 May

And the quantity is the coverage target — how many days you want the delivery to cover — times the rate, rounded up to the packaging unit. Thirty days of cover at 0.86 per day is 26 units; if 8815-F ships in boxes of 12, the suggestion is 36, not 26. A suggestion that cannot be ordered as stated is worse than no suggestion.

Confidence: when to believe the number

A rate calculated from two orders is not a rate, it is a line through two points. Before a suggestion is worth sending, three things should hold:

Articles that fail the regularity test are not failures of the model. They are articles that are genuinely not consumed on a rhythm, and the right handling is to exclude them rather than to widen the tolerance until everything qualifies.

Set the minimum confidence deliberately — see Configure reorder suggestions. A low threshold produces many suggestions, most of them noise, and buyers stop reading them within a month. That is the failure that is hard to undo: you can raise a threshold, but you cannot easily win back a buyer who has learned that your suggestions are wrong.

Suggestion, or order?

There is a ladder here, and the rungs should be climbed with each account, not switched on globally.

The third rung is where most of the value is and where most of the arguments happen. It only works if the notification arrives early enough to act on, names the articles and quantities, and has one obvious way to say no. See Act on reorder suggestions.

Where it goes wrong

Four failure modes, all of them common, none of them detectable from the rate alone.

Seasonality. Frostschutz, Streusalz, anything driven by weather, harvest or a shutdown calendar. A rate averaged over twelve months predicts a steady trickle of a product that is actually bought in two bursts. The symptom is suggestions that are late in season and pointless out of it. Either exclude seasonal articles or compare against the same period last year rather than the trailing average.

One-off projects. A customer fits out a new hall and buys 400 metres of cable, 60 sockets and 12 distribution boxes in March. The model reads a consumption rate and suggests the same again in June. Project purchases look exactly like an enormous consumption spike, and the only reliable filters are human: articles a customer has bought once or twice, and quantities far outside their own history, should not generate a suggestion.

Dual sourcing. This is the subtle one. Your history shows your share of their consumption. A customer who buys half their gloves from you and half from a competitor produces a rate that is half their real need, and the suggestion is half the size it should be. Worse, if they shift the split toward you, your model reads it as growth and gets the timing wrong in the other direction. The fix is not statistical — it is asking the buyer what their monthly consumption actually is and using that as the rate.

Substitution and stockpiling. They switched from 8815-F to the successor article, so the old one looks like churn and the new one has no history. Or they bought six months' worth in one go because you ran a price action, which flattens the rate and hides the next real need behind a mountain of phantom cover. Both show up as an account whose per-article predictions all drift at once.

Making it better without better maths

The cheapest accuracy improvement is not a model change:

• Ask the buyer for their consumption per month and use it as the rate for their top twenty articles. One phone call beats a year of history.
• Ask for the coverage target. "We want four weeks on the shelf" is a parameter you can set exactly.
• Round to the packaging unit and respect minimum order quantities, so a suggestion is always orderable as shown.
• Carry the buyer's own references through. A suggestion that arrives with the cost centre and the machine reference already on it is one an approver can release without asking questions — see Order lists and recurring carts.
• Convert the reliable ones into standing orders. An article with four years of clockwork ordering does not need a prediction; it needs a schedule. See Standing orders.

How this works in the Revenue Cloud

Smart reordering is an Intelligence app — install it from the Marketplace like any other, under Apps and the Marketplace. Once installed it works off data you already have:

• Order history per account and article supplies the rate and the intervals. It needs real history to say anything, so an account migrated last month has no suggestions until it has ordered a few times.
• Account-level metrics — the order_count_*, last_order_at and avg_order_value fields the Customers app maintains — give the account's own normal rhythm, which is what a per-article interval is judged against. See The metrics that matter in B2B.
• Catalog data supplies the packaging unit and minimum order quantity used to round a suggested quantity into something orderable.
• The output is a suggestion, delivered to the channel you choose, with the account, the articles, the quantities and the date it is based on.

The thresholds, the channel, the per-account opt-in and the minimum confidence are all yours to set.

Next

• Configure reorder suggestions — the settings behind everything above.
• Recurring revenue in B2B — the four patterns, and where prediction fits among them.