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

One of 49 field notes on AI coding agents. The whole set, and the sources behind every number, is on GitHub.

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

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.

Read next — more field notes from the same collection:

What a coding-agent model costs, next to how it ranks · AI Model Costs: Beyond Per-Token Pricing · Choosing the Right AI Model for Coding: Cost vs. Efficiency · The Hidden Costs of GPT-5.6 Model Selection: A Developer's Real-World Guide · Klarna Replaced 700 Support Agents With AI. Then It Started Hiring Again.

Part of llm-api-pricing — field notes on AI coding agents. This one is also on the web, where it links out to the related write-ups. Every figure across the whole collection is also published as JSON and CSV, each row with the sentence it came from.

Want this priced for your own usage? The price table behind these write-ups is also a calculator — one page, nothing to install, no account. It reads the same daily JSON as the table, resolves the peak/off-peak clock for the moment you are asking, applies the long-context cliff to the request you actually send, and lets you put in your own cache-hit share. 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. Does your own number disagree? This same piece has a reply box — it ends on one question written from the figures above, and one line answers it. No template, no title, nothing to organise first. 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. Requests get turned into rows. Got a better number? Open an issue — the form already knows which write-up you came from; corrections and counter-data are the point.