Multi-branch service networks fail at the second acquisition

the integration the model assumed

The thesis behind a branch roll-up in foundation repair, waterproofing, or specialty trades is straightforward: buy regional operators, keep the local brand and crews, centralise procurement, marketing, financing, and back office, and expand margin. The thesis is sound. The execution risk is almost entirely in the word centralise.

The first acquisition usually works, because it gets disproportionate attention and the founder is still in the building. The second one is where the model is tested, because now the platform has to run two variants of every process simultaneously — two CRMs, two pricing structures, two scheduling conventions, two definitions of a completed job — while the integration team is already stretched.

what breaks first

Reporting breaks first and loudest. The board asks for cost per lead by branch and the answer takes three weeks and carries caveats, because leads are defined differently in each system. Then scheduling breaks, because crew capacity is managed locally and cross-branch overflow requires a shared calendar nobody owns. Then warranty and callback tracking breaks, which is the expensive one, because callback rate is the leading indicator of both crew quality and future litigation.

None of these are technology failures in the usual sense. They are the absence of a canonical operating definition, and the software merely made the absence visible at speed.

where automation belongs in a roll-up

Not in replacing the branch systems on day one. The pragmatic sequence is to read from whatever the branches use, normalise into a canonical record, and run the cross-branch capabilities on that normalised layer: unified lead response, standardised proposal generation, callback and warranty analysis, and capacity balancing. Then migrate systems on a timeline the operation can absorb.

This inverts the usual integration plan, which is to standardise the systems and then get the reporting. Reading first buys you visibility in weeks instead of quarters, and visibility is what tells you which branch practices are worth standardising on. Occasionally the acquired company is running the better process, and a rip-and-replace integration would have destroyed it without ever knowing.

the acquisition math nobody stress-tests

Platform investors underwrite a roll-up on synergy assumptions — shared marketing spend, centralised financing partnerships, procurement leverage on materials — and those synergies are real. What is rarely underwritten explicitly is the integration labour cost of the second, third, and fourth acquisition, because the first one felt manageable and everyone extrapolates linearly from a sample of one. It does not scale linearly. Each additional branch adds not just its own systems but a combinatorial number of exceptions to reconcile against every branch already on the platform, and the integration team that handled acquisition one competently is often still mid-integration on acquisition two when acquisition three closes. This is where roll-up timelines slip and where the operating partner starts fielding uncomfortable board questions about a thesis that looked clean in the deck.

The tell that a platform is heading here is a familiar one: every quarterly business review contains a slide explaining why branch-level numbers are not yet comparable, followed by a promise that the next system migration will fix it. That promise has usually been made for two consecutive quarters by the time anyone escalates it.

the branch president's actual experience

From the seller's side of the acquisition, the pattern looks different but compounds the same problem. A branch president who sold their business a year ago is now being asked to adopt a corporate CRM that does not match how they have run scheduling for fifteen years, report metrics defined by someone at headquarters who has never worked a lead in their market, and do all of this while still being measured on the P&L they built the old way. Their instinct, entirely rational, is to keep running the business the way they know works and treat the new system as a reporting obligation layered on top rather than a replacement for their actual workflow. That is exactly how a platform ends up with thirty branches nominally on one system and thirty branches actually still running on spreadsheets, texts, and tribal knowledge underneath it.

sequencing the fix over the next two acquisitions

Before closing acquisition two, build the normalisation layer — a canonical data model for leads, inspections, proposals, jobs, and callbacks — that can read from whatever system the target already runs, rather than waiting to build it under pressure after the deal closes. Define the handful of metrics that must mean the same thing everywhere, in writing, before any board conversation depends on them: cost per lead, inspection-to-close rate, callback rate within twelve months, and technician utilisation. Give branch presidents a reason to feed the canonical layer honestly — usually by showing them their own branch benchmarked against peers, which is information they want, not just information corporate wants from them. Only after two or three acquisitions are running cleanly through that layer should system consolidation begin, and it should begin with the branches where the local system is weakest, not the ones where resistance will be loudest. A roll-up that gets this sequence right can absorb its fifth acquisition with less integration effort than its second cost, because the second one is where the operating model, not the deal model, finally gets built.