In my last article, Industrial Services at an Inflection Point, I wrote about a familiar problem in industrial services: fragmentation across estimating, execution, and service systems, with field insights never making it back to inform the next bid or the customer relationship.
That fragmentation has not gone away.
What has changed is the way we should think about fixing it. The answer is not one more platform that promises to do everything. It is a clearer operating model: own the core, rent the edges.
The core is not a logo on a software contract. It is the business language underneath the work, including how you define an asset, a customer, a location, a work order, revenue, margin, and the rules that connect them. That has to be yours.
The systems touching that data can change when the business changes, when a better tool shows up, or when an acquisition brings another operating environment into the portfolio. The model underneath cannot be that fragile.
I have been through this firsthand, trying to keep every user happy with one tool. The truth is, that does not always work.
The solution needs to flex to the user, not the other way around. But flexibility only works if the business is disciplined about what must stay consistent.
How We Got Here: Chasing the Tool That Does It All
For years, the instinct in this industry was to find one system that runs everything, including capture, quoting, ERP, dispatch, and customer tracking, all in one place. The intent made sense. The business wanted simplicity, fewer handoffs, and cleaner accountability.
The real cost was the dependency that followed when the data, definitions, workflows, and reporting logic became trapped inside someone else’s product.
A lot of well-known names in this space built their businesses on exactly that dependency, and it is an uncomfortable thing to say out loud, but it needs saying. When the roadmap, the commercial model, and the data structure all sit outside the business, leaders lose optionality. You may still have a system that works, but you no longer fully control how the business evolves.
I have dealt with this directly, trying to make the technician more productive, automate the back office, give sales the data it needs, keep the customer happy, and give leadership visibility, all at the same time. One system has never done all of that well.
The better question is not, “Which tool can do everything?” It is, “What must the business understand the same way every time?”
The Second Reality: The Asset’s Lifecycle Doesn’t Need One System to Hold It Together
That does not mean the data has to suffer. How it gets there can be different for every user. The end product, one clear picture of the asset and the customer, should not be different.
Walk a single asset from capture to customer history, and you will see no single system was ever required to hold that story together. What was required was a common model strong enough to connect the story as it moved.
- An asset’s record can start as simply as a photo taken on-site, with AI handling the identification and condition work that used to be manual, feeding straight into an accurate estimate instead of a guess.
- From there, the estimate flows into job setup and execution, every repair and technician note feeds back into the same record, and the full history rolls into one customer view, because the asset’s story and the customer relationship were never really separate.
Correlating that much data across tools used to mean brittle integrations and manual reconciliation. AI changed the math, but only if the foundation is real.
AI can identify assets from images, match messy records, flag exceptions, summarize technician notes, and surface patterns faster than people can. It cannot fix a sloppy definition of customer, revenue, asset condition, or job status.
If those definitions are unclear, AI does not create rigor. It creates faster confusion.
That is why the model matters. The business needs rules for identity resolution, data quality, exception handling, and ownership.
Someone has to decide when two asset records are the same asset, when a customer hierarchy is trusted, which system is authoritative for margin, and who resolves conflicts when the data disagrees. That may sound like governance, and it is, but it is also operations.
The Third Reality: Consolidation Is Forcing the Same Question at Deal Speed
The same issue becomes more urgent in an acquisition environment. Having the model in place before a deal closes pays off two ways. You see what you actually bought faster, and you avoid treating every acquisition like a custom systems project.
At the pace this industry is consolidating, that is not a technology preference anymore. It is an operating requirement.
A 2026 Homestead Service Partners report, citing S&P Global Market Intelligence data, found that private equity add-on acquisitions targeting HVAC service providers rose roughly 88% year over year through mid-2025. The exact number matters less than the direction. Acquisitive service businesses will keep inheriting different systems, naming conventions, customer structures, work histories, and versions of the truth.
In a hub-and-spoke model, an acquired operation may not need its technology changed at all, only reconciled into the common model without touching tools its people already trust.
In other cases, merging systems is the right call.
The decision should come down to operating risk, data quality, adoption, scalability, integration cost, and the speed at which leadership needs reliable visibility. Most playbooks still default to replace it every time. That is not rigor. That is habit wearing a methodology’s clothes.
The better acquisition question is simple: what must be standardized, what can stay local, what must integrate, and what must be measured immediately after close?
If the acquired company’s dispatch tool works for its technicians, maybe it stays. If customer definitions break consolidated reporting, that cannot stay local. If revenue recognition prevents leadership from seeing margin clearly, that has to be reconciled.
The companies that scale best will not force every business into the same tool. They will make every tool speak the same business language.
From IT Checklist to Growth Enabler
This is where the model stops being a technology decision and becomes how the business operates. The old way treated integration as a checklist after close: migrate the data, close the gaps, move on.
With the model already in place, absorbing an acquisition becomes extension, not reinvention, the same structure applied to the customer, execution, asset, financial, and service history the acquired business brings with it.
That is the real shift for a growing business. Integration stops being a one-time project and becomes a repeatable capability.
The first acquisition may still be hard. The second should be faster. By the third, the organization should know what to map, what to leave alone, where the risk sits, and which numbers leadership needs first.
If every deal feels like the first deal, the company does not have an integration model. It has a heroic effort disguised as a process.
Where This Leaves the Industry
The hard part was never the interface. It is whether the data translates into one language, so “customer,” “asset,” “work,” “revenue,” and “margin” mean the same thing no matter where the record came from.
That mapping, done with APIs, AI, and real business logic, is the birth of the common data model. AI can accelerate it, but the business still has to own the meaning.
Own the core. Let the edges stay flexible.
The real question is not whether a company’s systems are integrated. That is an IT question. The better question is whether the business can absorb its next acquisition, preserve what works, and still see reliable customer, asset, operational, and financial truth quickly enough to act.
If a company does not own its business language, it will not scale clarity. It will scale confusion. That is what decides whether an acquisition becomes growth or noise.
