Families 04 and 05
Two families sit on the same arithmetic. One counts what left the bottle and compares it against what was sold. The other takes the pooled gratuity and divides it by rules that were agreed before the shift started. Both exist because a venue lost an argument it could not settle with a spreadsheet.
Family 04
A bar that counts once a month finds out about a bad pour four weeks late. Five modules count where the liquor actually sits, then reconcile what was poured against what was sold.
Inventory Dashboard
"Live stock counts across every bar, storage room and floor." One screen answers the question a manager otherwise walks the building to answer.
Live Menu
"Edit menus once, push everywhere - printed, digital and POS." One edit, three surfaces, so the price on the table matches the price on the terminal.
Stock Room
"Counted, photographed and reconciled." The photograph is the part staff argue with least, because the count carries its own evidence.
In-Bar Inventory
"Each bar gets its own running count of bottles and kegs." A variance then points at a room rather than at the building.
Revenue Loss Calculator
"Reconcile pours vs sales, flag overpours and missing inventory." The flag is the whole point: it names the product and the bar while the night is still recent.
| Product | Poured | Sold | Variance | State |
|---|---|---|---|---|
| Vodka, 750 ml | 41 oz | 38 oz | +3 oz | Flagged, overpour |
| Tequila, 750 ml | 26 oz | 26 oz | 0 oz | Reconciled |
| House gin, 1 L | 54 oz | 54 oz | 0 oz | Reconciled |
| IPA keg, 50 L | 96 pt | 96 pt | 0 pt | Reconciled |
INTERFACE DIAGRAM, not a screenshot. One flagged row is the point: the module is quoted as "reconcile pours vs sales, flag overpours and missing inventory", and a flag on Saturday morning is worth more than a spreadsheet at month end. Every figure above is a structural placeholder. No venue's counts, no savings claimed.
What the count depends on
Poured against sold is a subtraction, and it fails the moment the two sides are describing different things. So the catalogue comes first: every item, price, modifier and tax code already on the terminals gets listed and compared against the menu the venue thinks it sells. Then each object gets exactly one owner, which is the decision that prevents two prices for one bottle.
Menus, prices and packages push out of Fennec. Closed tabs pull back in. That routing lives in POS and payments, and it is why the count can be trusted at all.
"Floor plans, reservations, packages and live ops - synced with Square."
Fennec product copy, fennecapp.com
Family 05
Schedules and permissions are table stakes. The part that stops arguments is the payout arithmetic, which we have now built twice: once inside Fennec, once as standalone software for a cruise operator.
Staff Management
"Schedules, clock-in, role permissions, and tip distribution." Four jobs in one module, and the last one is the one people check twice.
Tip-out engine, Palapa Tours Ottawa Shipped
Custom software, not a Fennec module. Palapa Tours runs floating tiki-bar cruises, and gratuity splits shifted cruise to cruise, which made them hard to reconcile fairly and caused disputes. We built software that calculates, splits and tracks staff gratuities automatically, so payouts stay consistent and the disputes stop. Read the Palapa Tours case study.
| Role | On shift | Share | Payout | State |
|---|---|---|---|---|
| Bartenders | 4 | 45% | 45% of pool | Locked |
| Servers | 3 | 30% | 30% of pool | Locked |
| Barback | 1 | 10% | 10% of pool | Locked |
| Host | 1 | 8% | 8% of pool | Locked |
| Galley | 1 | 7% | 7% of pool | Locked |
| Pool | 10 | 100% | Balanced to zero | Closed |
INTERFACE DIAGRAM, not a screenshot. The rules are set once, the arithmetic runs every shift, and every row is on the record afterwards. Role names and percentages here are structural placeholders: real splits are the operator's own. This is the mechanism behind the Palapa Tours build, described on the Palapa Tours case study.
These two families are shaped like a nightclub because that is the room they were built in. The parts underneath are not. A variance table is loss prevention for anything with stock on a shelf. A tip-out split is a payout engine for anything that pools money and divides it by rule.
Counted stock on one side, recorded sales on the other, and a flag where the two disagree. It needs a product list, a count and a sales feed. Any of those can come from a POS, a warehouse system or a spreadsheet we replace.
A pool, a rule set per role, and a record of every division. Palapa Tours Ottawa took this part on its own, for floating tiki-bar cruises, and the gratuity disputes stopped.
If a count or a split is currently settled by argument in your business, that is the thing to bring to the audit. We agree the baseline in writing before anything is built.
Start with the count
The free operations audit maps where time and money leak, then shows the arithmetic. We agree the bar in writing before anything is built, the clock starts at deployment rather than at signature, and if the system misses the agreed bar we keep working at no additional cost until it clears. Cancel any time. You own the code.
