Running a shift with DutyMap.

Before the shift — build the board

A clean shift begins the day before. DutyMap’s scheduling view lets a supervisor draft the next day’s board against each site’s target headcount — the number of crew the site needs to run safely and on schedule. The target is not a wish; it is the number under which the site is considered thin and under which the coverage lane starts flagging to dispatch. Drafting early means the alerts at 05:00 are about real misses, not about holes the schedule never filled in the first place.

Each crew assignment is tied to a shift code — start time, end time, break window, and site geofence. Once a crew member is assigned, the code is their identity for the day. Buddy-punching is not a posture problem; it is a protocol problem, and tying every verification to the shift code plus a device-bound identity is how DutyMap closes it.

At the start — verified reporting for duty

When a crew member arrives, their device prompts a one-tap report for duty action. The tap is accepted only if the device is inside the site geofence, the shift window has opened, and the device is bound to the crew record. Any failure of those three conditions routes the attempt into the exception queue as unverified arrival, where the supervisor can resolve it by sight. The supervisor never has to trust a text message saying I’m here; they have a row that says the person is here or not.

During the shift — the coverage lane

Once the shift is running, the coverage lane becomes the supervisor’s primary view. It lists every site in the region with target vs. current headcount, the shift code, and a status chip — ok, warn, or alert. When a crew member drifts off-site for longer than the break window allows, the site chip lifts from ok to warn and the exception queue adds a row with the drift duration. There is no separate dashboard for these signals; the map is the queue.

The coverage lane is intentionally plain. No gamified scoreboards, no leaderboard of the best-attended sites, no green-bar streak badges. Those devices encourage supervisors to game the number rather than run the shift. DutyMap lets the supervisor see the truth of the shift and act on it; it does not reward the sites that happened to have easy weeks.

Mid-shift — drift, break discipline, and escalation

Most shift failures are not dramatic walk-offs; they are drift — a crew member slipping off-site for ten minutes here, fifteen there, and a third of a shift disappearing across a week. DutyMap surfaces drift as a rolling tally per crew member, per week, viewable by the supervisor only. The tally is a conversation starter, not an automated penalty. A supervisor who sees drift accumulating on a specific crew member opens the conversation before it turns into a miss.

When an exception requires action beyond the supervisor’s authority, escalation is one tap. The exception moves from the site lane to the dispatch queue with its history attached; the dispatcher sees the full context, not a one-line forwarded message. That constraint is the reason the dispatch queue stays actionable on busy days.

Handover — a two-minute ritual

Shift handover is the moment most small issues become big ones. DutyMap’s handover view is a two-minute ritual: the outgoing supervisor confirms crew present, acknowledges any open exceptions, writes a short note for the incoming supervisor, and hands the site lane to the next shift. The incoming supervisor sees the same list of exceptions, the note, and the same coverage chip. No exceptions are closed at handover without an explicit resolution; the status handed over is its own explicit state, different from resolved.

End of shift — closing the day

The last task of the shift is to close exceptions. Every exception that entered the queue during the shift must end in one of four states: resolved, escalated, handed over, or noted. A shift that ends with open exceptions is flagged to the operations lead in the next morning’s roll-up. That discipline is the difference between an attendance system and a shift-control system, and it is the single feature we most often hear back on after a first month in the field.

Common edge cases

Crew working across two sites in a single shift; contractors whose site access is temporary; emergency call-ups outside the posted shift — these are handled with flexible shift codesthat the supervisor issues on the spot, all of them still tied to a geofence and a device identity. Flexibility lives in the supervisor’s hands, but it does not live outside the verification model; the supervisor cannot issue a code that skips the geofence or the device bind. Those rails are why the shift data is still trustworthy six months into a deployment.