Service as Software (SaS) is a new software delivery model in which AI agents autonomously execute business processes and billing is based on the outcomes they produce.

Whereas traditional SaaS operated on a model of "providing tools for humans to use," SaS represents a shift to a model in which "AI performs the work itself." This change is fundamentally challenging the way pricing strategy, procurement decisions, and business process design are approached in the B2B space.

This article provides a systematic explanation covering the essential differences between SaaS and SaS, the market shifts accelerating the transition, risk management during adoption, and the selection criteria best suited to your organization. It is intended to offer practical decision-making frameworks for business leaders and IT professionals involved in software procurement and business process automation.

Service as Software (SaS) is a new software delivery model in which AI agents autonomously execute business processes and billing is based on the outcomes they produce. Whereas traditional SaaS sells "access rights to a tool," SaS is fundamentally different in that it delivers "the execution of work itself."

Against the backdrop of rapid advances in generative AI and LLMs, the ability to handle complex judgment and execution tasks—beyond simple task substitution—has driven a surge of interest in this model. In the next section, we take a closer look at the definition of SaS and its specific differences from SaaS.

Service as Software (SaS) refers to a model in which AI agents autonomously operate software and execute business processes themselves on behalf of humans.

The key difference from traditional SaaS (Software as a Service) lies in "whether a tool is being provided, or an outcome."

• SaaS: Sells access rights to software on a monthly or annual basis. Users operate it themselves to extract value.
• SaS: AI agents autonomously execute business tasks, and billing is based on the completed outcomes.

Invoice processing serves as a useful concrete example. With SaaS, you purchase a "license for accounting software" and a staff member handles data entry and verification. With SaS, the AI agent handles everything end-to-end—from data extraction to journal entry and approval routing—at a rate of "X yen per invoice processed."

This difference is directly reflected in the pricing structure.

• SaaS: Flat-rate billing tied to resource consumption, such as number of seats or storage volume
• SaS: Outcome-based billing tied to metrics such as number of tasks completed, hours saved, or process accuracy

SaS is often compared to BPO (Business Process Outsourcing), but because SaS is executed by AI agents rather than human workers, cost increases tend to be more contained when scaling up. In addition, because agent operation logs accumulate over time, business process visibility can be expected from an AI observability standpoint.

That said, SaS is still a developing model, and its definition and scope vary by vendor. When considering adoption, it is essential to review official documentation and contractual terms carefully.

The rapid rise of interest in SaS is driven by the convergence of several structural shifts.

Technological Maturity

The reasoning accuracy of LLMs (large language models) has improved to the point where AI agents are approaching the level at which they can autonomously execute complex tasks that previously required human judgment. With the practical application of multi-step reasoning and agent orchestration, the role of AI is shifting from mere "assistance" to "delegation."

Shifts in Cost Structure

Traditional SaaS has primarily operated on monthly flat-rate billing based on the number of seats. However, as AI agents begin to take on portions of business operations, the premise of "licenses for human users" starts to break down. Billing models tied to outcomes or processing volume are increasingly rational for both adopting companies and service providers alike.

Competition with BPO

AI agents are emerging as an alternative in the domains of BPO (Business Process Outsourcing) and offshore development, which have long been used as cost-reduction measures. There are reports that SaS-type services are beginning to gain a competitive edge particularly in routine tasks such as data entry, document processing, and first-line response handling.

Key reasons for the growing interest:

• AI agents' autonomous execution capabilities are approaching practical, production-ready levels
• Outcome-based billing models make it easier for adopting companies to visualize ROI (return on investment)
• Demand for "human substitution" is growing against a backdrop of labor shortages
• Existing SaaS vendors are accelerating their efforts to integrate agent capabilities

The next section takes a deeper look at three specific changes that are accelerating this transition.

The shift from SaaS to SaS is not merely a change in pricing model. Three structural shifts—technological, economic, and in the labor market—are converging to make the transition irreversible. The following sections examine each of these changes in turn.

