Inventory tracking for a small operation: what to settle before choosing a system

01 / FIELD NOTE

Keep the decision tied to the operating context.

A small operation choosing a tracking system is usually comparing products before it has settled what it needs. That order is backwards, and it is why so many small deployments end up with capability nobody uses and gaps where it matters. The requirements are not hard to write, but they have to come first.

The first requirement is the unit of tracking. What is the smallest thing the business needs to distinguish? A case, a pallet, an individual item, a batch with an expiry, a serialized asset? Every later decision — label cost, application labour, reader type, software licensing — follows from this one. Choosing item-level when the business genuinely decides at case level adds cost to every unit for information that changes no decision.

The second is the movement that matters. Not every movement needs capturing; the ones that change a decision do. For a distributor it might be receipt and dispatch. For a retailer it might be receipt, sale and return. For a workshop it might be issue to a job. Writing down the four or five movements that genuinely change what someone does next keeps the design small enough to finish.

The third is the tolerance for error, stated in operational terms rather than as a rate. What happens if the count is wrong by one? Does it cost a re-order, a late delivery, a lost sale, or nothing? A business that can absorb small variance needs a different design from one where a single missing serialized unit is a reportable event. Stating the consequence is more useful than naming a number, because the consequence is what the team will actually be judged on.

The fourth is who owns the record. This is the requirement most often left implicit and most often the reason a system decays. If the count is everybody’s job it is nobody’s job; if correcting an exception has no owner, exceptions accumulate until the team stops trusting the figure and starts keeping a parallel spreadsheet. The owner does not have to be a dedicated role — but the responsibility has to exist and be visible.

The fifth is the environment the tags will live in. Metal shelving, liquid products, freezers, outdoor yards, high-temperature processes and abrasive handling each change what will read and what will survive. A short inventory of surfaces and conditions, taken by walking the space, prevents the commonest surprise: hardware that works in the demonstration and not on the shelf.

With those five settled, the technology choice becomes narrower and more honest. Where movements are at defined points and goods pass in bulk — a dock, a door, a conveyor — fixed reading suits the problem. Where the work is counting shelves and finding misplaced items, a handheld suits it, and it is usually the right first purchase because it can be trialled on a single area without infrastructure.

Barcodes remain the correct answer more often than an RFID project will admit. If the goods are individually handled, presented one at a time, and the business needs a product-level identity rather than a unit-level one, a barcode does the job at a fraction of the cost and with staff who already know how to use it. The reason to move on is a movement that cannot be captured one-at-a-time — bulk receipt, a count that is too slow, an item that must be found rather than scanned.

Integration is the requirement that most often decides the real cost. A tracking system that does not update the system of record leaves staff reconciling two views by hand, which is worse than either alone. Before comparing products, establish what the business already runs — accounting, order management, e-commerce, a spreadsheet — and what an acceptable update path between them looks like. Whether that path is an API, a scheduled file, or a manual export changes the project more than the reader does.

The starting scope should be one area and one movement. A single store room, one receiving door, one category. The purpose is not a modest result but a real one: a count that takes a known time, an accuracy the team can see, and an exception process that got used. Scale follows evidence, and a small deployment that produced evidence is more persuasive inside the business than a large one that produced a dashboard nobody reads.

Cost belongs in the plan as a per-unit figure rather than as a project total, because the per-unit figure is what scales and what gets compared to the value of being right. Labels, application labour, hardware amortisation and software fees all belong in it. A tracking approach that looks affordable at pilot scale and unaffordable at full scale was misjudged at the start, not at the end.

Finally, decide in advance what would make the business stop. A pilot with no stated failure condition is a pilot that will be declared a success and then quietly abandoned. Naming the condition — this many unattributed exceptions, this much time per count, this level of staff workaround — is what turns the exercise into a decision instead of an opinion.