The alerts you already have, and why they stopped working
Almost every platform worth using — a POS, an ecommerce backend, a warehouse system, an ERP — ships with reorder-point alerts out of the box. Set a threshold per SKU, and the system pings someone when stock crosses it. That's not a gap in the market. It's the default, and it has been for years.
The problem is what the threshold doesn't know. A static number has no sense of how fast a SKU is actually moving right now, and no sense of how long a reorder actually takes to land. For a fast seller, that's dangerous: by the time the count crosses the line, the SKU might already be days from zero, and a supplier lead time longer than that gap means the alert fires too late to prevent a stockout — it just announces one that's already locked in. For a slow seller, the same fixed number does the opposite: it fires the instant stock dips below a line that was set for a product moving several times faster, on a SKU that will happily sit above zero for another two months. The alert wasn't wrong, exactly. It just had nothing useful to say.
Run that pattern across a full catalogue for a few months and a predictable thing happens: staff learn which alerts to trust and which to swipe away without reading, because most of what lands in the inbox turns out to be noise. Once that habit sets in, it doesn't discriminate — the one alert that actually mattered gets the same glance and dismissal as the fifty that didn't. A stock alert nobody reads is worse than no alert at all, because it creates the appearance that someone is watching when nobody actually is.
The prerequisite: none of this works if the stock count is wrong
Before anything about rate of depletion or lead time — say this plainly, up front, because it's the part vendors tend to skip. An alert, fixed-threshold or dynamic, is only ever as good as the number it's reading. If the count in the system is off because of shrinkage, a miscount on the shelf, a return that never got scanned back in, or a channel that hasn't synced with the rest of the business, then the most carefully tuned depletion model available will still produce a confident alert built on a number that was never true.
This isn't a reason to leave the static threshold in place. It's a reason to treat stock accuracy as part of the build, not an assumption underneath it. Cycle counts, reconciliation between channels, and a single source of truth for "what's actually on the shelf" have to be roughly right before an alert — any alert — is worth building trust around. We say this before the pitch, not after a launch, because a client who finds out their counts were off after the alerts start misfiring won't trust the next system we build them either.
Fixed reorder points vs. automated depletion alerts
| Fixed reorder point | Automated depletion alert | |
|---|---|---|
| Trigger | A static count set once per SKU | Current sell-through rate weighed against real lead time |
| Fast movers | Often fires after the window to reorder in time has already closed | Fires while there's still time to place and receive the order |
| Slow movers | Fires repeatedly on stock that isn't actually at risk | Stays quiet until the trend says it matters |
| Seasonality | Blind to anything coming up on the calendar | Accounts for demand you already know is on the way |
| Location | Usually reads one combined total | Reads stock where it actually sits, by location or channel |
| Who receives it | A shared inbox or dashboard nobody specifically owns | The person who can place the order, with the order attached |
None of this makes the fixed threshold a bad idea in principle — a number is easy to set and easy to understand. It just isn't the same job as knowing when to act, and businesses that keep both running side by side usually find the static version adds noise rather than a safety net once the dynamic version is live.
How a build actually works
Alerting on rate of depletion and lead time, not a fixed number
The core change is what the system is actually watching. Instead of a single count threshold, it tracks how fast each SKU has genuinely been selling — not a single snapshot, but a trailing rate that adjusts as the trend shifts — and weighs that against how long a reorder actually takes to arrive. The alert fires at the point where those two numbers intersect: late enough not to waste anyone's attention, early enough that the order can still land before the shelf goes empty.
Seasonality and demand you already know is coming
A depletion rate calculated purely from the last few weeks assumes tomorrow looks like yesterday, which is a bad assumption right before a promotion, a seasonal spike, or a marketing push that's already scheduled. A system worth building layers in what you already know is coming — a planned campaign, a recurring seasonal pattern from prior years, a wholesale order already confirmed — so the alert adjusts ahead of the spike instead of reacting after it's underway.
Supplier lead-time reality vs. what the supplier record says
Most supplier records carry a lead time that was quoted once, at onboarding, and never revisited. Actual performance drifts — a supplier that shipped in two weeks a year ago might reliably take three and a half now, or ship reliably fast most of the time with the occasional long delay that the quoted number doesn't reflect at all. A build worth trusting tracks actual received-date history per supplier and per SKU, and calculates the real lead time — with its real variance — rather than trusting whatever number sits in a field that hasn't been checked in years.
Multi-location and channel-level stock, not just the total
A combined total across every warehouse, store, and sales channel can look perfectly healthy while the one location that actually needs stock is sitting empty. A retailer with three locations and a comfortable-looking aggregate count can still turn away a walk-in customer at the one store that happens to be out, and a marketplace channel can sell through its allocation while the storefront still shows plenty left. Alerts scoped only to the total miss exactly the shortfall that matters. A system built for this reads stock at the level where the shortage is actually happening — by location, by channel — and alerts on that, not the number that hides it.
Routing the alert to someone who can act, with the order attached
An alert that lands in a shared inbox nobody specifically owns gets the same treatment as everything else in that inbox — eventually. The alert needs to reach the person who actually places that supplier's orders, carrying the reasoning behind it and the recommended order — quantity, timing, supplier — already attached, so acting on it is a quick approval rather than a research project. That's the same human-in-the-loop principle that shows up across most of what Calfy builds: the system does the watching and the calculating, and a person makes the actual call on the order, with everything they need already in front of them.
The discipline of alerting less, so the alerts get read
The fix for alert fatigue isn't a louder alert. It's fewer of them, aimed better. A well-built system deliberately suppresses noise — raising the bar for slow movers that were never really at risk, escalating once rather than repeating the same notice daily, and going quiet again once an order has been placed against it. The goal isn't maximum coverage. It's a small number of alerts that a buyer opens without hesitation, because the last dozen they got were all worth their time.
What it connects to
A build like this is one application of broader workflow automation, and it only earns its keep once it's actually wired into the systems that carry real stock and order data:
- Your inventory, POS, or warehouse system — the source of the stock counts and movement history the whole thing depends on.
- Your ecommerce platform and marketplace channels, for businesses selling across more than one storefront, so alerts can be scoped to where stock actually sits rather than a blended total.
- Your supplier or purchase-order system, both to read actual lead-time history and to attach a ready-to-approve order to the alert itself.
- Wherever your buyer or ops lead actually works — Slack, email, SMS, or inside the inventory tool itself — so the alert shows up somewhere it will genuinely get seen, not a dashboard nobody opens.
For ecommerce businesses specifically, this usually sits alongside the broader back-office automation layer that keeps orders, catalogue data, and returns in sync across channels — inventory alerts are one piece of that picture, not a standalone tool bolted on separately. The same underlying discipline, reading a system's own data and routing it to the right person before it becomes a bigger problem, shows up in automating order-status calls too, on the customer-facing side of the same operation.