AI Chatbot for Business: Three Shapes, One Decision

Search for an AI chatbot for your business and you get ranked lists. Fourteen tools, nine tools, the best of the year, each row a logo and a sentence about seamless integration. Almost all of them are published by one of the tools on the list, which is not a scandal, but it does mean the pages are organised around the only question the publisher benefits from you asking: which product.

That is the last question, not the first. Before a vendor matters, one decision sets your running cost, your failure mode and the amount of work in front of you, and it is the same decision whether you buy something off the shelf or have it built. It is the shape.

Three shapes, and the difference is what the thing is allowed to read and do

Nearly every business chatbot in existence is one of three things. The boundaries are not marketing categories, they are architectural, and they are what decide everything downstream.

Scripted. A decision tree with language on top. It recognises what the customer is asking and routes them to one of a fixed set of answers. Modern ones use a model to do the recognising, which makes them far better than the button-menu bots of a decade ago, but the set of things it can say is still written in advance by a person.

Retrieval-backed. The bot searches your own material at the moment of the question, your help centre, your policy documents, your product pages, and writes an answer grounded in what it found. It can answer questions nobody anticipated, as long as the answer exists somewhere in the corpus you pointed it at. This is what most people now mean by an AI chatbot, and it is the shape a conversational agent starts from.

Agentic. The bot can call your systems. Look up this customer's order, check that subscription, issue the refund, book the appointment. It is the only one of the three that can change something in the world, which is the entire difference and the reason it needs a different conversation about authority and logging.

Sort your questions before you sort the vendors

The shape you need is decided by the questions you already receive, not by ambition. Take a genuine sample from the last month of your inbox or your ticket queue and sort each one into a pile.

• Can this be answered the same way every time? That is scripted work. Opening hours, return windows, where to find the invoice.
• Does the answer exist in writing somewhere, but in a form nobody wants to read? That is retrieval work, and it is where most support volume actually sits.
• Does the answer depend on something specific to that customer, held in a system? That needs the agentic shape, or it needs a handover to a person.
• Does answering it require a judgement your business would not delegate to a new hire in their first month? That is not chatbot work in any shape, and building it anyway is the most expensive mistake in this category.

The sort is usually lopsided, and its shape is the answer. A queue that is mostly pile two does not need an agentic build, and paying for one will not make the pile-two answers better. A queue that is mostly pile three cannot be served by a retrieval bot no matter how good its writing is, because the information it needs was never in a document.

The cost follows the shape, not the logo

Priced per conversation, the three shapes are not close to each other, and the reason is mechanical rather than commercial.

A hosted model bills separately for the text going in and the text coming out. A scripted bot sends very little text in, because it only has to classify the question. A retrieval-backed bot sends the retrieved passages in with every single turn, so the input side grows with how much context you feed it and how long the conversation runs. An agentic bot adds another round trip for each tool it calls, and each round trip carries the conversation so far back into the model again.

So the cost question is not which vendor charges less. It is how much text your shape moves per conversation, multiplied by your volume. That is computable before you buy anything: take a realistic question from the sort above, count what the bot would actually have to send with a token counter, and run it at your genuine monthly volume through the LLM cost calculator. The structure behind that bill, and where to read the current rates rather than a table that has gone stale, is set out in a piece on how this pricing is put together.

Do that before you talk to anybody. An estimate supplied by a seller is a number you cannot check, and this is one of the rare cases where the buyer can compute it more honestly than the vendor can.

What a build actually consists of

If you are buying development rather than a subscription, the proposal should name these, and a proposal that names a model or a framework before it names any of them has the order backwards.

• The corpus. For a retrieval bot, which documents are in scope, who keeps them current, and what happens to the answers when a policy changes. The bot is only as correct as the material, and stale material is the most common cause of a confidently wrong answer.
• The escalation path. What happens when the bot cannot answer. Not in principle: the actual route to a person, and how much of the conversation travels with the customer so they do not repeat themselves.
• The refusal behaviour. What it says when it does not know. A bot that guesses is worse than no bot, because a wrong answer in your brand voice is a commitment your business may have to honour.
• The boundary, for anything agentic. Which actions it may take alone, which need a human to confirm, and which it may never take. Refunds above a threshold, cancellations and anything touching payment details belong on the second or third list.
• The log. Every conversation, every retrieved source, every action taken. This is what lets you answer a customer complaint later, and it is the line most often missing from a quote.
• The measurement. How you will know it works, agreed before launch. Containment rate and customer satisfaction on contained conversations, not messages handled, which counts a bot failing repeatedly as a success.

Buy first, build only for pile three

For piles one and two, an off-the-shelf product is almost always the right call. Retrieval over your own documents is a solved and heavily commoditised capability, and paying for a custom version of it buys you maintenance rather than advantage.

The case for a build appears when the chatbot has to reach into systems that are specific to you, which is pile three, or when the conversation itself is the product rather than a support cost. That is a real category and it is much smaller than the market for chatbot development implies.

Either way the sort comes first, and it takes an afternoon with a month of real tickets. If you want a structured version of that exercise across more than support, the AI readiness assessment walks the same ground: what you have written down, what sits in systems, and which of it is ready to be automated at all.