Coverage view

A heatmap that answers “how many people are working in the kitchen at 11 PM?” — or in any department, at any hour, on any day. Lives behind the Coverage tab on the Roster page.

What it does

The Week tab (the planning grid) is laid out per staff member: one row per person, one column per day. That’s perfect for editing shifts but bad at answering coverage questions. To know “how many in the kitchen tonight?”, you’d have to scan every row, count who’s in for that hour, and tag the kitchen ones — for every hour, for every department. Tedious, error-prone.

The Coverage tab is laid out per department: one row per department, columns for time. At a glance, you see how thick each area is staffed. Cells are colour-graded — pale at low headcount, saturated at peak — so under-staffing or over-staffing jumps off the screen.

Two viewing modes share the tab, switched by a toggle at the top:

Day view — a single day, broken down hour by hour (24 columns from 6 AM to 6 AM next day, covering the typical service window plus late closing).
Week view — a whole week, broken down day by day. Cells show person-hours covered (the total hours all staff together worked or are scheduled in that department on that day). Click a cell to drill into that day.

There’s also a Show actuals toggle that overlays real clock-in / clock-out data on top of the planned shifts. With it on, every cell shows two numbers: planned and actual.

How to use it

Open Settings → Roster and tap the Coverage tab.

Day view

The default. Pick a date with the date picker (or use ← / → / Today to navigate). The table shows:

One row per active department, colour-coded chip on the left.
24 columns, labelled with hours starting at 6:00 (the “service day” pivot). The columns wrap across midnight: 6, 7, …, 23, 0, 1, …, 5.
A TOTAL row at the bottom showing how many unique people are in the venue at that hour. A staff member tagged in two departments for the same shift counts once in TOTAL but once in each department.
Numbers in the cells — the headcount. Empty cells show a faint dot (zero).
Cell colour intensity matches the department’s colour: pale at low headcount, saturated at peak.

Click a cell to see who is in that department at that hour — a small dialog opens with a list of names.

Week view

Tap the Week sub-toggle. The view changes to a 7-day heatmap:

One row per active department.
Seven columns, one per day of the ISO week (Monday to Sunday).
Cells show person-hours — for example, “16.0h” means the sum of every staff member’s shift duration in that department on that day adds up to 16 hours.
Click a cell to switch to Day view for that date.

The Week view is useful for spotting lopsided weeks: if Monday’s kitchen is at 8 hours and Saturday’s at 26, you’ve found a coverage skew. Or for comparing one week to another after editing the schedule.

Showing actual time-clock data

Tick Show actuals (time-clock punches) at the top right.

In Day view, every cell now shows two numbers, e.g. “3 / 2” — three planned, two actually clocked in. The actual number turns red when it’s lower than the planned number, so under-coverage during the live service is unmissable.

A new row appears at the bottom — Unscheduled — which shows people who clocked in at that hour but had no shift planned for then. (For example: a runner picked up an unplanned cover.)

In Week view, cells become “16.0h / 14.5h” — sixteen hours planned, fourteen and a half actually worked. Again, red on shortfall.

The actuals are computed from the same time-clock punches that the Reconciliation tab uses, with the same matching logic — a punch is attributed to a department only if it pairs with a planned shift in that department.

When the toggle is off, the system doesn’t fetch the time-clock data at all (no extra cost or network), so leave it off when you’re just planning.

What happens behind the scenes

The Coverage view is a different layout of exactly the same shift data the Week tab uses. Nothing extra is computed or stored — the page reads the same shifts, then groups them per (department × hour) instead of per (staff × day).

Headcount math:

For each hour cell, the system finds every shift that overlaps that hour. (A shift from 18:00 to 23:00 overlaps the 18, 19, 20, 21, 22 cells.)
Each overlapping shift contributes 1 to the count of every department it’s tagged with. (A shift tagged with both Kitchen and Bar adds 1 to the kitchen row’s cell and 1 to the bar row’s cell.)
The TOTAL row counts unique staff IDs — the same shift adds 1 to the total regardless of how many departments it’s tagged with.

For person-hours (Week view), the math is the duration of each shift’s overlap with each day, summed per department.

When the Show actuals toggle is on, the same-shape math runs against the time-clock punches: for each hour, every clock-in/clock-out pair that overlaps the hour contributes. The pair-with-planned-shift logic comes from the comparison report — see Comparing plan with reality for the matching rules and the ±2 hour tolerance.

The whole calculation runs in the browser, on top of the same data already loaded for the planning grid. No database hits beyond the one read of shifts (and time-clock punches if actuals are on).

Examples

🍕 Friday kitchen check The manager opens Day view, picks Friday. Kitchen row reads 0 0 0 0 0 0 0 1 2 3 3 3 3 3 2 1 0 0 3 3 3 3 2 1 from 6 AM through 5 AM. Lunch peaks at 3 (12 PM to 14 PM), there’s a gap 14:00–17:00 (between services), dinner peaks at 3 again (18:00 to 22:00). All looks balanced. The TOTAL row shows the same plus the dining-room and bar staff for those hours.

📈 Spotting an under-staffed Saturday lunch On Week view, the manager sees Sat lunch at 6 person-hours in the kitchen and Sat dinner at 24. That’s right for dinner but suspicious for lunch. Click the Saturday cell → Day view of Saturday. The kitchen row at 12:00 reads “1”. One chef during the busiest weekday lunch is too thin. Time to add a shift.

⚠️ Reality check during service — under-coverage At 8 PM on Friday, the manager toggles Show actuals. The kitchen row at the 19 column shows “3 / 2” in red. Three were planned, two are clocked in. One chef is missing. The manager taps the cell — the dialog shows three names, with one tagged “planned” only (didn’t clock in) and two tagged “planned · clocked-in”.

⚠️ Edge case — runner covering both areas Sara’s shift is tagged with both Dining Room and Bar from 19:00 to 23:00. On the Coverage Day view, the 19:00 cell of Dining Room shows “1” and the 19:00 cell of Bar also shows “1”. The TOTAL row shows “1” — Sara isn’t double-counted in the venue total, only in the department breakdown.

⚠️ Edge case — overnight closing The bar closes at 2 AM. On Saturday’s Day view, the Bar row shows people present from 19:00 onwards, and continues at 0:00, 1:00, 2:00 — those columns are Sunday morning in real time, but they sit on Saturday’s “service day” (which the system pivots at 6 AM). This matches kitchen mental model: Saturday-night closing is part of Saturday, even though the wall clock has rolled over.

Weekly schedule — the same shifts, viewed per staff. Use that to edit the roster; this view is read-only.
Comparing plan with reality — same actuals data, but with status badges (late / early / no-show) per individual shift.
Departments — the row order and colours come from there.