Pavel Yanushka
September 21, 2026
8
min. read
and updated on:
September 22, 2026
The chatbots people abandon and the chatbots people rely on differ in one respect above all others: whether the bot knows something specific and useful, or whether it is a general-purpose model with a company logo attached. A model with no access to your data, your policies, or your systems can only produce plausible-sounding generalities, and users detect that within two exchanges.
Everything that makes a chatbot worth building follows from giving it real grounding and a clear boundary.
Four kinds of chatbot, and what each costs
| Type | What it does | Build cost | Duration |
|---|---|---|---|
| Scripted or decision-tree | Fixed paths, no model | $5,000 to $15,000 | 2 to 3 weeks |
| Knowledge-grounded assistant | Answers from your documents via retrieval | $25,000 to $70,000 | 5 to 10 weeks |
| Account-aware assistant | Answers about the user's own data | $50,000 to $110,000 | 8 to 14 weeks |
| Transactional assistant | Takes actions on the user's behalf | $80,000 to $180,000 | 12 to 20 weeks |
Most companies asking for an AI chatbot want the second or third type and describe the fourth. The gap between them is large: reading your knowledge base is a retrieval problem, while changing a customer's subscription is an agent problem with authentication, authorisation, confirmation, and audit requirements attached.
The grounding decision determines everything else
A chatbot's usefulness is bounded by what it can see.
Grounding in published content, help articles, documentation, policies, product pages, is the common starting point and covers the majority of repetitive questions. Implementation is a retrieval pipeline: chunk the content, embed it, index it, retrieve relevant passages per query, and instruct the model to answer only from what was retrieved.
Grounding in account data, order status, subscription state, usage, appointment history, is where a support chatbot becomes genuinely valuable, because most support contacts are about the customer's own situation rather than about general policy. It also raises the bar considerably: the bot must authenticate the user, retrieve only their data, and never leak across accounts. Authorisation errors here are data breaches, so the retrieval must be scoped in code rather than by instruction to the model.
Grounding in live system state, inventory, availability, pricing, requires real integrations and introduces the risk of confidently stating something that changed a minute ago. Cache carefully and timestamp anything volatile.
Design decisions that decide whether users trust it
- Show sources. A knowledge-grounded answer with a link to the article it came from is verifiable. Without the link, a correct answer and a fabricated one are indistinguishable to the user, so both get doubted.
- Make the boundary explicit. Tell users what the bot can help with in the opening message. Products that imply unlimited capability generate questions the bot cannot answer, and each of those erodes willingness to try again.
- Provide an unmissable escape hatch. A visible route to a human, available at every turn. Bots that trap users are the primary reason the entire category has a poor reputation. Counterintuitively, an obvious exit increases bot usage, because it lowers the perceived cost of trying.
- Say I do not know. Instruct the model explicitly to decline when retrieval returns nothing relevant, and enforce it by checking retrieval confidence before generating. A bot that admits gaps is trusted on the answers it does give.
- Stream the response. Progressive text reads as fast. A spinner reads as broken.
- Preserve context within a conversation but bound it. Users refer back to earlier turns and expect the bot to follow. Sending the whole history every turn is also how token costs grow quadratically, so use a rolling window or summarise older turns.
The metric that matters is not containment rate. It is resolution rate plus satisfaction. A bot that prevents 60 percent of contacts by exhausting users has not helped anyone, and the cost shows up later in churn rather than in the support queue.
Where the chatbot lives changes what you build
Channel choice is not cosmetic. Each one imposes different constraints, and products that pick more than one at launch usually ship none of them well.
Website widget. Fastest to deploy and the standard choice for support deflection. Users are anonymous unless logged in, which limits account-aware answers. Accessibility matters here in ways teams forget: keyboard navigation, screen reader labelling, and focus management on an overlay are real requirements.
Inside your product. The strongest option for account-aware assistance, because the user is already authenticated and the bot can see their context. It also means the bot can act on the current screen, which is where genuine productivity gain lives.
Mobile app. Same advantages as in-product, plus the constraints of app release cycles, which is another reason to keep prompts and logic server-side. Streaming behaviour when the app is backgrounded needs a defined answer.
Messaging platforms. Reaches users where they already are and hands you their platform's constraints on formatting, session length, and identity resolution. Linking a messaging identity to an account is a real piece of work rather than a configuration step.
Bolder Apps builds web front ends in React, mobile in Flutter, FlutterFlow, Swift, and Kotlin, and backends in Node.js and Laravel, and the point worth taking from that spread is that channel work is client work sitting on the same server. Build the assistant service once, expose it to whichever channel you start with, and adding a second channel later becomes a client project rather than a rebuild.
Prepare the content before you build the bot
Retrieval quality is bounded by content quality, and most knowledge bases were written for humans who can tolerate ambiguity.
Four things reliably improve grounded answers. Remove contradictions and out-of-date articles, because retrieval will surface the wrong one and the model has no way to know it is stale. Split long documents into topic-coherent sections rather than relying on arbitrary chunking. Add explicit answers to questions your content currently implies, since models retrieve what is written rather than what is inferable. And date anything time-sensitive so the model can qualify it.
This work is unglamorous, does not require engineers, and can begin before development starts. It is also the highest-leverage preparation available, and teams that do it during the build rather than before it spend the first month of launch discovering content gaps one failed conversation at a time.
Architecture, briefly
The client, whether web widget, mobile screen, or messaging channel, talks to your backend. Your service authenticates the user, retrieves relevant grounding, assembles a prompt from a versioned template, calls the model provider, streams the response back, and logs the exchange with token counts.
The provider API key never leaves your server. Prompts live on the server so they can change without an app release. Every account-scoped retrieval is filtered in code by user identity rather than by asking the model to be careful.
Bolder Apps builds mobile clients in Flutter and native Swift and Kotlin, web front ends in React, and backends in Node.js and Laravel, and the reason to note this on a chatbot article is that the interface layer is the easy part. Where chatbot projects go wrong is retrieval quality and authorisation scoping, both of which sit on the server.
Where chatbots pay back, and where they do not
They pay back on high-volume repetitive questions with stable answers, on first-line triage that gathers information before routing to a person, on internal knowledge lookup where staff currently interrupt colleagues, and on guided onboarding where users need help finding a feature.
They do not pay back on low-volume complex issues, where each interaction is unique and the build cost cannot amortise. They do not pay back on emotionally charged contacts, where a person is the product rather than a fallback. And they do not pay back where your knowledge base is inaccurate, because a chatbot grounded in wrong documentation delivers wrong answers faster and more confidently than a search box does.
That last point is worth dwelling on. Roughly half of chatbot projects reveal a content problem rather than a technology problem. Auditing and fixing the knowledge base is usually the highest-return work available, and it happens to be a prerequisite either way.
