I. "ServiceTitan AI is what we need, just configured well."
The most common misread. The Pro Services team configures the standard AI features tightly: call summarization, technician scheduling, basic retention triggers. The features work. The platform CEO sees green dashboards.
What the dashboards don't show: the leverage points specific to multi-brand PE platforms. Cross-brand dispatch normalization. EBITDA-bridge reporting in the format the Operating Partner reads. Acquisition-integration FSM bridges. Membership-conversion priming with cross-brand customer history. None of these are in ServiceTitan's roadmap because the average ServiceTitan customer doesn't need them.
The honest read: if the LP deck math depends on multi-brand consolidation, off-the-shelf doesn't get there. Custom AI on top of ServiceTitan does. The ServiceTitan AI Integration Playbook describes what we'd commission.
II. "Each acquired brand can run its own AI configuration."
The second misread. Newly-acquired brands inherit their own ServiceTitan tenant configurations, their own dispatch logic, their own retention cadence. The platform's ops team doesn't want to flatten this immediately because each brand has institutional muscle memory tied to its current configuration.
The cost: dispatch optimization stays brand-by-brand. Routing, technician utilization and capacity balancing are each optimized inside a single brand rather than across the platform, so the operational density that consolidation was supposed to buy never shows up in the numbers. We do not publish a percentage for that gap, because we have not measured one on a platform of this shape.
The honest read: letting brands run separate AI configurations leaves cross-brand dispatch leverage on the table. Cross-brand normalization is a custom AI workflow; it's not configuration. The way to size it is to measure your own current routing against a cross-brand baseline, on your own dispatch data, before anyone quotes you a number. Same pattern at platforms running mixed FieldEdge + ServiceTitan stacks.
III. "The Operating Partner doesn't need technical AI conversations."
True, but the consequence is misread. Most platforms hold the OP at arm's length from AI implementation, on the theory that the OP doesn't need the technical detail. What the OP actually wants is the EBITDA-bridge math: this AI line item moves these specific operational metrics, which translate to these EBITDA dollars, which at our exit multiple translate to this exit-value uplift.
Platforms that don't translate AI work into exit-multiple math get less budget than platforms that do. Same actual operational improvement; different OP-level perceived value. The OP funds what they can put in the LP deck.
The honest read: every AI line item should arrive at the OP with the EBITDA bridge already built. "Membership conversion priming" is not the right framing. "This many additional memberships per month, at this margin, at our exit multiple" is, with every number in that sentence pulled from the platform's own baseline rather than from a vendor's deck.
IV. "We'll do AI after the next acquisition closes."
Common, defensible, wrong. The argument: M&A integration absorbs all the platform team's bandwidth; AI can wait until the dust settles.
What this misses: the workflow layer is what the next acquisition gets absorbed into. Platforms that commission AI before the next close bring a bridge that already exists. Platforms that wait rebuild the same manual integration work by hand, every cycle, with the same people.
For platforms acquiring 2-3 companies per year, the integration cycle is the line item worth attacking first, because every workflow the AI bridges is a workflow the next integration does not have to re-create. We have not measured a cycle-time reduction on a PE platform and will not quote one. The honest test is to time your last integration, name the workflows that ate the calendar, and scope against that number.
The honest read: AI is the integration accelerator, not the post-integration project. Sequence accordingly.
V. "ServiceTitan is the only system the platform runs on."
Half-true and the half that's wrong matters. ServiceTitan is the FSM. The platform also runs on a phone system, a customer-call layer, a marketing automation tool, a CRM (sometimes), an accounting system, a payroll system, an HRIS, and increasingly a separate analytics layer the OP relies on.
Off-the-shelf ServiceTitan AI lives inside ServiceTitan. The leverage in many workflows lives at the seams: the call layer into ServiceTitan dispatch, the marketing layer into ServiceTitan customer records, the analytics layer pulling from ServiceTitan + the accounting system + payroll into the OP's deck.
The honest read: the highest-leverage AI workflows often span ServiceTitan + 2-3 other systems. Custom AI architecture spans them; off-the-shelf ServiceTitan AI doesn't.
What we'd do.
If you're running a $20M-$100M PE-backed home services platform and any of the five above resonates, the next step is the Call-Center Leakage Calculator for a 90-second EBITDA-bridge read, or the diagnosis call for a written one-page scope. Plenty of those calls end with us recommending the Pro Services plus standard ServiceTitan AI path, because the platform's specifics don't justify a custom commission. We say that on the call, before there is an invoice. The rest end with a custom-commission scope shaped against one of the five misreads above. What we can point at today in this vertical is voice and call handling: 1,486 AI-handled calls and 2,203 minutes for one multi-location home services operator, and more than 6,000 live calls handled across the practice.