Stock walking out of the door with nothing to point at Voids and discounts with no record of who authorised them Staff drinks on a tab that stays open for weeks and blocks the stock take A roster on a WhatsApp group and a till that knows nothing about it Bar numbers tangled up with the venue’s books
What usually goes wrong
A day in the life
The roster fills itself from staff sign-ups. A session opens against tonight’s shift and inherits the right people. Tabs run all night, splits and voids are authorised and audited, and the cash-up at 02:00 reconciles takings against stock movement per item. By the time you get home, the P&L already knows.
How it runs
Every step below writes to the same records. Nothing is typed in twice.
From first contact to closed books 6 steps
- 1
The roster fills itself Monday
Publish the week and open shifts go up for self-service sign-up. The gaps fill without a manager chasing anyone on WhatsApp.
Scheduling - 2
Opening checks, with proof 16:00
Fridge temperatures logged as numbers, tills floated, a photo of the bar front. Signed off and audited, whether or not you are there.
Checklists - 3
Session opens against the shift 17:00
The POS session inherits tonight’s roster, so every sale, void and discount is attributable to the people who were actually working.
Bar & POS - 4
Tabs, splits and authorised voids All night
Tabs follow guests across sessions, payments split however the table wants, and a void needs a manager - and leaves a trail.
Bar & POS - 5
Cash up against stock 02:00
Takings reconcile against stock movement per item. Variance is a number with a cause, not a discovery at month end.
Bar & POS - 6
The P&L already knows Sunday
Bar expenses, supplier invoices and takings roll into a profit and loss that stands apart from the venue’s books.
Finance
Before and after
- Stock walking out with nothing to point at
Item-level variance at every cash-up - Voids with no record of who authorised them
Manager-authorised and audited - A roster on a group chat
Shifts staff can claim themselves - Bar numbers tangled in the venue books
Its own P&L, reported side by side
Switched on from the first day
These are the defaults for this kind of business, not a limit. Turn any of them off, or switch on the rest, whenever you like.
- Bar & POS
PosSync is the till: an app of its own on the device at the bar that keeps ringing up sales when the wifi drops. VenueSpine looks after the rest: stock, cash-up and what the bar made.
- Scheduling
Build the roster around your events, group people into teams, and let staff pick up open shifts themselves instead of messaging you at midnight.
- Workforce
Record time against the work it went to, run leave on a calendar the roster can see, and keep each person’s details and documents in one private place.
- Menus
Design menus and price lists that print properly, with every price tied to what the till charges. Change a price once and every menu follows.
- Checklists
Reusable checklists with photo proof, due dates and a sign-off, so the standard is the same whether you are there or not.
- Events
Create an event once and the rest of the platform knows about it: the tickets, the seating, the guests, the staff, the bar and the numbers afterwards.
- Reports
Build a report once, save it, share it and have it arrive by email as a PDF or a spreadsheet, on the day you need it.
A good fit for
Bars, pubs, clubs and nightlife venues trading at volume Anywhere with casual staff and a roster that changes weekly Venues where stock variance is currently a monthly surprise Bars attached to a venue that also runs events
Where it is not the answer
If you have no connectivity at the venue at all, ever, be straight with us up front. PosSync trades happily through a dropped connection, but a session has to be opened and closed online, so it needs signal at the start and end of a shift.
Does the till keep working if the wifi drops?
Yes. PosSync is its own app on the bar device, holding the catalogue and its open tabs locally. It keeps ringing up sales, opening tabs and taking payment offline, and drains the queue when the connection returns - with an idempotency key on every queued payment so a retry cannot charge twice. Opening and closing a session need a connection, because those are reconciliation records computed over every device that traded.
Can we run more than one till?
Yes. Multiple tills run concurrently against the same stock and event, each in its own session, each attributable to its own operator and shift. Offline, a device can only edit the tabs it opened itself - two operators settling one tab from two queues has no correct answer, so the design refuses to create the situation.
Who can see historical sessions?
Only people holding the view-closed-sessions permission. Without it an operator sees open sessions only, and that is enforced in the API rather than hidden in the interface.