Multi-Venue Hospitality Operations: Rostering, Labour Cost & Sales

The Client & Their Context

The client runs a group of bars and pubs across multiple sites. Managers are responsible for both sides of the counter — the roster and wage bill on one side, the till and the day's takings on the other — and until now those two lived in separate systems that only met in a monthly report.

The Problem

Labour cost leaks quietly. Rostered hours and hours actually worked drift apart, and if the wage bill and the till data are in different places, nobody notices until the month closes and the margin has already gone. Till reports also arrive as emailed attachments overnight, which invites a manual export step that gets skipped, and a corrected report that gets imported twice and doubles the day's takings.

What We Built

• Rostering as a drag-and-drop weekly grid with copy-last-week-forward, publishing to release the roster to staff, and approved time off shown inline so nobody gets double-booked.
• Shift cover in several forms: an offer to a named person, an open-shifts board staff can claim from, and drop requests with manager decision and replacement assignment, with every state change notifying whoever it affects.
• Clock-in, timesheets and close-of-business cash reconciliation, putting expected against actual for cash, card and account takings so variance surfaces at the point of entry rather than at month end.
• Automated data capture: a background service polls a mailbox on a schedule, pulls overnight till and clock reports straight from email, and parses the attachments into structured sales and attendance records before the venue opens.
• Re-imports that supersede the previous version rather than duplicating it, so a corrected report cannot double the day's takings, plus on-demand runs with live progress, durable run history, and failures reported with a reason rather than a silent no-op.
• Labour percentage and sales per labour hour answerable on the day rather than a month later, with rostered hours sitting next to hours actually worked.
• Four role tiers where the interface itself changes, not just the permissions: group-wide admin with the import console, stakeholders seeing cross-venue trading and labour performance without day-to-day operations, bar managers locked to their own venue, and staff in a separate app.
• Three delivery targets from one set of services: a .NET API, a React web client tuned for the tablet on the back-office desk, and a React Native app on Expo shipping to Android and iOS from a single codebase, with tokens in device secure storage and the same refresh and idle rules as web.

Outcome & Scale

• 30 screens, 136 documented endpoints, 35 data entities, 41 EF Core migrations, 4 role tiers and 3 delivery targets built from one set of services.
• 164 test suites across API and UI with enforced coverage floors, Playwright browser journeys, load testing on high-traffic endpoints, and a CI build and test gate on every pull request.