The buy-and-build playbook in industrial services is well understood. Buy a platform company with a strong management team. Add regional HVAC, mechanical, plumbing, electrical, fire protection and specialty contractors around it. Professionalize, integrate, and sell one larger, better-run business. The deal model shows where the value comes from: purchasing scale, a shared back office, cross-selling, best-practice estimating, and a combined business that a buyer values as a platform rather than a collection.
The back office usually integrates. Finance moves to one ledger, payroll and benefits consolidate, insurance and safety programs are standardized. What rarely integrates is the work itself: how each company reads a drawing set, prices a job, learns from past jobs and hands over what it built. A few years into the hold, many platforms are still several companies sharing an owner.
That gap has a location. It is the layer where drawings, estimates and job records live, and most value creation plans never name it.
Where buy-and-build stalls
A typical value creation plan has lines for pricing, procurement, the add-on pipeline, leadership hires, systems and reporting. Each assumes the companies can be made to work alike. But every add-on arrives with four things built for a company of one.
- Estimating spreadsheets. A workbook built up over years by the founder or chief estimator, with its own assemblies, labor factors, markups and hidden tabs. It works because the person who built it knows where every number came from.
- A drawing archive. Bid sets, construction sets, submittals, as-builts and closeout documents for every job, spread across a file server, a cloud drive, plan-room download folders and sometimes a principal's laptop. Searchable by job number, if you know the job number.
- Job-costing habits. Cost codes that reflect how that company thinks about work. One codes duct labor by floor, another by system. One carries test and balance in its equipment line, another subs it out and carries it separately. Margins look comparable in the ledger and are not comparable in the work.
- Tribal knowledge. Two or three senior people who know which general contractors pay on time, which engineers' drawings run light, what to carry for hangers on a steel-deck job, and which scope gaps turn into change orders. That knowledge is the company's real estimating system.
Energy and industrial services platforms see the same pattern. Companies that do maintenance, turnaround, inspection and small capital projects inside refineries, midstream assets and power plants price and execute from client P&IDs, isometrics, line lists and inspection records. Each add-on reads them its own way, prices turnaround scope off its own templates, and depends on a few people who know the client's units.
Put five such companies together and the portfolio has five estimating systems, five archives, five sets of cost codes and a dozen or so people it cannot afford to lose. The "synergies" in the deal model assumed these could be combined. In practice:
- Best-practice estimating has nothing to attach to, because there is no common way of estimating to improve.
- Integration is slow, because every company's data has to be interpreted by its own people.
- Key-person risk is real. The founder with rollover equity and an earnout often is the estimating system, and earnouts end.
- The portfolio cannot see itself. Bid volume, hit rate, fade between bid margin and final margin, change-order recovery: each company defines them differently, if it tracks them at all.
Why the usual integration levers miss it
Operating teams have good integration tools. For this problem, they work on the wrong layer.
- ERP consolidation standardizes the ledger. It sees cost after it is incurred, coded however the job was set up. It never sees the drawing set, the take-off or the scope assumptions that set the margin before the job started.
- A common estimating software license standardizes the screen, not the take-off. Counts are still done by hand, sheet by sheet, and the history still lives in each company's files.
- Mandating the platform's workbook standardizes the format by decree. The add-on's estimators lose the assemblies and factors they trust, work around the new template or leave, and their knowledge leaves with them.
- A platform head of preconstruction is a good hire and a single person. It moves the key-person risk from the add-on to the platform.
- Best-practice councils share lessons in quarterly meetings. Lessons transfer slowly when the underlying work is shaped differently in every company.
The ERP records the margin after it is lost. The estimate decides it before the job starts.
In a contracting business, the information that drives margin sits upstream of every system the integration plan touches: in drawings, specifications, take-offs and the judgment applied to them. That is the missing layer.
A shared intelligence layer as a value-creation lever
A shared intelligence layer reads the documents every company already has and runs the same core workflows on top of them, in every company. In practice:
- The same take-off and estimating workflow everywhere. Drawings go in, quantities come out with confidence scores, an estimator verifies them, and every number traces back to the sheet and region it came from. Quantities export into the spreadsheets and estimating software each team already uses, so pricing judgment stays local while the structure underneath becomes common.
- One knowledge base across all historical jobs. Every company's bid sets, estimates, change orders and closeout files, searchable in plain language, with answers that cite the sheet.
- One data model. A quantity, a scope item, a revision and a change mean the same thing in every company, so results can be compared.
- Consistent QA and compliance. One verification standard and one record of who checked what, with each company's data kept separate where it needs to be.
- An onboarding playbook. Each new add-on goes live in weeks on a layer that already exists, instead of starting an integration project from zero.
The value shows up through specific mechanisms:
| Lever | What changes in the work | Where it shows up |
|---|---|---|
| More bids per estimator | Estimators verify quantities instead of counting them | Revenue capacity without adding estimators |
| Tighter estimates | The whole set is counted, so fewer allowances cover what there was no time to count | Hit rate and bid margin |
| Fewer missed scope items | Gaps and addenda changes are caught at verification, before bid day | Less fade between bid and close, less change-order leakage |
| Faster add-on integration | New companies join an existing layer and playbook | Time to deliver what the deal model assumed |
| Less key-person dependency | Judgment is recorded in verification decisions and job history | Retention risk, earnout transitions, succession |
| Comparable operating data | One data model across companies, with history | Operating reviews that compare like with like |
These are mechanisms, not promised percentages. We would rather an operating partner measure them in their own portfolio than take a number from a slide.
It also changes where the initiative sits in the plan. Anything involving software tends to land under systems, next to the ERP migration. This belongs beside pricing and procurement: an operating initiative with an owner at every company, milestones in each 100-day plan and a standing line in the monthly operating review.
From diligence to scale
Diligence
Contractor diligence leans on the WIP schedule: backlog, over and under billings, and the fade or gain between the margin a job was bid at and the margin it closed at. That shows whether estimating is a strength. It doesn't show why. Where the seller grants access to a sample of closed jobs, reading the bid sets against the estimates and change orders shows whether fade came from missed scope, thin take-offs or field execution, and how much of the estimating runs through one person.
First 100 days
Inventory the drawings, estimates and job files. Get one workflow live on real bids. Build the knowledge base from historical jobs, then start reporting on common definitions. We lay out the phases, owners and failure modes in The first 100 days.
Integration
Converge on one data model without forcing one way of pricing. A common scope breakdown and verification standard come first; each company keeps its labor and markup judgment until the platform decides otherwise. The best estimator's review habits become checks that every company runs.
Scale
Each new add-on joins a layer that already works, so onboarding gets faster with every deal. When one company is at capacity, bids can move to another, because the take-off is in a common form. A company entering a new segment can draw on the portfolio's history of similar jobs.
What operating partners should ask any AI vendor
- Will it read our documents as they are? Scans, raster PDFs, legacy CAD and marked-up sets, not only clean native files. An add-on's archive is what it is.
- Can every output be traced to the sheet and region it came from? An estimator will not bid a number they cannot check.
- Who verifies, and is it recorded? Look for per-item confidence scores, human verification and an audit log of every change.
- Does it handle revisions? Addenda, bulletins and reissues are where scope moves. A one-time read goes stale at the next addendum.
- Does it produce one data model across companies with different conventions? If not, you have bought five tools.
- How long to production on a live bid, and who does the work? Our forward-deployed engineers take a deployment from kickoff to live work in three weeks. Ask every vendor for its number and who carries the load.
- What happens to our data? We do not train AI models on customer content. Each customer runs in an isolated tenant or on-premise, encrypted in transit and at rest, with role-based access control. Ask every vendor the same, and ask who owns the data model the platform builds.
- How will we know it is working? The answer should be in the estimator's terms, bids turned and scope caught, not logins.
Where a platform becomes one company
Most roll-ups integrate everything around the work and leave the work itself fragmented. The companies stay as good as they were the day they were bought, and the platform remains a set of businesses that share a ledger. A shared intelligence layer integrates at the level where margin is decided: the drawings, the take-off and the job history. That is where a platform becomes one company. Operon for Private Equity shows how it works.
