What are you actually buying with per-seat pricing?
Per-seat pricing, also sold as per-agent pricing, puts a monthly price on every login. It is the oldest model in the category and still the backbone of how Zendesk, Freshdesk, Help Scout and Intercom package their plans, usually inside tiers where a richer feature set raises the price of every seat at once.
The appeal is predictability. You know how many people you employ, so you can forecast the line item, and adding a person is a decision you make on purpose rather than something that volume does to you while you are not looking.
The real cost of per-seat is behavioral. Once a login carries a price, you start rationing logins. The weekend part-timer, the warehouse lead who could answer one shipping question a day, the bookkeeper who knows the refund policy better than anyone, the owner who wants to read raw customer messages on a Sunday: each of them now has to justify a recurring fee. So most of them never get access, support knowledge pools inside a small group of permanent seat holders, and handoffs that should take one sentence turn into relays through the only person with the password.
Per-seat also sits awkwardly next to automation. If software starts answering the routine questions, the work per agent falls, but a per-seat bill does not notice. You are paying for capacity rather than for work completed, which is comfortable while those two track each other and annoying once they separate.
Before you sign a per-seat plan, pin down the seat definitions. Some vendors offer free light or collaborator roles for people who only need to read and comment, which quietly solves much of the rationing problem. Ask whether a seat can be reassigned mid-cycle, whether removing one lowers this month's invoice or only the renewal, and whether admin and developer accounts are billed like everyone else.
How does per-ticket pricing change the way your team works?
Per-ticket pricing bills for cases created. Gorgias is the best known example of volume-tiered packaging built for ecommerce, where plans are sized by how many tickets you handle in a month rather than how many people handle them.
The advantage is that cost tracks demand instead of headcount. Everyone in the company can have an account, so anyone can pitch in during a rush without changing the bill. For a small shop where the owner, a seasonal hire and a fulfillment partner all touch customer messages, that is a better fit than counting logins.
The first disadvantage is timing. The invoice peaks exactly when the month is worst. A shipping delay, a failed release, a payment outage or a viral complaint produces both the workload and the surcharge, and the surcharge lands while you are already apologizing to people.
The second disadvantage is quieter. Per-ticket pricing prices customer contact as a problem to be reduced. Teams on these plans start burying the contact link, closing threads early, merging aggressively and pushing people toward a form. Some of that is healthy deflection. Some of it is hiding from customers in order to manage a line item, and it is hard to tell the two apart from inside.
Definitions decide what you actually pay. Ask whether a reopened ticket counts a second time, whether filtered spam counts, whether a ticket your team creates proactively counts, and whether one customer writing to two of your addresses creates two billable tickets.
Is per-conversation pricing different from per-ticket in practice?
It is, because the unit has a different shape. A conversation is a window of time rather than a single case: all of the back and forth between one customer and your team inside that window is billed once. Tidio and other chat-first tools lean on this unit, partly because the messaging platforms underneath them work the same way. WhatsApp business messaging is itself sold in conversation windows, so vendors reselling it tend to mirror the unit rather than invent a new one.
Conversation pricing is usually kinder than ticket pricing for live chat, where a single simple question arrives as six short messages. It is less kind to slow email threads that stretch across several windows, because one unresolved issue can be billed again every time it rolls over into a new period.
The questions to ask are mechanical. What opens the window, what closes it, does a human reply start a new billable conversation, do your own outbound or proactive messages open one, and does a customer who returns the next day with the same question count twice. Two vendors can both print "per conversation" on the page and mean materially different things.
Why does per-resolution pricing sound fairest and still surprise people?
Per-resolution pricing charges when an AI agent finishes a case without a human. Intercom's Fin made the unit familiar, and Zendesk sells automated resolutions on a comparable basis. On paper it is the fairest model available: you pay for outcomes, not for software sitting idle.
Three things tend to surprise buyers after the first few invoices.
The first is the definition. A resolution is defined by the vendor, typically as something like "the customer did not escalate to a human or reopen the case within a set window". That bucket holds customers who got a genuinely good answer and customers who gave up and went away, and you are billed identically for both. Read the definition, then ask what your dashboard would show if a frustrated customer simply stopped replying.
The second is the direction of the incentive. The better your help content gets, the more cases automation closes, and the more you pay. Writing a clear returns policy article becomes an investment that raises a variable cost. That is not dishonest, but it is the reverse of how most software savings work, and it deserves a moment of thought before you commit.
The third is forecasting. Your bill becomes the product of two numbers you only partly control: how much your customers contact you, and how often automation closes the case. For a business trying to hold a steady monthly number, two moving variables is one too many.
What happens when vendors stack these models together?
Most real quotes are hybrids. A typical proposal is per-seat for humans, plus per-resolution for AI, plus feature gating by tier, plus add-ons for voice minutes, extra channels, sandboxes or priority support. Each layer is defensible on its own. Stacked, they make two quotes nearly impossible to compare by reading them side by side.
Open source changes the shape of the cost rather than removing it. Chatwoot can be self-hosted, which converts license fees into servers, upgrades, security patching and engineering attention. If you have an engineer who enjoys that work, it is a real option with real control. If you do not, the cost has not disappeared, it has only stopped arriving as an invoice.
None of these models is a trap by design. Per-seat suits agencies with stable staffing and strict access rules. Per-ticket suits merchants with seasonal spikes and a wide bench of occasional helpers. Per-resolution suits companies with a large, repetitive and well-documented question set. What hurts is the mismatch between the model and your business, not the model itself. If you are mid-way through this comparison because an existing plan grew faster than your team did, a walk through Zendesk alternatives is a reasonable next step.
How do you compare quotes that use different units?
Do it on one page, in this order.
List the billable units each vendor charges on. Then count your own figures for a normal month: people who should have access, not only the ones who have it today, cases created, chat threads opened, and questions that could plausibly be answered from content you already have on your site.
Price every quote against that normal month, then against the worst month you have actually lived through, then against the volume you would see if the business doubled. Add the costs that never appear in the headline: migration, implementation, training time, paid channel add-ons, and an agency fee if the setup needs a developer. Finally, ask in writing what happens at overage. Blocked, throttled, auto-upgraded to the next tier, or billed after the fact are four very different answers.
Flat pricing exists to collapse that whole exercise into one line. Corebee charges a flat $99/month with unlimited seats and unlimited AI conversations, with no per-seat and no per-resolution component, so the worst month and the best month produce the same number. You can see the full breakdown on the pricing page.
Which model fits a small or mid-size business best?
For most small and mid-size teams, the metered models fit badly for the same underlying reason: the things they meter are the things you cannot predict. Your volume is spiky, your headcount is fuzzy because half your helpers do support as a second job, and your documentation is uneven, so any estimate of an automation rate is a guess dressed as a forecast.
Flat pricing answers that by moving the uncertainty to the vendor. Everyone who should be able to help gets a login, including the seasonal hire and the owner. A bad week costs the same as a quiet one. You can improve your help content without watching a variable cost climb in response, and you can add a channel because customers are asking for it rather than because the budget happens to allow it this quarter.
That is the model behind Corebee. One shared inbox covers web chat, email, voice with an AI receptionist that tells callers it is an AI, WhatsApp, Slack, Facebook, Instagram, SMS and Telegram. It answers from your website and your knowledge base, hands off to a human when someone asks or when it is unsure, books meetings through Cal.com or Calendly, and syncs to HubSpot, Salesforce, Pipedrive, monday or Zoho. Setup runs about ten minutes and does not need a developer.
The honest summary is this: pick the unit that your business grows slowest on, or pick a flat plan and stop having the conversation. What you should not do is sign a quote whose billable unit you cannot define in a sentence.