Why this market is hard to buy in
Choosing an AI chatbot development company is unusually difficult, for a structural reason: the barrier to appearing competent is now very low. Connecting a language model to a chat widget is a weekend's work, and the demonstration looks identical to something built properly.
The difference shows up three months in, when the bot confidently invents a price, or nobody can find who is meant to answer an escalated conversation, or a traffic spike produces a bill several times the estimate. None of that is visible in a demo.
We build these, so read this as interested advice. The questions below are the ones we would want asked of us, and several of them we answer in ways that lose us work.
The twelve questions
1. What happens when the bot does not know the answer?
Ask this first. The response sorts vendors faster than anything else.
A good answer describes confidence thresholds, an explicit escalation path, and the transcript being passed to whoever picks it up. A bad answer is "the AI handles it" or "we train it on everything so it always knows". The second is not possible, and saying so reveals they have not run one in production.
2. How do you stop it inventing things?
The real mechanisms are constraining the bot to retrieved content from your own material, refusing to answer outside it, and structurally preventing whole categories of response — prices, timelines, clinical advice — rather than politely instructing against them.
If the answer is only "we use a good prompt", the guardrail is a suggestion. Prompts drift, and a prompt is not a control.
3. Which exact data-handling configuration are you using?
Not "your data is safe". Which provider, which tier, which retention setting, in writing. Major providers offer configurations where inputs are not retained for training, and some consumer-tier defaults differ.
For sensitive sectors, also ask whether processing can be kept inside your own infrastructure and what that costs.
4. What will this cost to run at my volume?
Model pricing is per token. A multi-turn conversation consumes considerably more than a single question and answer, and a chatbot that summarises your whole knowledge base into every request consumes more again.
Ask for an estimated cost per thousand conversations, and ask what stops a traffic spike from becoming a large bill. Caching and rate limits should be part of the build, not a later fix.
5. Who owns the configuration, the knowledge base and the keys?
You should own all three, with the model API keys in your own account so you can see and control spend. If the bot only exists inside the vendor's platform, you are renting, and the renewal conversation will reflect that.
6. How does it get my content?
A bot can only answer from what it has. Ask concretely: what format do you need my information in, who assembles it, and is that included?
This is the most underestimated part of the project. Most businesses discover their opening hours, prices and process are written down in four inconsistent places, and reconciling them is real work. It is also useful work — several clients have found the exercise more valuable than the bot.
7. Where does an escalated conversation go, and who is accountable?
Concretely. Which inbox, which person, what happens outside working hours. And does the human receive the transcript, or does the customer have to start again?
Making the customer repeat themselves is the most common way an automated first contact makes the experience worse than no bot at all.
8. Can I see every conversation?
You should be able to. The transcript log is frequently the most valuable output of the whole project, because it is the clearest picture a business has ever had of what customers actually ask. If a vendor treats logs as their data rather than yours, that is a problem.
9. Which channels, and does the same bot serve all of them?
Website, WhatsApp and social have different constraints. WhatsApp in particular has template approval and opt-in rules that shape what is possible — we cover those in the WhatsApp API pricing piece.
Ask whether you maintain one knowledge base or several. Several will diverge.
10. What will you refuse to build?
An experienced vendor has a list. Diagnosis, price commitments, anything where being confidently wrong is expensive. A vendor with no boundaries either has not encountered the failure modes or does not mind who absorbs them.
11. How do I change an answer after launch?
You will need to, weekly at first. Ask whether you can edit the knowledge base yourself or must raise a request. A bot you cannot correct quickly becomes a bot giving stale answers, and the correction cycle matters more than the initial accuracy.
12. What happens if I want to leave?
Export of the knowledge base, the configuration and the conversation history, in a usable format. Ask now, while they want your business.
What a sensible build looks like
For comparison, the shape we use:
Discovery, about three days. Which questions, which channels, which content exists, and what the bot must never do.
Knowledge base, about a week. Assembling and reconciling your material. Usually the slowest part, and the part that needs you.
Integration, about a week. Channels, CRM, calendar, and the handover path — built before broadening the answers.
Launch, a few days. Testing against real questions, then a supervised period where transcripts are read daily.
Three weeks, roughly. A vendor promising a full deployment in two days is connecting a model to a widget, which you could do yourself.
The honest cases against hiring anyone
Three situations where we would tell you not to:
Low enquiry volume. If the same question arrives twice a week, automating it saves nothing and costs something.
Every enquiry is genuinely different. Bespoke consulting work has no repetitive core to automate.
Your content does not exist yet. If nothing is written down, the first project is documentation, not a chatbot. That is cheaper and more useful, and it makes the bot straightforward later.
There is also a legitimate middle path: an FAQ page that actually answers the questions, plus a well-configured away message, solves a surprising share of what people buy chatbots for. Less impressive, considerably cheaper, and we suggest it regularly.
Reading a proposal
Once you have the answers, the proposal itself tells you things. Four patterns worth noticing.
Scope described in features rather than conversations. "Includes NLP, multi-language, sentiment analysis" is a component list. What you want is "handles these eight questions on these two channels, escalates everything else to this inbox". The second can be checked at the end; the first cannot.
No separation of build cost from running cost. These behave completely differently — one is once, the other scales with your traffic — and a single blended figure hides which is which. Ask for them apart.
No mention of what happens after launch. A chatbot needs its answers corrected weekly for the first month, because real questions differ from anticipated ones. A proposal ending at launch has planned for a demo rather than a deployment.
Accuracy promised as a percentage. Nobody can commit to this meaningfully before seeing real traffic, and a number in a proposal is a number invented to win the work. What can be committed to is behaviour: that it will escalate rather than guess, and that you can correct it quickly.
Two things worth paying extra for
Most of the price difference between quotes is margin rather than capability. Two things genuinely justify paying more.
Retrieval over your own content, rather than a fine-tuned or prompt-stuffed model. The distinction matters practically: a retrieval setup looks up the relevant passage from your material and answers from it, so when you correct the source the answer changes immediately and you can see which passage produced a given reply. Fine-tuning bakes information in, which makes corrections slow and attribution impossible. Ask which approach is being used and how a correction propagates.
Evaluation before launch. A vendor who has assembled fifty real questions, run them, and can show you where the bot was wrong is doing engineering. One who demonstrates six questions they chose is doing a presentation. Ask to see the failures rather than the successes; the willingness to show them is most of the signal.
Both of these are invisible in a demo and both determine whether the thing still works in month four.
The question to ask yourself first
Before any of the twelve, one for you rather than the vendor: what are the five questions your team answers most often, and are the answers written down anywhere consistent?
If you can produce that list in ten minutes, a chatbot project will go well and be cheaper than quoted, because the expensive part is already done. If you cannot — and most businesses cannot on the first attempt — then producing it is the real first project, and it is worth doing whether or not you ever build a bot.
That exercise is also the fastest way to judge a vendor. Send them the list and ask what they would do with it. The useful ones will come back with questions about edge cases and escalation. The rest will come back with a quote.
Where this fits
A chatbot handles first contact. It does not fix a slow follow-up process, and it does not help if enquiries are arriving in four places with nobody owning them — that is what lead capture and routing addresses, and it is usually the more valuable project of the two.
If you want to put these twelve questions to us, the call is free and fairly often ends with us recommending the FAQ page.
