A stock count looks exactly the same whether it was taken an hour ago or yesterday afternoon. Most people ordering against one could tell you whether it is accurate. Very few could tell you how old it is.
Chris Wootton's paper, From Documented to Understood, set out why documentation describes the process someone intended, and why the evidence has to come from the systems that record the work. I spend most of my time connecting those systems, and the question I keep meeting sits one step after his. Once you have the evidence, when was it true? Build a current-state picture, the working account of how a business runs today, from records that arrive a day late, and it describes yesterday. In parts of a leisure business, yesterday is already too old to order against.
Two teams, one fleet, two stock counts
City Experiences operates a fleet of eight tour and event vessels across London and York. When Cocoon Technology started working with them, every sale went through Square POS, the tills on board, whether on a daytime tour or an evening event. At the end of each day the sales were printed out as paper dockets. Someone reconciled those dockets against stock by hand, a job that took several hours every day, and the ordering ran on the result.
Underneath that sat two processes. The daytime tour teams recorded stock directly in Square. The evening event teams kept their stock counts on paper, writing them onto the dockets to be typed up later. The two teams also used different product codes for some of the same items, so their figures disagreed about what things were called before they disagreed about anything else.
Follow one evening's stock through that. It is counted on board and written on a docket at the end of the shift. The docket is typed up the following day, in codes the day team does not use. By the time the count reaches the reconciliation, the day team has been making decisions for hours without it, and the order going out carries no count from the previous evening at all.
So the day team ordered blind, because the evening's counts had not reached it yet, and it covered the gap by ordering more. The extra landed on the stock that could least afford it. Perishables bought against a count that was a day old went in the bin.
The case for leaving it alone
There is a sound argument for doing nothing about this. Next-day data is normal, and plenty of businesses count stock weekly. A day's delay sits well inside any sensible ordering cycle, and chasing live figures across a fleet is an expensive answer to a problem a careful manager solves with a buffer. For anything with a long shelf life, all of that is true.
The argument breaks on the perishables. The test for any figure is whether it is older than the thing it describes lasts, and whether it is older than the decision it feeds. A count of stock that keeps for months can sit for a week. A count of fresh stock that arrives a day late has already missed the order it was meant to change. And the buffer that protects you from a stale count is the over-ordering itself, so the careful manager's fix and the waste are the same thing.
Where the day goes
Every sale, day or evening, was in Square the moment it happened. The evening's stock counts were what waited. The day was lost between Square and Procure Wizard, the system City orders stock through: in the docket, the transcription, the second set of codes and the hours of reconciliation. Both systems were doing their job. The delay lived entirely in the gap between them.
Recorded system data is the best evidence available of how work happens, and it is only ever as current as the connection that carries it. When systems are connected, the record arrives while it is still true. When they are joined by people, paper and spreadsheets, every hand-off adds age, and nothing on the final figure tells you how much.
Two processes make it worse. A late picture can be fixed by waiting for it. A picture assembled from two teams recording the same stock in two ways has to be reconciled before it is even late, and City had both.
What changed on the boats
The order of the work mattered as much as the work. Cocoon mapped the gaps first and agreed one consistent way for the daytime tour and evening event teams to record stock and sales. Automating two processes would have delivered two sets of figures faster.
Then came the build. Square POS was connected live on all eight vessels, and the end-of-day dockets stopped. A data pipeline on Connections, Cocoon's integration platform, now takes sales from Square, transforms them and feeds them straight into Procure Wizard. The stock position the ordering runs on moves with every sale made on board, day or evening. The several hours of daily reconciliation became a near-instant automatic check. Wastage is down.
Finding the age of your own picture
You can date your own current-state picture with a pen. Pick one decision that runs on it, such as the next stock order or the staffing rota, and work back from it.
When was the figure behind that decision last true? Count back from the decision to the moment the thing it describes actually happened. How many hand-offs sit in between, and how many of them involve someone retyping from paper or a spreadsheet? Does every team feeding the figure record the same thing the same way, with the same codes? And what in your business is gone before the data catches up with it?
The last question decides whether the delay matters. Where the answer is nothing, next-day data is fine, and money spent speeding it up is money wasted. Where the answer is fresh stock sitting on a boat, the gap between the sale and the system costs you something every day, and you can see it in the bin.
City's picture used to arrive the morning after, in two versions. It now arrives with the sale.