Productivity rate capture

Ask ten estimators what makes a bid land within 3% of as-built cost and nine of them say "productivity rates." Ask the same ten how they update their productivity rates and you'll get nine versions of: "I keep notes," "I check with the foreman," or "I use RSMeans and adjust by feel."

The right answer — the one that actually works — is a feedback loop. The loop has one simple shape:

Estimator prices an assembly at X hours per unit
        ↓
Field installs it. Foreman logs hours and units on the timecard.
        ↓
Actual hours per unit gets compared against the bid assumption.
        ↓
The variance updates a per-assembly observation pool.
        ↓
Next bid's default productivity for that assembly is a weighted average
of recent observations (with confidence interval).
        ↓
[loop]

This loop is straightforward to describe and almost never built. Because the timecard system and the estimating system are usually different products, the data doesn't flow. The estimator never sees the foreman's actuals at the granularity that would let them update an assumption. The foreman never knows what assumption they're working against.

That gap is the single-pipeline thesis in one workflow.

What "productivity" actually means

For a specialty trade, productivity is hours per unit installed for a given assembly under given conditions.

Hours — direct field labor. Not supervision, not shop fab, not delivery. The hands-on time.
Unit — the assembly's natural unit. SF of drywall, LF of MC cable, EA of fixtures, CY of concrete.
Given conditions — height of work, project type, GC, schedule density. The same assembly takes 25% longer in a four-story buildout than a single-story warehouse, and an estimator who doesn't adjust for that will systematically under-bid one and over-bid the other.

The feedback loop captures all three.

What the timecard already knows

A timecard line in STrOp records:

Worker (with classification)
Cost code (which maps back to one or more assemblies)
Hours by day
Project (with type, GC, region)
Optionally: phase, area, FWO

What it doesn't natively record: units installed. That's the missing piece. There are three places to capture it, in order of accuracy:

Per-FWO completion — foreman closes a field work order with "installed: 412 LF" before submitting timecards against it. This is the cleanest signal.
Daily report quantity entry — foreman logs "today: 800 SF drywall" in the daily report. Less precise (might not match exactly which workers did which units) but daily.
Pay-app % complete back-derivation — if PM marks the line item 60% complete at month-end, and the line is 12,000 SF, you can derive ~7,200 SF installed. Slowest and lowest-resolution.

STrOp has all three pathways. The bid → installed-unit signal gets stronger the more you use FWO-level closure.

How the loop updates the assembly library

For each assembly in the library, STrOp maintains:

The baseline rate — what the assembly was originally priced at (typically from RSMeans, historical experience, or estimator judgment when first added)
Observation pool — every project's actual hours-per-unit on that assembly, with project metadata (size, region, GC, year)
Filters / segmentation — productivity for "MC cable in stud wall, 1-story warehouse" is different from "MC cable in stud wall, 4-story buildout." The library segments observations by relevant project attributes.
Confidence interval — n observations get a tighter band than 3.

When an estimator pulls an assembly into a new bid:

The default rate shown is the weighted average of recent observations matching the project's profile.
The estimator sees the n and the confidence interval. n=2 is a guess; n=37 is data.
The estimator can override if they have project-specific reason — but they're overriding with knowledge of what the rate actually has been.

The compounding effect

This is the part subs underestimate. Each bid the loop adds observations. By bid #20, the library knows:

Your crew's actual productivity on every assembly that appears in 3+ jobs
Which GCs eat 10–15% productivity (because their RFI turnaround is slow)
Which project types your crew is fast in and which they're slow in
How your apprentice ratio affects net productivity
How weather correlates with productivity on outdoor work

That knowledge lives in the assembly library forever. Estimators who started yesterday inherit it. When the senior estimator retires, the institutional knowledge stays in the system.

The compounding only works if the data is connected. Foreman in QuickBooks Time, estimator in their own spreadsheet, no flow between — the loop is broken and every bid is a guess again.

Common failure modes

No FWO closure step. Timecards report hours but no units. The loop has no input. Fix: require a units field on FWO closure before the FWO can be marked complete.
Cost codes too coarse. "06 — Wood and Plastics" covers drywall, blocking, millwork. Productivity at that level averages out and tells you nothing. Use leaf-level cost codes (or assembly tags) that map to one assembly.
Foreman optimism / pessimism. "Today: 1,200 SF" when it was actually 900 SF biases the data. The fix is cross-check at pay-app % complete and reconcile.
Library updated without segmentation. Treating productivity on a one-story warehouse the same as a four-story buildout pollutes both numbers. Segment by project type at minimum.
Estimator overrides the data because "this one's different." Sometimes correct, often denial. The discipline is to write the reason for the override next to the override; if the override pattern is consistent, the segmentation needs another dimension.

How this becomes a competitive advantage

A sub with five years of clean productivity data has bid accuracy your competitors literally cannot replicate. They can copy your prices, your overhead structure, your suppliers — but they can't copy five years of your crew's actual productivity on assemblies similar to the one being bid. That data set is the single most defensible commercial asset a sub builds.

The loop has to run for years to compound. The single-pipeline data flow is what makes it possible to run.