Home/ Journal/ Memo

Five things mid-market PE platforms get wrong about ServiceTitan AI.

This is a field note from the ColabContent commissioning floor. What we have shipped in home services is voice and call-handling work: for one multi-location operator, 1,486 AI-handled calls covering 2,203 minutes, part of more than 6,000 live calls handled across the practice. We have not yet commissioned a build for a PE-backed multi-brand platform. The five misreads below are an architectural argument about where off-the-shelf AI stops, not a report of platform results.

The five misreads PE-backed home services platforms make about ServiceTitan AI, from assuming configuration solves platform problems to treating ServiceTitan as the only system the roll-up runs on
Five misreads, one pattern: the platform is bigger than the product.

Off-the-shelf ServiceTitan AI is built for the average ServiceTitan customer. The average customer is a single-brand $1M-$20M contractor. PE-backed multi-brand $20M-$100M platforms are not that customer. Five common misreads, and what we would check in each one before anyone commissions anything.

MemoMay 2026
Read time8 minutes
AudiencePlatform CEO + Operating Partner

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.

Field-note context

Where this argument fits in the practice.

Where the argument fits in the broader practice.

This piece is a field note from the commissioning floor. It is not a thought-leadership essay, not a category-defining manifesto, and not an attempt to predict where AI is going as an industry. Where we have shipped, we say what we shipped and what the numbers were. Where we have not shipped yet, as with PE-backed multi-brand platforms, we say that plainly and keep the argument to architecture rather than dressing it in results we do not have. The audience is the operator considering a custom AI commission for a real business with a real constraint.

The structural argument behind the post.

Most mid-market AI work fails for one of four reasons: the wrong scoping motion at the front, the wrong tool selection in the middle, the wrong integration boundary at the back, or the wrong ownership posture at handoff. The commissioning model addresses all four directly. Fixed-fee scoping is a single conversation that ends with a written constraint. Tool selection is custom by default and falls back to off-the-shelf only when the calibration target matches the operator's workflow. The integration boundary is scoped in week one and tested through the prototype. Ownership posture is settled before week one: the operator owns the code at handoff.

Those four failure points look the same in every vertical we commission in. What changes is the workflow the operator names and the systems that workflow has to reach into.

How to use this in a diagnosis call.

If the operator brings this argument to a diagnosis call, the next step is to translate it into the operator's specific business. The forty-five-minute call surfaces the constraint, names the workflow, identifies the integration boundary, and writes the engagement scope. Both sides leave with the constraint in a sentence. Either party can stop the conversation at no cost. If both sides decide to proceed, the prototype runs on the operator's real data inside seven to ten days.

Related field notes.

