SFTechScene | October 2026 | San Francisco AI Startups, Agentic AI, SaaS Pricing, and Business Automation

The software industry has spent decades selling businesses access to tools. Companies pay for employees to use customer support platforms, sales systems, marketing software, accounting tools, and project management applications. The more people who need access, the more software seats a company often buys.

Artificial intelligence is starting to challenge that business model.

Imagine a San Francisco startup that handles 10,000 customer support requests every month. Under a traditional software subscription, the company might pay for 20 support agents to access a help desk. The software vendor gets paid whether those employees solve 2,000 problems or 8,000.

Now imagine an AI agent that can answer customer questions, change subscriptions, check orders, and process simple account requests without human help. The business no longer cares as much about how many people can log into the software. It wants to know how many customer problems the AI can actually solve.

That creates a different pricing question: Why pay for access to software when you can pay for the work the software completes?

San Francisco’s AI industry is helping turn that question into a real business model. Companies such as Sierra, Intercom, and Decagon are developing different ways to connect software bills to customer conversations, completed work, and successful results.

The shift has major implications for AI startups, established software companies, investors, and businesses buying automation. It could change how software companies earn revenue, how AI agents are designed, and how buyers calculate the value of automation.

But there is a catch. Charging for outcomes sounds fair until buyers and sellers must agree on what an outcome actually means.

A customer who stops responding is not always satisfied. A lead booked for a sales meeting may never buy anything. An AI agent might close a support ticket only for the customer to reopen it two days later.

The companies that solve these problems could build stronger businesses than those simply attaching a price to every AI-generated answer.

This article examines the economics behind outcome-based pricing, what real AI companies are charging, where the model makes sense, and where it can fail. It also includes original SFTechScene financial models using public pricing data, San Francisco-area wage statistics, and explicitly stated operating assumptions.

The Short Version: AI Startups Are Moving From Selling Software Access to Selling Completed Work

Outcome-based pricing means a customer pays when software delivers a defined, measurable result. Instead of paying only for accounts, licenses, or technical usage, the customer pays for something the business considers valuable.

For customer support, that result might be a successfully resolved issue. For sales, it could be a qualified lead that meets agreed conditions. For accounting, it might be a completed and verified invoice reconciliation.

The model becomes particularly interesting when AI agents can perform meaningful work independently.

A traditional software platform helps an employee complete a task. An autonomous agent may complete the task itself. Those are different products, even when they operate inside the same business system.

Several developments show why this matters.

Intercom’s Fin publicly lists a price of $0.99 for a standard resolution outcome, while some lead qualification outcomes cost $9.99. Sierra describes its commercial approach as outcome-based pricing, while Decagon offers both conversation-based and resolution-based pricing.

Meanwhile, Salesforce offers Agentforce pricing by conversation, action credits, and user access. Zendesk combines conventional seat pricing with charges for automated resolutions. These are not identical models, but together they show software companies testing alternatives to selling seats alone.

Intercom Help

The economic opportunity is easy to understand. Businesses want to pay for useful results, and AI vendors want to earn more when their products deliver greater value.

However, outcome-based pricing does not guarantee lower costs. A company with weak automation, poorly written contracts, or large volumes of low-value tasks could actually spend more.

The strongest approach is to begin with one measurable workflow, calculate its real business value, define what qualifies for payment, and expand only after the numbers make sense.

Why the Traditional Software Seat Is Becoming a Weak Measure of AI Value

The old SaaS model worked because employees operated the software

Traditional software-as-a-service pricing grew around a simple relationship between users and business value.

A company with 10 sales representatives might need 10 CRM licenses. A company with 50 support employees might need 50 help desk accounts. As teams grew, software spending increased because more people used the tools.

The arrangement was not perfect, but it was easy to understand. Buyers could estimate costs from headcount, and vendors could forecast revenue from subscription contracts.

It also helped vendors pay for support, updates, infrastructure, and product development through recurring revenue.

The model begins to lose its connection to value when AI agents perform work that previously required those employees.

AI agents break the relationship between people and productivity

Consider two companies using the same customer support platform.

Company A employs 20 representatives who answer questions manually. Company B employs eight representatives and uses AI to resolve many routine requests.

Under a seat-based pricing model, Company B may pay less for software despite processing the same number of customer requests.

For the buyer, that reduction is an advantage. For the software vendor, it creates a problem. The vendor’s product may be performing more work while traditional license revenue declines.

A different pricing model can solve this mismatch by linking revenue to the amount of work completed.

If an AI agent resolves 4,000 support requests, the vendor can charge for those results rather than depending entirely on the number of employees remaining in the support department.

This does not mean every business will reduce headcount. Some will keep the same teams and use the available time to improve service, handle difficult issues, or support more customers. The key change is that employee count becomes a less reliable measure of software value.

Seat-based pricing can discourage automation

Suppose a software vendor makes most of its money from individual user licenses.

If its AI product allows one employee to perform work that previously required five people, successful automation could reduce the number of licenses purchased. The company has to find a way to charge for the additional value created by its AI rather than losing revenue as the customer becomes more efficient.

Outcome-based pricing offers one possible answer.

The vendor can earn more by improving the number of verified tasks completed. The customer can judge the investment against those completed tasks rather than relying on general claims about productivity.

That alignment sounds attractive, but it depends heavily on the definition of success.

Understanding the Five Main AI Software Pricing Models

One common mistake is treating every type of usage-based billing as outcome-based pricing. In reality, they measure different things.

Pricing model	Customer pays for	Example	Main weakness
Seat-based	People with access	$100 per user/month	Weak link to completed work
Subscription	Continued software access	$2,000/month	May not reflect usage or results
Usage-based	Technical activity	Tokens, API calls, actions	Activity can happen without value
Outcome-based	Verified business result	Successful support resolution	Success can be disputed
Hybrid	Base fee plus variable charges	Platform fee and completed tasks	More complex invoices

Seat-based pricing sells access

The customer pays based on the number of users or employees allowed to use a product.

This works well when software is primarily a tool operated by humans. It offers predictable bills and makes annual budgets relatively easy to prepare.

