When Inventory Meets the Front of House

Three systems, one week

On a normal week a bar might touch a website or booking path for guests, a POS for sales, and an inventory walk for the cooler and wells. When those three disagree, managers argue about which number is “real” instead of fixing the leak.

Open Source Barware exists so the inventory side stays free and usable. It is not a website product and it is not a booking engine. It is a floor tool. The point of this note is narrower: once counts and POS imports are honest, the rest of the stack gets easier to reason about.

What “connected” actually means on a shift

• Guest asks for a private event — someone has to capture the request, not lose it in a DM.
• POS rings a busy Friday — usage should eventually reconcile to the walk, not a gut feeling.
• 86’d item — floor, POS, and ordering should not find out at three different times.

You do not need enterprise software day one. You need clean handoffs: what got counted, what sold, what was promised to a guest.

Keep the free tool free

This program stays free and open source on purpose. No account wall, no trial timer, no “upgrade to unlock variance.” If something around the venue needs a custom website, AI phone intake, or deeper ops wiring, that is a different job — and it should stay labeled as such. Operators should never feel sold to for downloading a count tool.

For anyone mapping how guest demand and floor systems share data, there are separate notes on hospitality web systems at Resonant’s hospitality page. Read it if you care about the web side; ignore it if you only came for inventory.

Practical next steps this week

1. Finish one full voice or typed walk so stations are real.
2. Import one clean POS window and compare variance at bottle level.
3. Write down where guest requests currently die (phone, DM, host stand).
4. Fix the worst handoff first — not the prettiest dashboard.