Home/ Journal/ Memo

AI for PE-backed home services platforms, and whether a buyer will pay for the build.

A PE-backed home services platform is a roll-up built to sell. It is valued on a multiple of its EBITDA, and it is going to change hands, which means a dollar of durable EBITDA is worth its exit multiple, commonly high single digits to low double digits. That one fact resorts every AI decision at this kind of buyer. The question is not whether a system saves money; it is whether a saving becomes an asset the multiple pays for. Three tests decide it. The first is quality-of-earnings diligence: a saving that is documented, owned, and baselined gets credited as run-rate EBITDA, while a saving that rides a month-to-month subscription or one person's configuration gets added back and counts for almost nothing. The second is the transaction itself: a per-seat contract in the platform's name is a liability the acquirer re-buys or rips out, while an owned system in the platform's own cloud transfers as an asset and can become a synergy the acquirer pays up for. The third is compounding: a platform-level capability every future acquisition inherits makes the next integration cheaper, which is the consolidation thesis a sponsor underwrites, while a one-brand win is an operating result the multiple ignores. Where the platform sits in the hold clock decides the answer more than the workflow does. A platform close to exit should often buy nothing custom, or buy the tier it already owns; an early-hold platform is where a build seasons into the numbers and compounds across acquisitions.

An operating partner sizing an AI budget for a home services platform is not really buying efficiency. The platform is a roll-up assembled to be sold, priced at a multiple of its earnings, and every dollar that reaches the bottom line in a durable, defensible way is worth that multiple again on the day it changes hands. That is a different economy from the one most AI pitches are written for. A pitch names a workflow, counts the hours or the headcount it removes, and presents the saving as the return. At a business built to sell, the saving is only the first move. Whether it survives a buyer's diligence, transfers in the transaction, and compounds across the next acquisition is what decides whether it lifted the exit or simply lowered a cost for a while.

MemoJuly 2026
Read time11 minutes
AudiencePlatform CEOs, Operating Partners, Sponsors

The platform is priced on a multiple, and that changes which AI is worth buying.

Most businesses buy AI to lower a cost, and the cost stays lowered as long as they own the business. A platform assembled by a sponsor is not most businesses. It exists to be sold inside a fund's hold period, and it is priced the way it will be sold, at a multiple of its earnings. That multiple is commonly high single digits to low double digits, which means a dollar of earnings a buyer treats as durable is not worth one dollar. It is worth the multiple, counted once now inside the earnings and again as the multiple is applied at exit.

That single arithmetic fact reorders every AI decision at this kind of buyer. The right question is never whether a system saves money. Almost any competent system saves some money. The question is whether the saving becomes an asset the multiple pays for, or a convenience that quietly evaporates the moment the platform changes hands. An efficiency decision asks what a tool costs and what it removes. An asset-quality decision asks whether a buyer's diligence will credit the improvement as durable earnings, whether the capability survives the transaction, and whether it makes the next acquisition worth more.

Those are not the same question, and a platform that answers the first while believing it answered the second is the platform that buys well-liked software and sells at the same multiple it would have reached anyway. The efficiency was real. It just landed in a form the buyer had no reason to pay for, which at a business whose entire purpose is the sale is close to not landing at all.

The operational questions are real too, and they are largely settled elsewhere. Which workflow to automate, how dispatch and intake get normalized across brands, how the system reads the field service stack, how a sponsor sees the EBITDA bridge: those belong on the home services platforms industry brief and are not relitigated here. This memo takes the narrower question the brief does not, the one no vendor can answer for the platform. When the saving arrives, will a buyer pay a multiple for it, and will it still be there when the buyer looks.

Test one: will the improvement survive quality-of-earnings diligence?

Before a platform sells, a buyer runs a quality-of-earnings study, and that study is where an AI saving either becomes worth its multiple or becomes worth almost nothing. A quality-of-earnings team does not accept the platform's reported EBITDA at face value. It tests each component for whether it is real, durable, and likely to recur under new ownership, and it adds back anything that looks like a one-time benefit, an owner's discretion, or a number that depends on a relationship or a subscription the buyer would not keep.

