Housekeeping stock: why a list of items is not inventory control
Most inventory features answer "what do we have?". The question that actually runs a property is "what is missing from room 4 right now, and who has to bring it before 3pm?" — and those need different data.
A list tells you what you own; a target tells you what to do
The first version of every inventory feature is a list of items with quantities. It is genuinely useful for insurance and useless for operations, because nothing in it says whether the current state is acceptable.
The missing piece is one number per item per space: the par level, the quantity that space is supposed to hold. Six towels in this room. Two sets of linen in that cupboard. Once that target exists, everything operational falls out of it as arithmetic — how many units are missing, which spaces are below their target, which items need reordering, what the gap is worth in money.
In Boris only the target is stored. The gap, the below-par flag, the reorder flag and the stock value are all derived at read time, which is why they can never disagree with each other. That is what turns a list into a checklist.
The quantity is a conclusion, not a field
The second design decision matters more than it looks. If stock quantities can be edited directly, then at the end of a month you have a number and no explanation.
The alternative is a ledger: every change writes a movement, typed — created, adjusted, restocked, consumed, lost, damaged, counted — and the quantity is simply what the movements have left behind. Nothing writes the quantity without also writing why.
This is what makes shrinkage answerable. Thirty towels left the building; a ledger can tell you that twenty-two were consumption spread across stays, five were a single loss recorded after one check-out, and three were damage that opened maintenance tasks. The same net figure, three very different conversations.
One small schema choice worth copying: store the cost impact as a positive magnitude and read the sign from the movement type. A ledger where some amounts are negative and others are not is a ledger that eventually sums wrong in one report and right in another.
The count has to start itself
Turnover is the moment when stock control is both most valuable and least likely to happen. The previous guest has left, the room is empty, somebody is about to clean it — and nobody has time to open a stock app and start a count.
So the count sheet should already exist when they get there. In Boris the check-out event does three things without anyone asking: it deducts the consumables the stay used, it queues the turnover count for that space, and it does so seeded with only the items flagged as worth counting on turnover — nobody counts the furniture between two stays.
Deduction has two rates, because consumption does not work one way. Some items go per stay regardless of headcount (a welcome kit). Others go per guest-night (coffee, toiletries, breakfast items). A single rate forces you to mis-model half the catalogue.
The important architectural point: this control hangs off the check-out event, not off a nightly job. Scheduled jobs are fine for the periodic extras — the overdue nudges, the daily replenishment digest, the quarterly full count — but the control itself must not wait for a cron window, because the room is being cleaned now.
What a completed count must do
Overwriting the quantity is the least interesting part. A count that is finished properly does four things:
- Makes the counted quantity the new stock.
- Files the shortfall as a loss movement, so the ledger explains the drop instead of just showing it.
- Stamps when the space was last checked, which is what makes "not counted in six weeks" a question someone can ask.
- Opens a maintenance task for each item reported damaged, linked back to the item.
That last one is where inventory stops being an accounting exercise. A cleaner noticing a broken lamp is the cheapest maintenance report your property will ever receive, and if the count sheet is the only place they are already standing, that is where it has to be collected.
Built for a phone, between two stays
One last thing that decides whether any of this gets used. The person doing the count is standing in a room holding a phone, with ten minutes before the next arrival. If the count sheet needs a desktop, a login they do not have, or more taps than items, it will be filled in afterwards from memory — which produces data that looks complete and is fiction.
Stock control that works is mobile-first, pre-seeded, and short. Everything else — the valuations, the reorder reports, the shrinkage analysis — is derived from those ten minutes being genuinely easy.
Frequently asked questions
What is a par level and why does everything depend on it?
It is the target quantity a space should hold: six towels in this room, two coffee pods on that desk. Once the target exists, everything useful is arithmetic — the gap, whether the space is below par, whether an item needs reordering. Without it you have a list of what you own, which tells nobody what to do next.
Why should stock quantities never be edited directly?
Because the quantity is a conclusion, not a fact. Every change should write a movement — restock, consume, loss, damage, count — and the quantity is what the movements leave behind. Edit the number directly and you lose the only thing that explains a month of shrinkage: which changes were consumption and which were losses.
Should the turnover count be started by staff?
It should start itself. The count sheet for a room is created when the stay checks out, seeded with the items flagged as worth counting on turnover. Anything that depends on someone remembering to start it will be skipped exactly on the busy days when it mattered most.
What should a completed count do besides update quantities?
Three more things: record the shortfall as a loss rather than silently lowering stock, stamp when the space was last checked, and open a maintenance task for each item reported damaged. A count that only overwrites a number throws away the information it was collecting.