Its weakness becomes clearer when automated agents perform work across many departments without needing separate human licenses.

Usage-based pricing sells activity

Usage-based pricing charges for the resources or activities a customer consumes.

A business might pay for API calls, messages, tokens, transactions, workflow executions, or compute time.

This gives buyers more flexibility than a fixed subscription, but the company can still pay for work that fails.

An AI agent might make 12 API calls while attempting to solve a customer problem. If it ultimately fails, the provider charging for API usage still receives payment.

Outcome-based pricing sells a result

Outcome pricing moves the billing event closer to the buyer’s business goal.

If a contract defines success as resolving a customer issue without escalation, the vendor may receive payment only when that condition is satisfied.

That creates a stronger incentive to improve the agent’s reliability. Failed attempts can still cost the vendor money, but they may produce no billable revenue.

Importantly, outcome-based pricing does not automatically mean the vendor guarantees profit, customer satisfaction, or long-term financial gains. It means the buyer and seller agree on a specific result that triggers payment.

Hybrid pricing balances risk

Many companies will find that a combination of fixed and variable charges works better than a purely outcome-based contract.

A vendor may charge a platform fee to cover security, integrations, and ongoing support, followed by charges for verified outcomes.

This provides predictable revenue for the vendor while connecting part of the bill to results.

For buyers, the main advantage is that the contract can separate basic software access from the actual work performed.

The critical question is whether the combined bill remains attractive after all fees are included.

San Francisco AI Companies Are Already Testing New Pricing Models

San Francisco is an important market for this change because the region combines AI developers, enterprise software companies, venture capital, and business customers willing to test new automation tools.

The strongest evidence comes from companies that have already published their commercial models. Their approaches provide a useful picture of how AI pricing is evolving.

Sierra: Making successful outcomes central to the business

Sierra builds conversational AI agents for businesses. These agents can help customers with service requests and tasks that require access to company systems.

ringg.ai

Sierra publicly describes outcome-based pricing as part of its business model. Rather than treating a conversation or message as the central source of value, it emphasizes the specific business result delivered.

The company’s explanation highlights an important change in the relationship between vendors and customers. If customers pay when useful outcomes occur, the vendor has a financial reason to keep improving how well its AI agents complete work.

This changes the job of the AI provider. The company cannot simply deploy the software and assume the contract will generate value. It needs to maintain integrations, improve answers, monitor failures, and help the agent handle increasingly complex tasks.

Sierra

There is a broader lesson for founders here. An outcome-based AI startup is not simply a software seller. It is partly responsible for operating the workflow that generates its revenue.

That makes software reliability, customer training, and ongoing improvement central to the business model.

Intercom: Turning a resolved conversation into a billable unit

San Francisco-based Intercom offers one of the clearest public examples through Fin.

Fin’s published pricing includes several defined outcome categories, and the fees are not all the same. Its standard resolution outcome costs $0.99, while a qualifying sales lead can cost $9.99 under the listed qualification category.

fin.ai

Fin outcome category	Published price
Customer support resolution	$0.99
Procedure handoff	$0.99
Prospect disqualification	$0.99
Self-service routing	$0.99
Qualified prospect routing	$9.99

Source: Intercom’s published Fin outcome definitions, checked October 2026. These categories have specific contractual meanings, and minimum commitments or other plan costs may apply.

Intercom Help

This pricing structure reveals something important: not all AI outcomes are equally valuable.

Answering a routine product question may save a business a few minutes of support work. Finding a prospect that meets an agreed sales qualification standard may create a more valuable commercial opportunity.

That does not mean a $9.99 lead automatically generates more profit than a $0.99 resolution. The lead could fail to become a customer, and the support resolution could prevent an expensive escalation.

It does show why startups may eventually create separate prices for different types of work instead of treating every task as equal.

Intercom also uses a rule limiting charges to one outcome per conversation, even when Fin takes multiple actions. That rule matters because it reduces the risk of charging repeatedly for the same customer issue.

Stripe’s case study of Fin reports that its outcome-based billing system has supported substantial commercial scale. This is evidence that the model can operate beyond a small pilot, although the reported commercial performance should not be treated as proof that every buyer achieves positive ROI.

Intercom Help

Decagon: Why some customers prefer paying per conversation

Decagon offers a useful counterpoint.

The company publicly describes two pricing approaches: a fixed charge per incoming conversation and a charge per fully resolved conversation. Under the resolution model it describes, escalated conversations are not charged as completed resolutions.

However, Decagon has also said that most of its customers in the period discussed in its pricing article favored conversation-based pricing.

Why would buyers prefer paying for conversations when outcomes appear more attractive?

The answer is predictability.

A conversation is relatively easy to count. A successful resolution may require several judgments about the customer’s intent, the AI’s actions, and whether the problem was truly solved.

Decagon highlights the difficulty of determining whether a silent customer represents a success and whether a simple answer deserves the same price as a complex fix.

Decagon

This is a warning for founders. Buyers do not automatically prefer the most sophisticated pricing formula. They may choose a simpler model if it makes invoices easier to understand and reduces arguments over billing.

Salesforce and Zendesk: Large software companies are moving toward mixed models

Outcome pricing is not limited to newer AI startups.

Salesforce lists multiple Agentforce charging methods. These include conversation pricing, Flex Credits tied to agent actions, and user-based access options.

For example, its published list pricing includes $2 per conversation and $500 for 100,000 Flex Credits. Standard agent actions consume 20 credits each under the listed rate card, implying $0.10 for one such action at that credit price. A completed customer workflow may require several actions, so one action must not be mistaken for one resolved customer request.

Salesforce

Zendesk also combines traditional user licenses with automated-resolution billing.

Zendesk’s public pricing lists $1.50 per committed automated resolution and $2 for certain pay-as-you-go resolutions. It also provides included allowances and uses tiers or other arrangements depending on the account and plan.

That makes it a hybrid system rather than a complete replacement for traditional SaaS subscriptions.

Starting from $19/month

Original SFTechScene Research #1: What Public AI Pricing Actually Measures in 2026

