What AI Can Do For the Trades

A common thread across my life has been my obsession with efficiency - studying just enough to get an A, perfectly threading a backdoor pass in basketball. I’m always chasing that “only green lights on the way home” kind of feeling. It’s the same reason I’ve been attracted to the trades software world for the last 6 years: It’s a fragmented domain and for so many aspects of it, there feels like there has to be a “better way.”

The Problem

If you own a home, you know finding a quality contractor often feels more like traffic before a holiday weekend than “green lights on the way home.” Now imagine doing that for 100 or 1000 homes - a 100+ site retailer might need 3 contractors for each of 50+ trades depending on the type of business they’re running. At ServiceChannel, a workflow automation system for facilities owners, we built performance KPIs for contractors that helped facilities teams build and operate these massive vendor networks. This worked because we were able to build a marketplace on top of these KPIs: Joe’s Hot Dogs should choose Plumber A instead of Plumber B because Plumber A does high quality work, fast, for a good price. Like Yelp but for commercial trades contractors.

The business was successful and still runs today¹, but there were a few structural reasons ServiceChannel’s marketplace didn’t explode like a more transactional marketplace such as Uber or Etsy:

1. To match facilities operators with contractors effectively, you need lots of data - not just many historical examples (rows), but also many columns (attributes like region or trade specialty). I recall a fast food chain rejected our Kitchen Equipment contractor recommendation because we couldn’t confirm their technicians had experience working on a particular type of Wok. Another way of saying this is that to make useful predictions about contractor or technician competencies, a dataset needs to be both wide and deep. And intuitively this makes sense - the industry is highly complex: to diagnose a repair, a technician has to account for many factors, including the weather, system age, system type (there are many!), repair history, system location, and installation approach.
2. By definition, the wider your dataset, the deeper it needs to be to be useful. Take Uber for example - matching riders and drivers is trivial relative to matching facilities owners and contractors because Uber riders just want a driver with a pulse…OK and perhaps a short or, ideally, non-existent rap sheet. Net-net, because trades data is “column-hungry,” it needs to be “row-hungries” than less “column-hungry” industries.
3. One and two are further compounded by a third factor: the skilled trades lag other industries in software adoption, and as a result, data collection. But I don’t blame facilities managers and technicians, for 2 reasons: (1) If you’re working all day on your feet and with your hands, data entry just isn’t your #1 priority. And (2) it’s not like the software we’ve built for the trades so far is what anyone would call “sexy.” For these reasons, data accuracy in trades software lags household-name marketplaces like Uber or Facebook. Even if a trades software provider did have a dataset that’s wide and deep, it’s handicapped by the accuracy of the data itself. This may sound like common sense, but it’s particularly bad in industries where data is captured by workers whose primary responsibilities are offline.

In sum, marketplaces like Uber are highly transactional: find a rider and a driver in the same vicinity and voila! The trades/facilities are quite different: the notable use cases (like predicting maintenance for a particular asset) are data-hungry, and yet the industry itself is poor at collecting data.

During the last decade plus, while other industries were revolutionized by software, the facilities & trades seemed to lag behind. The complexity of the industry and its physical nature simply meant that software couldn’t “meet the moment” the way it did in more online industries, but that’s about to change.

Why I’m Optimistic

First, a caveat: I acknowledge that large language models have serious limitations relevant to the trades: (1) they don’t interact with the physical world on their own and (2) much of their training data (the internet) is inaccurate or biased either because of simple falsehoods or limited data about the physical world.

LLMs are great at bringing structure to chaos and being thorough when humans won’t. If I give Claude Code 200 photographed supply-house receipts, it'll return a clean spreadsheet with date, vendor, part, price in minutes, without me writing a line of code. Because of this, LLMs will massively accelerate the collection of physical world data (for the trades and other industries), solving our structural problems raised above: (1 and 2) we will gather more data and (3) it will be more accurate.

HappyRobot has proven both cases in logistics already. Through a combination of high quality agent tech (this demo is sick) and forward-deployed engineers, HappyRobot learns complex logistics workflows, for each customer, across a variety of systems and stakeholders, and deploys custom agents on top of their proprietary platform to execute real work previously done by a combination of fragmented human workflows. For example, it might report and analyze patterns around which suppliers pay late - info that previously lived in the human practitioner's head, collecting more data, more accurately.

But what about the physical nature of the work - isn’t it true that the impact AI can have on home services and facilities is limited by its connectivity to the physical world? While advances in robotics and hardware may still take some time to catch up, advances in LLMs seem to be speeding up that very process. Companies like Siro, a mobile app for in-person field sales coaching that uses transcriptions to generate structured insights for salespeople in the trades and other industries, and Monaire, which uses physical sensors connected to software to visualize and optimize HVAC/R costs, are showing already that physical world data can more easily be captured by combining LLMs with physical world interfaces. Video data may not be far behind. Meta/Raybans and Google/Warby Parker have recently announced promising new releases. It’s hard not to imagine that one day your HVAC technician will wear AI-supported glasses to your next “no cooling” call, and fix your unit in half the time. If and when that happens, the data collected will quickly compound the advantage to users. XOi tried this form factor in 2015, outfitting over 1,000 technicians, but “the hardware ultimately proved impractical for large-scale deployment.” Per TechCrunch, “unit prices were too high” and “the form factors were too clumsy when ruggedized to the level they needed to be to stay in one piece on site.” That was a decade ago, but since then XOi has rolled out mobile app features that help connect technicians to near real-time information like manuals, videos, parts and more (taking advantage of industry data acquired through its acquisition of Specifx), competing with Bluon and others.

