Stage analytics

A settings panel that shows how each project stage performed against its plan and, right beside it, how the plan itself has been edited — because either one alone misleads.

What it is

Settings → Project Stages → Analytics, over a 30-day to 2-year window. Four totals across the top (stages tracked, completed, plan changes, photos), then a per-stage table with runs, average planned, average actual, variance, ran-long versus ran-short, days lost and photo counts. Underneath: where the time went, a crew variance table, who documented the work, and the full history of edits to your stage setup.

Also called: project stage performance · how are my stages doing · planned vs actual by stage · schedule analytics

See it
Stage analytics
Apr
May
Jun
Jul
Gideon Alt — Hobby Shop
Framing
Sutter Kline — Riding Arena
Concrete
Ivy Brubaker — Equipment Storage
Trim
Delia Yoder — 40×64 Shop
Framing
Ivy Brubaker — Riding Arena
Concrete
Framing crewConcrete crewTrim crew
The Stage analytics tab: four tiles, then the stage performance table with a red '+2.4d' variance column and a 'Top cause: Weather · 6d' line under a stage name. StageAnalyticsTab.tsx. Sample data — no customer information appears here.
How it works
  1. 1Reads crew stage logs, delay reasons, stage photos, stage definitions and the stage-definition change log for the window.
  2. 2Variance is measured against the baseline the project was started with, never the current setting.
  3. 3Delay reasons are joined per stage to produce a top cause and a days-lost total.
  4. 4Every aggregate carries its denominator and the table shows completed-over-started as a fraction.
  5. 5Variance renders with an explicit sign and a colour: red over, green under.
Why we built it

The route header states the design: 'Two questions, deliberately kept apart, because conflating them is what makes schedule data useless' — how the plan changed, and how the work went. 'Why apart: a stage that suddenly "runs 2 days over" may have had its estimate cut by 2 days last month. One number cannot say which, so the response carries both and the UI shows the taxonomy edits ON the performance timeline.' The component repeats it: 'A stage "running two days over" reads identically whether the crew slipped or someone trimmed the estimate last month.'

The problem
  • Schedule variance could not be separated from schedule editing.
  • There was no record of what a stage was supposed to take when a project started.
  • Delay causes were never totalled per stage.
Sound familiar?
What you get
You can tell a crew slip from an estimate change without guessing.
Stage estimates can be tuned with real completed-run data behind them.
The cost of each cause of delay is a number, in days.
What's inside
Per-stage performance table
One row per stage: runs completed of started, average planned, average actual, average variance, how many ran long versus short, days lost, and photos taken.
Frozen plan baseline
Once a project starts, the duration you committed to is frozen, and every variance in the product is measured against that frozen number.
Where the time went
All delay causes across every stage, ranked by total days lost, with the occurrence count beside each.
Crew schedule table
Crews ranked by average variance against baseline, with stages completed of started, on-time rate and total days over.
Who documented the work
Photo counts per person, with how many of theirs were customer-facing, and an honest count of older photos that carry no photographer.
Changes to your stages
A dated log of every edit to your stage setup — renames, duration changes, checkpoints and stages added or removed — shown next to the performance it explains.

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 →