A little while back, one of our stores needed to restock a bullet, a dependable counter seller. The manager ordered six. We received 12 fishbowls, not six bullets. Twelve fishbowls.
The order had quietly increased by about $1,300, and I ended up transferring fishbowls to 11 other stores to spread out the damage.
The software cannot understand your business as well as you do, but its purpose is to learn to understand it and continuously improve without rest.
Nobody was asleep at the wheel. It was a unit-of-measure mix-up, the kind where the vendor sells by the case, the POS thinks in singles, and somewhere in between, a “6” becomes something nobody intended. The tools that should prevent these problems usually can’t, because they don’t know how that vendor actually ships the item.
That gap between what software knows and what you know is the central focus of this article.
If you’ve been following this series, you know my advice was to get ahead of AI. I’m here to sharpen that advice. AI is no longer an edge. It’s the price of admission.
Here’s the catch: none of these tools work out of the box. You have to build the environment around them and provide them with the context only you have. When you do, someone who understands the operation can build something that multiplies their output.
Over the past year, that’s what I’ve built for our 21 locations. I call it Retalyz, pronounced “retail-eyes.” Before that, I spent my time putting out fires. Now I have a tool that handles automatable work and improves it in a loop. This month, I want to open up its core: the engine that decides what to order.
Inventory is the lifeblood of a retailer, and ordering is where it lives or dies. Every order is a bet between two bad outcomes: money frozen in stock or empty pegs when a customer is standing there with cash. Across 21 stores, orders are placed by hand, and that bet is mostly a guessing game that eats hours.
Our old process was repetition disguised as control: A manager ran the POS reorder report, cleaned up discontinued items, dropped sales and clearance spikes, then guessed quantities. The buyer reviewed it again. If anything fell outside the usual range, it came to me or one of the owners. Each pass took one to three hours. The same order, three or four times.
Here’s the part that surprised me most when I dug in. The reorder math in most systems, ours included, is essentially units sold divided by the days between orders. Sounds reasonable. But it’s blind in an expensive way: an item that sold out on day one and sat empty for a month looks identical to one that sold the whole time steadily. The system only counts the sales you made. It has no idea about the sales you couldn’t make because the shelf was bare. Those invisible sales are where the money leaks out.
So I built the portal to estimate them. Every item gets a confidence score based on how available it was. If we were in stock throughout the period, I trust the sales as real demand, then adjust for seasonality and trend. If the item was out of stock for part of the period, the confidence drops, and the projection scales up to estimate what would have sold if we’d had it. Then the order is sized to ensure we don’t run dry again before the next delivery arrives.
That last piece matters more than it sounds. Most software lets you set a safety-stock level, usually the same across a whole category and based on a manager’s gut. Ours doesn’t guess. It watches order history and learns the real lead time for each path: how long it takes a manager to place the order, how long the buyer takes to process it, and how long the vendor takes to ship. Then it adjusts as those numbers drift.
At that forecast level, the portal automatically completes the rest of the review. Every night, it reads what changed, including sales, receiving, transfers and returns, then rebuilds the picture. It builds the order the way our best people would: drops discontinued items and clearance spikes, right-sizes quantities, checks vendor thresholds and minimums, converts singles into the boxes and cases the vendor actually ships, and flags when one more unit crosses a free-shipping line. Yes, exactly the fishbowl problem, handled early.
Then it routes the completed PO for approval and scheduling, so purchasing can time the cash flow. The people don’t disappear from the loop. They stop doing the work and start reviewing the exceptions.
What does that buy you? The clearest win is the one I can stand behind without hand-waving: The one-to-three-hour review, done three or four times, collapses into a few minutes of reviewing what the system flagged. Fewer fishbowl-class mistakes. Less idle stock and fewer empty pegs, by design. An order that takes this long also makes it easy to skip checks or miss things entirely, which is how the fishbowl problem happened.
Could you just buy this? You can buy something. There are big-name systems, and our POS has built-in dynamic reordering. They’re expensive and generic, which means they don’t know your lead times, your clearance habits, or that one vendor who ships in 12s. The thing that made ours work wasn’t clever code. It was the context only an operator has. That’s the real lesson: You don’t need to be a programmer to build this. You need to understand the business well enough to teach it.
I’m most excited about this shift: transitioning from automation to an agentic approach, where people monitor exceptions rather than follow strict scripts. The ordering process was challenging, but once the pattern is established, it becomes repetitive.
The software cannot understand your business as well as you do, but its purpose is to learn to understand it and continuously improve without rest.
Zondre Watson is the general manager of technology and analytics for adult retail chain Ero-Tech. With a background in finance, chocolate and controlled chaos, he blends retail know-how with AI tools to keep 17,000 products moving smoothly.
