Most contractors get sold AI as a product. It is not a product, it is a layer, and it only works when the two layers underneath it are already doing their jobs. Get the order wrong and you have bought a very fast way to send the wrong message to the wrong person.
The stack, in plain words
The CRM is the memory. One place where every lead, appointment, quote and job lives, with the history attached to it. If your memory is a phone, a notebook and three inboxes, nothing built on top of it can work, because the software cannot read any of those.
Automations are the hands. Rules you wrote, carried out exactly, every time. Form comes in, text goes out. Appointment booked, confirmation sends. Job marked complete, review request goes the next morning. Hands are dumb on purpose. That is the feature: they are predictable, and when they break they break loudly.
AI is the dispatcher. It reads the messy input a rule cannot handle and decides what should happen next. What was that voicemail about. Which of these six replies fits this text. Does this inquiry look like a buyer or like somebody pricing an insurance claim. Dispatchers are useful and they are also the layer that fails quietly, which is why one belongs behind rules rather than in front of them.
Read that order twice, because the money is in it. Most trades businesses need far more of the second layer and far less of the third than the marketing suggests.
What to automate first, and why in this order
Pick by two things only: how often it happens, and what it costs you when it is missed. That gives the same four every time.
- Lead response. Highest frequency, highest cost when missed, and the only one where minutes genuinely matter. An automated first touch buys the time it takes a person to get to the phone. It does not replace the phone call, which isthe part most providers decline to own.
- Booking and confirmations. The appointment is the asset, and the gap between booked and attended is where it gets lost. Confirm at booking, remind the day before, remind the morning of, and make every one of them a message a person can reply to.
- Estimate follow-up. The week after a quote is where most jobs quietly die. A sequence that carries actual information, the written scope, the option they hesitated over, the lead time on their product, beats "just checking in" every time, because it gives them something to answer.
- Review requests. Lowest urgency, highest compounding value, and the easiest to forget. Fire it off the job status, on the day, with a direct link. Never write the review for the customer.
Notice what is not on that list: anything that decides money.
The first touch, written out
Most automated first messages fail for the same two reasons. They pretend to be a person, and they ask for something. This shape does neither:
Hi [first name], this is [your company]. We have got your request about the [product] in [town]. Somebody is calling you in the next few minutes from this number. If now is bad, reply with a better time.
Four things are working in that. It names the company, so it is not pretending to be a friend. It repeats what they asked for, so they know it is not a blast. It says a person is coming and from which number, which is the single biggest reason a callback gets answered instead of ignored. And the only thing it asks for is permission to call later, which is the easiest yes in the message.
What it does not do: quote a price, promise a timeline, or ask four qualifying questions. Those belong to the person on the phone. Putting them in a text turns a warm inquiry back into a form.
What AI should never touch
- Pricing authority. Software can assemble a quote from your own rates. It must not agree a price, offer a discount, or answer "can you do better than that". Those are margin decisions and margin is the business.
- Contract terms. Scope, exclusions, payment schedule, warranty language, change orders. Every one of those is a promise somebody has to keep with a van and a crew, and a model that has never been on a job site should not be writing them.
- Customer conflict. The moment somebody is unhappy, a person picks up the phone. An automated reply to a complaint reads as contempt, and it converts a fixable problem into a review you will be reading for three years.
There is a fourth, quieter one: never let it invent an answer it does not have. Lead times, stock, whether a product suits a bathroom. A confident wrong answer about a product costs you the job on install day, when it is far more expensive than not knowing. The rule that holds all four together is the line between drafted and sent. Let software write anything. Let a person send anything that carries money, obligation or feeling.
Off the shelf or owned
Both are legitimate. The honest trade is not about features, it is about who carries which risk:
| Off the shelf | Owned infrastructure | |
|---|---|---|
| Cost shape | Monthly, per seat or per contact, rises as you get busier | Cost up front, then running costs closer to flat |
| Time to live | Days | Weeks |
| Fit | Their idea of how a contractor works | How you actually work |
| Lock-in | Your logic lives in their builder and rarely exports | You hold the data and the logic |
| Who fixes it at 9pm | A support queue, on their hours | Whoever built it, so agree that in writing first |
| Risk you carry | Price changes and feature removals you do not control | Maintenance, and knowing who does it |
The 9pm row is the one people skip and then regret. Ask any vendor, and ask us: when this stops sending texts on a Friday night, who notices, how fast, and what do they do about it. A stack nobody is watching is not infrastructure. It is a liability with a login. The lock-in row deserves the same treatment, and it is the whole argument in own your stack.
A sensible middle exists and most companies should start there. Rent the memory, because a CRM is a solved problem and building one rarely pays. Rent the software; own the account and the data. That is the whole trick. Own the parts that are actually your business: how a lead gets qualified, what gets said, what gets escalated to a person, and where the data ends up. That mix is what we build in a custom partnership, which you should read as an interest declared rather than a neutral opinion.
A sober 30-day plan
Nothing here needs a developer for the first two weeks, and the order is the point. Skipping week one is the most common and most expensive mistake, because you cannot tell whether any of it worked without a before.
- Week 1, measure. Write down, by hand if necessary, how many inquiries arrived, how long each waited for a first reply, how many became booked appointments, and how many of those were attended. Change nothing. This week is your baseline and you only get one chance at it.
- Week 2, lead response only. One automated first touch, within a minute, that says who you are and that a person is calling. Nothing else. Test it against your own phone first, including at 11pm, so you find out what the quiet hours rule does before a customer does.
- Week 3, booking and confirmations. The confirmation at booking, the reminder the day before, the reminder the morning of. Every message a real reply-to number. Watch what happens to attendance, not to booking count.
- Week 4, follow-up and reviews. A five touch estimate follow-up carrying real information, and a review request that fires off job completion. Then reread your week one numbers next to this week's.
At day thirty you are looking for movement in two places: the time between an inquiry arriving and a human speaking to it, and the share of booked estimates actually attended. Those two are what everything above is for, and they sit right next to the five numbers every owner should know.
The failure nobody warns you about
It is almost never the AI saying something bizarre. It is a sequence firing on stale data: the customer who signed on Tuesday still being asked on Thursday whether they had a chance to think it over. That single message undoes a week of good work, because it tells somebody who just trusted you that nobody is actually paying attention.
Three rules prevent nearly all of it. Every sequence needs an explicit stop condition. Every send needs a duplicate check. Every automation needs quiet hours. And every one of the three gets tested against your own number before a customer sees it.
None of this fixes bad demand, and it is worth being blunt about that. Faster replies to inquiries that were sold to four companies at once produce faster rejections, which is two of the three reasons leads go quiet. Automation makes a good process quicker. It makes a broken one quicker too. Before you buy anything, ask the same kind of questions we publish about our own trade in the seven questions, and notice which vendors answer the awkward ones.
