Coverage grid, exception queue, one view.
The operations console pairs live crew-vs-target by site with a single exception queue. Drift, late starts, and device outages all land in the same lane — assigned, sorted, and one tap from escalation.
The coverage grid is the queue
Traditional attendance systems run two screens: a site list and a separate exceptions inbox. The two screens drift out of sync the minute either one gets busy; a dispatcher ends up doing reconciliation rather than dispatch. DutyMap’s operations console is built on the other choice — the coverage grid is the queue. A site with an open exception surfaces the exception inline, and the exception cannot be cleared without touching the site row that produced it. Fewer screens, fewer context switches, fewer of the small reconciliation mistakes that compound into a missed cover.
What each row tells you
Every coverage row carries the site code, a human-readable name, a status dot, the current-over-target headcount, and the shift window. The status dot is the only computed signal: green when the site is at or above target, amber when the site is short of target but not in violation of its safe-operating floor, and red when the site is below its floor. The floor is configurable per site; a site that runs at target eleven of twelve crew is not automatically alerting, because the site’s own safety analysis has named the floor and the status reflects it. That one piece of configurability is why dispatchers in the field stop ignoring the alert color after the first week.
How exceptions are sorted
The exception queue defaults to a sort that mixes severity and assignment: unassigned alerts first, then unassigned warnings, then assigned alerts, then the rest. The sort is configurable per dispatcher — a dispatcher who wants to sort strictly by severity, or to group by site, can flip the sort and DutyMap will remember the preference. The default is chosen because it catches the exceptions that would otherwise fall through: an alert with no name on it is the exception that is most likely to age badly, and surfacing it first is the simple protection against that failure mode.
Escalation is one tap, on purpose
Every exception has an escalate action that hands the row to the next role in the chain — from supervisor to dispatch, from dispatch to operations lead. Escalation transfers the row and carries its full history; the receiving role sees what was tried, what failed, and what the exception state is right now. The one-tap commitment is deliberate. An escalation that requires a three-field form is an escalation that the supervisor does not reach for when they need to; an escalation that is a single tap is the one that gets used and that saves the cover.
What is not in the console
The console deliberately does not run a ticker of every verified check-in, does not show gamified leaderboards, and does not push notifications into the supervisor’s device for every minor state change. Those devices were available to us in design and we decided against them. A ticker trains the operator to ignore it; a leaderboard rewards the sites that happened to have easy weeks; and notifications for minor state changes make the operator’s phone a distraction rather than a tool. The console’s calm is a feature of the product, not a deficit.