Picture a procurement manager with two offers for an enterprise AI on her desk. Offer A quotes €30 per seat and month, Offer B quotes €45. The decision looks obvious until someone asks: “And what will this really cost us over three years?” Suddenly the room goes quiet, because the two numbers do not answer that question. They answer a different one: what the vendor invoices per seat per month.
This article turns the price list into a calculation model. It breaks the cost of an enterprise AI into six blocks, gives a formula for each, works through a complete example over 36 months and points out the mistakes that are easy to make when comparing offers. Our thesis: The price per seat is an input, not a result. Offers only become comparable as total cost over a fixed period, divided by the people who actually use the AI.
One note up front that matters to us: every number in this article is a round assumption for an invented example. They are not market prices, not measured values and not TheroAI prices. They exist to make the calculation visible, nothing more. For your own calculation, please use your own figures.
Why the Price List Answers the Wrong Question
A price list says what a vendor charges. Cost is everything your company spends to make the AI work in daily practice. Everyone knows the difference when buying a car: the purchase price is one part, insurance, servicing and tires come on top, and anyone who really wants to compare vehicles looks at the cost per kilometer. Finance calls this view total cost of ownership. For an enterprise AI, the gap between price and cost is wide for three reasons.
First, a large share of the work sits with you. Connecting systems, organizing data, getting people up to speed: all of it costs working time, and none of it appears on the vendor's invoice.
Second, time. Some costs arise once, others every month. Comparing only monthly fees overlooks the one-off costs. Looking only at the rollout overlooks the recurring ones.
Third, usage. A seat costs money whether anyone uses it or not. Value, however, only arises where people actually work with the AI.
So here is what a price per seat does not tell you:
- how much work it takes to connect your systems
- what condition your data is in and what it costs to make it usable
- how many hours your employees need for the rollout and for training
- who runs the system after launch and with what share of their time
- how many of the purchased seats are really in use after a year
- what data protection, permissions and co-determination require in preparation
That does not make the seat price unimportant. It is one line out of six. How large that line is compared with the rest can only be answered by a calculation, and that is what we build now.
The Six Cost Blocks at a Glance
We split the cost into six blocks. The split is a suggestion, not a standard. What matters is not the name of the blocks but that none is missing when you lay offers side by side. The graphic shows the blocks with their basic formula, and the table below summarizes them.
| Block | What it contains | Occurs | Basic formula |
|---|---|---|---|
| License or operation | Seat price, price per active user, usage fees or running it yourself | recurring | Seats × price × months |
| Connection | Access, permissions and tests for each connected system | one-off | Systems × days per system × day rate |
| Data preparation | Sorting, cleaning, clarifying responsibilities | one-off | Days × day rate |
| Training | Working time of employees, materials, refreshers | one-off | People × hours × hourly rate |
| Operation and upkeep | A responsible person, permission management, quality checks | recurring | Share of a post × annual cost × years |
| Security | Data protection review, permission concept, co-determination, evidence | one-off and recurring | (One-off days + days per year × years) × day rate |
Total cost is then the sum of all six blocks over the chosen period:
Total cost = License or operation + Connection + Data preparation + Training + Operation and upkeep + Security
And because the total is not what counts in the end, but what a person who actually uses the AI costs:
Cost per active user and month = Total cost divided by (active users × months)
Two decisions up front. First, the day rate: it is an internal charging rate. For external services it is the agreed rate, for your own employees the internal cost rate. If you do not think in day rates internally, do not set the effort to zero, estimate it. Working time costs money even when no invoice arrives. Second, the period: we calculate with 36 months. A shorter period makes one-off costs weigh more than they should, a longer one makes the forecast less certain.
License or Operation: Four Pricing Logics, Four Formulas
The block everybody knows is less uniform than it looks. There are four common pricing logics, and each one shifts the risk to a different place.
| Pricing logic | Formula | What to watch for |
|---|---|---|
| Price per seat | Seats × price × months | An unused seat costs as much as a used one. Check minimum volumes and tiers |
| Price per active user | Active users × price × months | How is “active” defined, who measures it and how often |
| Usage fees | Requests × price per request | The bill moves with behavior. Agree on a cap or a budget |
| Running it yourself | Infrastructure + operating staff + model access | Updates and availability are on you |
A price per seat is simple and predictable, but the utilization risk sits with you. With a price per active user, cost follows usage, and the decisive contract point is the definition of “active”: after how many requests, within which period, measured by whom? With usage fees, the bill swings with the behavior of your employees, which is why a cap belongs in the agreement. When you run the system yourself, you pay no license to a vendor, but you carry infrastructure, operating staff, updates and availability. That can pay off, but it is not a saving, it is a shift.
In the interest of transparency: a TheroAI offer consists of a one-off onboarding, the ongoing operation of the instance and a price per active user. Scope, connectors and deployment model are agreed before the start. This article does not name prices. It is meant to help you put every offer, ours included, into the same grid.
Two more questions belong with every pricing logic. How long is the term, and what applies on termination? And may prices be adjusted, and if so, when? Do not plan with price cuts that nobody has promised you in writing.
Connection: Count Systems, Not Features
An assistant is only as useful as what it can reach: the document store, the mailbox, the ticket system, the knowledge base. Every connected system means work. Access has to be set up, the scope defined, permissions checked, real questions tested, and someone named as the contact person.
The formula is: systems × effort per system × day rate. With four systems at ten days each, that is 40 days. At four days each, it is 16. Where the difference comes from is rarely spelled out in the offer. Usually it depends on whether a ready-made connection exists for a system or a custom interface has to be built.
A catalog of ready-made connections shortens the road. The TheroAI connector catalog currently lists 29 apps, among them Google Workspace, Microsoft 365 and Atlassian.
Ready-made does not mean free of work, though. An AI that searches documents may only show what the asking person would be allowed to see anyway. How permissions are taken over and kept current is part of the connection and belongs in the effort estimate. In the setup of our Google Drive connector, for example, it says that user permissions are indexed and that content and permissions are updated several times per hour. Whether that is enough for your stores, and whether the sharing settings there are clean, is best checked with real examples.
A practical rule: do not start with all systems, start with the one or two in which the answers for your first use case live. Every additional system is a new line in the calculation that only pays off once the benefit is established.
Data Preparation: The Block That Gets Forgotten
A fictional example: the framework agreement TP-118 sits in three folders. Once as a draft with comments, once as a signed scan, once as a Word file of unclear status. An employee asks the assistant about the payment term. The assistant finds all three versions and has to decide which one applies. A good system names its sources and so makes the contradiction visible. It cannot clean up, that is work for people.
Data preparation covers everything that makes your stores usable for an AI: archiving duplicates and outdated versions, clarifying who owns each store, cleaning up old shares and permissions, setting naming rules. The formula is plain: days × day rate. The hard part is estimating the days. Do not estimate across the board, estimate source by source: how many stores are affected? Who knows their condition? How many documents matter for the first use case?
Two things argue for calculating this block honestly. It rarely appears in offers, because it happens inside your company. And it is one of the few blocks that pays off even without an AI: tidy stores help everyone who is looking for something.
Training: The Cost Is in Your Time Sheet, Not in the Offer
Training is the block with the most invisible invoice, because nobody sends one. The cost is the working time of your employees. The formula: people × hours × hourly rate. If 100 people are trained for 3 hours each and the internal hourly rate is €60, that comes to €18,000. It is the same calculation you would make for any other rollout.
More important than the sum is what it stands for: utilization. People who do not know what to use the AI for will not use it, and then you pay for seats nobody needs. Good training is therefore not a product tour. It has four parts: a basic understanding (what the AI can do and where it can be wrong), the use cases of the person's own department, the rules (which data may go where) and contacts for questions. Shared templates reduce the effort. In TheroAI, the library holds prompt templates for typical tasks, filterable by department.
Also plan a refresher, because features change and new employees join. For simplicity, the example calculation further down only counts the initial training.
Operation and Upkeep: Somebody Has to Carry It
After launch begins the part that has no end in any project plan. Somebody has to manage users and groups, watch the connections, maintain tool permissions, evaluate feedback and communicate changes inside the company. In TheroAI, the administration shows for each connected app the status, the state of indexing and the number of documents. That helps with watching, but it does not replace the person who looks and acts.
The formula: share of a post × annual cost × years. With an annual cost of €90,000 for one position, 0.2 of a position is €18,000 per year, €54,000 over three years. A share of a position is an estimate, but an estimate beats zero, because zero is guaranteed to be wrong.
Two questions help to place it. Who in the company carries the responsibility, perhaps as a pair from IT and the business side? And what happens during vacation or when that person leaves the company? Operation that hangs on a single person is a risk you will not see in any calculation but will notice in daily work.
Security and Co-Determination: Preparation That Takes Time
Security is not an add-on product here, it is work before the start and after it. It includes the data protection review including a data processing agreement (Art. 28 GDPR), clarifying where data is stored and processed, a permission concept and rules on which actions need an approval. With TheroAI, data is stored in Germany and AI processing takes place in the EU. Whether that meets your requirements still belongs in your own review. You will find more on the security page.
Then there is co-determination. Under section 87(1) no. 6 of the German Works Constitution Act, the works council has a say in the introduction and use of technical systems intended to monitor the behavior or performance of employees. Whether and how that applies to your system is a question for the individual case. This is not legal advice, so clarify the individual case with your legal counsel. Plan time for conversations and agreements, not just for lawyers.
On an ongoing basis, permissions have to be maintained. In the AI tool settings of our demo environment, every tool can be set to allow, ask first or block (labeled Erlauben, Nachfragen and Sperren in the German interface). The overview there shows 236 allowed tools, 138 that ask first and 0 blocked. That shows how quickly permissions turn into many individual decisions, and each one takes time.
Traceability belongs here too. The audit log records what ran and when, and can be exported as CSV. But it only works if somebody looks at it. Plan fixed dates for that, for example once a quarter.
The formula for the block: (one-off days + days per year × years) × day rate. With 12 days one-off and 4 days per year, that makes 24 days over three years.
Example Calculation: Two Offers over 36 Months
Now we calculate. The example company is invented: 250 employees, 100 purchased seats, 60 of them active users, four systems to connect and a period of 36 months. General assumptions: day rate €1,000, internal hourly rate €60, annual cost of one position €90,000. Offer A has the lower seat price but demands more of your own effort for connection, data and operation. Offer B has the higher seat price and, by our assumption, comes with ready-made connections and rollout support. Both are assumptions for the example, not statements about real offers.
| Assumption (example values) | Offer A | Offer B |
|---|---|---|
| Price per seat and month | €30 | €45 |
| Purchased seats, of which active users | 100, of which 60 | 100, of which 60 |
| Systems to connect | 4 | 4 |
| Effort per system | 10 days | 4 days |
| Data preparation | 25 days | 15 days |
| Training (one-off) | 100 people × 3 hours × €60 | 100 people × 3 hours × €60 |
| Operation and upkeep | 0.3 of a position | 0.2 of a position |
| Security | 12 days one-off, 4 days per year | 8 days one-off, 2 days per year |
This gives the following calculation over 36 months:
| Block | Offer A | Offer B |
|---|---|---|
| License or operation | €30 × 100 × 36 = €108,000 | €45 × 100 × 36 = €162,000 |
| Connection | 4 × 10 days × €1,000 = €40,000 | 4 × 4 days × €1,000 = €16,000 |
| Data preparation | 25 days × €1,000 = €25,000 | 15 days × €1,000 = €15,000 |
| Training | 100 × 3 hours × €60 = €18,000 | 100 × 3 hours × €60 = €18,000 |
| Operation and upkeep | 0.3 × €90,000 × 3 years = €81,000 | 0.2 × €90,000 × 3 years = €54,000 |
| Security | (12 + 4 × 3) days × €1,000 = €24,000 | (8 + 2 × 3) days × €1,000 = €14,000 |
| Total | €296,000 | €279,000 |
What the calculation shows: for Offer A, license costs are €108,000 of €296,000, about 36 percent. Almost two thirds of the cost is not on the price list. For Offer B it is €162,000 of €279,000, about 58 percent. B's seat price is 50 percent above A's, yet its total cost is €17,000 or about 6 percent lower. In this example the ranking by seat price is the reverse of the ranking by total cost.
Now the more important part: how robust is this? Change a single assumption. If ready-made connections were available for Offer A as well and the effort per system were only four days, the connection cost of A would drop from €40,000 to €16,000 and its total to €272,000. Then A would be €7,000 cheaper than B. The ranking flips on one line.
That is not a weakness of the calculation model, it is its purpose. It shows you which assumption carries the result, and with that, which question to ask the vendor before you sign. In this example it reads: which connections are ready-made, and what exactly stays with us?
Cost per Active User: Utilization Outweighs the Difference Between Offers
Total cost is a big number that is hard to work with. More telling is the figure per person who actually uses the AI. With 60 active users over 36 months, you get 2,160 user months. Offer A therefore costs €296,000 divided by 2,160, about €137 per active user and month. Offer B costs €279,000 divided by 2,160, about €129.
Looking at the license alone, A's seat price of €30 becomes an effective €50 per active user (€108,000 divided by 2,160). For B, €45 becomes €75. That is the price you actually pay for each person who uses the AI when 40 of the 100 seats stay idle.
What happens when usage turns out differently than planned? Total cost stays the same, only the denominator changes:
| Active users out of 100 seats | Offer A (euros per user and month) | Offer B (euros per user and month) |
|---|---|---|
| 40 | 206 | 194 |
| 60 | 137 | 129 |
| 80 | 103 | 97 |
If the number of active users halves from 80 to 40, the cost per user doubles. The span between 40 and 80 active users is about €103 for Offer A. The difference between the two offers at 60 active users is about €8. In this example, utilization therefore has more than ten times the effect of the difference between the offers.
That moves the work to where it pays off. If you want to lower the cost per user, you have two levers: push total cost down or raise the number of active users. The second has the stronger effect here, and it hangs on the blocks training, connection and data preparation. An AI that reaches the right systems and whose answers can be relied on is more likely to be used. Nobody can guarantee it.
This side of the calculation only answers the cost question. How much time usage saves in the best case you can play through in the ROI calculator. There, too, the values are model assumptions, not tariff prices. Do not blend cost and benefit into one number: first the honest cost calculation, then the benefit estimate, then the comparison.
Mistakes When Comparing: Six Stumbling Blocks
Six typical mistakes follow from the calculation. The matrix shows the core of the first: a seat price fully answers exactly one of the six questions.
| Mistake | Why it gets expensive | Remedy |
|---|---|---|
| Comparing seat price instead of total cost | Five of six blocks stay invisible | Put all offers into the same grid of six blocks |
| Counting seats instead of active users | With 60 of 100 seats in use, €30 becomes an effective €50 | Calculate cost per active user, with a range |
| Setting your own effort to zero | The working time disappears from the calculation, but not from the calendar | Estimate day rate and hourly rate |
| Comparing different periods | One-off costs weigh more over 12 months than over 36 | Calculate all offers over the same period |
| Extrapolating the pilot | A small pilot hides the connection, operation and permission work of the larger rollout | Calculate pilot and regular operation separately |
| Calculating only one scenario | A single assumption can flip the ranking | Three scenarios: cautious, expected, favorable |
A cross-check on the second mistake: you do not have to avoid every offer with a price per seat. But you should know what you actually pay per person using it at 60 percent usage. On the fourth: a vendor with high one-off costs and a low monthly fee looks expensive over one year and perhaps cheap over three, and the other way round. Without a shared period, you are comparing two different things.
A seventh point does not belong in the table but in the negotiation: exit costs. How do your data and settings get out again, in which format, and what does switching cost? An offer that only describes the entry is incomplete.
The Calculation in Five Steps
From the six blocks, the example and the mistakes comes a procedure you can repeat with every offer.
- 1.Fix the period. Calculate all offers over the same 36 months so that one-off and monthly costs carry the same weight.
- 2.Write down assumptions per block. Quantity, effort and rate, each with its source: is it in the offer, does it come from experience, or is it an estimate?
- 3.Separate one-off from recurring. One-off costs plus months times monthly costs give the total cost.
- 4.Divide by active users. Total cost divided by active users times months gives a figure you can compare between offers.
- 5.Vary the usage. Calculate with 40, 60 and 80 active users and watch which assumption changes the ranking.
And these are questions every offer should answer before you start calculating:
Which systems are connected, and which connections are ready-made?
How much effort stays with us, estimated in days?
How is “active” defined, and who measures it?
What applies to term, termination and price adjustments?
What does the exit cost, and in which format do we get our data back?
What You Can Take Away
You do not have to choose us to work with this calculation model. Six steps worth trying right away with your own figures:
- Put every offer into the grid of six blocks. If a line stays empty, ask instead of entering zero.
- Fix a shared period, ideally 36 months, and calculate all offers over it.
- Note the assumption and its source for every block: offer, experience or estimate.
- Divide the total cost by active users, not by seats, and calculate with 40, 60 and 80 active users.
- Change the most influential assumption as a test and check whether the ranking flips.
- Ask about exit costs, term and price adjustments before you sign.
Our position: a price list is a good start for a conversation and a poor end for a decision. Decide on the basis of a calculation you can follow yourself and repeat with your own numbers. A vendor who helps you set up this calculation instead of shying away from it makes their offers comparable.
If you would like to put an offer into this grid together, a demo is a good place to see how TheroAI works and which assumptions you would have to make for your systems. No pressure: you can also set up the calculation on your own.
See Thero live
Book a short demo. You talk directly to the founding team.