Service as Software Pricing: Don’t Price the Labor

TL;DR: Your first deal priced against the FTE the agent replaced. Your renewal prices against the buyer’s own engineering estimate for building it. The unit you chose at signing decides whether you survive that comparison, because the replaced role disappears and falling inference cost becomes the buyer’s price expectation. Service as software pricing starts with the unit of work and the promise attached to it; the shape comes after.

What service as software sells, and how it differs from SaaS

Service as software is a services business in which agents do most of the delivery and a person stays in the loop for the judgment and the accountability. The vendor sells a defined unit of completed work, or the outcome that work produces. The model decouples labor from the service, so the firm operates more like a software company: delivery cost falls with the agents instead of rising with headcount. We have run this model ourselves since 2018: LevelSetter automated most of the back-end pricing work before agents existed, and our experts stay in the loop for the judgment. Picture every employee in an Iron Man suit, able to do far more than an hourly, labor-based service worker. Under hourly services, when an analyst misreads a contract, the buyer absorbs the error. Under service as software, the vendor does. Venture investors coined the label; it describes the operating model, nothing more. The reverse move, a services firm productizing a tool it used to deliver by hand, is covered in pricing software you used to sell as a service.

SaaS names something different, and the two do not compete. SaaS bundles three commitments: the deployment model, the payment stream, and the hosting and maintenance obligation that comes with the first two. The buyer pays over time, and the vendor absorbs the financial risk of the upfront build. A service-as-software company can be SaaS on all three counts, and most will be.

The value metric does not decide the category, and neither does the deployment. A vendor can charge per completed task, per resolution, or per seat and still be SaaS by deployment and payment stream. What is sold decides it. The pricing question in this piece is the unit of completed work and the promise attached to it.

Service as software is a subset of AI-enabled software, covered by the AI software pricing pillar. Who holds the license grant, a person, an agent, or a system, is a separate decision, covered in the software licensing model.

Why the labor-budget anchor fails service as software pricing

Displaced labor cost finds budget and sizes the opportunity; as a price anchor it fails for three reasons.

What happens to the reference point after the first renewal?

At the first sale, the buyer compares the agent to the FTE or outsourcer it replaced. By renewal, that role is gone, and the buyer compares against competing agents or an internal build on a foundation model. Peer-reviewed research on reference prices describes this pattern: buyers judge a price against the most salient comparable, and the comparable shifts as the alternatives change.

What happens to price when your inference cost falls?

Inference cost per unit of work keeps falling, and in the renewals we see, buyers raise that decline by name. A price justified as “a fraction of an FTE” or as a markup on cost has no defense when the buyer asks why the price held.

Who owns the budget you’re anchoring to?

Labor budgets sit with an operations leader; software budgets with IT or procurement. In the deals we see, anchoring to labor routes the deal to an operations buyer who benchmarks against headcount plans and outsourcing contracts.

Service as software pricing starts with the unit of work

The definition of a completed unit is the product and the first pricing decision.

What counts as a completed unit?

Take customer support, the home of pricing per resolution. “Ticket closed,” “ticket resolved without reopen,” and “ticket resolved with customer confirmation” are three different products, each with its own delivery cost, dispute rate, and exposure to gaming. A loose definition invites gaming from both sides: the vendor closes early, the buyer reopens to avoid the charge.

The shape recurs across our engagements. A vendor priced by workflow, and users stuffed every step into a single workflow to hold the count down. The gaming spread past billing: debugging and tracking became a nightmare, because the workflows no longer matched how the work ran. A unit the user assembles is a unit the user will assemble to minimize the bill.

Who verifies the count, and who disputes it?

A unit is meterable when both parties can observe it in a shared record. That record can be the vendor’s own product, as long as the buyer can read the count there. It can also be any of the buyer’s systems the work lands in, a ticketing queue and a CRM among them. Without that, billing becomes a recurring negotiation, and each round erodes net price.

The same shape appears where a vendor priced by application events. A usage spike produced a surprise bill, and the customer argued that many event types carried little value, and won. The metric stayed the same while the effective count fell, because the contract had treated every event as equal and the customer could sort them by value after the invoice.

How are exceptions and human escalation priced?

Agents hand edge cases to people. Whether a handoff counts as a full, partial, or zero unit is a licensing decision, made deliberately or by default. In the deals in our pattern library, undefined handoffs return as disputes, often at the first quarterly business review.

The unit of work is the value metric. Tokens, API calls, and agent runs meter vendor activity. When the contract sells completed work, renewal after renewal goes the same way in our record: the buyer cannot tie an activity count to work it asked for, and discounts the price to compensate.