For this analysis, SFTechScene reviewed the publicly documented commercial models of five relevant enterprise AI offerings: Sierra, Intercom Fin, Decagon, Salesforce Agentforce, and Zendesk AI agents.

The purpose was not to estimate market share or rank the companies by price. Their products, contracts, and billing units are too different for a fair direct price comparison.

Instead, we classified each vendor by the event that can trigger an AI-related charge.

Research methodology

We used company-published product descriptions, pricing pages, and documentation available by October 21, 2026.

A pricing category was included only when the vendor explicitly described it as an offered model. We classified charges as seat-based, activity-based, conversation-based, or outcome-based.

We also recorded whether the public material showed more than one model. Private enterprise discounts, custom agreements, and unpublished contract terms were excluded.

The results describe the five selected offerings only. They are not a random sample of San Francisco AI startups, and the findings should not be projected onto the entire market.

What the pricing documents reveal

Provider	Publicly described AI billing approach	Outcome link	Important qualification
Sierra	Outcome-based	Direct	Public per-outcome rates are not standardized
Intercom Fin	Defined billable outcomes	Direct	Different outcomes can have different prices
Decagon	Per conversation or per resolution	Optional	Customer can favor predictable conversation pricing
Salesforce Agentforce	Actions, conversations, user access	Mostly indirect	An action is not necessarily a completed task
Zendesk AI agents	Automated resolutions with seat plans	Direct for AI resolutions	Platform and other costs may remain

Source: SFTechScene classification of public vendor documentation. “Direct” means a charge is tied to a defined result rather than merely technical activity.

Sierra

Pricing mechanisms found in the five-company sample

Number of selected offerings publicly documenting each billing approach. Categories overlap; not market shares.

These categories overlap. The chart counts disclosed billing mechanisms associated with the selected AI offerings, not the number of customers using each mechanism. Zendesk’s general help desk seats are treated separately from its AI-resolution unit.

Original Finding #1: Outcome pricing is becoming a serious option, but not a universal standard

Four of the five selected offerings publicly describe a way to connect charges to a defined result. That shows how prominent outcome-linked billing has become among these particular vendors.

However, the same documents show why claiming that software seats are disappearing would be premature.

Salesforce continues to offer multiple charging methods. Zendesk retains seat-based platform plans. Decagon provides a conversation-based option because some customers prefer it.

The stronger conclusion is that enterprise AI pricing is becoming more flexible because different types of automation need different measures of value.

Original Finding #2: The billing unit can matter more than the headline price

A customer comparing $0.99 per resolution with $2 per conversation might assume the first option is cheaper.

That would be a mistake without knowing how many conversations are actually resolved.

If a business receives 10,000 conversations and an agent resolves 40%, a $0.99 outcome fee would produce $3,960 in outcome charges. A $2 per-conversation fee across all 10,000 conversations would produce $20,000.

However, these figures exclude any platform fees, contract minimums, quality differences, or included allowances. They also assume that the two offerings can perform the same work.

The correct comparison is not simply price per advertised unit. It is the full cost of delivering an equivalent set of verified business results.

Why San Francisco Is an Important Market for Outcome-Based AI Pricing

The region combines expensive professional work with advanced automation

The San Francisco-Oakland-Fremont metropolitan area has some of the country’s highest wages across several professional categories.

According to the U.S. Bureau of Labor Statistics, the region’s average hourly wage across occupations was $48.19 in May 2025, compared with $33.54 nationwide.

That is a difference of about 44%.

The same report recorded average hourly wages of $60.95 for business and financial operations roles and $80.51 for computer and mathematical occupations in the metro area.

Bureau of Labor Statistics

Source: BLS May 2025 Occupational Employment and Wage Statistics, published July 9, 2026. The last two bars are occupation-group averages, not the cost of a specific task.

Bureau of Labor Statistics

These wage differences do not prove that AI automation will create larger savings in San Francisco. Job complexity, supervision, legal requirements, and task quality also matter.

But higher wages can increase the potential value of recovering employee time when the work is suitable for automation.

A routine process that saves 30 minutes might have different economic value in different cities or departments. Companies must still measure whether that time can be productively redeployed or actually removed from costs.

San Francisco startups can test both sides of the market

The region contains businesses developing AI agents and businesses buying them.

That creates opportunities to test new pricing with demanding customers in software, finance, retail, and professional services.

An AI startup can begin with customer support, where tasks are relatively easy to count, then expand into billing, customer operations, or back-office processes.

But the expansion is not automatic. Completing a refund or changing a shipping address requires different permissions, tests, and success rules than answering a simple question.

For that reason, a good local strategy is to start with a workflow that has clear boundaries before attempting to automate an entire department.

Original SFTechScene Research #2: The Economics of Outcome Pricing for a San Francisco Support Team

To understand whether outcome pricing can work for buyers and vendors, SFTechScene built a transparent monthly financial model for a hypothetical San Francisco-area company.

This is an original scenario analysis, not a survey of companies or a measurement of a real deployment.

The model uses a publicly reported local customer support wage and a real, published AI outcome price. All operating assumptions are explicitly identified so readers can replace them with their own numbers.

The baseline: A business receiving 10,000 support requests each month

We assume a company handles 10,000 customer requests per month.

Some requests are simple enough for an AI agent to attempt. Others involve complex account problems, disputes, sensitive information, or situations requiring human judgment.

The model assumes 60% of incoming requests qualify for AI automation. This is a scenario input, not a measured industry-wide eligibility rate.

We assume the AI resolves 70% of eligible requests and that 95% of those apparent successes meet an independent quality standard.

These are intentionally separate tests. An agent can appear to complete a request while still delivering an incorrect or unacceptable result.

For labor value, we use $27.80 per hour, the reported May 2025 median wage for customer service representatives in the San Francisco-Oakland-Fremont metro area, corresponding to an annual median of $57,830. This value is published in a third-party presentation of BLS OEWS data.

CitySalaryData

We add an assumed 25% for employer costs, such as benefits and payroll expenses, giving $34.75 per hour.

That assumption is not an observed regional employer-cost estimate.

Full model inputs

