A Blocked button on the crew portal opens a fixed vocabulary of reasons — no materials, weather, can't get on site, equipment down, permit/inspection, crew short, scope question, something else. Reporting notifies through the org's routing matrix, attaches a delay reason to the stage log, and tells the reporter whether anyone was actually reached.
Also called: crew can't work · waiting on materials · report a delay from site · crew stuck
Four men waiting on a delivery is money burning right now
One button on the crew screen, then eight reason chips: no materials, weather, can't get on site, equipment down, permit or inspection, crew short, scope question, something else. Tapping one notifies every party your org has designated, in that minute. Every hour between the crew stopping and you hearing about it is an hour you have already paid for.
Chips rather than a text box, so the reasons can be counted
Typing on a site in gloves and glare is close to impossible, and a typed reason cannot be counted, filtered or learned from later. A fixed vocabulary makes the same delay look the same every time it occurs, which is what turns “we always seem to be waiting on materials” into a number of days lost.
It marks the stage delayed. It never moves your dates.
Reporting blocked flags the stage delayed with the reason attached and starts the clock on it, so the cost accrues visibly instead of being reconstructed on Friday. What it does not do is shift the plan. A framer tapping a chip at 7am must not quietly re-promise the customer a completion date — rescheduling stays an owner or PM decision, made from the record this creates.
The chips add up into where your days actually go
Overrun days are grouped by their recorded reason and ranked by total days lost, with the crews each reason affected and how often it happened. Stages that ran over with no reason recorded appear as exactly that rather than being dropped. A tap in the field becomes office analysis with nobody re-entering anything.
The man who reported it is told whether anyone was reached
The screen confirms the report and the response carries how many people were actually notified. On a site where the alternative is ringing the office and getting voicemail, knowing the message landed is the difference between a crew using this next month and abandoning it after the first time.
- 1The chips mirror BLOCK_REASONS on the server, which validates the code and refuses anything unknown.
- 2Project and stage come from the open shift through the shared currentWork resolver.
- 3The stage's crew_stage_logs row is set to 'delayed'; if none exists one is opened using planned dates from project_stages.
- 4A stage_delay_reasons row records the code and description with days_impact 0.
- 5notifyEvent fires 'crew_blocked' (severity critical) through the org's own routing, and the response reports how many people were reached.
Four men standing on a site waiting for a delivery cost money by the hour, and every hour before the office hears about it is spent. One tap reports blocked, and immediately everyone who needs to know is notified, the stage is flagged delayed with the reason attached, and the clock on the delay starts. What it never does is move the promised dates — a framer tapping a chip at 7am must not quietly re-promise the customer a completion date. The reason is chosen from a fixed list rather than typed, because typing on a site in gloves and glare is close to impossible and a free-text reason cannot be counted, filtered or learned from later.
- Hours of paid standing time before the office hears about a blocker.
- Delay reasons that were never captured in a countable form.
- Field reports silently re-promising customer dates.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →