If you build SaaS, your customers are getting closer to building their own software.
A small business owner can describe their workflow to an AI tool and get something working back. The build-vs-buy gap that once kept small businesses reliant on software companies like yours is narrowing.
If your only edge is "we added AI," you're already behind.
That's a feature announcement written for shareholders, not a strategy built for customers.
Working as a software engineering intern at Jobber changed how I think about AI in SaaS. Jobber builds software for blue-collar businesses: plumbers, electricians, HVAC technicians, landscapers, cleaners, and more.
You can't build AI that serves customers you don't understand.
Here's what I learned about the people Jobber builds for.
Every software company with a pitch deck says "AI-first." Most mean "we added a ChatGPT API call and put a sparkle icon somewhere." That's not a moat. A moat is a durable edge competitors can't easily replicate. Any competitor can ship a thin model call in a sprint. Model access is table stakes. The edge is knowing which customer problem the model should solve, what context it needs, and when it should stay out of the way. What nobody can copy quickly is what you know about your customers.
Meet Blake
At Jobber, product teams build detailed pictures of the people using the software. It keeps product decisions grounded in what real customers need. Blake is one of them.
Blake runs an electrical company with two crews. He has a toddler at home and a schedule that stays full. But staying full doesn't mean the business runs smoothly.
Quotes still go quiet. Blake sends one, the client goes silent, and the lead cools off before he has time to follow up. Nothing in his workflow catches it before it falls through.
After-hours calls pile up. Homeowners call at 7pm about a burning smell from an outlet or half the house going dark. Blake can't always answer, so the calls go to voicemail. Some get returned the next morning. Some don't.
Then there are client messages. Blake knows how to talk to clients, but after a long day in the field, writing a follow-up or finishing a quote takes time he doesn't have.
This isn't a story about a disorganized contractor. Blake is good at the job. These friction points are structural, built into how a two-crew electrical business runs. Missed calls. Late-night admin. Blank-page moments. They happen to every contractor in a predictable pattern.
That's what product teams at Jobber spend time learning. Not the idealized version of the workday. What the actual day looks like, friction and all.
Generic AI gets replaced. Domain knowledge doesn't.
As tools like ChatGPT and Claude improve, AI features that simply wrap them become interchangeable. By "wrap," I mean a thin UI around a model call where the underlying workflow doesn't change. No better tooling. No sharper product logic. No easier path through the work. A service business owner could often get the same result by opening ChatGPT for free.
When those tools can do the same task directly, a wrapper with no domain knowledge has no place to compete in the market. There's no reason for a service business owner to pay extra for a product that does what the model already does on its own. Most AI product work today is a thin UI over someone else's infrastructure.
The first problem is competitive. Small teams with AI tools can now ship features in a sprint that used to take an enterprise organization a full quarter. The bar dropped for everyone else.
The second problem comes from your own customers. No-code tools let non-technical business owners build working apps from a description. A plumber can't rebuild Jobber by prompting a no-code agent, at least not today. But that line keeps moving. Every year, more workflow complexity becomes something your customers can build themselves.
If your software only does what customers already understand about their own day, they'll build around you.
The software companies that survive won't win by picking a better model. They'll win by understanding their customers better than any competitor can. That means years of learning how those customers actually work, the patterns that only show up when you're close to the work. No off-the-shelf model has that.
Product teams at Jobber know a roofer's text to a one-time customer sounds different from a cleaner's message to a client they've served for two years. One may be a one-off job. The other may be an ongoing client relationship where a warmer tone feels natural. They know switching channels mid-conversation throws the client off. They know which jobs book overnight and which need a conversation first. So Blake's quote follow-up goes out at the right time in the right channel.
That knowledge didn't come from scraping the internet. Product teams sat with business owners for years. They turned what they learned into features that fit the actual workflows of these businesses.
Build that kind of understanding and nobody can copy it.
You can't design for outcomes you don't understand.
A chatbot answers a question and stops. An agent acts on the result and keeps going until the job is done. That distinction matters more than most teams realize. One informs. The other acts.
Blake doesn't want to chat about the afternoon schedule. Blake wants the 4pm call handled, the job booked, and the client texted, all while he's troubleshooting an outlet in a different house. A chatbot that generates a follow-up template isn't an outcome. It creates more work.
Take scheduling. A plumber's day is reactive. Emergencies cascade, jobs shift based on what's nearby, and parts availability can change the entire plan. A landscaping crew runs the same route every week. A commercial cleaner books weeks out, with hours that depend on when buildings open for after-hours cleaning.
A plumber, a landscaper, and a commercial cleaner all call it "scheduling." The similarity ends there.
Generic scheduling assumptions break in ways that only show up when contractors try them. AI that gets it wrong erodes trust in the software faster than no AI at all. Contractors don't give second chances to tools that make them look unreliable in front of their clients.
That is where Jobber's AI Receptionist fits. Blake runs a two-crew electrical business and can't always answer when homeowners call after hours. The Receptionist handles those calls. It answers, books appointments based on Blake's available job types, creates work requests for his review, and sends a confirmation. Blake wakes up to a summary of what happened overnight, with appointments already on the calendar. No missed business.
Product teams built this around Blake's outcome, not a generic automation. That's only possible when you understand what a missed overnight call costs an electrical contractor and what a worried homeowner needs to hear before they trust the booking. Those answers don't come from the model. They come from knowing the customer.
"Good" only has meaning inside a domain.
Ask a developer who's never spoken to a contractor to define "professional tone" for a quote follow-up. Then ask an electrician who's been in business for 15 years. You get two answers. Only one lands with the customer.
Every undefined standard is a gap in your domain knowledge. "Professional." "Friendly." "Helpful." An electrician and a landscaper use those words differently. The model doesn't know that. If you don't define them, the model fills in the gap with its own guesses. You only catch the mistake after a client reads the message. Defining those words precisely enough to build a dependable system around them is the actual product work.
Blake's client messages used to take too long to write. The easy answer would have been to ship "AI that makes your messages better." Product teams defined specific tones instead: Professional, Casual, Cheerful, Shorter. Each option came from research into when contractors write client messages.
Different situations need different tones. That's obvious. What "Professional" sounds like to a homeowner holding a $4,000 quote is less obvious. So is what "Casual" means from a tradesperson the client has met once. Those definitions are the product. The tone labels are the handle on top of them.
Every tone selection is a signal. Every edit is a signal. Every message sent without changes is a signal too. Across millions of messages, that becomes a flywheel no foundation model has. Teams build that flywheel over years. They learn how a window cleaner texts clients. They learn how an electrician quotes commercial jobs.
That's the domain knowledge moat. Not just a better model, and not just a clever prompt. The prompt only works when the team has already defined what good means inside the domain. Years of knowing what good looks like in blue-collar service work, and applying that knowledge in ways customers can feel in the product.
Service business owners only trust AI that knows their world.
Service business owners don't have time to spare. Most AI features they've tried didn't help. Plenty created more work. When a new "AI-powered" feature appears in the software they use, the first thought is: "This will waste my time."
Product teams earn a service business owner's trust by giving that owner control. Trust breaks the first time your AI makes a contractor look unreliable in front of a client.
Jobber Copilot is an AI assistant built into the product. It knows a service business owner's data. Ask it a question and it answers from that owner's own numbers. One Thursday, Blake asked the Copilot: "which open quotes should I follow up on today?" The Copilot returned a short list of open quotes, each with context on why it was worth following up on. It pulled from Blake's own sales pipeline, ranked the signals that matter for an electrical contractor, and gave Blake something he could act on immediately. The Copilot knows what a follow-up looks like for Blake's business. It does the work. Blake trusted it because the product clearly knew his business.
The AI Receptionist works the same way. Providers choose which job types it can book. They set what it says when it can't help a caller. The service business owner decides what the AI takes on. That's why contractors rely on it.
A prompt is copyable. A UI is cloneable. The years Jobber spent learning how blue-collar service businesses work to build those answers? You can't copy that. And when the software proves it understands the business, service business owners are more willing to trust the AI inside it.
The only moat that lasts
After putting these tools to work, Blake's experience looked different. Quote follow-ups had gone out on time in the same channel as the original quote. After-hours calls became booked appointments waiting in the morning. Client messages took two minutes instead of twenty. The Copilot surfaced which open quotes were worth calling on and why.
None of those outcomes came from a better model.
Domain knowledge is the only AI moat that lasts. Generic AI becomes interchangeable. Competitors copy features. Knowing how these blue-collar businesses actually work is an edge no competitor can close quickly. And it's not in any model's training data.
Before your next AI feature, start with a service business owner like Blake. Follow the actual workflow. Find the confusion points, the workarounds, the tasks that happen outside your software. Build around what you find. The model your competitor ships next quarter will match yours. What competitors won't have is Blake.
Top comments (0)