AI chatbots have become a default feature for websites and products, but the word chatbot hides a huge range of complexity. A scripted widget that answers ten questions and a retrieval assistant that reads your entire knowledge base are both chatbots, and they are not remotely the same to build. Understanding what drives the price is the fastest way to avoid overpaying or underbuilding.
What actually drives the cost
Four things move the price more than anything else: how intelligent the bot is, whether it connects to your own knowledge with retrieval (often called RAG), how many systems it must integrate with, and the guardrails that keep it safe and cheap to run.
Realistic ranges by type
A scripted or FAQ chatbot, with fixed flows and quick-reply buttons, is the most affordable option and suits simple support deflection. A single-purpose LLM assistant, which answers naturally but stays on one topic, sits in the middle. A retrieval assistant trained on your own content, with citations and human handoff, is more involved because it needs data pipelines and tuning. A fully custom assistant that takes actions across several systems is the largest build because most of the cost is in the integrations and safety, not the chat itself.
Because these ranges swing so widely with scope, NextiqumAI does not publish a single price. We give an exact quote after a short scoping call. If you want an instant ballpark first, Mark, our AI project scoper, will sketch a build plan and rough timeline for your idea in seconds.
The cost people forget: running it
A chatbot is not a one-time purchase. If it uses a hosted language model, every conversation has a small usage cost, and busy or abused bots can run that up quickly. This is exactly why guardrails matter: per-user limits, duplicate-message filtering and blocking off-topic spam keep your running costs predictable.
How to avoid overspending
Start with the narrowest version that delivers value, ship it, and expand based on real conversations rather than guesses. Most businesses do not need a bot that does everything on day one; they need one that handles their top questions reliably and hands off cleanly when it cannot help.
What questions decide which chatbot type you need?
Before asking what a chatbot costs, it helps to know which of the four types you are actually buying. The answers to a few questions usually settle it:
- Are the questions fixed or open? A known, short list of questions points to a scripted bot; questions that vary in wording and detail point to an LLM assistant.
- Do the answers live in your own documents? If the bot must quote your policies, catalogue or help docs, you need retrieval, and the data pipeline and tuning come with it.
- Does the bot need to do things, not just answer? Checking an order, booking a slot or updating a record means integrations, which is where the largest builds spend most of their budget.
- What happens when it cannot help? A clean handoff to a person is a feature in its own right and should be scoped from the start.
- How much traffic do you expect, and from whom? A public bot on a busy site needs stronger guardrails than an internal tool used by staff.
Where does chatbot spending usually go wrong?
The most common mistake is buying the biggest type for a job the smallest type could do. A business with a short list of recurring questions does not need a retrieval assistant, and paying for one adds pipelines and tuning that nobody uses. The opposite also happens: a scripted bot is launched for a support queue full of varied questions, cannot answer most of them, and gets switched off. The second mistake is ignoring running costs in the quote. A build price that leaves out per conversation usage, monitoring and the limits that stop abuse is not a complete price. The third is skipping the expansion plan. Shipping the narrow version first only pays off if real conversations are reviewed and the next step is chosen from what they show.
What does matching the chatbot type to the job look like?
Take an invented but typical case: an online shop whose support inbox is mostly about delivery times, returns and order status. Run the questions above. Delivery and returns questions arrive in many different wordings, and the answers sit in the shop's own policy pages, so a scripted bot would miss too many of them and a retrieval assistant on those pages fits. Order status is different, because answering it means connecting to the order system, and integrations are where the larger builds spend most of their budget.
The narrow first version answers delivery and returns questions from the policies and hands order questions to a person. Because it sits on a public site, it launches with per-user limits and spam filtering from the start. If the reviewed conversations show order questions are a large share of the traffic, order lookup becomes the next step, chosen from evidence rather than guessed on day one.