An AI-driven saving walks straight into that test. If the saving is documented, owned by the platform, integrated into the systems of record, and visible as a sustained change in an operating metric the diligence team can trace, it reads as run-rate EBITDA and earns the multiple. If the same saving rides a month-to-month vendor subscription, lives inside one clever manager's private configuration, or sits on a setting that will reset at the next platform migration, the diligence team treats it as reversible. Reversible savings get discounted or added back, and an added-back dollar contributes nothing to the price.

The defense is built long before diligence, and it is mostly bookkeeping rather than technology. A saving is only creditable if the platform can show what the metric was before the system existed and what it is now, which means a baseline has to have been captured in the systems the platform already runs. Platforms lose this argument by never writing down the year before the change; the general form of the problem is set out in how to measure the return on a mid-market AI engagement. The same discipline governs the inputs: a system whose outputs cannot be tied back to clean, owned operational data cannot be defended as durable, and data readiness is what makes the saving legible to a stranger reading the numbers cold.

The practical consequence is that the cheapest-looking AI purchase is often the one that fails this test. A subscription that shows a result on a dashboard but leaves no owned artifact, no baseline, and no integration behind it can be genuinely useful to operate and still contribute zero to the price the platform sells for.

Test two: does the capability survive the transaction?

At exit the platform stops being a standalone company. It folds into a larger acquirer, a strategic consolidator, or a continuation vehicle the same sponsor rolls it into, and the AI capability has to make that move intact or it does not count. This is where the form of the thing, owned asset versus rented convenience, stops being a philosophical preference and becomes a line in the purchase agreement.

Consider the two ways the same capability can be structured. In the first, the platform pays a per-seat subscription for an AI feature in the vendor's cloud, under a contract in the platform's name. To an acquirer, that is not an asset; it is a liability to be re-priced. The acquirer either re-buys the seats at whatever the vendor charges an enterprise, folds the function into a tool it already owns and rips the subscription out, or discovers the contract auto-renews on terms it did not choose. None of those outcomes puts money on the platform's side of the table. A capability the buyer has to re-acquire is a capability the seller was effectively renting.

In the second, the platform owns the codebase, it runs inside the platform's own cloud tenant, and the model choices, prompts, and data pipeline are documented well enough that the acquirer's engineers can read and keep it. That transfers cleanly. It shows up in diligence as intellectual property the platform built and controls, it carries no third-party contract the acquirer has to inherit, and it can be presented as a synergy the acquirer pays up for, because the buyer can extend it across a portfolio far larger than the platform that built it. Why ownership at handoff is the whole game, rather than a nicety, is the subject of owning your AI and why code handoff matters.

The subscription route also carries a cost that compounds against exactly this kind of buyer. A platform grows its seat count as it acquires, so a per-seat AI contract gets more expensive every time the roll-up does its job, and per-seat pricing at scale is where platforms find they signed up for the option that punishes growth. The capability that survives the transaction is the one the platform can hand over as a thing it owns, not a bill the buyer has to keep paying.

Test three: does it compound across the roll-up, or only lift one brand?

A sponsor did not buy a home services company. It bought a thesis that many home services companies, run on one platform, are worth more together than apart, and that each additional acquisition gets cheaper to absorb than the last. AI earns its multiple at this kind of buyer only when it serves that thesis, which means the test is not whether a capability helps a brand but whether it compounds across the roll-up.

The distinction is sharp in practice. A capability built for one brand, tuned to that brand's data and its people, improves that brand's numbers and stops there. It is a genuine operating win, and it is invisible to the multiple, because a buyer underwrites the platform's ability to keep consolidating, not a single location's performance. A platform-level capability is different in kind. It lives above the brands, every future acquisition inherits it on the day it closes, and it makes the next integration faster and cheaper than the last one was. That is the property a sponsor actually pays for, because it turns the acquisition pipeline from a series of one-off integration projects into a repeatable motion.

The mechanics of how a platform-level system normalizes across brands, and why cross-brand routing is a custom workflow rather than a configuration setting, are worked out in five things PE platforms get wrong about ServiceTitan AI, and there is no reason to repeat them here. The money point is narrower. A one-brand build is priced by the platform as a cost that paid off. A platform-level build that every acquisition inherits is priced by the buyer as part of what makes the whole machine worth a higher multiple, and those are different orders of magnitude.

