Short answer
Three things are worth doing at this size: forecast the products that are actually forecastable, flag stock drifting toward a stockout or an overstock, and detect suppliers whose real lead times have started slipping. Automate reordering only where being wrong is cheap and reversible. The usual blocker is not the model but a missing record of delivered-versus-promised dates — which is a week of work and the highest-value thing to do first.
What the phrase means at this size
“Supply chain AI” in vendor material means network design, multi-echelon inventory optimization and route planning across a distribution estate. Those are real problems for companies with several warehouses and a logistics function. Choosing what to automate first in a company of ten to a hundred people means looking at a different list.
Here the pain is concentrated: cash tied up in stock that is not moving, a stockout on the one item a customer actually wanted, and a supplier whose lead time has drifted from three weeks to five without anyone recording that it happened. All three are information problems before they are optimization problems, and information problems are where a model is strongest.
Three uses that pay, and their conditions
| Use | What the model adds | Precondition |
|---|---|---|
| Demand forecasting | A per-product forecast that updates itself, with a stated range rather than a single number. | Regular demand and enough history to cover a full cycle. Useless on lumpy, deal-driven products. |
| Stock alerts | A short weekly list: heading for a stockout, sitting far above what will sell, or not moved at all this quarter. | Accurate current stock. If the count is wrong, the list is confidently wrong. |
| Supplier drift | Detection of lead times, fill rates and response times that have moved away from their own history. | Delivered dates recorded against promised dates. The input LYVIA most often finds missing. |
Which products are forecastable at all
The most useful output of a first forecasting exercise is often the classification rather than the forecast: which of your products can be forecast, and which cannot.
Products sold steadily, in small quantities, to many customers are forecastable from modest history. Products sold in occasional large orders to a handful of buyers are not, and no technique changes that, because the pattern lives in your customers’ internal decisions rather than in your sales file. For the second group the right instrument is a conversation with the customer about their plans, which is cheaper and more accurate than any model.
Splitting the catalog this way is worth doing on its own. It tells you where to apply automation, where to apply attention, and it stops a team from judging a forecast badly because it failed on items that were never forecastable. A forecast should also arrive as a range — a single number invites a false sense of precision that the underlying data does not support.
The two stock errors are not symmetrical
Every reordering decision trades two errors against each other, and treating them as equivalent is the most common modelling mistake in this area.
An overstock costs cash, storage, and eventually a discount. A stockout costs a sale, sometimes a customer, and occasionally a relationship that took years to build. The ratio between those two is specific to your business and it is not something a general tool knows. A wholesaler with interchangeable products and a manufacturer whose customer stops a line when a part is missing need opposite settings from the same algorithm.
Before configuring any reordering logic, write down what a stockout actually costs you on your ten most important products. If nobody can answer, that conversation is worth more than the tool — and it is the input the tool needs anyway.
Supplier drift, detected not predicted
Supplier risk is sold as prediction: models that anticipate a failure from news, financial signals and geopolitical data. At this scale that promise outruns the evidence, and the false positives are expensive in attention.
Detection is a different and achievable thing. You already generate the signal: orders placed, promised dates, actual delivery dates, quantities received against quantities ordered, and how long a supplier takes to answer. A supplier whose average lateness has grown over the last several orders is telling you something before it becomes a crisis, and no one notices by hand across thirty suppliers.
The same shape applies as elsewhere: collect, compare to the supplier’s own history, report only what changed, and send it to the person who places orders — the pipeline described in our list of automation workflows to deploy.
The data gap LYVIA finds most often
Sales history, stock levels and unit costs usually exist somewhere. The one LYVIA most often finds missing is the actual delivery date recorded against the promised one — an observation from client work rather than a published survey.
Without it, every lead time in your system is the contractual figure, which is the number the supplier would like to be judged on. Safety stock calculated on quoted lead times is systematically too low for exactly the suppliers who are slipping. Recording the two dates for every incoming order is a small change to a receiving process and it is the input that makes both the reordering logic and the drift detection real.
This is a plumbing exercise rather than an AI one, and it follows the same pattern as everywhere else in this cluster — the constraint is consistent data, not model quality, as set out in our guide to AI infrastructure.
What to automate, and what to leave alone
- Safe to automate: reorders on low-value, short-lead-time, steadily selling items with no expiry. Being wrong costs a small amount of cash for a short time.
- Alert, never act: anything with a long lead time, high unit value, or an expiry date. The model proposes, a person places the order.
- Leave to a person entirely: supplier selection, contract terms, and any decision to switch away from a supplier. These involve relationship and quality history that exists nowhere in your data.
- Not a supply chain question at all: equipment that breaks and stops production — that is predictive maintenance, a different discipline with different economics.
A first version worth building
Take your twenty highest-value products. Classify them as forecastable or not. For the forecastable ones, produce a weekly range and put it next to current stock and the real lead time. For everything else, produce a short exception list: no movement this quarter, or heading for a stockout before the next delivery can arrive.
Send it to the person who places orders, and sit with them for the first few weeks to see which lines they act on and which they ignore. That is the fastest way to find out whether the model is wrong or the threshold is — and where this fits against the rest of a first year is in our AI strategy roadmap.
Stock and suppliers are one vertical; the cross-industry use cases that usually come first are in our list of use cases that survive the pilot.
Frequently asked questions
Is AI in the supply chain realistic for a company of 10 to 100 people?
For three things, yes: forecasting demand on products with enough history to be forecastable, flagging stock positions that are drifting toward a stockout or an overstock, and watching supplier lead times for changes nobody has noticed. What is not realistic at this size is the network optimization that the phrase usually evokes — that solves a problem you have only if you run multiple warehouses and many routes.
How much history does a forecast need?
Enough to cover the cycles that actually drive your demand, which usually means more than one full year if your business is seasonal. But the determining factor is regularity, not volume: a product sold steadily every week is forecastable from modest history, while one sold in occasional large orders will not become forecastable with any amount of data, because the pattern is in your customers' purchasing committees, not in your sales file.
Should stock reordering be automatic?
Only for items where being wrong is cheap and reversible — low unit value, short lead time, predictable demand, no expiry. In LYVIA's own engagements those conditions cover a usable slice of a typical catalog while excluding precisely the items that hurt: long lead times, high value, or anything where a wrong order ties up cash for a season. That is an observation from client work rather than a published figure, and the split is worth measuring on your own catalog. Automate the boring half and you free the attention for the half that needs judgement.
What data do we need before starting?
Sales history with dates and quantities, current stock, supplier lead times as actually experienced rather than as quoted, and cost per unit. The lead-time one is where LYVIA most often finds a gap on its own engagements: the quoted figure is in the contract, the real one exists only in people's memory of which supplier has been slipping. Recording actual delivery dates against promised dates is, in our experience rather than by any published measure, the highest-value week of work available before any model.
Can it predict supplier problems?
It can detect drift in what you already observe — deliveries arriving later than they used to, order quantities being partially filled, response times lengthening. That is genuinely useful and it is detection, not prediction: it tells you something has already started, early enough to act. Anything claiming to forecast a supplier failure from external signals is making a much larger claim than the data supports at this scale.
What is the most common way this fails?
A forecast is built, it is more accurate than the spreadsheet it replaced, and nobody changes an order because of it. As a working rule from LYVIA's own engagements rather than a published benchmark, a forecasting project that has not changed a purchasing decision within its first couple of months will not start later — so the person who places orders has to be in the room from the first week, not shown the output at the end.
If cash is tied up in stock and you still run out of the things customers ask for, that is a measurable problem with a short first build. Book a call.
