Every stage move records which steps were offered at that instant. A step added this month is not punished for deals that moved last month, and a step deleted last month keeps its true rate for the period it was in use — shown greyed out and tagged 'removed'. A step with no offered moves yet reads 'new' rather than 0%.
Also called: checklist changed and broke my stats · step added later · fair completion rate
- 1steps_offered is written on each transition, resolved through any tenant override active at that moment.
- 2Rows written before the column existed predate SOP editing entirely, so they are back-computed against the built-in defaults — exactly what they offered.
- 3The UI renders removed steps in italics at reduced opacity with their historical done/offered intact.
Migration 179's header is explicit: 'This is what keeps SOP analytics honest across SOP edits: a step added next month must not have its completion rate diluted by moves from before it existed, and a deleted step must keep its true rate for the period it WAS in use. Per-step denominator = moves where the step was offered, not all moves in the range.' It closes with why history is safe: 'Rows from before this column (and before SOP editing existed, same day) offered exactly the built-in defaults, so history back-computes exactly.'
- Editing a process used to destroy the ability to measure it.
- New steps looked like compliance failures on their first day.
- Removed steps erased their own history.
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 →