--- title: "Seat-Based Pricing After AI Agents: Count Jobs, Not Users" publishedAt: "2026-10-23" summary: "Seat-based pricing counts the people who operate software. When agents do the operating, count what the work is for instead: locations, employees, accounts." author: "Ben Skoog" authorImage: "/ben_skoog.jpeg" --- Seat-based pricing charges a customer for each person who has access to a piece of software, usually as a fixed fee per user per month. It became the default for SaaS because the number of people operating a product was a decent stand-in for the value the product delivered. AI agents break that stand-in. When an agent does the operating, the work can go up while the number of people logging in goes down. Most of the writing on this, including the glossary pages that rank for the term, lands on the same conclusion: price work, not people, and move to usage, outcome, or agent-based pricing. That is half right. It misses that "seat" has always meant two different counts. One counts the people who operate the software. The other counts the people, places or accounts the work is done for. Agents break the first and leave the second alone. That distinction is the argument of this post. A software company does not have to give up the predictable subscription to survive agents. It has to change what it counts, from the users of the product to the things the job is held for. Below is what that means, and what a vendor can charge for instead of the operator seat, in order of how much delivery capability each option takes. ## Why seat-based pricing worked For twenty years the seat was the simplest honest proxy SaaS had. A team of 20 using a project tool got more out of it than a team of 5, so it paid four times as much. Budgets were easy to plan, revenue grew as customers hired, and expansion happened without a renegotiation. Arnon Shimoni summarizes the era in his [notes on where seat-based pricing is going](https://arnon.dk/notes-on-where-seat-based-pricing-is-going/): "For twenty years, SaaS revenue scaled with headcount." The model rested on one assumption, which he states in a single line: "Seat pricing depends on more humans doing more work." That assumption held because the customer did the work. The vendor shipped features, and the customer's staff operated them. Paying per operator matched how the value was produced. ## How AI agents break the seat An agent changes who operates the product. Three things follow, and [Solvimon's glossary entry on seat-based pricing](https://solvimon.com/glossary/seat-based-pricing) names three shifts behind it: agents replacing users, smaller teams doing more work, and AI features reducing usage-based revenue. Bain's [Technology Report 2025](https://www.bain.com/insights/will-agentic-ai-disrupt-saas-technology-report-2025/) puts the buyer's side plainly: "Seat-based pricing may not fit when AI is doing the work," and "If an agent replaces a human task, customers will expect to pay based on outcomes, not log-ons." Its advice to vendors is to "stop charging for access" and "start charging for work done." Vendors are saying the same thing out loud. At HumanX in September, Zendesk CEO Tom Eggemeier said "Unequivocally: seats are dead," according to [The Next Web](https://thenextweb.com/news/zendesk-sierra-per-seat-pricing-ai-agents-humanx), and said Zendesk plans to drop seat-based pricing across its business. His warning: "If you're still on seats in two or three years, I believe your company will struggle." There is a quieter version of the problem too. monday.com's own [guide to its AI credits](https://monday.com/blog/ai-agents/monday-ai-credits/) notes that its MCP server, which lets outside assistants like Claude, ChatGPT and Copilot Studio work in a customer's workspace, "is available on all monday.com plans for free and doesn't consume AI credits." It also means that when a customer's own assistant does the work from outside, the work does not show up on the vendor's meter at all. The seat was the only thing being counted, and the seat is not doing the work. We made the broader case that seats are dying while software is not in [SaaS is dead, they say. Seats are dying, not software](/blog/saas-is-not-dead). ## The two kinds of seat Look closely at products priced "per user" and you find two different things being counted. - **Operator seats** count the people who use the software: the admin, the analyst, the support rep. A project tool, a CRM, or an office suite with an AI add-on prices this way. - **Unit seats** count the people or things the work is done for: employees paid, locations managed, accounts served. Payroll is the clearest case. OnPay's [published pricing](https://onpay.com/payroll/software/accountants/pricing/) lists Payroll Essentials at "$49 base + $6/worker," and its pricing calculator counts "paid workers," not the people who log in to run payroll. The difference matters once agents arrive. If an agent runs payroll instead of the office manager, the operator count can drop to zero. The number of workers who need to be paid does not change at all. A payroll vendor priced per worker loses nothing when its customer stops logging in. A tool priced per operator loses the seat. That is the overlooked point in most "seats are dead" writing. Seats are not dying as a unit of count. Operator seats are. Unit seats describe what the job is for, and the job still exists when an agent does it. ## What to charge for instead of the operator seat Here are the options a software company actually has, in order of how much it has to be able to deliver. Each step up asks more of the vendor and gives the buyer a closer match between price and value. ### 1. Keep the seat, add AI per seat The smallest change. Microsoft priced Microsoft 365 Copilot at "$30 per user, per month" for its business and enterprise plans when it [announced pricing in 2023](https://legaltechnology.com/microsoft-announces-pricing-for-copilot-at-30-per-user-per-month-unveils-bing-chat-enterprise/). Salesforce's [Agentforce pricing page](https://www.salesforce.com/agentforce/pricing/) lists Agentforce add-ons at $125 per user per month. This works while the AI helps a person do their job faster. It needs no new delivery capability. It still ties revenue to operators, so it inherits the seat's problem the moment the AI does the work instead of helping with it. ### 2. Keep the seat, add pooled credits The next step meters AI activity separately from people. monday.com's guide describes credits that "work like a phone plan": the subscription includes an allocation, and "AI credits are pooled at the account level and shared across all team members." Salesforce offers Flex Credits at $500 per 100,000 credits on the same pricing page. Credits fix the mismatch between seats and AI activity, and a pooled allowance avoids stranding credits with users who do not need them. But credits still meter effort, not results. The customer decides how much to use, and carries the risk that the effort produced nothing. We compared who carries that risk under each model in [AI agent pricing models, compared by who pays when it fails](/blog/ai-agent-pricing-models). ### 3. Price the agent as a worker Some vendors now license agents the way they license people: a fee per agent, per digital worker, or per "agent seat." Solvimon lists agent-based pricing among the replacements for seats. It is an easy story to sell, because it compares the agent to a salary. It is also the operator seat again, with the operator replaced. The customer is still paying for something that operates the software, not for what got done. If the agent is idle, they pay. If it does twice the work, they pay the same. ### 4. Price each result Outcome pricing charges per result: a resolved ticket, a completed sale. Sierra, in the same Next Web piece, says it charges only when its agents resolve an issue or make a sale, and its co-founder Clay Bavor argues that "the ROI is so clear you don't have to do fuzzy envelope math about productivity gains." This matches price to value closely, but only for work that happens as discrete events. It takes real delivery capability: the vendor has to complete the work and prove it happened. It also gives the buyer a variable bill, which is exactly what the seat model protected them from. ### 5. Price the job, per unit it is held for The last option keeps what was good about seats and drops what agents broke. The vendor sells a job, like "keep every location compliant" or "get every new hire through onboarding," and prices it per unit the job is held for: per location, per employee, per account. Take an illustrative example from a learning platform we will call Lessonfield. Its customer, Pellmark Training, has two admins, twelve locations and a few hundred staff. Priced per operator, Lessonfield earns two seats, and the number shrinks as an agent takes over the admin work. Priced as a job, Lessonfield sells "location compliance" per location, and earns on twelve. If Pellmark opens a thirteenth location, the price goes up because the job got bigger, not because someone new logged in. This is the most demanding option. A per-unit price for a job only makes sense if the vendor can actually hold the job: see the state for each unit (11 of 12 locations compliant), act when it slips, and keep going. That is why we argue the software vendor is best placed to sell it. The work happens inside its product, on data it already has, for customers it already bills. We wrote more about that in [outcome as a service: a service is a job, not a task](/blog/outcome-as-a-service). ## The options side by side | Option | What is counted | Who carries the risk the work fails | Delivery capability needed | |---|---|---|---| | Seat plus AI add-on | People operating the product | Customer | None beyond the feature | | Seat plus pooled credits | People, plus AI activity | Customer | Metering | | Agent seat | Agents operating the product | Customer | An agent that can operate the product | | Price per result | Each completed result | Vendor, per event | Completing and proving each result | | Job priced per unit | Locations, employees or accounts the job is held for | Vendor, continuously | Holding the job's state for every unit | Read top to bottom, each row moves the count further from the product's users and closer to the customer's business. The last row is the only one that is both predictable for the buyer and indifferent to who, or what, operates the product. ## How to move off seats without breaking your revenue A practical path for a software company that sells seats today: - **Check what you already count.** If your price is per employee, location or account, you have a unit seat, and agents are less of a threat than the headlines suggest. If it is per admin or per user, you have an operator seat. - **Find the job behind the seat.** Ask what your customers' operators spend their week doing in your product. That work is the job they would pay to stop thinking about. - **Pick a unit the customer already budgets by.** Locations, staff, active accounts. Something that grows when their business grows, not when their headcount in one department does. - **Price the job as a subscription.** A subscription per unit keeps the predictability your customers liked about seats. What you charge is yours to set, through your own billing. We cover the mechanics in [selling services through your own Stripe account](/services/sell). - **Only sell what you can hold.** If you cannot see the state of a job for each unit, you cannot hold it, and you should not price as if you can. Keep two kinds of money apart while you do this. What you charge your customers for a job is your price. What you pay to have AI do the work is a cost of delivering it. If you use Aimdoc, that cost is prepaid credits for the AI's work, with caps you control. Aimdoc does not charge per outcome or per resolution. ## FAQ ### What is seat-based pricing? Seat-based pricing charges a fixed fee for each user who has access to a product, usually per user per month. It is the most common SaaS pricing model because it is simple to budget and grows as a customer's team grows. ### Why do AI agents break seat-based pricing? Because agents do work without being users. When an agent operates a product, the work can increase while the number of people logging in falls, so revenue tied to operators shrinks even as the product delivers more. ### What replaces per-seat pricing for AI products? The common options are AI add-ons per seat, pooled credits, agent licenses, per-result pricing, and jobs priced per unit. The last keeps the predictability of seats while tying the price to what the customer actually needs done. --- Your customers do not want more seats. They want the job done for every location, every employee, every account. Aimdoc connects securely to your product and your systems, then delivers the work your customers need: metered, monitored and cost controlled. [Start free](https://app.aimdoc.ai/signup), or book a demo.