AI and PLM Pricing: Vendors Sell Seats the Way Architects Sell Hours

What should manufacturers pay for when AI does more of the work in PLM?

Outcome-based pricing in PLM is a model in which a manufacturer pays for defined work the platform completes and the product information it keeps trustworthy, rather than for the number of people who log in. It requires bounded deliverables with observable completion criteria, such as an engineering change package prepared, checked, approved, and delivered to suppliers.

A recent LinkedIn post by Jakob Strømann-Andersen, Director of Innovation and Sustainability at Henning Larsen, made me smile for the same reason it made him smile. Jakob questioned why architects keep paying more for Autodesk licenses, and then turned the question on his own business. Architects buy software to work faster, yet they still sell hours. If AI cuts billable hours in half, what do they sell instead?

I asked in the comments whether you can sell the outcome of your work instead of hours. Dominic Seah pushed back with the right questions. How do you define an outcome? If you take a slice of the client’s profit, do you also take the losses? When several providers contribute to a project, who gets credit for what? He also offered a more interesting answer: selling access to expertise accumulated over years, with a human “seal of approval” on top, the way Waymo still puts a person in the loop for the tricky stretch.

Here is what struck me. Jakob’s complaint about Autodesk and his question about his own business are the same question, asked one level apart. Software vendors sell seats the way architects sell hours. If AI means fewer people operate engineering software, seat-based revenue shrinks exactly the way billable hours do.

Manufacturing and PLM have this problem in three layers at once. Manufacturers pay engineers to prepare and coordinate product data. Implementation partners sell hours to configure and integrate PLM. Vendors sell named users. AI puts pressure on all three. So the question for our industry is not only what manufacturers should pay for. It is what anyone in the PLM value chain will be paid for when the hours and the seats go down.

Engineering software licensing has always followed how the work gets done

Over the years, I’ve seen many licensing mechanisms come and go. In the 1990s, a license manager with floating licenses was almost an industry standard. A company bought a pool of licenses, and engineers checked one out when they sat down at a workstation.

I’ve also seen the old enterprise approach: “we give you the system, measure what you use, and send you a bill at the end of the year.” It worked, and it still works in some enterprise deals. But it is a poor fit for modern applications that customers adopt quickly and expand on their own.

Then named-user seats became the default for SaaS, sometimes mixed with floating licenses. For project-based work, paying per project was a reasonable model. Pricing by storage or compute made sense for some categories of software, but until very recently engineering applications stayed away from it.

Today we see a wave of new ways to measure consumption, and tokens are clearly leading. Each model made sense for the way work was done at the time. The question of which unit fits engineering software when AI agents do a growing share of the work is still open. This article is my attempt to answer it.

An outcome you can’t bound is an outcome you can’t sell

Dominic is right that profit sharing is the wrong definition. A successful product launch is an outcome. So is a profitable manufacturing business. But design decisions, sourcing, capacity, and market demand all shape those results. No PLM service can take responsibility for them, and no manufacturer should want it to.

The workable definition sits much closer to the work. Take an engineering change. A service can take responsibility for preparing the affected product structure and documents, checking them against agreed rules, routing exceptions to the right people, collecting approvals, and distributing the approved package to suppliers.

Now the outcome has edges. Which configuration applies? Which checks run? Who approves? What happens when information is missing? What evidence shows the package was delivered and acknowledged? Answering these questions does not dilute accountability. It is what makes accountability possible.

The boundary also tells you what the service does not promise. A supplier acknowledging a package confirms receipt. It does not prove the part is manufacturable or that production will hit its targets. A good outcome contract says so plainly. My working rule is simple: an outcome in PLM is a defined responsibility with observable completion criteria. Anything broader is a marketing slogan.

Labor savings get competed away, so they can’t be the business

Most of the value people attribute to AI today is replaced labor, and in PLM there is a lot of it. Engineers collect files, compare revisions, reconcile BOMs, check attributes, assemble supplier packages, and chase missing answers. That effort is spread across engineering, procurement, operations, and external partners, and nobody’s job description says “spend a third of the week assembling data.”

An automated service can do much of this and hand people only the exceptions. The value is real: fewer hours of preparation, shorter turnaround, fewer corrections. But two things limit what anyone can build on it.

