Before you build your autopilot
The market thesis is correct. Here's the operational playbook.
Sequoia recently published a piece called "Services: The New Software." If you haven't read it (you should), the argument is simple: the next great companies won't sell software tools that help people do work, they'll do the work directly. AI “autopilot” makes this possible at software margins. The opportunity is enormous.
I've been running and advising service automation businesses for over a decade, across legal, permitting, marketplace operations, and a handful of other verticals. The thesis is real. I've seen it work.
What the piece doesn't cover, and what I don’t see represented in the public discourse, is what it takes to actually build one of these businesses. I learned it the hard way, but you don’t have to. Here’s my operational methodology.
The Reality
You need to embrace three things in your bones before you build one of these businesses.
You own the outcome. The terrible, magnificent truth of a service company is that you're completely on the hook. From the outside, a service automation business can still look exactly like a software company (though it doesn’t have to). There may be a slick UI, a mobile app, an API. What makes it a service is not the absence of technology, but rather the presence of accountability. Software companies used to build a tool and drop it off at the customer’s doorstep; service companies walk straight through that door every day.
This is a collaboration between subject matter experts and technologists. The SMEs know how to deliver the service. The technologists know how to systematize and automate it. Treat either as secondary and the whole thing falls apart.
The business model is founded on repeatability. The more standardized your service, the faster your margins improve. The more variance you allow in, the harder everything gets. A repeatable service with thin margins is an automation business with a future. A highly variable service with great margins is a consulting firm.
The Strategy
You start by delivering the service manually. Use whatever existing tools work best for you, and provide whatever customer interface works best for them: a weekly call, a Dropbox link, a dashboard, email. You just don’t need to write any code, because you don’t know yet what will actually be useful. It’s much easier to automate an existing workflow than a speculative one.
As you deliver the service, you learn it. You map the process, you standardize, you identify the repeatable steps, you start to see where a script or an LLM could do what a human is doing. You automate one step, or part of it, and the human moves on to the next thing. You automate that too. Margins improve incrementally with each minute you take off the human's plate.
This continues until the humans are reviewing outputs rather than producing them, then until they are auditing a sample rather than reviewing every output. The business at the end of that journey looks like autopilot. The journey itself looks like a service company that is quietly getting more efficient every quarter.
The timeline is months to years, not days. AI is shrinking these timelines, but not obviating the process. Automating anything meaningfully complex still requires extensive, intentional iteration. This is especially true when you’re dealing with mission-critical tasks, sensitive data, regulated environments, or other stringent requirements around quality and consistency.
The Upside
You’re generating revenue on day one, before writing a single line of automation code. Your margins may be thin (15%, 5%, even -5%), but money is coming in the door. That is not how SaaS ever worked. SaaS required you to build the thing before you could sell it. A service automation business lets you sell the outcome first, deliver manually, and build the automation underneath it over time.
This means you can evaluate and achieve product-market fit with almost no technology or upfront cost. You are selling a result. If customers pay for it and come back, you have PMF. The automation is how you scale, not how you prove the idea.
Because you own the entire workflow, you optimize and automate a single process. Not a thousand customer workflows pulling in different directions. One. Every improvement compounds, and every task you automate raises the floor on your margins. Like any exponential process it feels slow at first, until all of a sudden you step back and find your delivery is 10x or 100x more efficient.
Owning the outcome also means you can charge accordingly. Customers will pay significantly more for an outcome than they’ll pay for a tool, and you’re able to capture that full value. How many hours it takes (or doesn’t take) to deliver that outcome is your concern, not theirs.
This is also where pricing and repeatability reinforce each other. Flat-rate pricing feels risky when your scope is fuzzy, but when you’ve standardized the service and defined the edges, flat-rate pricing feels natural. You know exactly what the outcome is, you price accordingly, and automation reduces your COGS over time.
Delivering the service generates proprietary training data. Every case your SMEs handle, every edge case they resolve, every output they review and correct is building a dataset that is specific to your service and your customers. Fed back into the LLMs, it accelerates your automation and improves the quality of your results.
Diligently follow this path and you’ll end up with fully automated workflows, at software margins, overseen by a small cadre of SMEs.
The Pitfalls
The model is sensitive in ways that aren’t obvious until you are inside it.
Repeatability is the biggest risk. If your service has too much variance - too many edge cases, too many one-off requests, too many customers who need something slightly different - the automation never catches up. You end up with a service that is too custom to systematize and too operational to scale. Every new customer adds complexity instead of leverage. This mistake is easy to make early as you search for an ICP, and very hard to unwind later.
Owning the outcome means there is nowhere to hide. This may sound obvious but the implications run deep. You cannot ship a bad product and wait for feedback. You cannot blame the user for misusing the tool. The result is yours. Some founders respond to this pressure by quietly retreating, building something that looks like a service but functions like a tool, pushing responsibility back to the customer without saying so. It’s a great way to destabilize your operations, your automation, and your pricing all at once.
Unstable workflows can burn out SMEs. Delivering the service is a first-class concern, and good SMEs will help you move faster and break less as you automate. But your workflows are going to change constantly, especially early, and that can become a heavy SME burden. Steps that existed six months ago will disappear. New steps will appear that you did not anticipate. The humans doing the work are going to feel this disruption directly, and some of them will not be able to roll with it. Hire for that tolerance explicitly. Someone who is deeply expert but rigidly attached to doing things a particular way will become a bottleneck at exactly the moment you need to accelerate.
The expectations trap. To win customers early, you often (rationally) price based on where margins will land once automation is mature, not where they start. It’s easy for investors (especially when they’re used to SaaS) to anchor on the future state too. When they see a growing team of SMEs required to actually deliver the service, it can look like something has gone wrong, even when it hasn’t.
Reality sits in the middle for longer than anyone is comfortable with and creates a dangerous squeeze. Even if you’ve made real progress, moving margins from 15% to 50% may not match the narrative they had in mind. If you don’t explicitly align expectations around the role of human delivery and the timeline of automation, you can end up underpriced, overextended, and struggling to finance the exact phase of the business that matters most.
Human delivery is fundamental to this model. Those humans will become orders of magnitude more efficient as you build, but it takes time.
The Work
Success in this space requires disciplined repetition, across three distinct loops that run simultaneously.
Loop One: Go To Market
In a service business, you are selling a promise: we will do this for you, and it will be done well. That changes the language, the motion, and the relationship. The sales cycle is more personal, because the customer is not evaluating a product, they are deciding whether to trust you with something that matters to them.
Loop Two: Deliver the Service
You’re running an ongoing business, and it needs to work. Onboarding, work product, time to value, customer support, quality control, escalations, invoicing - everything you would expect from any service business needs to be humming. The goal is simple: make customers happy and keep them. If the outcomes are not being delivered well, nothing else matters.
This is where ownership gets tested. When something goes wrong at scale, when the automation produces a bad result, when a customer is unhappy, the easiest response is to open the black box and point at the process. But the customer paid for a result, so if the result is wrong, you have to fix it. That accountability is the thing that separates a service from a product, and it is also the thing that justifies the price.
Loop Three: Automate the Service
This is how the business improves over time. A collaboration between your SMEs and your technical team, running on a separate cadence from the other two loops. You’re deeply introspecting the service you are delivering, finding the steps that are ready to be systematized, and moving carefully and deliberately to improve your service delivery through technology.
Get the infrastructure right up front so that iteration is actually possible. The ideal is a single environment where humans and machines can operate side by side, handing responsibilities back and forth as the process evolves. If your human workflow and your automation layer are two separate things that need to be reconciled, iteration will be slow and painful.
Map the process before you touch it. Standardize before you automate. Use the simplest solution that works. The right automation at the right moment compounds over time; the wrong automation, rushed, creates fragility that costs more to unwind than it ever saved.
This is not a project, it is a practice.
The Bottom Line
Service automation is not a new category of software, but it’s not SaaS. It is a different kind of company, with a different relationship to customers, to employees, to quality, and to time. The founders who go after an autopilot product with a SaaS playbook will spend years fighting the model instead of building with it.
The adjustments required are not complicated, but they aren’t always easy or obvious either. The model rewards patience, rigor, and honesty about where you actually are versus where you are trying to go.
The opportunity is real, and so is the work.
Let's talk
If you're in the early stages of a service automation business, I’d love to hear from you. I’m always happy to talk through what you’re working on, and if you need to accelerate your progress I’m available for strategic or hands-on consulting engagements.