Input	Value	Basis
Incoming requests/month	10,000	Scenario assumption
Eligible for AI	60%	Scenario assumption
Resolution rate among eligible requests	70%	Scenario assumption
Quality-valid share of apparent resolutions	95%	Scenario assumption
Human work time per avoided request	12 minutes	Scenario assumption
Productively recoverable time	80%	Scenario assumption
Local median hourly wage	$27.80	BLS-derived public data
Employer cost loading	25%	Scenario assumption
Price per accepted outcome	$0.99	Fin standard-resolution reference price
AI attempt cost	$0.18	Modeled vendor cost
Verification cost per accepted outcome	$0.08	Modeled vendor cost
Fixed monthly operating cost	$1,200	Modeled vendor cost

Research inputs: BLS-derived regional wage data and Intercom’s public reference price. Operating volumes, success rates, internal costs, and time savings are illustrative assumptions, not vendor-specific performance claims.

CitySalaryData

Calculating completed work

The first step is to identify how much of the incoming workload is suitable for automation.

\[ 10{,}000 \times 60\% = 6{,}000 \]

Under this assumption, the AI attempts 6,000 eligible cases.

Next, we apply the 70% resolution rate.

\[ 6{,}000 \times 70\% = 4{,}200 \]

The system initially reports 4,200 completed cases.

However, the model assumes that only 95% pass independent quality checks.

\[ 4{,}200 \times 95\% = 3{,}990 \]

The company therefore receives 3,990 verified outcomes.

This distinction is essential. Billing against the number of cases an AI closes is not the same as billing against the number of cases it resolves correctly.

Monthly AI workload funnel

Incoming customer requests

10,000

Eligible for automation

6,000

Initially resolved

4,200

Quality-verified outcomes

3,990

Original SFTechScene model. The funnel uses assumed eligibility, resolution, and verification rates.

What is the value of the completed work?

A verified resolution does not necessarily eliminate an entire employee task.

Some customers would have used self-service anyway. Some requests take only a minute or two. Other cases still require staff to follow up.

To avoid assuming that every automated resolution equals full labor savings, the model counts only 80% of the 12-minute handling time as productively recoverable.

That produces 638.4 hours of recoverable employee capacity:

\[ 3{,}990 \times 0.20 \times 80\% = 638.4 \]

At an assumed fully loaded labor rate of $34.75 per hour, that represents a monthly capacity value of approximately $22,184.

The AI outcome bill, using the $0.99 public reference price, would be about $3,950.

Monthly capacity value

$22,184

Modeled recoverable staff time

Monthly outcome charges

$3,950

3,990 outcomes at $0.99

Capacity value after outcome charges

$18,234

Before buyer-side implementation costs

Recoverable hours

638.4

Not equivalent to guaranteed payroll savings

The difference is meaningful, but it needs careful interpretation.

The $22,184 represents the estimated value of time that could be used productively elsewhere. It is not automatically cash savings.

If the business keeps every employee at the same salary and workload does not grow, payroll spending may remain unchanged. The company might gain faster service or additional capacity without immediately improving cash profit.

To turn capacity into financial value, management must reduce overtime, avoid planned hiring, handle additional demand, or redeploy employees toward work with measurable benefits.

Original Finding #3: Pricing below the value of avoided work creates room for both sides to win

The model produces an effective labor-capacity value of $5.56 per verified outcome.

The calculation comes from 12 minutes of handling time, 80% recoverability, and the assumed $34.75 loaded hourly rate.

At a $0.99 outcome price, the vendor receives roughly 18% of that modeled capacity value.

This creates potential economic room for both parties.

The vendor can earn revenue from automated work, while the customer may retain most of the value created. But the calculation is only favorable if the outcomes are valid and the customer’s other implementation and operating costs remain controlled.

What if the outcome price is higher?

Comparison at 3,990 verified outcomes and $22,184 in modeled recovered capacity value.

■ Monthly outcome charges

■ Capacity value after charges

Original scenario calculation. These are hypothetical prices applied to the same verified outcomes, not a like-for-like comparison of vendor contracts.

The buyer’s modeled capacity value stays constant because the workload and verified success rate have not changed.

As the outcome price rises, the vendor captures a greater share of that value.

This shows why buyers need a price ceiling based on their own cost of handling the work. A price that looks inexpensive in isolation may become unattractive when the same task can be completed internally at very low cost.

Original SFTechScene Research #3: The Hidden Risk Is on the AI Vendor’s Side

Outcome pricing shifts some risk from the buyer to the AI provider.

The buyer may pay only when work succeeds, but the vendor still spends money when an attempted task fails.

Every attempt can involve model usage, tool calls, data retrieval, monitoring, and infrastructure. The vendor must also support the system, handle errors, and verify results.

That means a vendor can be growing its AI usage without growing profitable revenue.

A modeled AI vendor cost structure

For the same 6,000 monthly eligible cases, we assume the provider spends $0.18 on each attempt.

This is a blended operating cost, not just the price of an AI model call. It is intended to cover model processing and related variable resources.

The vendor also spends an assumed $0.08 verifying each of the 3,990 accepted outcomes and incurs $1,200 in monthly fixed service costs.

The resulting monthly costs are:

Vendor expense	Calculation	Monthly cost
AI attempts	6,000 × $0.18	$1,080
Outcome verification	3,990 × $0.08	$319.20
Fixed service operations	Assumption	$1,200
Total modeled cost		$2,599.20

At $0.99 per verified outcome, the vendor receives $3,950.10 in revenue.

That leaves approximately $1,350.90 after these modeled service costs, or a contribution margin of 34.2%.

This is not the company’s net profit margin. It excludes expenses such as corporate administration, sales, research, and other costs not included in the modeled account.

It also is not a statement about Intercom, Sierra, Decagon, or any other actual vendor’s unit economics.

The same AI system can lose money when resolution rates decline

To test the model’s sensitivity, we held the number of eligible attempts, quality-validation rate, unit price, and other assumptions constant while changing the resolution rate.

Original SFTechScene sensitivity analysis. All figures use the same modeled 6,000 attempts, 95% outcome verification rate, and $0.99 outcome price.