The autonomous execution capabilities of AI agents have reached a qualitative turning point over the past few years. They have evolved from simple question-and-answer interactions to completing entire business workflows by coordinating multiple tools. This shift is the single greatest factor that has made the transition from SaaS to SaS a realistic option.

Key Technological Advances Supporting Capability Improvements

• Expanded context windows: LLMs can now retain and process significantly more information at once, enabling them to execute long business workflows without interruption
• Improved accuracy in multi-step reasoning: The emergence of reasoning models has made it possible to arrive at accurate results through step-by-step thinking, even for tasks requiring complex judgment
• Tool calling and external integration: Standardization through protocols such as MCP (Model Context Protocol) has created an environment where AI agents can seamlessly operate ERPs and external APIs
• Agent orchestration: The proliferation of multi-agent systems has enabled multiple specialized agents to divide labor and collaborate in handling large-scale operations

The combination of these advances has led to reported cases where a series of accounting tasks—such as "invoice receipt → content verification → ERP registration → payment approval request"—are completed without any human intervention.

What is significant is that agents are moving beyond the stage of "acting on instructions" and are increasingly capable of Outside the Loop operation, where they autonomously design and execute procedures given a goal. This makes software itself the primary driver of outcomes, establishing the economic rationale for SaS as a business model.

Traditional SaaS has been dominated by the "seat license" model. While paying a fixed monthly fee based on the number of users makes it easy to forecast deployment budgets, this approach has long carried the drawback that costs are not tied to actual usage frequency or outcomes.

In the SaS era, this billing structure changes fundamentally. The primary billing models can be organized into the following three categories:

• Usage-based: Billing based on the number of tokens processed, API calls made, or tasks executed
• Outcome-based: Billing tied to business outcomes such as the number of tickets resolved or deals closed
• Hybrid: A combination of a base fee (minimum guarantee) plus outcome-linked upside

Driving this shift is the fact that an AI agent's "unit of work" is easy to quantify. While human working hours are difficult to make visible, the number of tasks an agent has processed and its resolution rate can be retrieved directly from logs. This makes it easier for vendors to demonstrate results and for customers to calculate return on investment (AI ROI).

One important caveat: in outcome-based models, the definition of "outcome" becomes the core of the contract.

• What constitutes a "resolution"?
• How is billing handled when a human re-intervenes?
• Who holds the rights to the data used for measuring outcomes?

Leaving these questions ambiguous at the time of contracting creates a risk that cost projections will break down in later stages. Documenting KPIs and data collection methods in writing before deployment is a prerequisite for sound cost management.

Under traditional business models, an increase in workload required a proportional increase in headcount. However, the spread of generative AI and AI agents is fundamentally undermining this assumption.

Looking back at the cost structures of the past, they were characterized by the following:

• Personnel costs weighed heavily as fixed costs, making it difficult to respond flexibly to fluctuations in workload
• Software licensing costs were relatively small compared to personnel costs and played a supplementary role
• Scaling up required recruitment and training costs and time, placing limits on speed

This structure is beginning to reverse. AI agents scale with processing volume without requiring additional headcount. Because they operate continuously through nights and weekends, the cost of achieving the same output tends to decrease significantly.

The areas most significantly affected are routine tasks in BPO (Business Process Outsourcing) that have relied on manual labor. In domains such as data entry, invoice processing, and first-line customer support, there are reported cases where replacing these tasks with AI agents has altered cost structures.

At the same time, the nature of software costs is also changing. In SaS-type outcome-based models, costs are incurred based on the number of items processed or outcomes achieved. While initial investment is kept low, billing increases as workload grows, so it is important to note that it cannot simply be said that costs will decrease.

What matters is a comparison of total costs. It is necessary to calculate the full picture—including personnel costs, management costs, and error-handling costs—and make a judgment about the economic rationale for adopting SaS on that basis.

