Multi-site staff management
Replacing thirteen years of spreadsheets and an offline fingerprint clock with a platform for clock-in, shift planning and alerts across three sites and ~25 rotating staff.
PRD rewritten from scratch for publication. The work is real; the client isn't named.
Context
A franchisee in food retail runs three physical sites plus a wholesale channel, with around 25 employees on rotating morning, afternoon and night shifts, a 44-hour week, and rest days that rotate — full and half.
All the planning lived in a spreadsheet with thirteen years of history. Clock-in ran on a fingerprint device at each site, offline: the data existed, but nobody could look at it until someone walked over and exported it.
Two things about the business shape the design:
- Sharp seasonality. Headcount nearly doubles in December and drops in winter.
- Weather moves demand. A heat spike or a rainy day changes how many people you need behind the counter, and today that call is made from memory.
The problem
The operation had no live data. Without connected clock-in there's no way to know someone came in late until the month piles up, and without a consolidated view across sites the imbalances stay invisible: one site overstaffed on a Tuesday while another runs at the edge the same day.
The ask was a custom web platform to replace both the spreadsheet and the offline clock, with one architectural decision made on day one: design it multi-tenant even while a single account operates it, because the client wanted to turn the tool into a product for other franchisees later.
Phase 1 scope
Clock-in. A responsive web app built for the operational phone each site already has. Entry and exit logged with a photo, validation that the employee is active and assigned to that site that day, optional geolocation, and explicit handling of the failure cases: unrecognised employee, poor photo, no connectivity.
Shift planning. A weekly grid of employees by hour and site, with drag-and-drop assignment. Multiple shifts per day, full and half rest days, different weekly hours per person, non-operational tasks, and real-time validation against the hours cap. Reusable week-over-week templates.
Consolidated multi-site view. The use case that started the project: all three sites on one screen, with the imbalance visible as it happens.
Alert engine. Configurable rules over clock-in and planning data: late arrival, early exit, absence, unplanned overtime, and a mismatch between the published plan and the weather forecast.
Dashboards. Today's operation, the consolidated weekly plan, and a filterable, exportable clock-in history.
Weather API integration. A seven-day forecast, detection of temperature spikes and rainy days, feeding both the dashboard and the alert engine.
Prototype screens
- Daily dashboard — clocked in versus expected per site, late arrivals, absences, active alerts and a weather widget.
- Weekly planner — drag-and-drop assignment grid with cap validation.
- Consolidated view — the three sites compared on a single screen.
- Coverage heatmap — staffing density by time band and site.
- Employees — records, contracted hours, assigned sites.
- Alert inbox — history with state: new, seen, handled, dismissed.
- Clock-in history — filterable by site, employee and date range, with export.
- Mobile clock-in app — the screen the employee uses on the site phone.
The decision I deliberately left open
The client wanted facial recognition. It's the most expensive option and the one carrying the most technical risk: recurring service cost, real-world lighting at a counter, and the uncertain camera quality of the phones already sitting in each store.
Rather than settle it inside the prototype, I left it open with five evaluated alternatives — facial recognition, a personal code, a hybrid of code plus an unmatched photo, integrating the existing fingerprint clock, or replacing it — each with its relative cost. The hybrid shows up as the MVP inside the MVP: it deters fraud without putting machine learning in the first release.
Expensive decisions are worth putting on the table while they're still cheap to change.
What it excludes
- Integration with the franchise ERP: it exposes no API and only exports spreadsheets. Phase 2, via manual upload.
- Sales data cross-referencing and productivity KPIs — Phase 2.
- Global tenant administration and self-service onboarding — Phase 3.
- Native apps: everything is responsive web.
- WhatsApp as an alert channel in Phase 1 (email and web push are in).