There is a failure mode that lives exactly here. A capability that was supposed to be platform-level but was actually built against one brand's quirks does not inherit; the next acquisition needs it rebuilt, and the promised compounding never arrives. That is a common reason a rollout that looked successful at one brand quietly stops paying off as the platform scales, a pattern that shows up across industries as rollouts stalling around month four. Inside a roll-up the cost is not just a stalled project; it is a compounding story the sponsor underwrote and did not get.

The case for buying nothing this year, or just buying the tier you already own.

We commission custom systems for a living, so weigh the following accordingly. It is also the section we would most want an operating partner to read, because a platform that buys a custom build at the wrong point in its hold decides the whole category was a waste of money, and it was half right.

A platform twelve to eighteen months from exit should usually not commission a custom build. The reason is the same arithmetic the rest of this memo runs on. A build takes time to ship and more time to show a sustained change in an operating metric, and only a change that has seasoned into the trailing-twelve-month numbers a quality-of-earnings team reads will be credited at exit. A capability that goes live three months before the bankers do gets no run-rate credit; it reads as a new, unproven cost. Set against that thin upside is a real downside: standing up a new system across the operation during a live sale process introduces disruption risk at the exact moment the platform most needs clean, boring, predictable numbers. Close to exit, the honest answer is usually to wait, harvest what is already seasoned, and hand the build to the next owner as an opportunity rather than a half-finished project.

The second honest case is the commodity workflow. If the need is generic to the industry, call summarization, basic scheduling assistance, routine follow-up, it is very likely already shipped inside the field service management tier the platform pays for. Buying a custom version of a feature the platform already owns is a maintenance liability with no exit story attached. The question of when a workflow is specific enough to justify a build and when it is not is the whole subject of the build versus buy decision, and for a platform the default should tilt toward the owned tier for anything generic.

The case flips for an early-hold platform with a long runway. A sponsor two or three years from a sale has exactly the time a build needs to season into the numbers, and exactly the acquisition pipeline for a platform-level capability to compound across. That is the window where a custom commission passes all three tests at once: it has time to become run-rate EBITDA, it can be built as an owned asset that transfers, and every deal in the remaining hold inherits it. The right move is not a fixed policy on buying AI. It is a policy of reading the hold clock first and saying plainly, in each case, whether the answer is build, buy the tier, or wait.

What a platform CEO or operating partner can do this week, with no vendor in the room.

None of this requires a vendor, a demo, or a budget. It requires an afternoon and the platform's own records, and it produces a decision an operating partner can defend to a sponsor. Run the three tests as three lists.

For the first test, take every dollar the platform currently spends on AI and automation and sort it into two columns: what a quality-of-earnings team would credit as durable run-rate EBITDA, and what it would add back as reversible. A line belongs in the run-rate column only if the platform can produce a baseline, an owned artifact, and an integration that outlives the vendor relationship. Most platforms find the add-back column longer than they expected, and every line in it is a saving the platform is booking today that will not survive the buyer's read.

For the second test, list every AI capability the platform relies on and mark each one as a per-seat contract in the platform's name or an owned asset running in the platform's own cloud. The contracts are the ones an acquirer re-buys or rips out; the owned assets are the ones that transfer and can be sold as synergy. If the important capabilities are all in the first column, the platform is renting the very things it will want to present as intellectual property at exit, and that is a position to change while there is still time to change it.

For the third test, name the single capability the next acquisition would inherit on the day it closes, and be honest about which capabilities would instead have to be rebuilt for the new brand. If nothing inherits, the platform has been buying operating wins and calling them platform strategy, and the compounding the sponsor underwrote does not exist yet.

Those three lists take a CFO and an operating partner one afternoon, and between them they answer the only question that matters at a business built to sell: not whether AI would help the platform run, but whether a buyer will pay a multiple for what the platform is about to build. A platform that walks into a vendor conversation with those three lists already filled in has supplied the one input no vendor can supply, and it is the input that decides whether the money spent this year shows up in the price next year.

Field-note context

