The roll-up math nobody's FSM vendor warns you about

Every field service management vendor sells you software for the business you have today, not the business a private equity sponsor is about to turn you into. That's the gap. PE-backed buyers completed 60.5% of all residential-services acquisitions through July 2026, and 62.8% of HVAC, plumbing, and electrical transactions specifically, according to Capstone data reported by Contracting Business. Alvarez & Marsal counts more than 890 trade-services deals since 2021, including over 620 in HVAC alone (A&M).

The runway is nowhere near finished. McKinsey estimates independents still hold roughly 76% of critical, infrequent home-services markets like electrical and roofing, and about 51% of critical, frequent markets like HVAC (New American Tradesman). IBISWorld puts the US HVAC contractor count at around 120,461 businesses. That's a lot of shops left to buy, which means a lot of platforms are going to keep acquiring, and every acquisition brings its own software stack along for the ride.

Here's the part nobody mentions in the pitch deck: software doesn't consolidate when a roll-up acquires a company. It fragments further. Acquisition one is running ServiceTitan. Acquisition two never left spreadsheets and a shared Google Calendar. Acquisition three is on Housecall Pro because the previous owner's son set it up in 2019. By acquisition five, the platform has five different customer databases, five technician rosters that don't talk to each other, and a finance team trying to close the books across systems that were never meant to share data. Nobody designed this mess. It's just what happens when you buy growth instead of building infrastructure for it.

What field service management software actually does well at one location

Tools like ServiceTitan, Jobber, Housecall Pro, and FieldPulse earn their reputation for a reason: for a single-location shop, they're genuinely good. ServiceTitan alone carries a 4.5 out of 5 rating across more than 1,700 reviews on its own market page, and that's not just marketing copy; operators who've used it generally mean it (ServiceTitan).

These platforms handle the fundamentals well: dispatching a technician to a job, tracking a work order from intake to invoice, managing a pricebook, running payroll off completed jobs, and giving an owner a dashboard that used to live only in their head. For a shop with one P&L, one set of technicians, and one brand identity, that's the entire job, and these tools do it without requiring the owner to think about software architecture at all. That's the correct trade. Most independent operators should never build custom software. They should buy a proven tool, learn its quirks, and run their business.

This is worth saying plainly because it's the fair starting point: the problem with FSM software isn't the software. It's the assumption baked into all of it, that there's one brand, one location, and one decision-maker behind the screen.

What breaks the moment you add a second brand

The first acquisition is where the cracks start, and by the third, they're structural. A PE-backed platform usually ends up with some combination of these problems, and we've seen the pattern repeat across different trades:

• Customer history lives in whichever tool the acquired company happened to use, so a homeowner who's used three different brands under the same platform looks like three strangers.

• Technician rosters, certifications, and availability sit in separate systems, which means a platform can't move a tech from an overbooked brand to an understaffed one without someone manually checking spreadsheets.

• Parts and inventory data don't reconcile across brands, so the platform can't negotiate volume pricing with suppliers even though it's buying the same parts five times over.

• Pricebooks drift. Each brand prices the same repair differently because nobody rebuilt a unified pricing model after the acquisition closed.

• There's no single pane of glass for the PE sponsor or the platform CEO to see portfolio-wide revenue, technician utilization, or margin by job type. Someone on the finance team is manually exporting five CSVs into one spreadsheet every month end.

None of this shows up in a due diligence deck. It shows up six months post-close, when the integration team realizes that "just migrate everyone to ServiceTitan" is a 12 to 18 month project with real data loss risk, and that even after migration, the platform still doesn't have a unified customer or technician data model, just one vendor instead of five. Buying one more FSM seat for everyone doesn't solve a data architecture problem. It just centralizes the symptom.

This is the same pattern we see across other roll-up-heavy categories, where off-the-shelf software was built for a single operator and starts cracking once a business crosses a scale threshold the vendor never designed for. We've written about the same breaking point in demand planning software once revenue crosses a certain range, and the mechanics are nearly identical: the tool is fine, the assumption that one tenant equals one business is the thing that fails.

Is there a ServiceTitan alternative built for multi-brand operators

Not really, and that's the honest answer. ServiceTitan, Jobber, Housecall Pro, and the rest are built around a tenant-per-business model, with multi-location features bolted on for operators who run several branches of the same brand under one name. None of them were architected for a holding company running five to ten independently branded acquisitions, each with its own customer-facing identity, pricing, and technician pool, that still needs portfolio-level visibility and cross-brand resource sharing.

Some platforms will sell you an "enterprise" tier that lets you run multiple instances under one account. That's not the same thing as a unified data layer. You still end up with five databases that happen to be billed on one invoice. The actual gap PE-backed platforms hit isn't "which vendor has the best multi-location feature," it's "nobody sells the thing that sits above all our FSM instances and makes them behave like one business for reporting, dispatch, and customer history." That layer doesn't exist as a SaaS product because every roll-up's brand structure, acquisition pace, and tech stack is different enough that a generic tool can't serve all of them well. It's closer to infrastructure than it is to software you install.

The labor-shortage multiplier

