Plans, resources, company information, and legal documents.
Most cycle-count programs are scheduled by item value. We think the better question isn't how often to count something — it's how likely it is to be wrong right now.
The classic approach to cycle counting is ABC: sort items by value, count the high-value ones often and the low-value ones rarely. It's a reasonable answer to an old question — how do you spend scarce counting time when every count is slow and manual?
But ABC never asks the question that actually matters: is this item likely to be wrong? It prioritizes by value, not by probability of error. So you spend labor recounting expensive items the system already has right, while a cheap, fast-moving, heavily-handled item drifts out of sync unnoticed.
A count that finds nothing is a wasted count
The whole purpose of cycle counting is to catch discrepancies before they compound into stockouts and mispicks. A count that confirms what the system already knew cost you labor and produced no information. The counts worth doing are the ones likely to surface a real problem.
How Nautilus prioritizes
Instead of a value-based schedule, Nautilus ranks locations by how likely they are to be wrong right now. It weighs things like how long it's been since a location was last counted, how much picking, receiving, and relocation activity it has seen since, whether it sits near a congested zone where items get bumped and restacked, and whether that particular bin has a history of being problematic.
The output is a ranked queue: start at the top, where a discrepancy is most likely, and work down. Operators can always override it, but the default sends them to the counts most likely to matter.
One design note from experience: we present priority as plain levels — critical, high, medium, low — rather than a precise-looking probability. A number like "87%" gets misread as "you'll find a problem 87% of the time," which isn't what it means. Clear priority bands communicate the same ranking without the false precision.
Risk-based counting won't rescue a broken process. If labels are unreadable or one station is systematically miscounting, you'll just keep recounting bad data — fix the root cause first. But when the process is sound, pointing your counting labor at the likely errors makes every count pull more weight.