Features · SOW, BOM & estimating
The design writes the scope, the BOM, and the estimate.
The same building model that computed your coverage carries its own paper trail: a Statement of Work classified scope by scope, a bill of materials with provenance on every line, and estimates that reproduce to the digit — nothing re-keyed between tools.
One survey, three documents
- 01 Scope SOW rows — in scope, by others, excluded
- 02 Materials BOM lines with typed provenance
- 03 Labor hours by phase and crew role
- 04 Cost sections, contingency, benchmarks
- 05 Budget a ROM band for early conversations
Derived from the design — the numbers agree because they share a source.
Statements of work
Scope that reads the survey
The Statement of Work is computed from the survey — a pure function of what you designed. Device counts, cable footage, mounting heights, per-closet detail: derived, not retyped.
- Scope rows build from the design across fiber backbone, MDF and IDF, wireless, cameras, ethernet drops, access control, electrical, and racking.
- Every section classifies three ways — in scope, by others, excluded — down to individual bullets, and excluded scope never leaks into the order form.
- Camera mounting heights derive from placed devices and zone geometry; cable footage totals come from the drawn paths, buffered for slack.
- Reusable scope presets — up to 50 saved per organization — carry category states, bullet exclusions, and customer-facing by-others notes.
- A gap analysis scans the survey for missing fields that affect SOW accuracy, asks the questions, and folds the answers back into the scope.
One scope row
- State
- in scope · by others · excluded
- Bullets
- excludable one by one
- By others
- a customer-facing note, not silence
- Presets
- org-saved, reapplied in one click
- Gaps
- asked before they become surprises
Excluded scope never reaches the order form.
SOW provenance
A narrative that shows its receipts
On the project side, SOC drafts the SOW narrative from deterministic evidence — survey metrics, sealed BOM revision lines, per-closet rollups — and the document records exactly what it was built from. SOC writes the sentences; the engines own the numbers.
- Every generated SOW pins its sources: the survey it read, a hash of the exact metrics block, and the BOM revision it quoted.
- Evidence blocks are computed before a word is drafted — survey metrics, cabling tables, closet rollups, project metadata — and kept with the document verbatim.
- The same survey snapshot yields identical derived lines across the SOW and the order form — one line-key scheme unifies them.
- Versioned on the project: generate, compare, and file the executed copy — the SOW hub keeps the record together.
Pinned to the document
- Survey
- source id and metrics hash
- BOM
- the exact revision quoted
- Evidence
- computed blocks, kept verbatim
- Versions
- drafts and executed copies, together
SOC writes sentences around engine numbers — never the other way around.
Bill of materials
Every line knows where it came from
The BOM is one canonical set of lines with a single write path. Whether a line came from the survey, a CSV row, a PDF page, or a hand entry — it says so, on the line.
- Derived from the design: devices group by product and location, cable runs aggregate per type and round up to the next hundred feet, and closet racks, UPS units, PDUs, and patch panels roll up across closets.
- Unmatched devices are never silently dropped — they land as visible needs-SKU lines you can resolve.
- Eight provenance types live on the line itself — survey generator, CSV, PDF, XLSX, DOCX, smart order import, manual, add-on — down to the row number or page.
- Reconciliation is deterministic first: exact SKU matches and near-exact merges happen in a transaction; the ambiguous band gets a suggested match with a visible badge and a review flag. Nothing merges silently.
- Revisions seal with diffs — compare what changed and when, and import from CSV, PDF, XLSX, or DOCX with the same reconciliation applied.
One line, accounted for
- Source
- one of eight typed provenances
- Match
- exact first, then high-confidence merge
- Review
- badges and flags, not silence
- Revisions
- sealed, diffable history
- Portal
- readable by your customer
One kernel is the only write path — survey, imports, and hand edits all reconcile.
Labor & cost estimating
Estimates that reproduce to the digit
The cost engine is deterministic — same inputs, same configuration, same hash, same numbers. Labor productivity references BICSI TDMM 15th Edition and RS Means data, and the rates are yours to configure.
- Five labor phases — design and planning, procurement and staging, installation, commissioning and testing, documentation and closeout — across eight crew roles with burden-loaded rates.
- Productivity references BICSI TDMM 15th Edition and RS Means — cables per day, devices per day, fiber splices per day — applied to what the design actually contains.
- Complexity multiplies honestly: building type, floor count, ceiling height, access difficulty, and region scale the labor — and contingency grows with complexity and data gaps instead of sitting at a flat percent.
- Rate cards and productivity profiles live at your organization — admin-editable and audit-trailed — with project overrides above org defaults and reference baselines beneath.
- Every estimate carries benchmarks — cost per square foot, per drop, per device, hardware-to-labor ratio — plus a reproducibility hash and versioned side-by-side comparisons.
One estimate, itemized
- 01 Hardware from the BOM lines
- 02 Cabling & pathway J-hooks, ties, fire stops included
- 03 Labor five phases, eight roles
- 04 Contingency risk-scaled, not flat
- 05 Benchmarks $ per sqft, per drop, per device
Same inputs, same hash, same numbers — estimation, and labeled as such.
Rough order of magnitude
A budget band before the design exists
Sometimes the conversation starts before the survey. The ROM generator takes square footage and scope and produces a portfolio budget band in seconds — explicitly a planning number, and it says so on the document.
- Per-facility inputs: square footage plus scope — network, wireless, cameras, access control — detected from the survey when one exists.
- Three density tiers set the band: the low end sums the simple tier, the high end the dense tier, with a recommended middle.
- Category distribution reconciles to the total — network and fiber, wireless, cameras, access control always sum exactly.
- Multi-facility portfolios roll up into one branded document with a deterministic content hash.
- Every ROM prints its own disclaimer: budgetary planning, not a formal quote.
One ROM, banded
- Inputs
- square footage and scope
- Band
- low, recommended, high
- Categories
- reconcile to the total, exactly
- Provenance
- deterministic content hash
- Honesty
- "not a formal quote," on the document
A defensible band in seconds — not a promise dressed as one.
The engines own every figure.
Scope rows, BOM lines, labor hours, and budget bands come from deterministic engines — hashed, versioned, reproducible. SOC researches, suggests, and explains around them; it cannot author a number. And where a suggestion is a suggestion, the line wears a badge that says so.
The trust architecture, on the platform pageDownstream
Where the scope and the numbers land
The same model that wrote the scope fills the documents that follow it — nothing is re-keyed between tools.
Into the order form
SOW scope and the survey BOM flow into pre-signature order forms — with excluded scope filtered out before it ever reaches paper.
Into the proposal
Phase-level labor and cost feed the design proposal's rollout pages — hours by cable pull, rack build, device mount, and test.
Into execution
Each SOW scope bullet can seed a work item with its trade attached — low voltage, networking, security — so delivery tracking starts from the scope you sold.
Into change orders
Change orders bind to BOM revisions and carry line-level deltas through customer approval — the record of what changed stays coherent.
Frequently asked questions
Is the Statement of Work written by hand or generated?
The scope itself is computed: categories, classifications, device counts, cable footage, and mounting heights derive from the survey as a pure function. On the project side, SOC can draft the narrative around that evidence — and the document pins the survey hash and BOM revision it was built from. The engines own the numbers; SOC writes sentences around them.
What happens to devices the BOM cannot match?
They stay visible. Unmatched devices become needs-SKU lines instead of being silently dropped — you see them, assign the product, and the line keeps its provenance back to the survey device it came from.
How does reconciliation avoid duplicate lines?
Deterministically first. Normalized SKU matches merge in a transaction; near-exact description matches merge at a high confidence floor; the ambiguous middle band gets a suggested match with a visible resolution badge and a review flag; anything below lands as a new line marked for review. Nothing merges silently.
Whose labor rates does the estimate use?
Productivity references BICSI TDMM 15th Edition and RS Means data — cables per day, devices per day, splices per day — across five project phases and eight crew roles with burden-loaded rates. Rate cards and productivity profiles are managed at your organization, admin-editable and audit-trailed, with project overrides above org defaults.
Is the estimate a quote?
No, and it does not pretend to be. Estimates carry confidence tags, stated assumptions, and a risk-scaled contingency; the ROM goes further and prints its own disclaimer — budgetary planning, not a formal quote — on the document itself.
Can it compile the design into dispatchable work automatically?
Work items can seed from SOW scope bullets today, with trades attached. A deeper design-derived scope compiler is direction, not delivered — and we do not market what has not shipped.
Put your scope on the same model as your coverage
Bring a floor plan — the SOW, the BOM, and the estimate come from the design itself. Talk to us about what your team sells.