Chatbot examples: what they do and what they cost
Short answer: useful chatbot examples fall into four shapes. A support assistant that answers from your documentation, an internal assistant that answers from your systems with per-user permissions, a transactional assistant that takes actions in a system of record, and a qualification assistant that gathers information before a person gets involved. The first is cheapest and most common. The third is where cost multiplies, because it stops being a retrieval problem and becomes a distributed systems one.
Four chatbot examples worth building, and what each costs
The support assistant
Answers customer questions from your documentation, help centre and policy pages. Deflects the repetitive third of your ticket volume and hands the rest to a person with the conversation attached.
The measure that matters is resolution without human intervention, not deflection. A chatbot that stops someone opening a ticket because they gave up is not deflecting anything, it is losing a customer quietly.
The internal assistant
Answers staff questions from internal documents: HR policy, engineering runbooks, sales collateral, process documentation. Usually the highest-value chatbot idea in a large organisation and the one most often done badly.
The reason is permissions. Different employees may see different documents, so retrieval has to filter by entitlement before it ranks, using the requesting user’s identity. An internal assistant that surfaces the wrong HR document to the wrong employee is an incident, not a bad answer.
The transactional assistant
Does something rather than saying something. Checks an order, updates an address, cancels a subscription, raises a ticket in the right queue.
This is where the cost changes shape. Every action needs a typed tool contract, authorisation scoped to the user, idempotency so a retry cannot duplicate work, and either a reversal path or an approval gate. A retrieval assistant is a few weeks; this is months, and the time goes into integration rather than conversation.
The qualification assistant
Collects what a salesperson or a clinician would otherwise spend the first ten minutes asking. Structured output, handed to a person who then starts from an informed position.
Low risk, quick to build, and it works because it is not trying to replace the judgement step.
What is an example of a chatbot that fails
Worth naming, because the failure modes repeat.
The one with no retrieval. It answers from the model’s general knowledge, fluently and wrongly, about your specific business. A wrong answer from a general model reads exactly like a right one, which is what makes it dangerous.
The one with hundreds of intents. Older frameworks required enumerating everything the bot could understand. A mature one becomes hundreds of intents nobody can safely modify, because adding one risks shadowing another.
The one with no handoff. Users learn within two exchanges whether they can reach a person. If they cannot, they stop trusting the whole channel.
The one measured on engagement. Conversation length and message volume are vanity metrics that often move the wrong way. A user sending many messages may simply be failing repeatedly.
Chatbot automation, and where it stops
Chatbot automation works when the decision rules can be written down. Answering from documented policy, routing by category, checking a status, collecting structured information.
It stops at judgement. Anything with money, legal or clinical consequence should route to a person, or execute only inside limits enforced in code rather than in a prompt. Telling a model in its instructions never to issue a refund over a threshold is a suggestion; the model will follow it most of the time, and the failure will be the interesting case.
Our AI chatbot development services put those limits in code paths for exactly that reason.
What these cost, in shape
A grounded assistant over a reasonable corpus is four to six weeks. Most of that is not the conversation: week one is corpus work and an evaluation set, weeks two and three are ingestion, retrieval and grounding, and the rest is evaluation and deployment.
A transactional assistant that acts in systems of record is three to five months, and the difference is integration and failure handling.
The variable that moves the number most is not the build. It is how long it takes to get access to the content and to a person who can say which answers are correct.
Chatbot examples: build or buy
Buy a platform when your content is public-facing, permissions are uniform, and nothing the assistant does writes to a system of record. That covers a large share of support chatbots and you should not let anyone talk you out of it.
Build when retrieval must respect per-user permissions, when the assistant must act in systems a platform does not reach, when data cannot leave your infrastructure, or when per-seat pricing dominates at your scale.
The takeaway
The useful chatbot examples are the ones that answer from your own content or act in your own systems, and the two have very different costs. Decide which shape you need before choosing a tool, and measure resolution rather than engagement once it is live.
EpochC builds AI chatbot development services grounded in your data and policies, on custom RAG development services, plus AI agent development services where the assistant needs to act. See the clinical multi-agent API case study or start a project.