While the adoption of Service as Software brings clear benefits such as improved cost structures and greater operational efficiency, it is equally essential to prepare for new risks. Given the nature of outcome-based billing models, gaps between expectations and reality can easily arise, and upfront design is what determines success or failure. The following H3 sections will each outline the specific benefits and the key points to be mindful of during implementation.

The benefits that companies adopting SaS are most likely to experience can be broadly organized into the following three points.

① Costs are tied to "outcomes," reducing unnecessary fixed expenses

Traditional SaaS tends to generate fixed monthly costs based on the number of users or features, making it easy to end up paying for functionality that is not being fully utilized. In SaS, usage-based and outcome-based billing tied to the number of items processed or outcomes achieved becomes the norm, making it easier for costs to move in line with fluctuations in workload. In industries with large seasonal variation, improvements in cost efficiency have been particularly reported.

② Compensating for labor shortages and improving operational throughput

Because AI agents handle autonomous execution, organizations can build a structure that is less susceptible to the impact of hiring difficulties and rising personnel costs. By delegating repetitive tasks—such as data entry, document verification, and first-line inquiry handling—to agents, it becomes easier to concentrate human talent on higher-value judgment work. Depending on the design of HITL (Human-in-the-Loop), it is possible to increase throughput while maintaining quality.

③ Faster cycles of operational improvement

In SaS, the provider continuously improves models and updates automation logic, creating a structure in which performance improves without the adopting organization needing to undertake large-scale version upgrade efforts. When combined with Process Mining, it becomes possible to visualize bottlenecks and accumulate incremental improvements.

These three benefits are mutually reinforcing. However, it is worth noting that none of them can be realized without proper operational design and a well-structured operating model in place—a point that will be examined in detail in the next section.

While SaS adoption brings the benefits of cost reduction and automation, there are also risks that are easy to overlook. Understanding these risks in advance and taking countermeasures is a prerequisite for stable operation.

Key Risks and Countermeasures

• Difficulty in ensuring quality and accuracy In outcome-based billing models, if the definition of "outcomes" remains vague at the time of contracting, gaps between expectations and reality are likely to arise. It is important to agree on KPIs (e.g., number of processed items, error rate, approval rate) in numerical terms before signing the contract.

• Lack of accountability due to black-boxing Because AI agents execute tasks autonomously, the basis for their decisions can be difficult to see. It is advisable to leverage AI Observability tools and establish a system for recording and auditing processing logs and decision histories.

• Data dependency and privacy risks Due to the structure in which data is handed over to SaS providers, there are risks of information leakage and use beyond the intended purpose. Clarify the scope of data use, storage location, and deletion policies in the contract, and supplement these with technical controls such as Zero Trust Network Access (ZTNA).

• Deepening vendor lock-in When business processes become dependent on a SaS provider's agents, the cost of switching tends to be higher than with conventional SaaS. It is advisable to verify API specifications and data export requirements in advance and design an exit strategy.

• Omission of HITL (Human-in-the-Loop) design In the rush to achieve full automation, human review processes are sometimes eliminated. HITL must always be incorporated into high-risk decisions (such as contract approvals and credit assessments), and rollback flows for error cases should also be defined.

In the early stages of adoption, it is practical to operate at a PoC (Proof of Concept) scale and first identify areas where risks are likely to surface.

SaaS and SaS are not a matter of which is superior — they should be used selectively based on the nature of the work and the goals at hand. Making the wrong choice carries the risk of increased costs and degraded quality. This section organizes the approach to selection based on operational characteristics, as well as specific checkpoints for determining whether adoption is appropriate.

Whether to choose SaaS or SaS depends on the "nature of the work." It becomes easier to decide when framed around the axis of whether a human is the one wielding the tool, or whether an AI agent is the one delivering the outcome.

Work suited to SaaS

• Work that requires human judgment and creativity (strategy planning, customer negotiations, etc.)
• Work with established, standardized operational flows where users take an active role
• Work where compliance requirements legally mandate a human approval step

Work suited to SaS

• Recurring routine processing (invoice reconciliation, data entry, report generation, etc.)
• Work involving cross-cutting processing of large volumes of documents or unstructured data
• Review and classification tasks where decision criteria can be formalized into rules or quantified