Eligible-case resolution rate	Verified outcomes	Vendor revenue	Vendor cost	Contribution margin
40%	2,280	$2,257	$2,462	-9.1%
55%	3,135	$3,104	$2,531	18.5%
70%	3,990	$3,950	$2,599	34.2%
85%	4,845	$4,797	$2,668	44.4%

The key insight is that revenue grows with successful work, while the vendor’s attempt costs are partly driven by the total workload.

At a 40% resolution rate, the provider loses money under these assumptions. At 70%, it achieves a positive modeled contribution margin.

The AI agent has not necessarily become dramatically cheaper to operate. It has become better at converting the same incoming workload into billable results.

Original Finding #4: Reliability becomes a revenue driver, not just a product feature

In ordinary usage-based pricing, more model calls can generate more billable activity.

In pure outcome-based pricing, unnecessary calls may reduce margins because the vendor spends more without creating another billable result.

The provider therefore has a strong reason to improve task completion, reduce failed attempts, and use less expensive methods for routine jobs.

That could encourage better engineering choices.

For example, a startup might use a simple rule to retrieve an order status instead of asking an expensive general-purpose model to reason through the request. It might route complex cases to a stronger model only when necessary.

It might also improve instructions, data access, and error handling because those investments raise the chance of a successful result.

The strongest AI infrastructure companies could benefit from this pressure. As outcome pricing spreads, customers may place greater value on tools that make agents accurate and inexpensive per completed task.

Original SFTechScene Research #4: How Much Does the AI Model Itself Cost per Outcome?

The previous analysis used a blended cost assumption for each attempted case. We can go one level deeper by examining how publicly listed model prices interact with the amount of processing an AI agent performs.

This matters because AI startups often make a costly mistake: they calculate the price of one model call and assume it represents the full cost of completing a task.

A real agent may need to read instructions, search for customer information, make decisions, call tools, retry failed operations, and verify the final answer.

The total cost of useful work can be much higher than the cost of its first response.

Using published OpenAI API prices as a reference

OpenAI publicly lists GPT-5.4 mini at $0.75 per million input tokens and $4.50 per million output tokens.

For this research model, we use those published prices without assuming discounts, caching benefits, or special contractual rates.

OpenAI API

We create three possible AI workload profiles. These are hypothetical usage profiles rather than measurements of any specific product.

Scenario	Input tokens per attempt	Output tokens per attempt	Model cost per attempt
Simple task	10,000	1,000	$0.012
Medium task	50,000	5,000	$0.060
Complex task	200,000	20,000	$0.240

Each figure is calculated using the model’s input and output rates. For example, the medium task costs $0.0375 for input and $0.0225 for output.

The complex workload may involve several calls across a full task, not one unusually long response.

Original SFTechScene calculations using GPT-5.4 mini’s published standard text-token rates. Excludes external tools, retrieval, hosting, security, monitoring, and support.

Why these costs cannot be compared directly with outcome prices

The model costs above apply to attempted work, not necessarily verified results.

If an agent spends $0.24 attempting a complex task but only succeeds on half of its attempts, the model cost alone becomes $0.48 per successful task before considering other expenses.

If success falls to 25%, the effective model cost rises to $0.96 per successful task.

At that point, a business charging $0.99 per resolution would have almost no revenue left to cover the rest of its costs.

This reveals an important risk for startups selling AI agents that handle complex work.

A low advertised outcome price can look attractive to customers while becoming unsustainable for the provider if tasks require many model calls or repeated attempts.

Original Finding #5: The best AI model is not always the cheapest model

Founders often compare models by the cost of one million tokens. That is useful for estimating processing expenses, but it does not answer the full business question.

A cheaper model may require several retries or fail more often on difficult cases. A more expensive model may complete the task in fewer attempts.

To choose the most economical option, startups need to measure total cost per verified result.

A useful formula is:

\[ \text{Cost per verified result}= \frac{\text{All task-attempt and service costs}} {\text{Verified results}} \]

Suppose one model costs $0.08 per attempt and succeeds 50% of the time. Ignoring all other costs, its expected model expense is $0.16 per successful task.

Another model might cost $0.12 per attempt but succeed 90% of the time. Its expected model expense is roughly $0.133 per successful task.

The second model is more expensive per attempt but cheaper per successful result.

That is why startups should measure AI reliability and processing costs together rather than optimizing them separately.

Original SFTechScene Research #5: An Interactive Break-Even Model for AI Outcomes

The next calculation combines the buyer’s economics with the price of verified work. It allows businesses to explore how the value of recovered staff time changes with local labor costs, task duration, resolution performance, and outcome fees.

SFTechScene AI Pricing Calculator

Change the assumptions to see how the modeled economics respond. The model keeps quality validation at 95% and recoverable time at 80%.Monthly incoming requests

10,000Eligible for AI automation

60%Resolution rate on eligible cases

70%Staff minutes per avoided request

12 minutesLoaded labor cost per hour

$34.75Price per outcome

$0.99

Verified outcomes

3,990

Outcome bill

$3,950

Capacity value

$22,184

Value after outcome charges

$18,234

Reset to baselineThis is a scenario calculator, not a vendor quote or ROI forecast. It omits buyer-side integration, supervision, fixed platform fees, and any labor value that cannot be realized.

How San Francisco businesses should use this analysis

The calculator is most useful when a company has actual operating data.

A support manager can replace the default time per request with a measured average from the help desk. A finance team can use loaded employee costs from payroll records. An operations leader can estimate how much of the recovered time will genuinely be useful.

The next step is to compare the modeled value with the full contracted cost of the agent.

If the result looks attractive, that supports running a pilot. It does not justify signing an unlimited contract immediately.

The most important numbers to validate in a pilot are the share of tasks suitable for automation, the quality-verified completion rate, the real time saved, and the cost of handling failures.

Why Defining a Successful Outcome Is Harder Than It Looks

The most difficult part of outcome-based pricing is often not technical infrastructure or contract negotiation. It is deciding what counts as success.

A buyer and vendor can agree on a price of $1 per resolved request. Yet that agreement may be almost meaningless if neither side has a clear definition of a resolved request.

