WhatsApp AI chatbots: designing for how people actually message

WhatsApp is not a web chat widget with a different logo. People use it differently: several short messages instead of one composed one, voice notes instead of typing, replies hours later, and a persistent thread where last month's conversation is visible above this one.

A bot designed for a chat window handles none of that well, and the failures are characteristic — answering a fragment before the sentence is finished, losing the thread, treating a returning customer as a stranger. The design differences are worth knowing before building rather than discovering in transcripts.

What we'll cover

• How people actually message
• Fragmented input
• The thread is permanent
• Building it with CodeWords
• Writing for the channel
• Buttons, lists and when to use them
• Handover, which every conversation needs
• Voice notes and other realities
• Saying who you are, every time
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

How people actually message

Short bursts, several in a row, rather than one complete message.

Asynchronously. A reply may come in four hours, and the conversation is still live to them.

With context assumed, because the thread above is visible and they can see what they said.

Voice notes, which in several markets are the primary mode rather than an exception.

Informally, with abbreviations, emoji, and without punctuation that would disambiguate a sentence.

In their own language, frequently mixed within a sentence.

Fragmented input

Do not answer the first fragment. "I want to book" followed by "for Thursday" followed by "for two people" is one message arriving in three.

Wait briefly before responding, which is the single highest-impact design choice on this channel.

Combine what arrived in that window and treat it as one input.

A reply to a half-finished thought derails the conversation and reads as not listening.

Handle the correction. People send a message and then a fix immediately afterwards.

Tune the wait from your own transcripts rather than guessing, since it varies by audience.

The thread is permanent

Last month's conversation is visible above this one, to them and to you.

Treating a returning customer as new is conspicuous in a way it is not on a web widget.

Reference the history where relevant — the previous order, the last booking — which is available and rarely used.

Do not repeat onboarding to somebody who has spoken to you before.

Long gaps are normal, and a conversation resuming after a week is not a new one from the customer's perspective.

Be careful what you say in a permanent record, since it stays in their phone.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: what the bot handles, how it should sound, and when it hands over.
3. Authorize the connection to your WhatsApp Business Platform account and the systems it needs to answer from.
4. Describe the exceptions: a fragment, a voice note, a question out of scope, a request for a person, a returning customer.
5. Read a week of real transcripts before changing anything, since that is where the design problems are visible.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Writing for the channel

Short messages. A paragraph that is fine in email is a wall on a phone.

One idea per message, and two short messages beat one long one.

No formatting theatre — headings and bullet lists read oddly in a personal thread.

Plain language, since this is a conversation rather than a document.

Answer first, explain after, because the answer is what they asked for.

Sound like the business, which means whoever writes your customer emails should read these.

Buttons, lists and when to use them

Interactive components reduce ambiguity and are underused.

Buttons suit a small closed set — confirm, reschedule, speak to someone.

Lists suit a longer but still bounded set, such as choosing a service.

They make a reply one tap, which materially improves completion on a phone.

Do not force them where an open answer is natural, since a menu in the middle of a conversation is frustrating.

Always accept typed answers too, because people will ignore the buttons.

Handover, which every conversation needs

It is the most important path, and the one most often left until last.

Offer it visibly rather than making people discover it through frustration.

Transfer the whole thread, which is easy here because the thread exists.

Say what will happen — who is coming, roughly when — since silence after a fast bot is worse than an honest wait.

Detect frustration and offer before being asked, which is the difference between a good and a bad experience.

A person answering the same number is what customers expect, so the staffing arrangement matters as much as the code.

Voice notes and other realities

Voice notes arrive and pretending otherwise is not an option in most markets.

Transcribe or hand over, but do not ignore, since ignoring reads as broken.

Photographs arrive too — a document, a damaged item, a screenshot — frequently as the entire message.

Location shares are common for anything involving an address.

Forwarded messages carry context you do not have and should not assume.

Handle the unsupported gracefully, saying what you can do rather than failing silently.

Saying who you are, every time

An unfamiliar number on a personal messaging app is treated as suspicious by default, and a bot that opens without establishing identity is fighting that from the first word.

Identify the business in the first line, not in a signature at the end.

Reference why you have their number — their booking, their order, their enquiry — which turns an intrusion into a continuation.

Say it is automated and that a person is available, early, which is required in some jurisdictions and reduces suspicion everywhere.

Do not open with a question, which from an unknown number reads as a phishing pattern.

Never ask for anything sensitive in a first message, both because you should not and because it is exactly what a fraudulent message would do.

Repeat identity after a long gap, since somebody returning after months does not have the earlier context in mind even though it is visible above.

Making it survive

Buffer fragments before responding, which is the design choice with the largest effect.

Track the service window per conversation, since replies depend on it.

Deduplicate on message id, because webhooks repeat.

Keep a person reachable on the number during business hours.

Report the outcome: conversations, handovers, fragments merged, and questions it could not answer.

Limits worth knowing about

No group messaging, which constrains some designs entirely.

The service window limits free-form replies to 24 hours after a customer message.

Language quality varies, so some customers get a materially worse experience.

Transcription is imperfect, particularly with background noise and accents.

The thread is theirs. What you write stays in their phone, which is worth remembering when drafting.

What to build first

The fragment buffer: wait briefly before responding and combine what arrived. It is a small change, it is the difference between a bot that reads as listening and one that answers half a sentence, and no amount of better conversation design compensates for getting it wrong.

Two habits make the difference. Read real transcripts weekly rather than relying on metrics, since the design problems on this channel are visible in conversations and invisible in aggregates. And offer the handover before people ask for it, because a customer who has to fight to reach a person remembers that rather than whatever the bot got right.

Frequently asked questions

How is WhatsApp different from a web chat widget?

People send several short messages instead of one, reply hours later, send voice notes, and see a permanent thread where last month's conversation is visible. A bot designed for a chat window fails on all four.

What is the highest-impact design choice?

Buffering fragments — waiting briefly before responding and combining what arrived. Answering "I want to book" before "for Thursday" arrives derails the conversation and reads as not listening.

Why does the permanent thread matter?

Because treating a returning customer as new is conspicuous when they can see the previous conversation above. The history is available and rarely used, and repeating onboarding to somebody who has spoken to you before is noticeable.

How should messages be written?

Short, one idea each, plain language, answer first and explain after. A paragraph that reads fine in email is a wall on a phone, and heading-and-bullet formatting looks odd in a personal thread.

When should I use buttons and lists?

For small closed sets — confirm, reschedule, speak to someone — and for bounded choices like selecting a service. They make replying one tap, which improves completion, but always accept typed answers because people ignore them.

What about voice notes?

They arrive, and in several markets they are the primary mode rather than an exception. Transcribe or hand over, but do not ignore them — ignoring reads as broken.

How important is the handover?

It is the most important path and the least tested. Offer it visibly, transfer the whole thread, say who is coming and roughly when, and detect frustration rather than waiting to be asked.

How do I find the design problems?

Read real transcripts weekly. The failures on this channel are visible in conversations and invisible in aggregate metrics, which is why a dashboard will not surface them.

How should a bot open a conversation?

By identifying the business in the first line and referencing why you have their number — their booking, their order, their enquiry. An unfamiliar number is treated as suspicious by default, and opening with a question reads as a phishing pattern.

Should the bot re-introduce itself to a returning customer?

After a long gap, yes. The thread above is visible but not in mind, and somebody returning after months benefits from the context without needing the full onboarding again.

Related reading

• WhatsApp bot prompt engineering
• How to build a WhatsApp chatbot
• WhatsApp bot analytics