Taking the accounting department as an example, a SaaS-based workflow where humans handle the final approval of the monthly closing is appropriate. On the other hand, tasks such as matching journal entry data and performing OCR processing and classification of receipts have high affinity with SaS-type services in which AI agents execute autonomously.

Routine tasks that were previously outsourced through BPO (Business Process Outsourcing) tend to be the strongest candidates for migration to SaS. This is because the cost structure shifts from "labor costs + management fees" to "number of outcomes × unit price," making it possible to simultaneously pursue variable cost conversion and quality stabilization.

However, simply dividing work into two categories is insufficient — a hybrid configuration is also a realistic option. An On the Loop model, in which AI agents handle preprocessing while humans review only exceptional cases, can leverage the advantages of both SaaS and SaS. It is important to take a bird's-eye view of the entire business flow and design which approach to apply at each step.

When considering SaS adoption, working through the following checkpoints in order tends to improve the accuracy of investment decisions.

Assess the degree to which the work is standardized

• Is the business flow documented, and are the decision criteria clear?
• Does the proportion of exception handling account for less than 20% of the total?
• Can success metrics (KPIs) be defined numerically?

The more fully a task satisfies all of the above, the lower the migration cost to AI agents tends to be. Conversely, for tasks with many exceptions, it is advisable to first use process mining to visualize the current state before making a decision.

Estimate the cost structure

Compare the combined current costs of labor and licensing fees against the outcome-based billing costs of SaS. While outcome-based billing models tend to offer greater cost advantages for tasks with large fluctuations in volume, there are also cases where fixed-cost SaaS is more economical for tasks with stable processing volumes. As a reference at the time of writing, check the latest unit prices on each vendor's pricing page.

Evaluate data and security readiness

• Has the data required for training and inference been organized and cleansed?
• Are policies for handling personal information and confidential data in place?
• Can a monitoring framework using HITL (Human-in-the-Loop) be established?

Particularly in the financial, medical, and legal sectors, human review flows for AI agent decisions may be mandatory under regulations.

Determine the appropriate PoC (Proof of Concept) scale

Rather than rolling out company-wide all at once, it is important to start small with a single task and a single team. Set a pilot period of approximately three months as a guideline, and use the achievement rate of success metrics to determine whether to proceed with full-scale adoption.

When adopting SaS, the risk of failure increases if an attempt is made to replace all operations at once. The starting point is to visualize the current business flow and identify the areas where AI agents are likely to be most effective. From there, a phased rollout approach — verifying outcomes through small-scale pilots before expanding — is considered effective for confirming ROI while minimizing disruption on the ground.

To successfully implement SaS, the starting point is accurately understanding the current state of your own business operations. Blindly deploying AI agents makes it difficult to expect a favorable cost-benefit ratio.

3 Points to Confirm in Current-State Analysis

• Frequency of task repetition: Does it occur at high frequency, such as monthly, weekly, or daily?
• Clarity of rules: Are decision criteria documented, with few exceptions?
• Data readiness: Does structured data or historical logs exist that AI can reference?

Tasks that satisfy these three criteria tend to benefit more readily from automation through SaS adoption.

Criteria for Selecting Pilot Tasks

The standard approach for an initial pilot is to choose tasks that are "easy to succeed at, and where failure has limited impact."

• Internal-facing tasks (with little direct impact on external customers)
• Tasks where processing volume is measurable and effect evaluation is straightforward
• Tasks where API integration with existing SaaS tools is possible

For example, first-tier routing of internal inquiries and automated generation of standardized reports are frequently cited as tasks well-suited for pilots.

Leveraging Process Mining

Using Process Mining tools, you can visualize processes with high automation potential directly from actual operational logs. Because pilot candidates can be narrowed down based on data rather than intuition, the accuracy of decision-making improves.

Considering whether HITL (Human-in-the-Loop) is necessary during the current-state analysis phase allows you to design the subsequent transition phase more smoothly.