A closed support ticket is not always a solved problem

Suppose a customer asks an AI agent why a subscription charge increased.

The AI provides a general explanation, and the customer leaves the conversation.

The system marks the issue as resolved.

However, the customer’s real problem remains. The explanation was incorrect, and the customer contacts support again the following morning.

Was the original interaction a successful outcome?

A billing system that only checks whether the conversation closed might count it. A stronger system would consider whether the answer was correct and whether the same issue returned within a defined period.

Different vendors use different definitions. Intercom’s documented Fin categories include rules based on the result of a conversation, while Zendesk documents its own automated-resolution measurement methods and tiers.

Intercom Help

That variation is one reason buyers must read the actual contract rather than relying on the phrase “pay for results.”

A good outcome definition needs six elements

For a startup building an outcome-based product, a useful billing rule should identify the task, the completion requirement, the evidence, the verification method, the waiting period, and the exclusions.

Consider an AI agent that handles customer address changes.

The event should not be “the agent told the customer the address was updated.” It should be “the authorized account’s address was successfully changed in the system of record.”

The evidence could be a logged account update with a transaction identifier and timestamp.

The verification process should confirm that the correct account was changed and that the new address passed the company’s rules.

The contract should also explain what happens if the change is reversed, if the request is duplicated, or if the customer reports that the result is wrong.

These rules turn a vague claim into an auditable service.

The danger of paying for the wrong behavior

Pricing systems influence how businesses design products.

If an AI provider receives payment whenever a ticket closes, the system might appear more successful by closing tickets quickly rather than solving them thoroughly.

If a sales agent is rewarded only for booked meetings, it could prioritize meeting volume over prospect quality.

If a collection agent is paid only on recovered money, it might create unacceptable pressure or ignore customer protections.

These risks do not mean outcome pricing is inherently bad. They mean the outcome must reflect the customer’s real goals and include quality requirements.

For customer service, those requirements could involve customer satisfaction, repeat-contact rates, and complaint handling.

For sales, they might include agreed qualification standards and penalties for invalid appointments.

For finance, they could require accurate records and approval before money moves.

Which AI Workflows Are Best Suited to Outcome-Based Pricing?

Not every task should be sold using the same commercial model.

Some workflows create measurable results almost immediately. Others produce value slowly, involve several teams, or depend on factors outside the AI vendor’s control.

The following table is a practical evaluation framework developed for this article. Its ratings represent an editorial assessment of how clearly each task can be defined and verified, not observed market adoption.

AI workflow	Possible billable outcome	Measurement difficulty	Pricing suitability
Order tracking	Correct order status provided	Low	High
Basic account changes	Verified change completed	Low	High
Support resolution	Issue solved without escalation	Medium	High
Invoice matching	Accurate match approved	Medium	High
Sales meeting booking	Qualified meeting attended	Medium	Medium
Customer retention	Valid cancellation prevented	High	Medium
Marketing content	Published content delivered	Low for delivery, high for impact	Medium to low
Strategic planning	Business strategy improves results	Very high	Low
Legal decision support	Valid, compliant outcome	Very high	Low

Customer support offers a clear starting point

Support workflows often provide useful historical data.

Businesses know how many conversations arrive, how long employees spend handling common requests, and how frequently issues are reopened or escalated.

They can also divide requests into categories such as password resets, billing explanations, shipment tracking, cancellations, and technical problems.

That creates a relatively strong foundation for testing outcome pricing.

A startup can begin by automating a narrow set of requests and comparing AI performance with historical human handling.

Finance automation needs stronger verification

Invoice processing, account reconciliation, and payment operations can have measurable completion events.

However, a completed action is not necessarily an acceptable financial result.

An AI agent that matches an invoice to the wrong purchase order may appear to finish a task while creating more work or financial risk.

For this reason, finance-focused startups should include validation, exception handling, approval requirements, and record keeping in their commercial definitions.

Charging for verified reconciliations can make sense. Charging for financial decisions without clear accountability is much more difficult.

Sales outcomes can create disputes over attribution

Sales automation offers attractive pricing possibilities because customers understand the value of qualified leads and revenue.

But sales results depend on more than the AI agent.

A prospect might respond because of the company’s brand, advertising, existing relationship, or previous outreach. A sale might close months after an agent first contacted the prospect.

If the vendor claims credit for every deal involving its software, the buyer may end up paying for results the agent did not meaningfully create.

A more practical early model is to charge for a qualified meeting that satisfies clear conditions.

Those conditions might require an appropriate buyer, an agreed business need, valid contact information, and actual meeting attendance.

Complex professional work may favor fixed or hybrid contracts

Research, strategy, product design, and technical analysis often produce value that is difficult to measure immediately.

A strategic recommendation may be valuable even if management decides not to act on it. A software agent may correctly identify a bug but require an engineer to finish the repair.

Trying to attach a price to long-term business results can introduce disputes that outweigh the benefits of outcome pricing.

These situations may work better with a fixed project fee, usage pricing, or a hybrid arrangement that includes clearly defined deliverables.

The lesson for founders is straightforward: choose a pricing model that fits how value is delivered, rather than forcing every product into the same contract structure.

Why Investors May Favor AI Startups That Charge for Results

Outcome-based pricing could make certain AI businesses attractive to investors because it creates a clear relationship between product performance and revenue.

A startup that completes more valuable work for customers may be able to expand revenue without increasing the number of human software users.

That creates growth opportunities beyond traditional per-seat expansion.

However, the same business model exposes the vendor to costs and risks that investors should examine carefully.

Revenue growth is not the same as profitable automation

Consider an AI provider that doubles the number of conversations processed for a customer.

If its resolution rate remains weak, the provider’s infrastructure expenses could rise faster than revenue.

A company may report rapid adoption while losing money on difficult workflows.

Investors therefore need to examine contribution margins by workflow, rather than relying only on annual recurring revenue or the number of tasks attempted.

A customer support agent resolving simple billing questions may have very different economics from one handling complex technical troubleshooting.

Combining the two into one average can hide weak business performance.