What we notice inside a platform built to sell.

The add-back nobody models when they buy the subscription.

When a platform signs a monthly AI subscription and books the saving, the model in the operator's head is that a dollar saved is a dollar of EBITDA, and a dollar of EBITDA is worth the multiple. The quality-of-earnings team does not see it that way. A saving that exists only because a subscription is active, with nothing owned behind it and no baseline captured before it, is precisely the kind of item a diligence team adds back, because a new owner could cancel the subscription tomorrow and the saving would vanish with it. So the operator has modeled the saving at the multiple and the buyer credits it at roughly zero. The gap between those two numbers is not a rounding error at a business priced on a multiple; it is the difference between a line that lifts the exit and a line that was quietly funding a vendor. Nobody models the add-back at purchase, because the subscription looks cheap and the dashboard looks convincing, and both of those are true right up until the diligence team reads the contract.

An owned capability can be a synergy line the acquirer pays up for.

Most AI value at a home services platform gets framed defensively: a cost removed, a leak closed, hours taken out of a process. That framing understates what an owned, transferable capability is worth to the right buyer. A strategic acquirer or a larger sponsor is not buying the platform's cost base; it is buying what the platform can do that the acquirer's other holdings cannot, and a capability the platform built and owns can be extended across a portfolio many times the platform's size. At that point the capability stops being a cost the platform avoided and becomes a synergy the acquirer underwrites in its own model, which is a line the buyer will pay up for rather than a line the buyer discounts. The platform captures that premium only if the capability is genuinely owned and genuinely portable. A rented feature cannot be a synergy, because the acquirer already has the vendor's number. The asset the platform built, running in the platform's own environment and documented well enough to travel, is the one that shows up on the buy side as a reason to pay more.

The hold clock decides more than the workflow does.

Operators tend to argue about which workflow to automate first, as though the workflow were the decisive variable. At a business built to sell, it usually is not. Where the platform sits in the fund's hold period changes the right answer more than the choice of workflow, because the same build is a good decision early in the hold and a bad one near the exit. Early, a build has time to season into the trailing-twelve-month numbers a buyer reads, time to compound across the acquisitions still to come, and room to absorb the disruption of standing something new up. Late, none of that is true: the capability will not season into the numbers in time, the acquisition pipeline that would have compounded it is nearly spent, and the disruption lands during the sale process. An operator who picks the perfect workflow at the wrong point in the hold has made a worse decision than one who picks a merely good workflow at the right point. The first question is not what to build. It is how much runway remains before the platform changes hands, and that answer reorders everything after it.

Extended questions

The questions a sponsor asks once the multiple is on the table.

Does AI actually raise a home services platform's exit value?

It can, but not because it saves money. A PE-backed platform is priced on a multiple of its EBITDA, so an AI investment raises exit value only when the saving it produces is credited as durable earnings and survives the sale. Three conditions have to hold. The saving has to be documented, owned, and baselined well enough that a quality-of-earnings team credits it as run-rate EBITDA rather than adding it back as reversible. The capability has to transfer in the transaction as an owned asset the acquirer keeps, not a per-seat subscription the acquirer re-buys or cancels. And it should compound across the roll-up, so every future acquisition inherits it and the sponsor's consolidation thesis gets cheaper to execute. An AI system that saves real money but fails those conditions can leave the exit value unchanged, because a saving that a buyer will not credit, cannot inherit, and would not keep is worth close to nothing at a business whose purpose is the sale. The efficiency is real either way. Whether it becomes exit value depends entirely on whether a buyer will pay a multiple for it.

What does a quality-of-earnings team do with an AI-driven cost saving?

It tests the saving for durability and adds back anything it cannot verify will recur under new ownership. A quality-of-earnings study does not accept reported EBITDA at face value; it examines each component and strips out one-time benefits, owner discretion, and anything that depends on a contract or a relationship the buyer would not keep. An AI-driven saving passes that test when it is documented, owned by the platform, integrated into the systems of record, and visible as a sustained change against a baseline the team can trace. It fails when it rides a month-to-month subscription, lives in one person's private configuration, or sits on a setting that resets at the next platform migration, because all three are reversible and a new owner could lose the saving without doing anything. A saving the team credits as run-rate EBITDA earns the platform's multiple. A saving the team adds back contributes nothing to the price. The determining factor is rarely how clever the system is; it is whether the platform captured the baseline and kept the artifact that lets a stranger confirm the saving is real and durable.

