Getting your staff to use the new stocktaking system (it dies in week three, not week one)

New stocktaking systems don't die in week one. Week one everyone's keen, the app is a novelty, and the first count feels like progress. They die in week three, when the novelty's gone, the Friday delivery didn't get booked in, two spot checks got skipped, and the numbers quietly stop being true. Then the app becomes the thing nobody mentions, and the spreadsheet comes back. I've watched this cycle from both sides, as a licensee and as the person who built one of these systems, and the failure is almost never the staff. It's the rollout design.

Vendors won't put a page like this on their sites because "your team may ignore our product by October" is a hard sell. But adoption, not features, is where the money you spend on stocktaking software is won or lost, so here's what actually keeps a system alive past the first month.

One owner, narrow jobs for everyone else

The single biggest design decision: the count belongs to one person. You, or one senior you trust. Not "the team". A stocktake owned by everyone is owned by no one, and the first week someone's off sick you'll find out which.

Everyone else gets, at most, one small and specific job. A five-line spot check on the Tuesday day shift. Writing the wastage line in the book when something goes down the drain. Checking the dray against the delivery note before signing. Each of those is a two-minute task a person can actually be responsible for, and none of them requires learning the whole system. Most decent software supports this shape with team roles, so bar staff can record a count or a spot check without ever seeing settings or reports. Use that. Handing every part-timer the full system is how you end up with nobody confident in any of it.

Launch without the blame, out loud

Here's the thing your team is silently wondering at the first mention of new stock software: is this about catching us? If you don't answer that question, they'll answer it themselves, and the system will be resented before it's even installed.

So say it out loud, before the first count: the first results will show variance, and most early variance is recording, not people. Till buttons that don't match products, deliveries booked wrong, wastage nobody logged, comps nobody wrote down. That's not a speech to make them feel better, it's what the evidence says: work through an unexplained loss properly and the paperwork causes come up long before anything sinister. If the first team meeting about the new system is about theft, you've lost the room, and you were probably wrong anyway.

The same rule applies to how you read the reports afterwards: by reason and by time, never by name on a noticeboard. The voids and refunds guide covers why reading reports by name backfires even when you're right.

Train inside the count, not in a meeting

A one-hour classroom session for four staff costs you about £51 in wages at the £12.71 National Living Wage before employer's NI goes on top, and a week later most of it has evaporated because nothing was learned by hand. Ten minutes each, on a quiet shift, doing a real five-line spot check on the actual bar: cheaper, and it sticks, because they did the thing rather than watched the thing.

It also surfaces problems training can't. The product that's missing from the list, the keg with no size set, the wine that's in the system at the wrong bottle. Your staff find setup gaps faster than you will, because they touch the stock all day. The setup-time guide makes the same point from the other direction: the first counts are the best setup audit you'll get.

Don't put money on the number too early

The fastest way to poison a rollout is to bolt an incentive or a penalty onto a number nobody trusts yet. If the first month's GP is built on estimated prices and half-recorded wastage, and someone's bonus or someone's blame hangs on it, every conversation about the system becomes a negotiation. Fix the recording first, prove the number over a few counts, and only then think about incentives. The kitchen GP bonus guide covers how to build one that doesn't blow up, and the first rule there is the same: never announce a target before you've proved you can measure it.

Make the system carry the load, not the people

A rule I'd apply to any vendor, including mine: if recording something takes longer than doing the thing it records, it will not happen at 11pm, and your data will be fiction by Christmas. Comps need one till button, wastage needs one line, a spot check needs one screen. When you're choosing software, weigh the recording moments, not the reporting dashboards; dashboards are for you, recording is for a busy nineteen-year-old on a Saturday, and the second one decides whether the first one is true. Pick tools that flag what's missing (unset keg sizes, products with no price) rather than relying on anyone's memory, and let the app nag so you don't have to.

The first month, week by week

A rollout shape that survives contact with a real pub. Author's working method, not a published standard.

Week	What happens	Who's involved
1	Owner runs the first full count solo, in tenths where setup is incomplete. Say the "early variance is recording" line to the team	Owner only
2	Fix what count one exposed: prices, sizes, missing products. One senior learns the count	Owner plus one
3	The dangerous week. Spot checks start, two minutes, five lines, one person per shift. Wastage book goes live	Everyone, narrowly
4	Second full count. Compare, read by reason, share one win with the team ("we found the till button that was bleeding lager")	Owner, results to all

Week three is in bold in my head because that's where the quiet deaths happen. The novelty is gone and the habit isn't formed yet. Whatever you do, don't let a skipped spot check slide silently that week; ask about it the same day, kindly, once.

Common questions

Should every staff member learn the whole system?

No. One owner, one backup, narrow jobs for the rest. The full system is maybe two people's business. Trying to train everyone on everything is the most common rollout mistake I see, and it fails twice: nobody masters it, and everybody resents the training time.

What if staff think it's surveillance?

Some will, quietly, whatever you say, because plenty of them have worked somewhere that used stock results as a stick. You beat it with behaviour, not reassurance: read results by reason not by name, blame the button not the person the first ten times something's off, and when the system finds money, say so out loud. Nothing converts a sceptical bartender like watching the thing catch a short delivery instead of catching her.

My head bartender hates it. Now what?

Find out which recording moment is annoying them, because it's usually one specific moment, and it's usually right to be annoyed at. Fix that: a quicker button, or take the task off them entirely. A senior who's been counting the bar their own way for a decade isn't wrong to be sceptical of your app; recruit them by asking them to break it, then fixing what they break.

How long until it's just routine?

If it survives week three, the second month mostly runs itself: counts get faster as the library gets accurate, and by the third count you're arguing about results instead of the system, which is the goal. If you're still fighting the software itself after a month, the problem may be the software; the switching guide covers getting out cleanly.