The most useful financial metrics are changing

Traditional SaaS investors frequently examine subscriber growth, recurring revenue, retention, and the cost of acquiring customers.

Those metrics remain important for AI companies, but they are not enough to explain outcome-based businesses.

A more complete view includes the verified resolution rate, cost per attempted task, cost per verified outcome, revenue per completed task, customer dispute rate, and contribution margin.

Customer retention also remains essential. A company might produce thousands of billable outcomes but lose customers because the automation creates poor experiences.

For vendors, a useful way to evaluate business health is to ask whether the system becomes more profitable as it gains experience.

If the AI handles more difficult work without matching gains in efficiency or pricing, scale alone may not improve margins.

The Biggest Business Risks of Outcome-Based Pricing

Risk 1: Customers may face unpredictable monthly bills

Outcome pricing creates variable invoices.

A retailer experiencing a seasonal increase in support requests may generate more successful AI resolutions and therefore incur higher charges.

That increase may be economically reasonable, especially if it replaces an even larger amount of manual work.

But finance teams still need to plan for it.

A good contract can address this through spending limits, usage forecasts, volume discounts, and alerts before costs exceed agreed thresholds.

Risk 2: The provider may charge for low-value successes

Not every completed task is equally useful.

An AI agent answering a simple shipping question may save two minutes. Another agent resolving a complicated billing issue might save 20 minutes.

Charging the same price for both makes billing easy but can create uneven economics.

Some companies may respond with different outcome categories or prices based on task complexity.

Intercom’s public distinction between standard outcomes and certain qualification outcomes illustrates how different types of work can receive different prices.

Intercom Help

Startups should be careful not to make pricing too complicated, however. A pricing system with dozens of hard-to-understand categories can create new administrative work.

Risk 3: Businesses may pay twice for the same work

Suppose an AI agent answers a support question but does not fully solve it.

The company pays the AI vendor for the initial interaction and then pays a human employee to handle the escalation.

If the AI result does not satisfy the agreed outcome definition, that interaction should not automatically qualify for an outcome charge.

Contracts must also address duplicate tickets, repeated contacts, transferred conversations, and partially completed workflows.

Without these protections, buyers can end up paying for activity that did not reduce their workload.

Risk 4: The AI vendor may not control the final result

An AI agent might correctly process a refund request, but the payment system could fail.

A sales agent might qualify a strong prospect, but the company’s sales representative could miss the meeting.

In both cases, the vendor performed some useful work without controlling the final business result.

This creates a practical limit on outcome-based pricing.

The best billing outcomes are usually those the vendor can reasonably influence and the buyer can independently verify.

Risk 5: Regulatory and security requirements can increase costs

Businesses handling healthcare records, financial information, identity documents, or sensitive customer data cannot judge AI systems only by speed and price.

They must also consider privacy, permissions, audit records, error recovery, and applicable laws.

In some workflows, an employee must approve an action before the system can complete it.

That human involvement does not make the AI product useless. It simply means the pricing model must reflect the actual division of responsibility.

A startup that ignores security and compliance costs when setting outcome prices could end up with an unsustainable business.

How San Francisco AI Startups Can Build an Outcome-Based Pricing Model in 90 Days

The most practical approach is to test outcome pricing before rebuilding an entire software business around it.

A startup needs evidence that its customers value the result, that success can be measured fairly, and that the company can deliver the result profitably.

Days 1–15: Choose one narrow workflow

Select a task with a clear beginning and end. Use customer records to establish its volume, current processing time, error rate, and cost. Avoid broad promises to automate an entire department.

Days 16–30: Define the billable outcome

Write a precise success rule. Identify how completion will be verified, what counts as failure, and when an outcome can be reversed or disputed. Agree on those rules with the pilot customer.

Days 31–45: Test without automatic billing

Run the agent against a controlled set of real or representative tasks with appropriate permissions. Record every attempt, result, escalation, and cost. Have reviewers independently assess a sample of apparent successes.

Days 46–60: Build the unit economics

Calculate the total cost per accepted outcome, including failed attempts. Compare that cost with the price the customer is willing to pay and the value the task creates for the buyer.

Days 61–75: Test invoices and contract rules

Generate sample invoices using recorded outcomes. Give customers the evidence needed to verify charges. Resolve disagreements over duplicate requests, incomplete tasks, and delayed failures.

Days 76–90: Launch a limited paid pilot

Introduce agreed spending limits and clear service expectations. Compare verified financial results with the baseline, monitor customer experience, and decide whether the workflow is ready to expand.

The most important decision happens before pricing

Founders often begin by asking how much they should charge per outcome.

A better first question is which outcome they can consistently deliver.

A startup that resolves a narrowly defined customer problem with high accuracy may have a stronger commercial product than one promising to automate hundreds of workflows without dependable results.

Once the task is reliable, pricing becomes much easier.

How Businesses Should Negotiate an Outcome-Based AI Contract

Buyers should not assume that outcome-based pricing automatically protects them.

The commercial agreement needs to specify exactly what the vendor is responsible for delivering and what happens when the system fails.

A useful contract separates the definition of successful work from the broader service obligations.

Require an auditable record for every billable result

The buyer should be able to examine why each outcome was charged.

For customer support, the record might include an anonymized conversation identifier, task category, actions taken, outcome timestamp, and verification result.

For accounting automation, it might include the transaction identifier and the record showing that the correct reconciliation occurred.

Sensitive information should be handled under appropriate security and retention rules. Billing transparency does not require exposing every piece of personal data.

Stripe’s published guidance similarly emphasizes defining outcomes, documenting evidence, and agreeing on attribution and billing rules.

Stripe

Agree on a reasonable dispute process

Customers need a way to challenge incorrect charges without creating an expensive manual review process.

A practical agreement can specify how long the buyer has to dispute an outcome, what evidence must be supplied, and how corrections appear on future invoices.

The review process should also cover cases that appear successful initially but later fail.

For example, a support resolution that results in a reopened ticket within an agreed period may need to be excluded or credited.

Set spending limits and performance expectations

A customer should know the maximum possible bill under realistic workload scenarios.

