Settings → Project Stages → Analytics. Per-stage performance (started, completed, average planned vs actual, average variance, ran long / short / on time), delay counts and days lost by cause, crew performance and on-time rate, photo documentation coverage, and a timeline of every taxonomy edit — renames, duration changes, checkpoints added or removed, and who did it.
Also called: stage performance · which stages run over · crew performance · how long does framing really take
How long framing actually takes you, measured on your own jobs
Started, completed, average planned against average actual, average variance, and how often a stage ran long, short or on time. After a season the number you put on a 40×60 shop stops being the estimator's memory and starts being your own history. Every average states how many jobs it is built from, because an average over two stages is not the same claim as one over forty.
Nobody can move the goalposts mid-build
What you said a stage would take is locked when the job starts. Where it sits on the calendar stays free to move, so a slipping job can be re-plotted without quietly making itself look on time. Before that lock existed, changing a stage from five days to seven mid-build rewrote the estimate that every planned-versus-actual number reads from.
Delays carry a cause and a day count, so they add up to an answer
Marking a stage delayed opens one form: cause — weather, crew no-show, material issue, equipment, permit delay, site access, scope change, other — days or hours lost, what happened, and photos. Nothing is written until you save, which is why the rows are complete enough to total. The version before this wrote a row the moment you tapped a cause chip, and most of them ended up recording that a delay happened for an unknown number of days for no stated reason.
“We got slower” and “somebody cut the estimate” look identical in one number
So both are kept: every rename, duration change, colour change, reorder and checkpoint added or removed is logged with the person who made it, and shown on the same timeline as the performance. A stage that suddenly runs two days over may simply have had two days taken off its plan last month, and you can see that in one place.
- 1Pulls crew stage logs, definition-change rows, crews, stage photos, definitions and live stage instances over a selectable window (30 days to 2 years)
- 2Variance reads against the frozen baseline; actuals are trigger-derived
- 3Every aggregate reports its own denominator (n)
- 4Taxonomy edits are shown ON the performance timeline
A stage that suddenly runs two days over might have had its estimate cut by two days last month, and one number cannot tell those apart — so builders were making decisions about crews using figures that were really recording their own edits. Performance and plan changes are shown on the same timeline. Sample sizes are shown too: an average over two stages is not the same claim as one over forty, and a leaderboard that hides the difference invites exactly the wrong call about who to keep.
- No measured stage durations to estimate from
- Performance changes indistinguishable from estimate changes
- Averages presented without their sample size
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 →