Author: 4jfyj

Order capture sounds like the simple part. A buyer decides they need more stock of something, and someone writes down what, how much, and from whom. In practice, for a retailer carrying real stock across multiple stores, it’s one of the most detail-heavy jobs in the whole business, and it’s exactly the kind of task where small friction adds up to real cost.

The same item, a dozen ways

A single item on an order is rarely one line. It’s usually one item across a grid of sizes and colours, and the quantities in that grid are almost never uniform, more of one size, none of another, depending on what’s actually selling and what’s already on the shelf. Get the grid wrong and the business either orders stock it doesn’t need or runs out of stock it does. Multiply that across every item on every order, and the accuracy of that one grid becomes a real number on the business’s balance sheet.

Some items don’t fit a size grid at all, they’re sold as a single generic unit rather than in sized variants. A system that assumes everything comes in sizes handles those items badly, forcing someone to work around it. One of the things we paid close attention to in iStoko was making that distinction correctly, so the person capturing the order sees the right input for the item in front of them, not a generic form that almost fits.

Why a photo matters more than it sounds like it should

Attaching a photo to an item sounds like a small convenience. In practice, it’s what lets a supplier confirm, at a glance, that the order matches what was actually agreed, rather than relying on a code and a description that can be misread or mistyped. It also protects the business: if a delivery doesn’t match, the original order, photo included, is the record of what was actually asked for.

The detail that mattered most here was making the photo stick to the item, not the order. Once an item has been photographed, that photo shows up automatically the next time anyone orders it again, no retaking a photo of something that hasn’t changed. It’s a small thing, but it’s exactly the kind of small thing that either saves someone a few minutes on every order, or costs them a few minutes on every order, for as long as they use the system.

Slow or wrong, at the worst possible moment

Order capture usually happens under time pressure, a buyer working through a supplier’s full range against real stock levels, trying to get an order out before a cutoff. If the tool they’re using is slow, or unclear about what it’s asking for, or loses work partway through, that pressure turns into mistakes, and mistakes in a purchase order are expensive to unwind. Getting this part right isn’t about adding features. It’s about making sure the ordinary case, someone placing a normal order in the middle of a busy day, is fast and hard to get wrong.

Order capture was the first piece of iStoko we built, and it’s live and in use now. The next pieces, getting an order from “placed” through to being received in the warehouse, and getting it to the supplier reliably by email, are what we’re working on next. We’ll write about those as they take shape.

Every business that’s been running long enough eventually reaches the same point: the system it depends on every day was built years ago, by people who may not even be around anymore, and it has quietly become the one thing nobody wants to touch. Not because it works badly. Often because it works, most of the time, and everyone is afraid of what happens the day it doesn’t.

We’re currently a few months into exactly that situation with a multi-store South African retailer. Their existing system has run purchasing and stock for years. It’s old, the technology behind it is no longer easy to find people for, and every change to it carries more risk than it should. It needed to be replaced. The harder question was how.

Why we didn’t do it all at once

The obvious approach to replacing an old system is to build the whole new one, test it, and switch over on a chosen date. It’s also, in our experience, the riskiest way to do it. A business like this one runs on its purchasing system every single day. If a full rewrite goes live and something in it doesn’t match how the business actually works, there’s no old system left to fall back on while it gets fixed. Everyone finds out at once, on the day it matters most.

So instead, we’re building the replacement, which we call iStoko, one working piece at a time, alongside the old system rather than instead of it. The old system keeps running production, untouched, while each new piece is built, tested against real data, and used by the actual people who’ll depend on it, before we move on to the next piece.

What “one piece at a time” actually looks like

We started with order capture, the part of the business where buyers place purchase orders with suppliers, because it’s a self-contained piece of work with a clear, testable outcome: can someone place a real order, correctly, faster than they could before. Once that was solid and signed off, we moved to the next piece. Each one gets tested against the same real data the business already has, not sample data invented for the demo, and each one gets used by the people who’ll actually be using it, not just approved by whoever commissioned it.

It’s slower to describe in a project plan than “go live in Q3”. It also means that at every point along the way, the business has a working system, not a promise of one.

It’s not really about this one retailer

The problem underneath all of this isn’t specific to one company or one industry. Any business that carries real stock, whether that’s a retailer, a wholesaler, or a manufacturer, eventually ends up with a system that started as the right answer and became the thing everyone is afraid to change. The shape of the problem, and the way out of it, tends to look the same wherever it turns up.

We’ll keep writing about how this project actually goes, including the parts that don’t go smoothly. Next up: what order capture involves once you get past the obvious bits.