The contract should explain how seasonal spikes, unusually difficult requests, and unexpected increases in usage will be handled.

It should also define appropriate quality measures, such as error rates, escalation handling, and verified completion standards.

These protections help both sides. Buyers avoid uncontrolled costs, while vendors gain clearer expectations about the service they must deliver.

What Traditional SaaS Companies Should Do Before AI Changes Their Pricing Power

Established software companies do not need to abandon subscriptions overnight.

In many cases, their platforms still provide valuable human interfaces, reporting, permissions, workflows, and business records.

Those functions remain useful even when AI handles more work.

The challenge is determining which parts of the product should be priced by access and which parts should be priced by completed work.

Separate software access from automated labor

A useful first step is to identify where customers primarily need a tool and where they want a task completed.

A sales manager may still need CRM access to review accounts and plan strategy. The same company might prefer to pay per successfully completed lead-enrichment workflow instead of purchasing additional software seats for manual data entry.

This suggests a hybrid commercial structure.

The platform subscription covers access, reporting, administration, and security. A separate charge covers verified AI work.

Such a structure can protect existing product value while allowing the vendor to grow revenue as automation expands.

Avoid forcing every workflow into an outcome contract

Some automation features improve productivity without producing a clean, billable event.

A writing assistant may help employees create better documents, but measuring the long-term business value of each generated paragraph would be impractical.

A forecasting tool may improve business decisions even when a specific forecast proves wrong.

These products can still justify subscriptions or usage-based charges.

The goal should not be to make all software outcome-priced. It should be to price products in ways that match how customers receive value.

What the Next Stage of AI Pricing Could Look Like

The most important long-term shift may be the separation of software interfaces from automated work.

Businesses will still need dashboards, reports, settings, and human controls.

But they may increasingly use AI agents to perform the repetitive tasks that once required employees to operate those interfaces.

This could create several connected markets.

One group of companies will build the AI agents performing tasks. Another will provide the systems used to measure completion and verify results. Others will handle billing, security, monitoring, and approvals.

The infrastructure supporting outcome pricing may become as important as the pricing model itself.

Verification could become a competitive advantage

A startup that can prove its AI completed a task correctly may be more attractive to enterprise customers than one offering only an impressive demonstration.

Verification creates trust between the buyer and vendor.

It also helps the vendor identify which workflows are genuinely profitable, which are creating disputes, and which should be improved.

Companies building dependable verification systems may have opportunities to serve many different AI providers.

Pricing may become more closely tied to task difficulty

Today’s public pricing examples already show differences between types of work.

As AI agents take on more complex responsibilities, a single flat rate per task may become less useful.

A business may eventually pay different amounts for routine requests, verified account updates, complex technical resolutions, and high-value business transactions.

However, pricing complexity has costs.

Customers still need simple forecasts, understandable invoices, and confidence that the vendor is not inflating charges through unclear task categories.

The most successful pricing systems may offer a small number of transparent outcome types rather than a complicated charge for every possible action.

Hybrid pricing may remain the practical middle ground

Pure outcome pricing gives buyers strong protection against paying for unsuccessful work, but it transfers substantial operating risk to vendors.

Pure usage pricing is easier to measure, but it exposes buyers to charges for failed tasks.

A hybrid structure can balance those concerns.

A fixed fee may cover the platform, integration, and support. A variable fee may apply to completed work. Additional performance terms can reward quality or protect buyers from repeated failures.

For many enterprise customers, that may be more practical than removing subscriptions entirely.

Methodology and Research Limitations

The original research in this article consists of three distinct types of analysis: a classification of published pricing mechanisms, a modeled San Francisco-area customer support workflow, and financial sensitivity tests.

The vendor comparison uses published material from Sierra, Intercom, Decagon, Salesforce, and Zendesk. It describes documented commercial offerings rather than private contract terms, actual customer adoption, or market share.

The financial analysis uses public wage information for the San Francisco metropolitan area and a published outcome-price reference. All assumptions concerning request volume, automation eligibility, resolution performance, handling time, recoverable employee capacity, employer loading, and provider operating costs are hypothetical.

The analysis is reproducible through the formulas and input tables provided. It does not establish how much money any named vendor earns or how well its agents perform.

The model also assumes a stable monthly workload and does not capture differences in task difficulty, changes in customer demand, financing costs, annual commitments, integration expenses, or every category of operational risk.

Most importantly, it distinguishes the value of recovered staff time from realized cash savings. The two are not interchangeable.

Key public sources include:

These sources support the article’s public-data inputs and documented pricing examples. The scenario findings remain SFTechScene’s own modeled analysis.

Final Takeaway: The Future of AI Pricing Is About Paying for Results Businesses Can Trust

Outcome-based pricing represents a meaningful change in the way software companies and their customers share value.

Traditional SaaS products largely sold access to tools. AI agents increasingly promise to perform the work those tools were designed to support.

That creates a reasonable demand from buyers: show us the completed work, prove that it was done correctly, and charge us for the value delivered.

San Francisco AI companies are already exploring different answers.

Sierra emphasizes outcomes. Intercom offers defined outcome charges through Fin. Decagon allows customers to choose between conversation and resolution models. Salesforce and Zendesk demonstrate how large software platforms can combine several pricing approaches.

The original SFTechScene analysis shows why the economics can be attractive. In a hypothetical San Francisco support operation, thousands of verified AI resolutions could create substantial employee capacity value relative to per-outcome charges.

It also shows why the model can be difficult for vendors. When resolution performance falls, operating costs can exceed the revenue generated from successful work.

For founders, the lesson is to build reliable agents before trying to maximize revenue per task. Measure the full cost of verified completion, not just the cost of a model call.

For business buyers, the lesson is to demand clear definitions, audit rights, reasonable spending limits, and financial evidence that automation is improving operations.

The strongest AI companies will not necessarily be those charging the lowest price per action or promising to automate the largest number of tasks.

They will be the companies that can repeatedly deliver useful results, prove those results happened, and make the economics work for both the customer and the provider.

The next major change in enterprise software may not be how many people use a product. It may be how much valuable work that product can complete without them.