What Customers Buy When Software Performs Work
In the SaaS era, the customer bought access: seats, modules, storage, API calls, dashboards, workflows. In the AI-native era, the customer increasingly asks whether the software performed a job.
Key Takeaways
- What Customers Buy When Software Performs Work is a chapter about AI revenue engineering, not a generic AI adoption note.
- The operating rule is to sell proved work, measured risk, and margin discipline rather than demo theater.
- The failure mode to watch is polished output without evidence, owner, cost line, or rollback path.
- The useful next step is an artifact a future teammate can replay without folklore.
AI revenue work converts when the seller can prove resolved work, cost, risk, and expansion evidence, not just a polished demo.
In the SaaS era, the customer bought access: seats, modules, storage, API calls, dashboards, workflows. In the AI-native era, the customer increasingly asks whether the software performed a job. Did it resolve the ticket? Draft the filing? Summarize the call? Find the exception? Qualify the lead? Write the code? Catch the risk?
Access is still sold. But work performed becomes the center of value.
This chapter explains the transition from access value to performed-work value. The shift does not eliminate subscriptions or seats. It complicates them. A product may combine platform access, usage, workflow volume, resolution fees, premium automation, and human review. The commercial architecture must match how the buyer experiences value and how the vendor incurs cost.
Research spine
This chapter uses: OpenView, Usage-Based Pricing; Stripe Billing; Zuora, Quote-to-Cash; Brynjolfsson, Li, Raymond, Generative AI at Work, NBER Working Paper 31161; Bessemer Venture Partners, State of AI 2025.
Access, usage, outcome, and risk
There are four pricing surfaces. Access pricing charges for the right to use the product. Usage pricing charges for consumption: tokens, messages, documents, minutes, tasks, API calls. Outcome pricing charges for a result: resolved case, qualified lead, approved claim, recovered dollar. Risk-adjusted pricing changes price based on confidence, review level, indemnity, compliance controls, or service tier.
AI-native products often need a hybrid because no single surface captures all economic realities. Seat pricing may undercharge high-volume automation users. Pure usage pricing may punish adoption and create budget fear. Outcome pricing may be attractive but hard to attribute or risky if the product does not control the full workflow.
The work unit
The work unit is the smallest measurable job the customer recognizes as valuable and the vendor can meter defensibly. A token is a cost unit, not usually a value unit. A message may be a usage unit, but not necessarily a resolved-work unit. A resolved support case, validated document, completed onboarding step, or accepted code patch is closer to value.
Choosing the work unit is a strategic act. It shapes product design, instrumentation, sales narrative, customer success, and gross margin.
Proof of performed work
If the product performs work, the vendor must prove the work happened and mattered. That proof may include audit logs, before/after baselines, acceptance rates, human override rates, outcome metrics, quality samples, customer-visible reports, and renewal dashboards. Without proof, the customer will discount AI output as convenience rather than value.
Operating table
| Pricing surface | Best fit | Danger |
|---|---|---|
| Seat/access | Collaboration products and broad platform value | Underprices automation-heavy users |
| Usage | Meterable consumption tied to value | Can create budget anxiety |
| Outcome | Clear result with measurable business value | Attribution and vendor risk |
| Hybrid | Most AI-native B2B products | Billing and sales complexity |
Artifact example: a simple performed-work margin calculation
def gross_margin(price_per_task, model_cost, infra_cost, human_review_cost, support_cost):
cogs = model_cost + infra_cost + human_review_cost + support_cost
return (price_per_task - cogs) / price_per_task
print(round(gross_margin(
price_per_task=2.50,
model_cost=0.38,
infra_cost=0.07,
human_review_cost=0.20,
support_cost=0.10
), 2))Checklist
- Separate cost units from value units.
- Define the work unit before choosing the pricing model.
- Decide whether outcome attribution is defensible.
- Instrument proof of work inside the product.
- Model margin under realistic usage distributions.
Takeaway
AI-native customers do not only buy access to software; they buy credible performance of work.
Internal map
For the larger argument, keep this chapter connected to Revenue, Re-Engineered, Pricing Software That Thinks, selling AI to burned buyers, and the judgment economy.