First, hours saved are not cash saved. A manufacturer usually spends freed engineering capacity on more releases, more alternatives, or better documentation. That is valuable, but it is a harder story to put in a budget than “we cut cost.”

Second, savings do not stay where they first land. A service provider on a fixed fee improves its margin when effort drops. A vendor that starts doing work users used to do can charge for it. Then a competitor automates the same task with similar reliability, and the customer reasonably expects a lower price or more work for the same price. Dominic made this point about tokens: more productivity can simply mean more work that earns no extra fee, because the competition is offering it too.

I’ve watched this happen with reports and derivative files. Automatically generating BOM reports, PDFs, STEP files, and other derivatives from CAD is genuinely valuable. Engineers hate doing it by hand. But it did not lead any company to remove engineers, and it very quickly became a standard expectation rather than a reason to pay more.

So labor replacement is the reason a customer tries an AI service. It is not the reason they keep paying for it. That reason has to come from somewhere else.

Jakob’s three ideas are the moats that survive automation

In PLM Moats in 2026: 8 Ways to Defend PLM Software from AI, I argued that defending a feature list is getting harder, and that the better question is what customers continue to entrust to a platform. Reading Jakob’s post again, I noticed that his three suggestions for architects line up almost exactly with three of those moats.

Dominic’s first comment adds a fourth point that vendors should think about. He asked why users should burn their own time and tokens writing macros and integrations that the vendor could build once, centrally. I agree. Customers will increasingly expect vendors to deliver the vertical automation themselves. That shifts the vendor from selling a tool to carrying out work, which is exactly where the outcome question starts.

None of these advantages comes free. A large database is not a system of record anyone trusts. A large user count is not a network effect, because that requires new participants to add value for existing ones. Running a workflow is not the same as learning from it. Each one has to be earned through the work itself, and each has to respect that the customer owns its product data.

One engineering change shows where the lasting value sits

Consider a hypothetical change to a machined housing. Engineering updates the drawing and revises the BOM. An automated service assembles the supplier package, runs the agreed checks, routes it for approval, distributes it, and tracks acknowledgments. That is the labor replacement, and it pays off on this change alone.

Then the supplier asks about an ambiguous inspection requirement. Engineering clarifies it, approves the interpretation, and updates the package. A few weeks later, production reports whether the requirement was understood and achievable.

This is where most companies lose the value. The answer lives in an email thread, the approval in a workflow log, the production feedback in a quality report. Nobody connects them. On the next release, the same ambiguity reaches the same supplier, and the same conversation happens again.

If the service keeps the revision, the question, the accepted interpretation, the approver, and the production result connected, the next release can be different. The service can flag a similar ambiguity before the package leaves the building. That is not the saved hour from the first change. It is a better second change.

I would not oversell it. One question from one supplier does not justify a universal rule, and the lesson may only apply to one material, process, or customer. The learning is useful when the system keeps those limits attached and there is evidence the new check actually helps. Connecting what was defined and decided with what happened afterward is what I mean by Product Memory, and it is the part of this story a competitor cannot copy by automating the same task.

When users shrink, price the responsibility, not the access

Now back to the bill. If AI does more of the preparation, checking, and coordination, the number of people logged into PLM becomes a poor measure of what the platform does. A manufacturer could manage more products, more suppliers, and more engineering changes with fewer people doing administrative work. The platform’s responsibility grows while its seat count falls. A seat-based vendor in that situation is punished for doing its job well.

Customer support software hit this problem first, and it is a useful preview. When AI agents started resolving support conversations, seat pricing stopped making sense, and many vendors moved to the ticket, the core data element of every support system. Gorgias prices by monthly ticket volume rather than seats, starting at $10 for 50 tickets. But when its AI Agent resolves a conversation, that resolution is billed on a second meter and also counts as a billable ticket, so automation adds cost instead of replacing it. Helply shows how unsettled this still is. It sold a flat $1 per ticket with unlimited seats, then in September 2026 switched to $0.50 per outcome, and soon after moved toward tiered plans with credits.

Two lessons carry over to PLM. The natural pricing unit is the core data element of the domain, which for us means items, BOMs, and CAD files rather than tickets. And when the vendor charges extra every time automation does its job, the model works against the thing customers are buying.

Here is how the main options compare for PLM.

