Restaurant group, St Julian's

The shape of the business

Four full-service venues across St Julian’s and Paceville. A shared central kitchen at one of the sites; a shared menu (with venue-specific specials); a single owner and two managers. Roughly 80 covers per venue at peak, full table service, KDS in each kitchen, Wolt + Bolt integration for the takeaway side.

This is the archetype where the old POS — a per-venue legacy system with no central reporting — was costing serious operator time. Reconciling four Z-reports a night, four times a week, into a single weekly P&L was eating the better part of two days a month between the owner and the bookkeeper.

What the workflow needed

The multi-site constraint pulls in features that a single-venue café never touches:

1. One menu, four kitchens. A price change to the burger had to propagate to every venue without four manual edits. Specials per venue had to be additive, not destructive.
2. One inventory, four venues. Stock at the central kitchen is the source-of-truth; transfers to each venue have to be recorded so the COGS per venue is correct.
3. One backoffice, four sets of Z-readings. Every venue closes its own day, but the owner needs the aggregated daily total without four separate logins.
4. RBAC that scales. A manager at venue 2 should see venue 2’s data, not venue 3’s. Cashiers see only their own venue. The owner sees everything.
5. Aggregator orders routed correctly. Wolt sends one webhook; the order has to land at the right venue based on the address.

What the VIND-shape workflow looks like

• One tenant, four venues in the VIND data model. Menu items belong to the tenant; venue-specific pricing and availability are overlays.
• Central kitchen as a venue with stock-source flag. Daily transfers to each retail venue are first-class movements (not “edit the count”); inventory journals reconcile by month-end with no manual SQL.
• Backoffice dashboard with venue filter and aggregated daily-totals view. Z-readings list across all venues, with the Sunday-to-Saturday weekly P&L generated automatically.
• RBAC matrix enforced at both the gateway and each service. A manager’s JWT carries their venue assignment; queries are tenant- and venue-scoped at the data-access layer.
• aggregator-bridge venue routing based on the order’s delivery address against each venue’s polygon. The owner draws the polygons in the backoffice once; the routing follows.

The reconciliation that made the case

Before VIND-style consolidation, the bookkeeper would spend the first Tuesday of every month rebuilding the previous month’s P&L from four sets of Z-printouts and a stack of supplier invoices. Eight to ten hours, every month, of work that produced a number nobody trusted to two decimal places.

With the workflow above, the same P&L is a one-click export. The reconciliation went from 8–10 hours to 30 minutes, and the bookkeeper’s actual job — interpretation, anomaly-spotting, talking to the accountant — got the time back.

This is the workflow that motivates VIND’s multi-site backoffice surface and the reason RBAC is enforced twice in the stack — at the gateway and again at each service.

Honest caveats

This is a composite profile, drawn from conversations with multi-venue restaurant operators during 2026 H1. The “central kitchen with retail venues” model is common in the St Julian’s / Sliema corridor; the specific group structure described here represents the archetype rather than a single operator.

The four-venue group profile is also the most complex VIND workflow we ship out of the box. Larger groups are an Enterprise conversation — come talk to us and we’ll quote properly.