Per-Seat vs Flat-Rate Support Tool Pricing

What are the four pricing models in support software today?

Per-seat pricing charges for each person with a login. Per-resolution pricing charges each time automation closes a conversation. Per-session or monthly-active-user pricing charges for how many people the widget was shown to or interacted with. Flat-rate pricing charges one price regardless of seats, conversations, or traffic.

That last column is the point of the whole article. Every model creates an incentive for you to do something slightly irrational, and the cost of that distortion is often larger than the difference in monthly invoices. A team that shares one login to avoid a seat fee has destroyed its ability to attribute conversations, audit access, or measure individual quality, and it did so to save an amount that is trivial next to the cost of the confusion.

Why does the pricing model matter more than the price?

Because you will live inside the model for years and inside the price for one negotiation. Prices move, discounts appear at renewal, and a good procurement conversation can shift a line item. The model shapes daily decisions that nobody logs.

The clearest example is per-resolution pricing on AI. On paper it sounds fair: you pay for outcomes. In practice it means every improvement in your knowledge base raises your bill, and the better your automation gets, the more it costs. Teams in that position start asking whether they should route more conversations to humans to control spend, which is precisely backwards.

Session and MAU pricing has a quieter version of the same problem. A successful marketing campaign, a product launch, or a viral week increases what you pay for support without increasing the number of people who needed help. Some teams respond by hiding the chat widget on high-traffic pages, which is a self-inflicted wound dressed up as cost control.

How do you calculate your per-seat break-even?

One division. Break-even seats = flat monthly price divided by the quoted per-seat price, using the tier that actually contains the features you need, not the cheapest tier on the page.

The table below uses a $99 flat rate and hypothetical seat prices. These are not any vendor's prices. Find the number on your quote in the left column and read across.

Two adjustments make this honest. First, count everyone who needs a login, not just full-time agents. Founders, the ops person who checks billing questions, and the engineer who answers API threads all consume seats on most plans. Teams routinely undercount here by half. Second, use the tier price after adding whichever add-on carries the AI capability, because that is usually where the number you were quoted stops being the number you pay.

How do you compare per-resolution pricing to a flat rate?

Same idea, different divisor. Break-even resolutions = flat monthly price divided by the quoted per-resolution rate.

Using a $99 flat rate and placeholder rates that are not any vendor's published price:

Then ask the question that matters more than the rate: what counts as a resolution? The definitions differ enough to change your bill by a wide margin. Some vendors count any conversation automation closed without a human. Some require the customer to confirm. Some count a reopened conversation as a second resolution. Some count a conversation where the bot only greeted the customer.

Several of these definitions are published, if you go and read them. Intercom counts an "Assumed Resolution" when "a customer disengages from the conversation for 24 hours after Fin's last answer", and states on the same page that "if a customer asks for a human or shows frustration, Fin escalates based on its default logic. You are not billed for these escalations." Gorgias bills when its AI "resolves a customer conversation entirely on its own". Front bills its Autopilot per conversation rather than per resolution, and Freshdesk sells extra AI capacity by the session, which is consumed whether or not the issue is solved. All fetched 2 August 2026. Four vendors, four different meters, and silence counts as a win on at least one of them.

Get the definition in writing, and get the answer to one more question: what happens when the assistant gives a wrong answer and a human has to redo the work? If you pay for both the automated resolution and the agent's time, you are paying twice for one failure.

What are you actually paying for with per-session pricing?

Per-session and monthly-active-user models charge based on how many people the widget reached, which means you are buying audience rather than work. The distinction sounds academic until you notice that a person who opened the chat, read the greeting, and closed it can land on your invoice identically to a person you spent twenty minutes helping.

That decoupling cuts both ways, and it is worth being fair about. If your traffic is stable and your contact rate is high, a session model can be cheaper than paying for seats you barely use, because you pay only when someone engages. It also scales down naturally in a quiet month, which per-seat pricing never does.

The failure mode is spikiness. A launch week, a press mention, a paid campaign, or a seasonal peak all inflate sessions without inflating the number of people who actually needed support. Your bill tracks your marketing calendar instead of your support workload, and forecasting becomes an argument between two departments.