Once results have been confirmed in the pilot, the standard approach is not to rush the transition all at once, but to expand gradually in stages. Taking into account the organization's level of maturity and the complexity of system integrations, dividing the process into phases distributes risk.

Guidelines for Transition Phases

• Phase 1 (Validation): Promote the pilot task to the production environment. Maintain operations where AI agents and HITL (Human-in-the-Loop) are used in tandem, with humans reviewing outputs.
• Phase 2 (Expansion): Roll out horizontally to adjacent business processes. Confirm that KPIs such as error rates and processing speed are stable before moving on to the next task.
• Phase 3 (Optimization): Increase the ratio of autonomous execution and transition human involvement to On the Loop. Refine exception-handling rules.

Conducting effect measurement at each phase is essential for improving the accuracy of investment decisions.

Key Metrics to Measure

• Processing cost: How has the per-unit processing cost changed compared to the SaaS era?
• Throughput: Increase or decrease in the number of items processed per unit of time
• Error rate / rejection rate: Quantifying the output quality of AI agents
• AI ROI (AI Return on Investment): Calculating how much operational reduction has been achieved relative to implementation costs

Measurement results should be dashboarded using AI observability tools and shared in a form that is visible to management as well. As data accumulates, the accuracy improvement cycle of agents accelerates, and the Agentic Flywheel begins to turn.

Even after the transition is complete, do not neglect periodic reviews. Establishing a system for continuously updating agent designs in response to changes in business requirements and new model releases will lead to long-term results.

Q1. What is the biggest difference between SaS and SaaS?

The biggest difference is "what you pay for." With SaaS, you are billed on a monthly or annual basis for access rights to the software. With SaS, on the other hand, you are billed based on the number of tasks actually completed or the outcomes achieved by AI agents. Think of it less as purchasing the right to use a tool, and more as purchasing the execution results of business operations themselves.

Q2. Will all existing SaaS tools be replaced by SaS?

Not everything will be replaced. Tasks with clear rules and high repetitiveness—such as data entry, report generation, and inquiry handling—tend to have high affinity with SaS. On the other hand, for tasks requiring advanced human judgment or creativity, or domains where strict compliance management is necessary, using SaaS and SaS in combination remains the realistic approach for the foreseeable future.

Q3. Can the outcome-based billing model be utilized by small and medium-sized enterprises?

There are a growing number of cases where it can be utilized. The ability to keep initial costs low tends to be an advantage for small and medium-sized enterprises. However, if the definition of "outcomes" and the method of measurement are not clearly established before signing a contract, there is a risk that billing amounts become difficult to predict. It is recommended to start with a small-scale pilot for a single task.

Q4. Does SaS adoption increase security risks?

As the scope of AI agents accessing internal systems expands, the importance of access rights management and log auditing increases. It is effective to incorporate the concept of Zero Trust Network Access (ZTNA) and design systems so that the permissions granted to agents are limited to the minimum necessary. Before implementation, be sure to verify the vendor's security policy and the data handling terms in the contract.

Service as Software (SaS) is a new software delivery model in which AI agents autonomously execute business operations and billing is based on outcomes achieved.

If traditional SaaS represents a model of "providing tools," then SaS signifies a shift to a model of "providing outcomes." Because the cost structure, operational design, and criteria for vendor selection change fundamentally, there is significant value in developing an early understanding of this model.

When considering adoption, use the following three points as a starting point:

• Begin with small-scale PoC (Proof of Concept) efforts, starting with highly repetitive tasks
• Define outcome metrics (KPIs) in advance and establish a framework for measuring effectiveness
• Proceed in parallel with designing AI governance and HITL (Human-in-the-Loop)

SaS is not a silver bullet, but when applied to the right tasks, it has the potential to simultaneously reduce labor costs and stabilize quality. Taking stock of your organization's operational characteristics and strategically designing how to differentiate between SaaS and SaS will likely lead to competitive advantage in the age of AI.