Why bar documents go stale — and how to stop it
A beverage programme's documents go stale because they are copies. The costing is a spreadsheet, the spec cards are a Word file, the prep sheets are a PDF on the bench, the order sheet is whatever was printed last month and the engineering report is a one-off — six files, six versions of the truth, and every price change or recipe tweak makes another one wrong. The only durable fix is to stop keeping documents at all — make the spec card, the prep sheet, the order sheet, the costed menu and the margin report derived views of one database, published as a snapshot the team reads and flagged the moment the record behind it changes.
I built Deluge because the programme never lived in one place. At Eau de Vie it was forty technical cocktails — clarifications, washes, cordials, carbonated and kegged serves — and the product list, the costings, the menu drafts, the spec cards, the engineering and the reports were six files, six versions of the truth. Every price change made another one wrong. At a resort with more than one bar, multiply it.
This is not a story about one venue being disorganised. It is how every bar I have walked into works, including the good ones.
Copies drift
A spec card is written from a recipe. A prep sheet is written from the prep’s recipe. An order sheet is written from a par list. A costed menu is written from the costing. Each is a copy of something, made at a moment, and from that moment on it is wrong by whatever has changed since.
The changes are constant and small. A supplier lifts a price. A bartender tightens a spec by five millilitres. A cordial’s yield gets rewritten after a bad batch. A menu line is re-priced after an engineering run. None of these is an event anyone would schedule a document review for, and so nobody does, and the documents quietly diverge until the count does not reconcile and the GP does not match and everyone is arguing from a different sheet of paper.
Updating the spreadsheet does not help, because the spreadsheet is one of the six.
Views, not files
The fix is to stop making copies. If the spec card is derived from the recipe every time it is rendered, it cannot be out of date with the recipe. If the prep sheet is derived from the prep, the order sheet from the pars and the product list, the costed menu from the menu and the costing, and the margin report from the sales period and the costing — then a supplier price change re-costs every prep, batch, drink and menu line that depends on it on save, and every document is a view of the same numbers.
That is what Deluge is: one database, every document. A product is costed once, ex-tax. Preps, batches and drinks reference it by identity, so renaming a product does not orphan anything. Change a price and everything downstream moves. The documents do not go stale because they are not documents.
Publish a snapshot, not a live feed
There is a subtlety. The bar team should not see a live view. A bartender mid-service needs the card to say the same thing at eleven as it said at six, whatever the manager is editing in the office.
So each list publishes as a pack: spec cards and, as chosen, a production list, prep sheets, container labels and an order sheet — rendered once, stored, fingerprinted. The team reads that snapshot through one shared link or on the bar kiosk. When a build, a method or a price that the card prints changes, the manager’s board says the pack is out of date; one Apply sends every out-of-date pack again. The team always has either the current version or one the board knows is stale — never a silently wrong one.
Packs show guest prices and never costs. That is a principle as much as a feature: the person pouring does not need the margin, and a card with a cost on it is a card nobody laminates.
What this looks like on a Tuesday
A supplier’s price list arrives. It is pasted in; the columns are recognised from last time; the products it names re-cost. The board shows two packs out of date because their menus print a price that moved. The manager decides whether to hold the price or re-price, presses Apply, and the kiosk and the staff link update. The order sheet for Thursday is printed from the pars as they stand. Nobody opened Word.
What it takes to get there
Getting a programme into one database is the setup that follows the health check: every product, prep, batch and drink entered once, properly. It is the least glamorous week of an engagement and the one everything else depends on. After it, the documents look after themselves — and the venue keeps running on the database under licence, because the whole point is that the programme should not depend on the person who built it.