The dispute we see most often starts with a unit defined by the vendor’s own event, a ticket closed or a document generated, that the buyer never agreed to count. The dispute arrives with the second invoice, and the next quarter goes to renegotiating the definition instead of expanding the contract. The redefinition that holds makes the buyer’s confirmation part of the unit.

Pressure-test your unit-of-work definition with an SPP pricing expert.

Pricing the promise attached to the work

The promise is the set of guarantees attached to delivered work. Selling work brings the obligations services firms have always carried: quality standards, rework, error liability, turnaround, and scope disputes. A price set on output alone underprices what the vendor sold. Peer-reviewed research on outsourcing contracts points the same direction: when risk shifts to the provider, monitoring and renegotiation costs rise, and those costs belong in the price.

When the agent makes an error, the remedy sets the effective net price: service credits reduce revenue, rework consumes capacity, and indemnity moves liability onto the vendor’s balance sheet. In the enterprise deals in our pattern library, remedy terms draw more redlines than the rate.

In the engagements we see, a labor-based services firm hands over its recommendation and is gone before it stalls. A service-as-software firm stays through implementation and monitoring, so every friction point feeds back into delivery. In the implementations we see, three frictions recur. The buyer’s system of record carries only part of what the agent produced; the people who understood the old process leave mid-rollout; edge cases route back to people nobody budgeted for. Each is a way the promise breaks, and each fix lowers the cost of keeping the next one.

The promise is also a packaging axis: the same unit of work can carry different turnaround or accuracy commitments across editions, so different Customer Groups buy different promise levels.

Four shapes of service as software pricing

Each shape is a combination of a licensing, packaging, and pricing choice. What is counted is the licensing decision: the completed unit, or the outcome it maps to once a countable instance is named. How money flows against that count is the pricing model. It can flow per unit, paid in arrears or in advance; as a share contingent on the outcome; as a prepaid commitment drawn down; or as a standing fee with units beside it. Whether the standing capability is sold apart from the work, or includes an opening tranche of units, is packaging. A vendor makes one licensing choice, one packaging choice, and one pricing choice, and these are the four combinations that recur across the Pricing Observatory record.

Three questions sort the four shapes: what the buyer can observe, who carries the gap between the work and the outcome, and what happens to price when delivery cost falls.

Shape 1: Per unit of work

It is the service-as-software case of output-based pricing, with the promise attached. It fits when units are discrete and similar in effort. It fails when effort varies across units, because margin then depends on the buyer’s mix. The contract defines what counts as a completed unit, where both parties observe the count, and how a handoff to a person counts.

Shape 2: Outcome share

It fits when both sides accept one attribution method before signing. It fails when attribution does not survive scrutiny; outcome-based proposals fail there most often, then reduce to disputed per-unit pricing. The contract defines the outcome, the attribution method, and what the vendor is paid when a person closes the gap.

Shape 3: Committed capacity

It fits when demand is predictable enough to commit; peer-reviewed research on cloud pricing finds committed-spend contracts let buyers self-select by demand predictability. It fails when buyers expect more units per commitment at each renewal and the price was justified by cost. The contract defines the drawdown unit, the term, and what happens to unused commitment.

Shape 4: Platform fee plus work units

It fits when onboarding and tuning are real, recurring work the buyer can see apart from the delivered units. It fails when the platform fee is a disguised minimum, because the buyer then reads the whole price as per unit and pressure concentrates there. The contract defines what the platform fee buys, how many units it includes, and where onboarding and tuning land.

In the proposals we see, few buyers of automated work can supply an attribution both sides accept. The agent does the work and a person usually closes the gap to the outcome. Price the agent’s work as if it were the outcome, and the buyer pays outcome rates for work while the vendor is paid nothing for the risk it still carries.

How buyers compare service as software

The declared choice set names a few agent vendors. The actual choice set is wider: competing agents, an internal build on a foundation model, the incumbent outsourcer, and existing staff. Benchmarking only against named vendors misreads what the buyer is willing to pay, and the internal-build estimate is the comparison that sets the renewal ceiling. The Pricing Observatory tracks how categories price agent-delivered work.

How much should you charge for service as software?

Start from the buyer’s next-best alternative in that wider choice set. Price the unit against that alternative, and put the headroom in the promise: turnaround, accuracy, and remedy commitments carry price that the unit alone cannot. A discount to displaced labor expires with the role, and a markup on inference cost invites the buyer to claim every decline.

Five steps to price service as software

1. Define the unit of work.
2. Define the promise attached to it.
3. Map the actual choice set.
4. Choose the shape.
5. Instrument verification in a shared record before launch.

Start with a Pricing Architecture Assessment, or talk to an expert about your unit definition.

FAQs