Attribution is not surveillance. It is the only way a day's revenue can be reconciled without rebuilding it from memory.
01 — The problem
02 — Attribution
03 — In practice
Most cafés lose money in the gap between what was served and what was recorded. Not through theft — through evaporation. A ticket written on a pad, a drink added verbally, a table that changed hands mid-service.
When the day's total does not match the till, the instinct is to look at the staff. That is almost always the wrong place to look. The failure is structural: nothing in the process made the order durable at the moment it was taken.
If an order exists only in someone's short-term memory until it reaches the register, then every busy hour is a data-loss event. The fix is not more supervision. It is capturing the order once, at the point it happens, with the person who took it attached to it.
Once every ticket carries a server, three things become possible that were not before. You can reconcile the till against a list rather than a feeling. You can see which sections of the floor actually generate revenue. And you can train against real numbers instead of impressions.
It also protects the staff. A server who is consistently attributed is a server who can demonstrate their contribution — and who cannot be blamed for a shortfall on a shift they did not work.
Keep the friction near zero. A server should sign in with a short code, not an email and password. The order should be built by tapping items, not typing them. And the ticket should be immutable once submitted — corrections become their own recorded event.
Done properly, closing the till stops being an act of reconstruction and becomes an act of reading.
Categories, naming and price architecture that cut training time.
What offline-first means when the router fails mid-rush.
If the day must be rebuilt from paper, it was never recorded.