Someone has quoted you a five-figure sum for an AI assistant. Someone else has told you that AI is basically free now and their nephew could do it in a weekend. Both statements contain some truth, which is exactly why the question is so hard to get a straight answer to.
The confusion comes from lumping two completely different numbers into one question. AI chatbot cost is really two figures, and they behave nothing alike. A custom assistant grounded in your own content typically costs $8,000 to $60,000 to build, and $100 to $2,000 a month to run. The build is a one-off you can scope and fix. The monthly figure is not a licence fee and not a per-seat charge: it is a cost per conversation, which means it scales with how many people talk to it and how much work each answer takes. Almost every article on this subject quotes the first number and ignores the second.
AI chatbot cost, split into the two numbers that matter
| A simple assistant | A standard business assistant | An assistant that acts | |
|---|---|---|---|
| What it is | Answers from one set of documents, on one channel, and hands anything else to a person by email. | Grounded in several sources, on your site and inside your helpdesk, escalating with the full transcript, plus a view of what people actually asked. | All of the above, and it does things: checks an order, books a slot, raises a ticket, through permissioned connections to your systems. |
| Illustrative build | $8,000 to $20,000 | $20,000 to $45,000 | $45,000 to $100,000 and up |
| Illustrative monthly | $100 to $400 | $300 to $1,200 | $800 to $3,000 and up |
| What the monthly covers | Model usage, hosting, the search index and basic monitoring at low volume. | The same at real volume, plus the retrieval infrastructure and enough monitoring to see where it fails. | The same again, plus the integrations, which need maintaining as the systems at the other end change. |
The monthly figure moves with conversation volume more than with anything else. Double the conversations and you roughly double the model portion of the bill, which is why the design decisions further down matter so much.
What you are actually paying for in the build
Six things go into building an assistant grounded in your own content, and only one of them is the part people picture when they imagine the work.
- Getting your content ready. The unglamorous majority of most builds. Documents, product data, policies and past tickets have to be collected, cleaned, split sensibly and indexed. Where a build overruns, it is usually here, because the assistant will faithfully repeat whatever you feed it, and most businesses discover during this step that two of their documents contradict each other.
- Retrieval. The machinery that finds the right passages to answer from. This is the single biggest determinant of whether the thing is any good, it is invisible in a demo, and it is cheap to do badly. It is the same engineering as knowledge search, which is why the two often get built together.
- Guardrails and refusal behaviour. What it may say, what it must never say, and when it should stop and fetch a human. Then testing that explicitly, with questions your content genuinely cannot answer, to confirm it says so rather than inventing something plausible.
- Escalation and handover. Getting the conversation, the customer details and a suggested reply into the inbox or helpdesk your team already lives in. Skipped, and you have built a wall rather than a door.
- Integrations, if it is going to do anything rather than only say things. Each connection is priced like any other integration: trivial with a documented interface, a small project without one.
- Testing and a review loop. Real questions, run through it, read by a human, with the failures fed back in. Nobody gets the retrieval right first time, and the difference between an assistant customers trust and one they learn to bypass is mostly made in this step.
Why the running cost is per conversation
You are billed for the material sent to the model and the words it sends back, measured in tokens, which are roughly fragments of words. Not per user, not per seat, not a flat monthly platform fee.
Every single answer sends the model four things: your standing instructions, the passages retrieved from your content, the conversation so far, and the customer's latest message. It then generates a reply. So the cost of one conversation is, approximately, how much context each answer carries, multiplied by how many turns the conversation runs, multiplied by the model's rate.
Output is charged at several times the rate of input, but the volume of input is usually far larger, so the retrieved context is normally the dominant line on the bill. That leads directly to the three things you control.
- Model tier. Between the cheapest genuinely capable model and the most expensive frontier one, the difference is roughly tenfold per token. Most support questions do not need the top of that range, and a well-built assistant routes by difficulty: a small fast model answers the routine ones, and only the hard or sensitive questions are escalated to something larger. Sending every question to the most expensive model available is the most common way to multiply a bill for no benefit anyone can perceive.
- Context size. How many passages you retrieve and how long they are sets most of the cost of every answer. Retrieving twelve documents when four would do multiplies the bill and, counterintuitively, often makes the answer worse, because the relevant sentence is now buried among eleven irrelevant ones. Tightening retrieval usually improves quality and cost at the same time, which is a rare thing.
- Caching. The parts of every request that never change, your instructions and standing policy text, can be cached and served on later requests at roughly a tenth of the price. It only engages above a minimum size, and it breaks the moment anything earlier in the prompt changes, including something as small as a timestamp. Designed for from the start, it is the largest single saving available on a busy assistant. Not designed for, you pay full price on every conversation, forever, for text that is identical every time.
Then there are the non-model costs, which are modest and predictable: hosting, the search index, logging and monitoring. On a small assistant these are a few tens of dollars a month. They rarely surprise anyone.
Model choice, and why you should not over-buy today
The price of a given level of capability has fallen consistently and repeatedly, and there is no sign of that stopping. What costs a certain amount per conversation today has a good chance of costing meaningfully less in a year, for the same or better quality.
Two consequences follow, and they point in opposite directions from the advice people usually give. Do not compromise the quality of the build to save a running cost that is likely to fall on its own. And do not let anyone build the model into the foundations. It should be a configuration value behind an abstraction, so that when something cheaper or better appears, and it will, switching is a settings change rather than a rebuild. Ask that question explicitly before you sign anything.
One more saving that is easy to miss: work that no human is waiting on, such as overnight re-indexing or summarising yesterday's conversations, can usually be run asynchronously at a substantial discount. It is worth asking whether any of your workload qualifies.
Where the money actually gets wasted
- No escalation design. The most expensive assistant in the world is one that argues with a customer for fifteen turns before a human takes over. Every turn costs money, and the customer's patience costs considerably more. Decide the exit rule before you decide anything else.
- Too many channels at once. Website, WhatsApp, Messenger, SMS, in-app and phone are each an integration, a testing surface and a set of edge cases. Start with the one your customers already use and add the second only when the first is earning its keep.
- Retrieving too much. Covered above, and worth repeating because it is the most common single fault we find in assistants built elsewhere.
- Building it before the content exists. If your policies contradict each other and your help pages are three years out of date, an assistant will amplify that rather than fix it. Sorting the content first makes your humans better immediately and makes the assistant cheaper and more accurate later.
- Using an assistant where a workflow would do. If what you actually need is for a form to reach the right person, or for an order to move between two systems without retyping, that is workflow automation and it is cheaper, more reliable and easier to explain to your team than a conversation.
A worked example
Not for you if
How to get a real number for your business
- Count the questions. Pull the last month of emails, chats and calls and group them. Ten patterns usually cover the great majority, and that list is the entire brief.
- Decide the escalation rule first. What must always reach a human? Anything clinical, financial, legal, or about a complaint, is a common starting answer.
- Pick one channel for the first version.
- Ask for the monthly estimate modelled on your real volumes, with the assumptions written down: which model, how many passages retrieved, whether caching is designed in, how many turns per conversation.
- Ask what happens when volume doubles, because that is the question a licence-fee mindset never thinks to ask.
- Ask how the model gets swapped when a cheaper or better one appears.
- Ask who owns the prompts, the content pipeline, the index and the conversation data, and where that data is processed.
A supplier who answers all seven with specifics is quoting. One who gives you a single monthly figure with no assumptions attached is guessing, and the gap will show up on your card in month three.