Agents don't need human seats

Fewer human seats can leave you with a bigger software bill.

Jason Lemkin reported cutting his company's Salesforce account to two human seats and an API seat, while its annual bill rose from $12,000 to $22,000. He didn’t break down the increase.

I’d want to understand what replaces the seat before counting the savings. A useful pricing unit is one I can budget for and check against the work the agent actually does.

So much for pricing by seat.

The seat worked as a pricing unit because one employee used one tool to do a job. A hundred salespeople meant roughly a hundred CRM licenses. An agent can update opportunities for the whole team through an API without opening the pipeline screen, so counting logins misses some of the work the software now performs.

Lemkin's company had more than 20 agents running on Salesforce, even as it cut back from 10-plus seats. Those agents still needed to read and update the CRM.

There are two purchases to account for here: access to the business software an agent uses, and the agent service itself. The CRM may charge for API capacity while a support-agent vendor charges for conversations or completed resolutions. Buyers need to know which charges replace human seats and which get added to them.

In an a16z survey of 50 technical AI buyers, 27 preferred credits tied to recognizable work, compared with 14 who preferred tokens. A support leader can estimate conversation volume from the existing queue. Estimating the model calls, retries, and token usage inside each conversation is much harder.

Decagon offers both per-conversation and per-resolution pricing, and says most customers choose conversations. They can forecast the volume, and they avoid having to decide whether a customer who stopped responding had their problem solved or simply gave up.

Ada made a similar change. According to Bessemer's account, it moved from per-resolution pricing to a platform fee, prepaid conversation volume, and implementation services. Customers wanted an annual number they could plan around. Paying per successful outcome sounds attractive, but a buyer still has to estimate how many outcomes the vendor will bill for.

Sierra describes two conditions for outcome pricing: the agent can complete the job, and both sides can verify that it produced the result. A case the agent closes on its own and a case it helps a person resolve are different contributions. The contract needs to say which one earns the charge.

Now define what "resolved" means.

Salesforce's Help Agent announcement gives a concrete example: it says there is no resolution charge when a customer asks for a person or gives negative feedback. Those exclusions determine what the quoted price buys.

Would you pay for this resolution?

In Chris Bakke’s 2023 exchange, he first told the bot to agree with him. No vehicle sale followed.

I'd walk through a few actual cases before agreeing to that price. A customer stops responding, then returns with the same problem the next day. The agreement needs to say whether the first interaction counts as resolved, whether the second creates another charge, and what happens to the original charge if the resolution was wrong. Both teams should be able to reconcile the invoice against the support record using the same rules.