Dispatch and scheduling mistakes used to be annoying. Now they're closer to existential, because there's no slack labor pool left to absorb them. HVAC technician supply met only 63.8% of estimated demand in 2024, and that ratio is projected to fall to 62.9% by 2029, per TechForce Foundation data cited by Simpro. Industry estimates from SMACNA put the US HVAC technician shortage at around 110,000 workers. The Bureau of Labor Statistics projects HVAC mechanic and installer employment to grow 8% from 2024 to 2034, and electrician employment to grow 9% from 2025 to 2035 with roughly 72,700 annual openings, numbers that assume the current supply of trades workers holds steady, which it isn't (LinkedIn, Kemp). That same analysis cites a JLL estimate of around 600,000 open skilled-trades postings against roughly 150,000 apprenticeship entrants a year.

What that means operationally: a scheduling error that sends the wrong technician to the wrong job, or double-books a tech across two brands because nobody can see both calendars, used to cost you an annoyed customer and a reschedule. Today it costs you a missed revenue day you can't recover, because there's no bench of idle technicians to absorb the mistake. Roll-ups are acquiring their way around the labor shortage instead of solving it, and the fragmented software stack is exactly what turns a tight labor market into missed appointments and overtime nobody budgeted for.

When to build instead of keep buying more FSM seats

The decision point isn't about company size in revenue. It's about whether you're managing one data model or several that don't talk to each other. If you're still inside one brand, one FSM instance, keep paying your SaaS vendor and move on with your life. The build-vs-buy question only gets real once a platform has three or more acquisitions running separate systems and a PE sponsor asking for portfolio-level numbers that nobody can produce without a week of manual reconciliation.

At that point, the useful framework looks like this, and it's the same one we walk clients through in our build-vs-buy decision framework for AI applied to this specific vertical:

• Data unification first. Before any AI or automation conversation, you need one canonical customer record and one technician record across brands. This is unglamorous integration and data-modeling work, not AI. It's also the part most platforms underestimate and underbudget.

• Cross-brand reporting second. Once the data model exists, portfolio dashboards for revenue, margin, and utilization become a reporting layer on top, not a rebuild of every brand's operations.

• AI-assisted dispatch and scheduling third. Only once you have unified technician availability, skill data, and job history does an AI dispatcher actually have something useful to reason over. Bolt it onto fragmented data and you'll automate the chaos faster, not fix it.

We've seen this exact sequencing play out with a client outside home services: at C&G Energy Services, a utility billing process was leaking over $1M a year not because the company lacked AI, but because field logs, billing systems, and invoicing had never been unified across their operation. Genta AI Solutions broke the fix into six discrete projects and recovered roughly $800K a year, and the honest detail worth repeating is that most of that fix was process automation and integration work, not machine learning. The diagnosis mattered more than the model. That's the same order of operations a multi-brand FSM mess needs: fix the data architecture, then decide where AI genuinely earns its keep.

Who actually builds that layer matters too. A single in-house engineer can prototype a dashboard, but unifying data across five acquired companies with different schemas, different pricebooks, and different compliance requirements is a systems problem that usually needs a team that's shipped this kind of integration before. We've laid out that hiring trade-off in more detail in why hiring an AI firm beats a single in-house hire for most mid-market platforms. And if you're not sure whether your platform has actually hit the threshold where building makes sense, rather than it just feeling painful, an AI readiness assessment is the honest way to find out before you commit budget.

If you're working through this decision for a multi-brand platform, this is exactly what Genta's Discovery phase maps out before anyone writes a line of code, and the output is a system your platform owns outright, not another SaaS seat per brand. Our full-stack AI software work is built around that ownership model: you commission the layer that sits above your fragmented FSM instances, and you keep it, no subscriptions tied to vendor roadmaps you don't control.

Frequently asked questions

What's the difference between CRM and FSM software?

A CRM tracks the sales relationship: leads, quotes, and customer communication history. FSM software manages the operational side after a job is booked: dispatching technicians, tracking work orders, managing parts, and invoicing completed jobs. Most home-services platforms need both, and the disconnect between them is exactly where multi-brand roll-ups lose customer continuity across acquisitions.

Is there a ServiceTitan alternative built for multi-brand or multi-location operators?

Not as an off-the-shelf product. ServiceTitan, Jobber, and Housecall Pro offer multi-location tiers, but those run parallel instances rather than a true unified data layer. Platforms running several distinctly branded acquisitions usually need a custom reporting and data layer built above their existing FSM tools, not a different vendor with the same per-tenant assumption.

What happens to customer and technician data when you acquire a company running different field service software?

Usually nothing good without intervention. Customer history stays siloed in the old system, technician certifications and availability don't sync with the parent platform's scheduling, and finance ends up manually reconciling exports across tools. Migration to one vendor helps consolidate billing but doesn't by itself create a unified customer or technician record unless someone designs that data model explicitly.

When does it make sense to build custom field service software instead of buying another FSM license?

Once a platform is running three or more separate FSM instances across acquired brands and a sponsor or CEO needs portfolio-level reporting nobody can produce manually, buying another license stops solving the problem. That's the point to unify data across brands first, then layer reporting and AI-assisted scheduling on top, rather than adding another standalone tool.

Can AI agents handle dispatch and scheduling instead of a standalone FSM tool?

AI agents can handle dispatch and scheduling well, but only once they have clean, unified data on technician skills, location, availability, and job history to reason over. Bolted onto five disconnected systems, an AI dispatcher just automates the existing chaos faster. The data unification has to come first, especially with HVAC technician supply meeting only 63.8% of demand industry-wide.