According to Sequoia, the next $1T company will be a services company run by software, and that model is called service-as-a-software.
For every dollar companies spend on software, they spend about $6 on services. A company might pay $10K a year for QuickBooks and $120K for the accountant who closes the books. For 25 years, software companies have competed for the $10K by selling tools that people operate.
AI changes that arrangement.
Software can now do the parts of the work that need intelligence, while the parts that need judgement still depend on a person.
Intelligence is work that follows rules, even complex ones, like turning a spec into code and fixing its bugs. Judgement is deciding what to build next or whether a product is ready to ship.
That means a company can sell the finished work instead of the tool. A GTM agency can sell qualified pipeline instead of software that helps a sales team find prospects. At Workflows.io, we sell go-to-market systems as a service.
For HeyReach, we built a signal-based outbound channel that added $500K in ARR in its first three months using our own company OS.
This guide covers what the model is, which work it can automate, and how we run it at Workflows.io.
What is service-as-a-software?
Service-as-a-software is a business model where the customer buys an outcome and software performs most of the delivery. The provider owns the result as an agency does, and runs delivery on software as a SaaS company does.
SaaS | Traditional services | Service-as-a-software | |
|---|---|---|---|
Customer buys | Access to software | People’s time and expertise | A completed piece of work |
Who does the work | Customer’s team | Provider’s team | Software, with the provider's team on decisions and exceptions |
Who owns the result | Customer | Provider | Provider |
What limits growth | Product and distribution | Hiring | How much of the work software can do reliably |
What matters most is who owns the result.
A CRM gives a sales team a way to manage pipeline, but buying one doesn't create pipeline. The customer still pays people to research accounts, write outreach and run campaigns.
SaaS companies can serve thousands of customers because they never take on that work, and it's also why they only capture the software budget.
An agency takes on the work, which is why it can charge for the larger budget. But every new client adds research, writing and reporting, so revenue and headcount grow together. Service-as-a-software keeps the agency's position with the customer and changes what happens behind it.
Copilots and autopilots
A copilot helps a professional do the work. A legal copilot summarizes a contract, flags unusual clauses, compares language against a playbook and drafts suggested changes, and the lawyer decides what to use. The lawyer is the customer, and the product succeeds if the lawyer gets faster.
An autopilot delivers the work to the person who needs it. A founder submits an NDA. The provider's system compares each clause against an approved playbook, marks deviations, prepares changes, and sends high-risk or unclear clauses to a qualified lawyer. The founder is buying a reviewed NDA and never sees the software.
The test is what happens when the AI gets something wrong. If a prospecting tool drafts a bad email, the salesperson is expected to catch it. If an AI-native outbound service makes the same mistake, the client doesn't care that a model caused it.
The provider owns the process, so it needs checks and escalation rules to catch the error first. That delivery system is part of what the customer pays for.
Autopilot doesn't mean full automation. At Workflows, AI runs in three modes:
Standard automations are fixed flows in n8n, like adding every campaign lead to Supabase.
Autonomous loops are agents that act on their own and notify us of changes, like our campaign optimization agents.
Human-in-the-loop workflows have Claude run the execution while a person owns the strategy and final review. Most of our work still sits here.
The business model changes even when a person reviews most outputs, because what matters is how many people the service needs.
Using AI is Different from Service-as-a-software
Almost any service company can now call itself AI-powered. A copywriter who drafts with ChatGPT or an account manager who has AI summarize calls is using AI, and it makes them faster. But the work still moves through individual employees. Each one prompts differently and keeps knowledge in their head. Someone still copies data between systems and moves each step forward by hand.
Service-as-a-software turns the repeatable parts of a company's expertise into systems that run the same way every time. Those systems have access to company knowledge and client context, and they connect to the tools where the work happens. People step in where a decision or an exception needs them, and they own the client relationship.
What AI can automate
Asking whether AI can do a job is the wrong level of detail. A job is a bundle of tasks, and they don't all need the same kind of thinking. The useful question is which parts follow rules and which parts need judgement once the rules run out.
Take a GTM strategist:
Their week might include interviewing a client, researching competitors, defining an ICP, building account lists, writing campaigns and deciding what to change next. Researching 500 accounts follows rules.
Choosing which market the client should go after doesn't. Writing 50 variations of an approved message follows rules. Deciding what the core message should be doesn't.
Rule-based work can still be hard. To qualify an account, a researcher might check industry, employee count, geography, business model, hiring activity and funding history, then weigh them against the client's ICP.
If an experienced operator can explain what to look for and what makes an account qualify, software can follow the same process and check its own output against those rules.
Judgement deals in trade-offs instead of correct answers. A rule can tell you a prospect matches the ICP. Judgement tells you whether the ICP is still the right one.
A rule can tell you a contract clause differs from standard language. Judgement tells you whether the difference is worth delaying the deal over.
Break a role into tasks, and most of the execution around each decision turns out to be rule-based. Software can take that on, so the people in the role spend their time on the decisions.
How the Model works: The Four Layers
A prompt isn't enough to deliver a service. The system needs to know how your company does the work, what's specific to this client, how to perform each task, and how to act in the tools where the work happens.
At Workflows.io, we build that as four layers.
1. Company Knowledge (The Company OS)
Every agency has its own way of working: how it defines an ICP, what makes a good signal, how long a cold email should be, and when a campaign needs to change. Most of that knowledge lives in people's heads and old Slack threads.
That works when people do the work. It fails when software does.
The first version of our Company OS was our Notion knowledge base, mostly SOPs. It now lives as markdown files in a GitHub repo, because AI reads markdown easily and every change goes through a pull request. It holds our playbooks, writing rules, research methods, quality standards, escalation criteria, and examples of good and bad work.
Telling a model to "write a good cold email" leaves most decisions open. The Company OS tells it the length, the claims it can make, how to personalize, which phrases to avoid and what evidence it needs. It improves through feedback loops, manual pull requests and agent evals.
2. Client Context
The Company OS says how to do the work. Client context says who it's for. Two clients can buy the same outbound service and need very different campaigns. One sells cybersecurity software to banks, the other sells recruiting services to startups, so their buyers, positioning, objections and proof points have little in common.
Each client gets a dedicated GitHub repo holding ICPs, personas, positioning, offers, brand voice, customer stories, competitors and past campaigns. We keep piping fresh data into it: call transcripts, Slack threads, CRM changes and account summaries.
Campaign performance data goes into Supabase and Pinecone, where workflows can query it. An employee who has worked on an account for six months doesn't relearn the client every morning, and the system shouldn't either.
3. Skills and workflows
A skill is a written procedure for one piece of work. Our account research skill tells the AI to load the client's ICP, research the company, collect the specified signals, compare them against the qualification criteria, record the evidence for its decision, and flag unclear cases for review.
The copywriting skill follows a different procedure, starting from the account research and the client's approved messaging angles.
This is where an operator's expertise becomes reusable. A method it took a senior person years to learn gets written once and applied to thousands of accounts. The operator's job shifts from doing each instance of the task to designing and improving the skill.
We've broken down the five Claude Code skills we use most across GTM, with each one open-sourced so you can adapt it for your team.
Turning our SOPs into skills got tasks like client updates, campaign creation, content ideation and documentation 80% or more of the way done without a person. Skills with a clear trigger run as agents on their own and deliver the output in Slack or our internal UI.
4. The execution layer
If the prospect list ends up in a Markdown file, someone still has to create the contacts, update the CRM, load the sequence and track replies. The execution layer connects the AI to those tools through APIs, command-line tools and MCP (Model Context Protocol) servers.
The ones we use most are Instantly, HeyReach, HubSpot, Supabase, Apollo, AI Ark, Findymail, Nooks, Slack, GitHub and Notion, plus an internal MCP for campaign analytics.
With them, one person can run work that spans several systems from a single Claude session, and the research skill can pass an approved prospect straight into the next step.
Complete flow of a GTM Campaign
Here's how the four layers work together on one campaign. A B2B software company hires us to book qualified meetings with operations leaders at mid-market logistics companies.
1. An operator defines the campaign
A senior operator works with the client on the decisions:
Target logistics companies with 200 to 2,000 employees
Focus on operations and supply-chain leaders
Prioritize companies expanding into new regions
Position the product around reducing manual coordination
Exclude existing customers
Each of these is a judgement call, so a person makes it. Once made, they become instructions for the rest of the system.
2. AI researches and qualifies accounts
The research skill pulls accounts from Apollo, AI Ark, Ocean.io, DiscoLike and custom Apify scrapers, dedupes them across sources and sorts them into tiers. It then loads the Company OS rules and client context, checks each account against the criteria, and records its reasoning with each classification, for example:
Qualified: in the target industry, within the employee range, expanding into two new regions and hiring operations managers.
Needs review: matches the firmographic criteria, but its business model makes the offer's relevance unclear.
The first account moves on. The second goes to the operator, who only reviews accounts the system can't classify with confidence.
3. AI finds the right people and a reason to contact them
For each qualified account, the system finds contacts that match the persona, verifies their roles and enriches their records. A VP of Operations owns the problem at one company; at another it's a regional operations director. Unclear roles go to a person.
It then looks for a reason the message is relevant now, like a new distribution centre or a jump in operations hiring, and records the source. If it can't find a supported signal, it doesn't make one up. It falls back to an approved account-level angle or flags the prospect.
4. AI drafts and checks the message
With the research, signal and positioning in hand, the copywriting skill adapts one master copy doc for each segment. That's about 80% of the work. A GTM engineer then QAs and edits the output, which is the other 20%. Before a draft reaches them, the skill checks:
Is every personalized claim backed by the research?
Does it use an approved angle?
Does it match the client's voice?
Does it avoid prohibited claims?
Does it meet the length rules?
A draft that fails gets revised or escalated.
5. The execution layer launches it
Our launch skill checks the list, the copy, the sending accounts and the sequence logic, then uploads and configures everything in Instantly and HeyReach. Approved prospects go into the right campaign, the CRM updates, and the research and message are stored with the record. Nobody copies data between spreadsheets.
When replies come in, unsubscribes, out-of-office replies, referrals and wrong-person replies follow set processes. A prospect asking a technical question, asking about pricing, objecting to the positioning or describing a use case nobody expected goes to a person.
That's where the operator's time goes now, instead of into research and data entry.
6. Results feed the next campaign
A weekly analysis workflow pulls the replies, enriches everyone who replied, and reports which segments, signals, titles and messaging angles the copy is landing with. When one copy variable beats the others, it suggests applying that change across the client's other campaigns. The findings also go back into the client repo.
If expansion signals beat hiring signals for this client, the next campaign ranks accounts that way from day one.
The client bought an outbound service and got one. What changed is who does the work: software handles most of the execution, and people own the decisions and the client relationship.
Conclusion
Everything in this playbook comes down to one question: who owns the work? If the customer operates your software and stays responsible for the result, you're selling a tool, and you're competing for the smaller budget. If you take responsibility for the result and use software to produce it, you're competing for the money companies already spend on people.
Services companies are closer to this model than most software companies. They already own the client relationship and the outcome, and their customers already buy the work from outside. What they're missing is the delivery system: a Company OS, client context, skills and the connections that let software act in other tools. That can be built one workflow at a time, starting with the repetitive work your team does every week.
Better models will keep moving the line between intelligence and judgement. Each time they do, a company that sells the work gets cheaper to run, while a company that sells the tool has to defend its product again.