Three questions settle whether the model fits you. Does a session count if nobody sends a message? Does the same person returning the next day count again? And is there a monthly ceiling you can set so a viral week cannot produce a bill nobody approved? Ask all three before you compare the headline rate to anything.

Which costs never appear on the pricing page?

The subscription is often not the largest number in year one. The hours are.

Estimate migration honestly: exporting history, remapping fields, rebuilding macros and views, reconnecting integrations, and retraining the team. Multiply your total hour estimate by your loaded internal hourly cost and put that figure next to the subscription. For a team moving off a heavily customized platform, that line frequently exceeds the annual license, and no vendor will volunteer it during a demo.

Then check for the lines that surprise people at renewal: sandbox or testing environments that require a higher tier, API rate limits that force an upgrade once you build anything, per-channel charges for voice or messaging, data export terms if you leave, and whether an annual contract lets you reduce seat count mid-term. Adding seats mid-term is almost always easy. Removing them frequently is not, which is exactly the asymmetry to check in the contract before you sign a headcount you have not hired yet.

What should you ask a vendor in writing before signing?

Send these as an email, not as demo questions. Written answers are quotable at renewal; verbal ones are not.

Before you plan the afternoon, check there is something to compare. Neither Decagon nor Ada published a price of any kind as of 2 August 2026; both route every visitor to a demo request. If a vendor will not put a number on a public page, budget a week for the written-answer round rather than an hour.

The fair-use question is the one flat-rate buyers skip, and they should not. A vendor selling unlimited anything has an incentive to keep the cap vague. Ask for the number. If nobody will give you one, treat the word unlimited as marketing rather than a term.

Where is flat-rate pricing the wrong choice?

At one or two seats on a low-tier plan, per-seat pricing is genuinely cheaper, and that is not a close call. If you are a solo founder answering email yourself and you do not expect to add anyone this year, the arithmetic above says buy the seat.

Flat-rate vendors also tend to be smaller companies with narrower products. If procurement requires a specific compliance package, a named account manager, custom data residency, or an uptime commitment with financial penalties, larger platforms are built for that and small ones frequently are not. Saying otherwise would be selling you something you will regret at the security review.

Seasonal teams are the other honest exception. If you staff up sharply for a few months a year and drop back down, a per-seat plan that lets you add and remove seats on a monthly cycle can beat a flat rate you pay through the quiet half of the year. Check the contract language before assuming it, because monthly seat reduction is a term you have to be granted rather than one you get by default.

The same applies to scope. Workforce management, contact-center telephony, deep multi-brand routing, granular role permissions across dozens of agents, and heavy workflow customization are enterprise-suite jobs. Paying several times more for a platform that actually does them is the correct decision, not a failure of negotiation. If you are weighing that trade specifically, our Zendesk comparison lays out which side of the line different teams fall on.

Does the pricing model change how your team behaves?

It does, in ways that rarely make it into a spreadsheet. Per-seat teams share logins and delay adding the teammate who should obviously be in the inbox. Per-resolution teams hesitate to improve the knowledge base. Session-priced teams hide the widget. These are all rational responses to the incentive and all bad for customers.

Flat-rate has its own distortion, and it points at the vendor rather than at you. When revenue does not grow with your usage, the vendor's margin improves if your usage stays low, which creates pressure toward cheaper models, slower responses, or quiet caps. The honest defence is transparency: published limits, a stated fair-use number, and pricing you can read without a call. That is the standard we hold ourselves to on our pricing page, and it is the standard you should demand from any flat-rate vendor including us.

Pick the model whose distortion you can live with. For most teams under about thirty agents, that means paying for outcomes you control rather than for headcount, traffic, or automation success.

How do you run this comparison in one afternoon?

Six steps. First, count every person who needs a login, including part-timers and founders. Second, list the features you will actually use in the next twelve months and find the tier that contains all of them, not the tier in the demo. Third, get a written quote with the add-ons included.

Fourth, run the two divisions above. Fifth, estimate your migration hours and multiply by your loaded hourly cost, then add it to year one. Sixth, send the seven written questions and wait for answers before signing anything annual.

That is it. The exercise takes an afternoon and it is the only version of this comparison that stays accurate, because it uses today's numbers rather than a table someone published months ago. If a flat rate turns out to be the right shape for your team, you can start a free trial and check the fit before the pricing conversation happens at all.