Most WhatsApp chatbot demos look great for about ninety seconds. Someone asks for opening hours and the bot answers. Someone asks for a price and the bot answers. Then a real customer types "my order came broken and I want a refund now", the bot replies cheerfully with a product suggestion, and the business has a problem.
After building and reviewing a fair number of these for small businesses, my view is that the model is rarely what decides whether a chatbot helps or hurts. What decides it is the plumbing around the model: what the bot is allowed to answer, where its answers come from, and above all when it gets out of the way. Here's the blueprint I'd use.
1. Start from conversations, not features
Before writing a line of code, export a month of real WhatsApp chats and sort them into buckets. In most service businesses you'll find:
- Repetitive FAQs: hours, location, prices, documents needed.
- Lead questions: "Do you do X? How much? When can you start?"
- Transactional requests: bookings, rescheduling, order status.
- Sensitive conversations: complaints, refunds, anything medical, legal or financial.
The first three are where automation pays off. The fourth is where it gets you into trouble. Write the buckets down, because they become your routing rules.
2. Route before you generate
Don't send every message straight to the LLM. Put a cheap classification step in front of it:
incoming message
-> intent = classify(message, history)
-> if intent in [complaint, refund, human_request, low_confidence]: hand_off()
-> elif intent == order_status: answer_from_database()
-> elif intent == booking: run_booking_flow()
-> else: answer_from_knowledge_base()
Order status should come from your database, not from a model's guess. Bookings should come from your calendar API. The LLM handles the open-ended middle.
3. Ground answers in your own content
A knowledge base bot is only as good as what you feed it. Chunk your FAQ, service pages, price list and policies into small passages, store the source URL with each chunk, and tell the model to answer only from the retrieved text. If nothing relevant comes back, it should say so and offer a human. "I don't know, let me connect you with the team" is a perfectly good answer. A confident wrong price isn't.
4. Make lead qualification feel like a conversation
For lead-driven businesses such as real estate, clinics or consultancies, the bot's most valuable job is qualification. Ask your best salesperson which three questions they always ask first (usually budget or scope, timing, and location), then have the bot ask exactly those, one at a time. Write the answers into your CRM as structured fields, not as a transcript blob, so the sales team can sort and follow up.
5. Design the hand-off before anything else
This is the part most builds skip. A good hand-off:
- stops the bot from replying once a human takes over,
- passes a summary (who, what they want, what has been answered),
- tells the customer that a person is now handling it,
- works after hours, with a clear promise of when someone will reply instead of silence.
Trigger it on explicit requests ("agent", "human"), on negative sentiment, on topics the bot shouldn't touch, and when retrieval comes back empty.
6. Respect the platform rules
On the WhatsApp Business Platform, free-form replies are allowed inside the customer-service window that opens when the customer messages you. Outside that window you need approved templates. Meta's business messaging policies also expect clear escalation paths, and they've tightened what kinds of AI assistants are allowed on the API, so keep your bot scoped to your own business's customers and check Meta's current policy before you launch.
7. Log everything, then improve weekly
Log every question, the retrieved sources, the answer and any hand-off reason. Once a week, read the hand-offs and the "I don't know" answers. Each one is either a missing FAQ entry or a routing rule to add. That loop is what turns a demo into a 24/7 assistant your team actually trusts.
Where website and voice fit
The same architecture works for a website chatbot, with the bonus that you can collect lead details in a form and book meetings directly. Voice AI bots that answer calls use the same routing and hand-off logic, plus speech-to-text at the front. Building it once with clean routing means you can add channels later without rewriting the brain.
I work on AI chatbot development at DigeeX, where we build website, WhatsApp and voice assistants for businesses in the UAE. Happy to answer questions about routing or hand-off design in the comments.
Top comments (1)
The routing sketch is a good corrective to the demos that send everything to the model, especially answering order status from the database instead of letting the LLM guess.
The part of hand-off I'd add to your list is the way back. Stopping the bot once a human takes over is easy; deciding when it is allowed to speak again is where the builds I've seen went wrong. If release depends on staff clicking resolve, some threads stay muted for weeks, and the same customer asking for opening hours next Tuesday gets silence. If it releases on a timer, the bot can jump back into a refund conversation the owner is still handling from their phone. What worked better for me was attaching the hand-off to the open issue rather than the whole chat: the bot stays quiet while the issue is open or a human has replied recently, and when it resumes, its first message acknowledges what the person already sorted out instead of greeting the customer like a stranger.
The other edge is the customer-service window. A complaint handed off at 9 pm on a Friday may not get a human reply until Monday, after the 24 hour window has closed, so the promise of when someone will reply has to be backed by an approved template the staff can send, or the human literally cannot answer. Worth testing before launch.
How do you decide when a handed-off conversation goes back to the bot: a staff action, a timeout, or something in the customer's next message?