Tokens are the weakest option from the customer’s side. They measure what the vendor consumed, and a customer has no reason to care how many tokens a task took, only whether the result can be trusted. Per-transaction pricing is closer to outcomes, but it gets messy quickly. Is a 3-line change worth the same as a 300-line change? Who pays when a package bounces back from a supplier?

My view is that the most practical unit for PLM is the managed product information itself. It scales with the responsibility the platform carries, not with the number of humans at keyboards. It stays stable when agents take over tasks. And customers can understand it, because it maps to things they already count: parts, assemblies, CAD files, products, assets in the field.

I should say that I have spent years building a business on data-based pricing, so I have a view here. Judge the argument on its merits. At OpenBOM, we built a hybrid model that combines data records and seats, and it solved many of the licensing problems we had with seats alone.

Delivering outcomes does not mean billing per outcome. A subscription tied to managed information can fund responsibility for completed work. The pricing unit and the value proposition need to be connected. They do not need to be the same thing.

Per-record pricing fails the moment it taxes history

The first objection to charging by managed records is obvious: storage is cheap, so why pay per row? The answer is that customers are not paying for the row. A managed item carries its place in product structures, its applicable revisions, approved suppliers, drawings, specifications, and change history. A serialized asset connects a delivered configuration to service records and later modifications. Keeping all of that consistent while sources change, permissions evolve, and integrations break is ongoing work. That work is what the price funds.

If the vendor cannot explain what it maintains for each record and what the customer can depend on, record pricing is just storage pricing with a markup, and customers will treat it that way.

The second risk is quieter and more dangerous. Pricing shapes behavior. If every revision, relationship, or archived product adds to the bill, customers will stop preserving history and stop connecting information. They will delete old revisions and keep supplier context in email. The pricing will discourage the exact behavior that makes Product Memory valuable, and it will erode the vendor’s own moat. It is the same trap as charging extra each time an AI agent resolves a support ticket.

So the design questions matter more than the headline unit. What counts as one managed item? Are revisions and relationships included? How are archived and end-of-life products treated? A good model charges for the scope of the product the customer manages and makes depth of history and connection free, or close to it.

We had to answer these questions at OpenBOM. We decided customers pay for part numbers and CAD files, because those define the scope of the product they manage. Charging for revisions and changes made no sense, because it would penalize the history we want customers to keep.

Record count is a fair measure of service scope. It is not proof that outcomes are good or that the vendor has a defensible business. Those claims still need evidence about reliability, usefulness, and improvement over time.

The human seal of approval is part of the product, and it has a cost

Dominic’s Waymo comparison fits manufacturing well. A technically complete package can still raise questions about tolerances, sourcing, production methods, or customer requirements. An AI service needs clear limits on what it can execute, when it must stop, and who has authority to decide. Human review belongs wherever judgment or approval is required.

That review is not free. A service that looks cheap on routine changes can get expensive when the hard exceptions arrive, and any outcome commitment has to price that in. Over time, connecting expert decisions to what happened afterward can improve both the automation and the review. The expertise does not disappear. It becomes part of what the customer entrusts to the service.

What is my conclusion?

The outcome conversation gets much clearer once you split it into three questions. What work does the service take responsibility for completing? What makes it more valuable as that work accumulates? And what unit should the customer pay for as the number of people operating software goes down?

In manufacturing and PLM, AI will reduce the effort of preparing information and coordinating processes. That saving is real, but it will be competed away. What lasts is trusted product records, working collaboration with suppliers, and learning from observed results. Those are reasons to keep entrusting the work to one service.

For pricing, I think seats will stop being the main unit. They still make sense for access, which is why hybrid models work, but they cannot carry the whole bill when agents do more of the work. Tokens are a poor replacement because they measure the vendor’s cost, not the customer’s value. Managed product information is the most honest proxy for the responsibility a PLM platform carries, as long as the model rewards customers for keeping history and connections instead of taxing them.

Jakob asked what architects will sell when AI cuts their hours. The same question is coming for every PLM vendor and every implementation partner. My answer: when AI reduces the hours needed to manage a product, the business belongs to whoever makes the next release better and takes responsibility for it.

Just my thoughts…

Best, Oleg

Disclosure: I am the co-founder and CEO of OpenBOM. My work on connected product data and Product Memory shapes my perspective, and my opinion can be unintentionally biased.