Should a platform commission custom AI or use the AI features already in ServiceTitan?

For anything generic to the industry, use the tier already owned; commission custom only where the workflow is specific to the platform and the capability needs to be an owned, transferable asset. Field service management platforms have shipped AI features for common needs like call summarization, scheduling assistance, and routine follow-up into tiers many platforms already pay for. Buying a custom version of a feature the platform already owns is a maintenance liability with no exit story attached, so the default for commodity workflows should be the owned tier. The case for a custom commission is narrower and specific to a roll-up: a workflow that off-the-shelf features do not serve, that spans multiple brands or systems, and that the platform wants to own outright so it transfers at exit as intellectual property rather than a subscription the acquirer re-buys. The deciding question is not which is cheaper on the sticker. It is whether the workflow is specific enough to the platform to justify owning it, and whether the platform is early enough in its hold for the build to season into the numbers and compound across the acquisitions still to come.

We are eighteen months from exit. Is it too late to start?

For a custom build, usually yes; for harvesting what is already seasoned and buying the owned tier, usually no. A build takes time to ship and more time to show a sustained change in an operating metric, and only a change that has settled into the trailing-twelve-month numbers gets credited by a quality-of-earnings team at exit. A capability that goes live shortly before the sale process reads as a new, unproven cost rather than durable EBITDA, so the upside is thin. The downside is not: standing up a new system across the operation during a live sale introduces disruption at the moment the platform most needs clean, predictable numbers. Eighteen months from exit, the productive moves are to make sure the savings the platform already has are documented, owned, and baselined so they survive diligence, to move any important capability off a per-seat subscription and into an owned form that transfers, and to buy the generic features from the tier the platform already owns. A custom commission at that point is usually better handed to the next owner as an opportunity than started as a project the platform will not get credit for.

How should a PE-backed home services platform measure the return on an AI build?

In exit terms, not efficiency terms: whether the saving is credited as durable EBITDA, whether the capability transfers in a sale, and whether it compounds across the roll-up. Hours saved and headcount avoided are operating metrics, and at a business priced on a multiple they are only the first half of the return. The measure that matters is whether a quality-of-earnings team would credit the saving as run-rate EBITDA, which requires a baseline captured before the build, an owned artifact rather than a rented one, and integration into the systems of record. Alongside that, track whether the capability is structured to survive the transaction, meaning it runs as an owned asset in the platform's own cloud rather than a per-seat contract in the platform's name, and whether it is platform-level, so every future acquisition inherits it instead of needing it rebuilt. A build that scores well on all three raises the multiple, not just the margin. A build measured only in hours saved can look like a success on an operating dashboard and still add nothing to the price the platform sells for, which is the only number a sponsor is underwriting.

How does the AI Maturity Index help a platform sort this?

It runs the three tests without a call and without a vendor. The Index asks which process is worth investing in first, who touches it and how often, and where that process gets its inputs, which is most of what a platform needs to tell a saving that will survive diligence from one that will be added back, an owned capability from a rented one, and a platform-level build from a one-brand win. For a roll-up the most useful output is usually the elimination rather than the recommendation. It surfaces the candidates that only lower a cost a buyer will not credit, or that ride a subscription that will not transfer, or that lift a single brand the multiple ignores, which are the ones to leave alone or hand to the next owner. And it reads against the hold clock, so the same workflow sorts differently for an early-hold platform than for one twelve months from exit. Ten minutes, no call, and the result is specific enough to bring to a sponsor's next board meeting alongside the operating numbers the platform already reports.

Not sure which of the three tests your platform's AI would pass?

Start with the AI Maturity Index. Ten minutes, no call, and it names the one workflow worth investing in first, sizes who touches it and how often, and tells you whether the capability you are about to build becomes an asset a buyer pays a multiple for or a cost that disappears at exit, before you talk to anyone.

Take the AI Maturity Index → Or book a diagnosis call →