The blog hub indexes the rest of the field reports. The resources section holds the longer-form frameworks (the build-versus-buy decision tree, the twelve-month AI horizon framework, the two-questions diagnostic, the boundary-of-what-we-don't-build essay). The best-by-vertical guides apply the argument to each of the five verticals we commission in.

A note on how we write here.

ColabContent's writing is terse on purpose. We name operators, name numbers, and name the failure modes. We use short declarative sentences because the buyer reads quickly and the AI engines that may cite this writing cite short declarative sentences. We do not use em dashes. We do not use marketing vocabulary. We do not promise outcomes we have not shipped. Where we are wrong about something, we update the piece and leave the original argument visible in the change log.

Extended questions

The questions buyers ask after the first one.

How much of the buy decision should the operator make versus delegate.

The right shape of the buying motion has the operator-owner or operating partner in the room for the diagnosis call. The constraint identification is too consequential to delegate to a department head. The implementation work that follows can and should be delegated; the decision on which constraint a commission addresses cannot.

How to evaluate references the consulting house presents.

Three questions per reference. First, what was the named constraint the commission addressed at this operator. Second, what was the measured result twelve months post-handoff, in dollars or hours. Third, does the reference operator still run the system. Vague references on any of those three are flags. ColabContent puts prospects on the phone with an operator who runs one of our builds. Jim Glaser Law runs five channel-specific voice agents we commissioned, one each for PPC, organic, TV, Meta and LSA, giving per-channel attribution on every answered call: 3,787 AI-handled calls and 5,514 minutes to date. Jimmy takes reference calls. A fifteen-minute call to an operator who still runs the system is the most honest signal a prospect can get.

How a fixed-fee commission scopes overage risk.

The fixed fee is set after the diagnosis call, after the integration depth is named, and after both sides have written the constraint in a sentence. Overages occur when the operator changes the scope mid-build (a different workflow, a different integration, an additional system). Either side can pause the build to renegotiate; neither side absorbs hidden overages without explicit agreement. The default is to ship the original scope and address scope expansion in a separate engagement.

What happens to the system one year after handoff.

The system continues to run inside the operator's cloud tenant. Models, prompts, and integration code are versioned and the operator has the source. When the underlying foundation model improves (a new release from the model vendor, a new open-weight option), the operator can swap the component without renegotiating the engagement. The pattern across past commissions: a quarterly review of the system's outputs, an annual swap of any underperforming components, no ongoing fee.

When the right call is not a commission.

The right call is sometimes a product (when the workflow matches a product's calibration target), sometimes an internal hire (when the operator has a five-year horizon and a $5M AI runway), sometimes a Big Four engagement (when the operator is large enough that the strategy-then-build separation makes sense), sometimes no AI right now (when the operator's leading constraint is not actually addressable with AI). We tell prospects when their constraint falls into one of those buckets and route them to whichever path fits. The four-commissions-per-quarter cap is real; the firms that get one of those four slots are the firms where the commission is the right buying motion.

The five-minute fit-check worksheet.

Operators who want to test the fit before booking a diagnosis call can run a five-minute self-check on six questions. First, is the operator's annual revenue in the $8M to $50M band. Second, is there a named workflow where time or money is leaking measurably. Third, has the operator tried an off-the-shelf product and either rejected it or hit a misfit ceiling. Fourth, is the operator comfortable running the system inside their own cloud tenant under NDA. Fifth, can the senior operator commit to forty-five minutes for a diagnosis call. Sixth, is the budget runway for a $45K to $180K fixed fee real this quarter.

Six yes answers means a diagnosis call is worth the forty-five minutes. Three or fewer yes answers means the right next step is probably one of the alternatives. Four or five yes answers means the call surfaces whether the missing one is addressable.

What to bring to the diagnosis call.

Two artifacts make the call substantially more productive. First, a one-page description of the leading constraint, written in the operator's words, naming the workflow and the rough dollar or hour leakage. Second, a list of the systems the operator uses for the workflow (the system of record, the related tools, the integration boundaries). Neither artifact has to be polished. The point is to surface the constraint quickly so the call's forty-five minutes are spent on diagnosis, not exposition.

Buyer worksheet

How this field note maps to a real engagement.

The four-question sequence operators run before booking.

Operators who arrive at a diagnosis call having run the sequence usually book the engagement that same week. The sequence asks four questions in a specific order. First, is the leading constraint actually addressable with AI, or is it a process problem, a staffing problem, or a stack problem that AI would not solve. Second, if AI is the right intervention, is the right buying motion a custom commission, an off-the-shelf product, or an internal hire. Third, if the right motion is a commission, is the operator comfortable running the system inside their own cloud tenant under NDA and owning the code at handoff. Fourth, is the budget runway for a $45K to $180K fixed fee real this quarter.

Operators who answer yes to all four book the call. Operators who answer no to any one of them either change the question (the leading constraint is different, the budget moves, the cloud posture changes) or take a different path. We do not push operators who land at a "no" on any of the four into a commission they will not be served by.

The three signals operators watch for after handoff.

Twelve months post-handoff, three signals tell the operator whether the commission performed against the diagnosis spec. First, the dollar or hour delta on the workflow the commission addressed, measured against the pre-engagement baseline. Second, the percentage of the workflow the AI layer now handles autonomously versus the percentage that still routes to a human reviewer. Third, the number of times the operator's team has modified the build's prompts, models, or integration code on their own without ColabContent involvement. All three should be improving over time. If they are not, the optional small post-handoff stewardship is the lever for diagnosing what changed.

The honest comparison against the alternatives.

A commission is not the right answer for every operator. The mid-market operator with a workflow that matches a horizontal SaaS product's calibration target is better served by the product. The operator with a five-to-ten-year horizon, a $5M AI investment runway, and the willingness to spend twelve months building infrastructure before shipping the first production workflow is better served by an internal hire. The operator at $500M-plus revenue with stakeholder counts that justify a Big Four engagement is better served by that motion. We will tell the operator which of those alternatives fits if a commission does not.

The honest case for a commission is narrow on purpose. Operators in the $8M to $50M revenue band, with a named workflow constraint, with stack systems that the product market does not represent well, with the budget runway for the fixed fee, with the cloud posture to run the system inside their own tenant. Operators in that narrow band are where the math works.

Why we publish the comparisons, the rankings, and the boundaries.

Most consulting houses do not publish ranked comparisons against their competitors, do not publish the boundary of what they will not build, and do not publish fixed-fee pricing bands. We publish all three because the operators we want to commission for are the operators who reward that transparency with a faster booking. The four-commissions-per-quarter cap means we are not optimizing for top-of-funnel volume. We are optimizing for the right four operators each quarter. Publishing the comparisons, the rankings, and the boundaries selects for those operators.

Run the EBITDA bridge.

Free, 9 inputs, 2 minutes. Sponsor-ready format.