So What (Predictions)

With so much change in AI and the world of the trades, I wanted to create a framework to think through the next generation of winners and losers.

First, there’s a vibe in tech right now that no incumbent is safe. I totally disagree - moats still matter, and that’s no different in the skilled trades. It’s fair to say that incumbent moats in facilities / trades software aren’t nearly as defensible as Uber’s or Facebook’s, because of the structural issues (data sparsity, data accuracy) discussed above. The world of CMMS (Computerized Maintenance Management System) and FSMs (Field Service Management) is still highly fragmented compared with social media and ridesharing. ServiceTitan, XOi, MaintainX, ServiceChannel all have great starting places, but their distribution, data and network moats can be usurped quickly if a niche player with a credible wedge can build its own data moat with an agentic execution layer.

That’s point #1: the next generation of winners will build and own data moats. These data moats will be compounded by “execution layers” (point #2) that don’t just store data in systems of record but execute real work without a human in the loop. HappyRobot-enabled workflows actually collect more data than humans ever could, because an agent can collect a near-infinite amount of metadata about every interaction it has. Avoca is another great example: the platform automates home services intake and scheduling. Besides consolidating the number of CSRs each shop needs for scheduling and therefore freeing that headcount up for more strategic work, Avoca increases data accuracy (by removing the human-in-the-loop) and expands the scope of data that can be collected. Siro is another example: they’re building a massive cross-industry dataset about in-person sales through transcribing billions of real conversations, automatically, for their users. All three of these examples address the 2 issues we discussed above - data-hungriness and poor data hygiene. By doing the work instead of just storing its byproducts, AI-driven systems generate more data, more accurately.

So Should You Build Your Own?

The next generation of winners in skilled trades software will also continue to build “network” moats (point #3) like software giants of the past, e.g., ServiceTitan or ServiceChannel. Aggregated data means more data, and more data means better proprietary models. This prediction is more controversial than it sounds - there’s a hot debate right now about whether third-party software will be replaced by every customer creating their own software from scratch. If the cost of building software has gone to 0, why not build your own system of record and stop paying ServiceTitan? But that comes with a high cost on your time - you can build a CRM, but should you? Do you have the resources to maintain it? Is your business willing to prioritize the upgrade, maintenance and implementation costs of the software?

Third-party software is here to stay. A team that specializes on a specific problem will by definition do it better than someone who has a separate day job. What’s changed is that the floor for building great software is much lower. Companies and consumers should develop their own software, but only for highly niche use cases - the use cases they never had the resources to build before that a plurality of their peers don’t have (and therefore a vendor won’t build). If your peers have the same problem, odds are a vendor has an incentive to solve it. And because more data is better data, a vendor who has solved your problem for many others is likely going to have a compounding advantage over you - its software’s predictions are based on thousands or millions of examples.

There are likely far fewer cases where building in-house is better than buying, not only because of network and data moats, but also because the floor for building good software has been lowered for everyone - including third party vendors. AI-native vendors can customize software per customer much more easily than they ever could before. We’re already seeing this with companies like HappyRobot, who have a single platform underlying per customer customization across 150+ enterprises. On implementation, forward-deployed engineers partner with the customer to ensure its software is tailored to the customer’s use case. The concept of tailoring software isn’t new, but AI has unlocked a depth of customization we’ve never seen before.

And that’s point #4 - the software winners of the future will create highly customizable experiences for their customers, through a combination of self-service customization and forward-deployed engineers.

For important use cases like systems of record, CRM, accounting, dispatch, skilled trade contractors will inform software customization, but they won’t build the entire system themselves. Just because you can do something, it doesn’t mean you should.

Should skilled trade contractors be hiring developers? Large platforms like Apex Service Partners and Southern Home Services already have lightly resourced functions like data engineering, ServiceTitan architects, or otherwise. But smaller shops will likely want an in-between - an internal ops guy who has figured out Claude Code / Codex, or a 3rd party contractor. That’s exactly the gap my consulting practice aims to fill - ensure mission-critical trades businesses are “AI-ready.” Building software isn’t the hard part - you can speak an app into existence with Claude Code, but knowing how to implement, test, and maintain code sustainably and securely is still a massive learning curve for an industry that’s historically slow to adopt vendor-supported software.

This transformation will require training, 3rd party support, and ongoing maintenance for the bespoke software being built to bridge the “last mile” of niche use cases for each company.

Whether you’re a home services business owner, or practitioner/investor in trades software, I’d love to hear from you. You can book time or send me an email via colin-ford.com.

Footnotes

1. That business probably does low $XXM / year (a small fraction of ServiceChannel’s total revenue) at the time of writing. ↩