Most teams building an AI chatbot start with the wrong question: Which model or platform should we use? The real success or failure of your chatbot is decided long before you pick a tool.
If you’re deploying on WhatsApp and web, the stakes are even higher: different channels, different user expectations, and more ways for things to break. This guide walks through how to create an AI chatbot that actually works in production, not just in a demo.
---
Three Decisions That Determine Everything
Before you touch a single platform or model, you need to answer three questions. These decisions, made in the first hour of planning, determine whether your chatbot succeeds or quietly dies after launch.
1. What is this chatbot not going to handle?
Scope creep is the fastest way to a broken chatbot.
A bot trained on your entire company knowledge base but given no clear boundaries will:
- Answer confidently on topics it shouldn’t touch
- Contradict other channels
- Create support and legal risk
Define hard edges up front. Examples:
- Support scope: Only customer support for product lines A and B
- Function scope: Only order status and returns, nothing else
- User scope: Only existing customers with an order ID
The tighter the scope, the better the performance. You can always expand later once the core use cases are stable.
2. Where will users interact with it?
A chatbot on your website is not the same product as a chatbot on WhatsApp.
WhatsApp characteristics:
- Asynchronous by default
- Short, mobile-first messages
- Limited formatting
- Users expect quick, actionable replies
Web widget characteristics:
- Richer formatting (links, bullets, sections)
- Easier to maintain session context
- Can be triggered contextually (e.g., on pricing or checkout pages)
Design for each channel separately:
- Different response lengths
- Different tone and formatting
- Different triggers and entry points
Don’t assume one conversation flow will work everywhere.
3. What happens when it fails?
Every chatbot fails. The only question is whether it fails gracefully or badly.
Graceful failure looks like:
- Detecting out-of-scope topics or low confidence
- Saying clearly what it can and can’t do
- Routing to a human without losing context
Bad failure looks like:
- Looping the user through the same unhelpful answer
- Hallucinating policies or prices
- Dropping the conversation entirely
Design your fallback and human handoff as part of the initial build, not as a patch after complaints start.
---
Building Your Knowledge Base: The Part That Actually Matters
For most modern platforms, your chatbot uses retrieval-augmented generation (RAG):
- Retrieve relevant content from your knowledge base
- Generate an answer using that content
If the knowledge base is wrong, outdated, or messy, the model will confidently repeat those problems. Model choice can’t fix bad inputs.
Common ways knowledge bases break
- Outdated content
- Old return policies
- Deprecated product features
- Legacy pricing
Treat your knowledge base as a living system:
- Align updates with your website and product releases
- Assign ownership for keeping it current
- Ambiguous or redundant documents
- Multiple FAQ versions with slightly different answers
- Conflicting policy PDFs
- Overlapping internal docs
Before uploading:
- Audit and consolidate
- Decide a single source of truth for each topic
- No coverage of common edge cases
- Users ask about exceptions and corner cases
- The bot falls back to generic or wrong answers
After launch:
- Review conversations where the bot said “I don’t know” or failed
- Add or refine content to cover those gaps
- Expect the first two weeks of live traffic to be your best source of improvements
Special note for WhatsApp chatbots
WhatsApp users will not read a 400-word answer.
To adapt your knowledge base for WhatsApp:
- Summarize long-form documents into concise, answer-ready snippets
- Structure content so the bot can extract only the relevant fragment
- Prefer short paragraphs, bullets, and clear calls to action
You can still keep long-form content for web; just ensure the bot knows to respond differently per channel.
---
Designing Conversation Flows
Modern AI chatbots don’t need rigid scripts, but they do need clear intent routing.
Design for intent, not exact phrasing.
Rule-based bots required you to list every possible way a user might ask a question. AI models handle paraphrasing well, but they still need to know:
- What to do when someone asks about pricing
- What to do when someone wants to change an order
- When to answer directly vs. when to route to sales or support
The AI handles language understanding; you define what happens next.
Practical guidance on flows
- Start with your top five intents
- Use support tickets, email logs, or CRM data
- Aim for intents that cover ~80% of real usage
- Examples: order status, returns, product fit, pricing, account access
- Write sample dialogues for each intent
- Not rigid scripts, but examples of a good conversation
- Include:
- A typical happy path
- A confused user
- A user changing their mind mid-conversation
- Use these to evaluate whether your setup and knowledge base are working
- Build explicit “I don’t know” pathways
- The bot should be able to say:
- “I can’t help with that, but our team can—want me to connect you?”
- This is better than inventing an answer or looping
- The bot should be able to say:
- Differentiate flows by channel
- On WhatsApp: shorter turns, fewer steps per message
- On web: richer formatting, more information per response
---
How to Create an AI Chatbot for WhatsApp and Web
Most B2C and SMB setups deploy on both WhatsApp and a website. The technology is straightforward; the design choices are where things succeed or fail.
WhatsApp setup
To deploy a chatbot on WhatsApp, you need:
- A verified business number
- Must be a dedicated business line
- Cannot be an existing personal WhatsApp account
- Registered through:
- Meta’s Business platform, or
- A WhatsApp Business Solution Provider (BSP)
- WhatsApp Business API access
- Your chatbot platform connects to this number
- It receives and sends messages through the API
- Message templates (for outbound)
- Pre-approved by Meta
- Used for proactive outreach or re-engagement
- Inbound, user-initiated conversations are more flexible and don’t require templates for each message
Design considerations for WhatsApp:
- Keep replies short and actionable
- Avoid heavy formatting; use simple bullets and clear questions
- Make it easy to switch to a human when needed
Web widget setup
Most no-code and low-code platforms provide an embeddable widget.
- Implementation
- Typically a JavaScript snippet added to your site
- Minimal engineering effort compared to the design work
- Placement and triggers
- Avoid showing the bot immediately on every page
- Better patterns:
- Appear after 30–60 seconds on high-intent pages (e.g., pricing)
- Trigger on checkout when a cart is idle
- Offer help on documentation pages after scroll depth
- Session handling and identity
- Decide whether conversations should carry over between web and WhatsApp
- If you want continuity, you need to capture identity early (email, phone, or login)
- Define:
- When to ask for identity
- How to store and sync conversation context across channels
Make these decisions before you build; changing them later is costly.
---
Setting Up Human Handoff
Human handoff is not a failure state; it’s a core part of the product.
Design it with the same care as your primary chatbot flows.
1. When does handoff trigger?
Common triggers:
- The user explicitly asks for a human
- The bot’s confidence score is below a threshold for 2+ consecutive replies
- The topic is tagged as sensitive (billing disputes, complaints, legal issues)
- The conversation exceeds a certain number of turns without resolution
Use at least two triggers in combination to avoid over- or under-routing.
2. What does the human agent receive?
A poor handoff just says “new conversation” and drops the agent into a cold chat.
A good handoff package includes:
- Full conversation transcript
- Identified intent (e.g., “order status”, “refund request”)
- A one-sentence AI-generated summary of the user’s issue
- Any captured data:
- Order number
- Account ID