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.
The real prototype, interface in Spanish. The client's brand and data are replaced, and the numbers are for demonstration.
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).