· 6 min read
There is a version of this project that takes nine months and never finishes. It starts with a data cleanse, moves to a categorisation scheme, acquires a spreadsheet of every item anyone can think of, and ends when the person driving it moves on. Nothing was ever used, so nothing was ever learned.
The version that works starts smaller than feels responsible and is in real use by the end of the first week — because the only reliable way to find out what your store actually needs is to run it badly for a fortnight and see what hurts.
Week one: one store, the top fifty lines
Pick one physical store. If you have several, pick the busiest, not the tidiest — the tidy one will teach you nothing and the busy one is where the problems live.
Then take the fifty lines that move most. Not the fifty most valuable, and definitely not all of them. Fifty lines covers most of the daily traffic in a typical maintenance store, it can be counted in an afternoon, and it is small enough that a mistake in the setup is cheap to correct.
- Count those fifty and enter them as opening balances. Do it in one session — a balance counted on Tuesday and entered on Friday is already wrong.
- Decide the stocking unit for each one as you go, and write it on the shelf label. This is the decision that causes the most pain later if it is left implicit.
- Turn on recording for issues and nothing else. No reorder points yet, no reports, no approvals.
- Tell people what is happening in one sentence: we are recording what leaves the store, starting Monday, so we stop running out.
Week two: watch where recording does not happen
Do not add anything this week. Watch instead, because the gaps between what the process assumes and what people do are visible now and will be invisible in a month once workarounds have hardened.
The things worth noticing:
- When does someone take something without recording it? Usually out of hours, in a hurry, or when their hands are full. Each of those has a different fix and none of them is a reminder email.
- Where does the recording step take too long? If it is more than about fifteen seconds at the point of issue, it will decay.
- What do people ask for that is not on the fifty? That is your next tranche, chosen by reality rather than by a meeting.
- What arrives at the door and gets used before it is booked in? That is your goods-in problem, and it is usually bigger than the issuing problem.
When somebody bypasses the system, they are telling you the system costs more than the thing they are trying to do. That is information, not misconduct.
Week three: extend by usage, not by category
Add the lines people actually asked for. Resist the urge to complete a category for tidiness — "we may as well do all the fixings while we are here" is how fifty lines becomes eight hundred and the project stalls.
This is also the week to introduce goods in, because by now you have felt what happens without it. Deliveries booked at the bay, counted rather than copied from the note. That step alone removes a category of discrepancy you would otherwise spend the next year investigating.
Week four: minimums and the first count
Now you have three weeks of real consumption for the fifty lines that matter, which is enough to set minimums that mean something. Setting them in week one would have been guessing, and a wrong minimum is worse than none — it produces alerts people learn to ignore, and an ignored alert is permanently ignored.
Then count twenty of the fifty, blind, and see how you did. Expect somewhere between 60% and 85% exactly right on a first pass. That number is not a verdict on your team; it is your baseline, and the trend from here is the only thing that matters.
How to tell it is working
Not by adoption statistics. By these:
| Signal | What it means |
|---|---|
| Someone asks the system instead of asking a person | The record is becoming more trusted than memory |
| A stockout is noticed before it happens | The minimums are roughly right |
| A discrepancy is explained rather than absorbed | The history is detailed enough to be useful |
| Somebody asks for a line to be added | People consider it theirs |
That last one is the real milestone and it usually arrives in week three or four. Until people ask for things to be added, they are complying. After it, they are using it.
The three ways it goes wrong
- Perfect data first. The cleanse never finishes, nothing goes live, and the effort is written off. Start with fifty lines that are right and let the rest arrive.
- Everything at once. Stock, assets, reorder points, approvals and reporting in week one — so when something does not work, nobody can tell which part is at fault.
- Introducing it as a control. If the first message is about accountability, the system becomes something done to people. If it is about not running out, it becomes something that helps them. The mechanism is identical; the reception is not.
Thirty days of this gets you a store where the balances are broadly true, the busy lines do not run out, and the discrepancies you do find are recent enough to explain. That is a working system. Everything after it is refinement.
Nilstock is built to be usable on day one rather than after a configuration project — one store, a handful of lines, recording at the point of issue. The pricing page sets out what a trial includes, and the feature list what is there when you need it. If you are moving off a spreadsheet, when a stores spreadsheet stops working covers what breaks and why; setting reorder points is week four.
Nilstock does this bit for you.
Scan a badge, scan the item, confirm. Fourteen days free, no card.
Read next
When a stores spreadsheet stops working (and why it is not the spreadsheet)
It is rarely the number of rows. It is the number of people who can change stock without changing the file.
Cycle counting: how to stop shutting the store for stocktake
An annual count tells you that you are wrong. A weekly one tells you why.