DutyMap is not one tool that three roles argue over. Dispatch, supervisors, and operations leads each open the console into the lane they need — and every lane sees the same verified truth.
Open the console and read all sites at once — target vs current, open gaps, and who is still not verified. The map is the queue, not a separate view.
Supervisors open the site lane on mobile — crew, shift, gaps. No separate supervisor spreadsheet. Dispatch and site always look at the same row.
Roll-up views for which sites drift, which shifts are hardest to fill, and where the crew-to-target ratio is quietly falling.
DutyMap deliberately opens into a different view depending on the role that signed in. A dispatcher lands on the coverage grid with every site in their region visible at once. A site supervisor lands on their site’s lane — the same crew list their dispatcher can see, the same exception queue, but filtered to the supervisor’s responsibility. An operations lead lands on the rollup view where the pattern across sites and weeks is the point, not the live-minute state. The three lanes share the same underlying records, which is how dispatch and site always look at the same row works in practice. A shared dashboard with a different default tab would be a slower tool for every role; three landing lanes built on the same data is the right compromise.
A dispatcher is not running every site; they are triaging the exceptions the sites have surfaced and taking the calls that cross site boundaries. The coverage grid lets them scan twelve sites in the time it takes to read a single status email. The exception queue lets them act on the three exceptions that actually need intervention rather than wading through the twenty that the supervisors have already handled. The role’s shift pattern, over a DutyMap deployment, usually shifts from tracking to triaging; the triage work is more useful and, generally, more welcome.
A site supervisor spends most of their day in the site’s own lane — crew list, shift times, break windows, exceptions — with the coverage grid one swipe away when they need the context of neighboring sites. The supervisor has the authority to resolve most exceptions locally without escalation, which is the other half of the dispatcher’s offload: the supervisor can close the routine exceptions, leaving the dispatcher to handle the ones that require cross-site coordination or a decision above the supervisor’s authority.
The operations lead is looking at weeks, not minutes. Their rollup view carries the coverage rate per site per shift, the drift tallies by crew member, the shift-fill success rate, and a miss report that rolls up the exceptions closed over the period. The rollup is the artifact that tells the lead which sites are quietly trending toward a cover issue, which shifts are hardest to fill, and which crew members need a conversation. It is deliberately not a live-minute view; an operations lead who spends their day in the live-minute view is doing the supervisor’s or dispatcher’s job, not their own.
The most useful practical consequence of the lane-per-role design is that handoffs are almost invisible. An exception that starts in a supervisor’s lane and is escalated to dispatch arrives in the dispatcher’s queue with its full history — who touched it, what was tried, when the escalation fired. An operations lead running a weekly review pulls the same history into the rollup without a supervisor having to compile a report. DutyMap’s lane-per-role design is a tax on the initial design; it is a perpetual dividend on every handoff that follows.