Charge Per Conversation, Not Per Seat: The Billing Model Behind AI Support

Written with AI assistance. Figures without a traceable source were cut before publishing.

The same piece is posted as a thread on GitHub — that copy has a reply box under it, and this one does not.

Respond.io bills its customers for every contact who had a conversation in a given month rather than for every employee login, and I think that one decision explains more about the company’s position than any feature on its comparison page. Seat-based pricing ties a vendor’s revenue to the size of a customer’s support team, which is a strange thing to bet on in a year when everyone is trying to shrink that team. Conversation-based pricing ties revenue to message volume instead, so a customer who automates half their replies and doubles their conversation count is worth more to the vendor, not less. That alignment is rare, and it is worth copying.

The Problem Underneath Is Boring and Universal

Before the billing model matters, the pain has to be real, and here it is plainly stated: merchants selling internationally have no single place to manage customer messages.

Conversations arrive on WhatsApp, on Instagram, on whatever channel a given market prefers, and each channel keeps its own fragment of the customer. Profiles end up scattered. Handoffs between staff get messy, because the person picking up a thread cannot see what happened on a different platform yesterday. Nobody writes a blog post about this problem, which is exactly why it stayed unsolved long enough to build a company on.

Scattered inboxes. One customer. That is the whole gap.

I’d argue this is the more instructive half of the story for anyone building something. The AI is the current headline, but the durable asset is being the place where all the threads land, and the AI only has leverage because it sits on top of consolidated context. An assistant that can see one channel is a chatbot; an assistant that can see the full history of this customer across every channel is doing something a human agent could not do quickly either.

Automation Only Pays When It Can Touch Real Systems

The distinction that separates useful support agents from expensive ones is whether they can act.

Respond.io’s AI agent calls external systems to make bookings and check inventory, and that is a different category of product from one that answers questions about the return policy. A deflected FAQ saves a few minutes of staff time. A booking made at 11 p.m. without anyone awake to make it is revenue that did not previously exist, and the customer on the other end experiences it as service rather than as a wall.

The same pattern shows up in a completely different setting, which is why I find it convincing. An analyst asked an AI to write DAX for Power BI and the generated code failed immediately, because the model had invented table and column names that did not exist in the actual model. With a built-in Power BI modeling skill and an MCP connector giving it access to the real environment, the corrections became mechanical, and verifying the code dropped from an entire afternoon to a few minutes. The user’s role changed from translator and hauler to requester and acceptor.

Connected agents act. Disconnected ones guess.

That is not a subtle difference in output quality; it is the difference between a tool that produces a draft you have to check line by line and one that produces something already validated against the system it will run in. Honestly, I would use “can it reach the real system” as the first question about any agent product, ahead of which model is underneath.

What the People Making Money Actually Use

There is a case worth quoting because the numbers are specific and the pattern behind them is more useful than the headline. A former Alibaba P8 engineer, laid off and 3 months into an unsuccessful job search, ended up running three separate AI instances — one tracking competitor pricing, one generating ad creative, one handling customer service — and reports about 170,000 yuan a month. The individual figure is self-reported and I would not build a plan around it.

The pattern across the collection it came from is the part I would keep. Out of 27 documented cases, the ones earning money used at least 3 of the same 5 capabilities: scheduled automation, multiple agents running in parallel, packaged Skills, MCP connectors, and a memory system. Not better prompts. Not a specific model.

Look at that list next to the Respond.io setup and it matches almost item for item. Scheduled automation and parallel agents are how you cover a Black Friday spike without hiring. Skills and MCP connectors are how the booking actually happens. Memory is how the customer stops repeating themselves on the third channel.

The Vendor-Side Lesson

If you are building the software rather than buying it, the billing decision deserves as much design attention as the product.

Per-seat pricing made sense when software’s value scaled with how many people touched it. For anything agent-shaped, the value scales with volume handled, and the customer’s explicit goal is fewer people. I suspect a lot of AI support products are quietly fighting their own pricing page, promising to reduce headcount while charging by headcount, and the sales conversation that results is unwinnable in a way nobody attributes to the pricing model.

Enterprise buyers push in the same direction from the other side. What they ask for at platform level is aggregation: models, interfaces, data, billing, and access all unified in one place. Billing aggregation sits in that list right alongside model aggregation, which tells you the finance side of this is a first-class product requirement rather than an afterthought for the ops team.

And whatever you charge for, tie the claim to a number the buyer already tracks. Moving from efficiency AI to growth AI means binding to metrics like new-product success rate or inventory turnover instead of promising unspecified savings; a project that only lives in customer service and copywriting never moves a core operating number, and eventually someone notices.

Build It Like an Org Chart, Not a Prompt

One more thing carries over from how these systems get built, and it took me a while to accept it.

Multi-agent development is closer to organizational design than to model-calling technique. The failure people hit is letting a single agent define the requirement, implement it, and then announce that it is finished, which leaves the whole process with no independent check and piles requirements, error output and conversation history into one context. Splitting by responsibility fixes it for the same reason splitting by responsibility works among people.

And the input that matters most is not the prompt. A requirement document beats prompt tuning, because an agent that misbehaves is often responding to a requirement that was never defined, an interface standard that was inconsistent, or a project constraint that existed and was never written down anywhere. Define what the service does, what problem it solves, which functions the current version has and does not have, and which constraints apply. That document is what a fresh session reads instead of re-deriving everything, and I’d argue it is the cheapest artifact on this entire list.

Where I Would Still Keep a Person

None of this argues for removing humans from the loop, and the boundary is fairly crisp.

In a hiring workflow that decomposed a role into observable, scoreable dimensions, the AI screening worked well and the interview stayed human, because tone, pauses and hesitation are signals the AI never receives. Support has the same structure. Order status resolves against a rule. A customer writing in for the third time is communicating mostly through things your ticket schema does not record, and routing them into an agent flow is how you get the efficiency metric to look good while the relationship gets worse.

Build the connector layer, charge for volume rather than seats, and keep a person on the threads where the meaning is not in the text. That last part is the piece that gets cut first when the dashboard looks healthy, which is precisely when it is doing the most work.

Also readable on Telegraph.

Read next

All 49 write-ups

The 1 figures in this piece — each with the sentence it came from — are in the figures table, alongside 407 more, as JSON and CSV.

Topics: Automation Systems · SaaS Business · Revenue Growth

Part of llm-api-pricing — field notes on AI coding agents.

Did this save you an afternoon? A star on the repository is the whole ask — it is what puts these in front of the next person looking; the data is CC BY and does not require starring.

One thing this piece could not settle: reply with the exact number of conversations your current AI support platform bills per month, and compare it to the conversation-based model used by Respond.io. The reply box is on the thread copy of this piece.

Want a figure that is not in here yet? Say which metric, which provider, which unit — in one line. One required field, and the page you came from is already filled in. Got a better number? Open an issue — that form knows which write-up you came from too; corrections and counter-data are the point.