Triggering Supplier Orders Automatically: Our Reorder Setup

For two years we ordered stock on gut feel. Once nano sat there for four days without its bestseller, once 8,000 euros of dead capital sat on the shelf.

Both were the same mistake: we had an opinion instead of a number. Today a workflow calculates every morning how long each SKU will last and hands us a finished reorder proposal. We click "approve" or we change the quantity. That is all.

This article shows you how the setup is built, which data it needs, and where it still fails for us today. It is not a concept. It has been running for nearly a year for nano, mate and MUSTAX.

Why ordering on gut feel is expensive

Purchasing is the one decision in ecommerce that punishes you in both directions.

Order too little and the item is out of stock. You lose more than that day's revenue. On marketplaces you lose ranking, in campaigns you burn ad budget on a page with no buy button, and some of those customers never come back.

Order too much and your money sits on the shelf. In our worst month that was around 8,000 euros we had wanted to put into marketing. Storage costs come on top, and with perishable or seasonal goods so do write-downs.

The annoying part: the decision is tedious rather than hard. It is always the same four questions. How much is there? How fast does it move? How long does the supplier take? How much safety do I want? Questions like that belong in a machine, as I described in The real cost of manual processes.

The one metric: days of cover

The whole setup hangs on a single number. We call it days of cover. It says how many days an item will last if things continue as they have.

The calculation is deliberately simple:

Days of cover = available stock divided by average daily sales

Available stock for us means: physical stock at the fulfiller minus reserved quantities minus the safety buffer we already keep for oversells. How that buffer comes about is described in Multichannel inventory management.

For daily sales we settled, after a few failed attempts, on a weighted average. The last 14 days count double, the last 90 days count once. That way the number reacts to real trends without jumping because of one good Tuesday.

One number, one denominator, no model with twelve dials. We first built something clever and threw it out after three weeks, because nobody could explain any more why a proposal had come out the way it did. A proposal you cannot explain is a proposal you will not approve.

Lead time is what you have measured

Days of cover alone is not enough. What matters is whether it is longer than the time until the next delivery.

For us that time consists of four pieces, and we maintain them per supplier:

• Order lead-in. How long it takes us to actually send an order out.
• Production or picking time. Three weeks at the manufacturer of our brush heads, three days at the packaging supplier.
• Transport. Air freight, sea freight or road haulage makes the biggest difference.
• Goods receipt. Checking, putting away, flagging as available in the system. Sounds like nothing, takes us two to four days.

The words "per supplier" matter. We enter what we have measured, not what the quote says. With one supplier, a promised 21 days was in reality 34 days on average. Since then the system calculates with 34.

The trigger for a proposal is then a simple condition. As soon as days of cover falls below lead time plus safety time, the item becomes a candidate. Our safety time sits between 7 and 21 days depending on the item.

A proposal instead of a blind order

Here is the most important decision in the whole project: the system does not order. It proposes.

Every morning at 7 a message per supplier lands in Slack. Per item it contains: current stock, daily sales, days of cover, calculated lead time, proposed quantity and one sentence of reasoning. Something like: "19 days of cover left, lead time 34 days, proposal 1,200 units for 90 days of cover."

The proposed quantity covers a target horizon, usually 60 to 90 days, rounded to the supplier's minimum order quantity and carton size. Those two roundings are no detail. A proposal for 1,137 units is useless when the supplier only ships full cartons of 400.

We look at it, change the quantity in maybe one case in five, and approve. Only the approval creates the order: an email to the supplier with line items and a requested date, plus an entry in our order list so the expected goods show up in planning.

The time saved is real without being spectacular. Purchasing for three brands used to cost us a good half day a week, including hunting down the numbers. Today it is around 20 minutes a week for the approvals. The bigger effect is a different one: we have not had an unplanned stockout on an A item since.

Why a human approves, and why that stays

We could abolish the approval step. We deliberately keep it, for three reasons.

First, an order is money going out. A wrong support message costs an apology, a wrong order costs four figures and ties up capital for months. That is also why it shows up in our cashflow planning.

Second, the system only knows the past. It does not know that we are launching a campaign in three weeks, that a creator is planning something big, or that we are phasing an item out. That knowledge sits in our heads, not in the database.

Third, the approval is our quality check. Every time we correct a proposed quantity, the system records the correction. If we correct upwards three times in a row on one item, an assumption is wrong. That is how we found the over-optimistic 21-day lead time in the first place.

It is the same pattern as everywhere in our setup, in support as in bookkeeping: machines handle the standard case, humans decide. More on that in Automating bookkeeping with AI.

Where the setup fails

Now the uncomfortable part. The reorder workflow is good for items with calm, recurring sales. For everything else it is a hint at best.

• Seasonal items. In November our setup proposed a quantity for a seasonal item based on the previous weeks' sales. Sales multiplied in December and collapsed in January. A backward-looking average cannot know that. For seasonal goods we still plan by hand, using last year's numbers as the base.
• New products. No sales, no average, no days of cover. The first 8 to 12 weeks of an item are pure manual work.
• Campaigns and creator peaks. One video taking off makes every forecast worthless. So we enter planned campaigns as a manual uplift. Unplanned peaks are absorbed only by the safety buffer, and sometimes not even then.
• Bundles and sets. A set pulls stock from several items. The days of cover for an individual item stops being correct once part of it moves into sets. We break sets down into components, and that logic is the most error-prone part of the whole workflow.
• Unreliable suppliers. When actual lead time swings between 20 and 60 days, no average helps you. What helps is a second supplier or more buffer, and both are business decisions rather than automation.

And one limit that has nothing to do with technology: below roughly 30 orders a day and with fewer than 20 items you need none of this. A spreadsheet and one look per week is enough. Where automation does not pay off in general is covered in What automation really costs.

What you need if you want to rebuild this

In this order, not in another:

1. Reliable stock data from one source. Without it every days-of-cover figure is fiction. That is groundwork you cannot skip.

2. Sales history per item, at least 90 days. From the shop or from the fulfiller, wherever, as long as it is consistent.

3. Measured lead times per supplier. Take your last five deliveries, not the quote.

4. Minimum order quantity and packing unit per item. Otherwise your proposals cannot be ordered.

5. A channel for the proposal. Slack in our case. All that matters is that you see it daily.

Start with your ten most important items. Let the workflow write proposals for four weeks without acting on them, and compare them with your own decision. Only once it has convinced you several times do you start relying on it. This approach in small waves is the same one we recommend in the roadmap from 0 to 100 orders.

Conclusion

Automating purchasing puts a reasoned number in front of you every morning instead of a gut feeling. No machine spends your money.

The three building blocks are days of cover per item, measured lead time per supplier, and a proposal that a human approves. The rest is diligent work on your master data, and you cannot skip that.

For us it took purchasing from half a day a week to 20 minutes and ended the stockouts on A items. For seasonal goods we still plan by hand, and that will stay that way.

If you want something like this for your brand and would rather not build it yourself: these are exactly the systems we build at Flowhouse. Write to us, and we will also tell you when the effort does not pay off at your volume yet.