I spent about seven years writing purchase orders by hand. Three years at a natural foods co-op, four more at a 9-location specialty grocery chain. Monday was order day. I'd pull the weekend sales reports from each location, cross-reference with on-hand counts from the Saturday morning inventory walk, and sit down to build the week's replenishment orders by SKU and supplier.
On a good week it took four hours. On a week where we'd had a supplier substitution, a promotional push at one location, or an unusual weekend event nearby that spiked sales at two of our stores, it took most of the day. The work wasn't hard -- it was just relentless and manual, and it consumed Monday almost completely.
What the Manual Process Actually Looked Like
If you've run buying for a multi-location chain, you know the rhythm. The process I used was probably similar to yours. Pull each location's sales report for the previous 7 days. Check the on-hand count -- either from a POS inventory module or from a physical count one of the store managers did on Friday. Compare that to the par level I'd set for each SKU at each location. If on-hand was below par, calculate the order quantity. Add it to the supplier's purchase order for that delivery window.
The par levels were the heart of the system -- and the heart of the problem. I'd set them at the start of each quarter based on sales velocity from the prior period. They were right-ish for the products that sold consistently. For fast movers, seasonal SKUs, and anything we were actively promoting, they drifted out of accuracy within a few weeks. I'd catch it when a location called in about an empty shelf, or when I noticed during my order review that I'd been ordering the same quantity for a SKU that was clearly selling faster now than it was in January.
I was managing roughly 400 active SKUs across 9 locations. That's 3,600 inventory positions to track. Manually. Every week.
The First Week With Automated Order Drafts
The first time I opened my Monday workflow and found the replenishment orders already drafted -- quantities calculated per location, organized by supplier, ready for review -- the disorientation was genuine. I spent the first 20 minutes checking the numbers against my own mental model of what we should be ordering, half-expecting the system to have made obvious errors.
It had made two small ones that week. One location's order for a slow-moving specialty grain was about 10% higher than I'd have ordered. The system didn't know I was thinking about discontinuing that SKU because of space constraints. I adjusted it. The other was a quantity that didn't meet a supplier's shipping minimum, which I'd need to round up or consolidate with another order. I fixed both in about 8 minutes.
Total time on order review that Monday: 35 minutes. My prior baseline was 3.5 hours on a normal week. The time savings were immediate and real.
What Changed -- and What Didn't
The parts of my job that changed: order construction, quantity calculation, the weekly POS pull-and-compare ritual. Those were automated. I stopped doing them.
The parts that didn't change: vendor relationships, negotiating terms and minimums, evaluating new products, managing promotional pricing, handling supplier substitutions, deciding whether a slow-moving SKU deserved more shelf space or should be discontinued. Those decisions still required me. They still required judgment about what was actually happening in the stores, what our customers were responding to, what our category mix looked like.
What changed was the ratio. Before, I was spending roughly 60-65% of my buying time on order mechanics -- the calculation and placement work -- and about 35-40% on the decisions that actually determined what we carried and how we positioned it. After, that flipped. Order mechanics dropped to around 15% of my week. The rest went to the work that has more leverage on the business.
The Accuracy Question
The question buyers ask most often about automated replenishment is whether it's accurate enough to trust. The honest answer, in my experience, is: it's more accurate than I was for the high-velocity products that matter most, and approximately as accurate as I was for the slow-velocity products where the stakes are lower.
For the 20% of SKUs that drove 60-70% of our volume -- the fast movers that needed to be in stock every weekend -- the automated forecast updated based on actual weekly sell-through and picked up velocity changes faster than my quarterly par-level review did. That's where the stockout prevention happened. I was maintaining par levels based on January data in March. The system was calculating based on the last four weeks. It was right more often.
For the slow-moving specialty items with irregular sales patterns, neither the system nor I could forecast with much confidence. The system flagged uncertainty and I reviewed those SKUs manually. That was appropriate -- some decisions need a buyer's knowledge of context that no forecast model has access to.
What I Would Have Done Differently
I would have switched earlier. The skepticism I had going in -- that automated orders would miss context, would require constant override, would create more work reviewing exceptions than it saved in order construction -- was wrong. The override rate was low on the products that mattered. The exceptions were real exceptions, not systematic errors.
I would also have spent more time upfront on the POS integration setup. The accuracy of the automated orders is directly dependent on how clean and current the sell-through data is. A well-integrated POS feed is the foundation. If you're still uploading CSVs manually or relying on weekly inventory walks for on-hand counts, the system is working with stale data and the forecast quality suffers accordingly. Getting the data pipeline right at the start is worth the time investment.
The buying part of my job -- the decisions about what to carry, how to position it, how to manage supplier relationships -- that work didn't change. What changed was how much of my week was available for it.
