If you do any of these, you aren't building WhatsApp-first. You're building a cute chat that will eventually turn into human support in disguise.
TOP 10
1. Infinite Menu
You've recreated a bad dashboard in text. Chat is not the place to list everything. Chat is the place to guide.
Real-world example:
Customer sends: "I want Dipirona".
Bot responds with 25 mixed options: "
1- Quote
2- Status
3- Speak with an agent
4- Promotions
5- Catalog
…
25- Exchange/Return".
Effect:
The customer chooses nothing, repeats the question, or asks for a human. It becomes a service queue.
2. Dashboard dependency to finalize
If the journey starts on WhatsApp but the critical action only closes on the web, WhatsApp is just an entry point, not an operational layer.
Real-world example:
Customer chooses a product, sends the address, and wants to pay.
Bot: "Ok, I'll forward you to an agent to finish in the system" / "Click the link and finish on the website".
Effect:
You killed the WhatsApp-first promise: WhatsApp becomes just triage. Conversion drops because you created a context switch and dead time.
3. No contextual confirmation for high-impact actions
Canceling, paying, changing addresses, refunding… without explicit confirmation leads to errors, fraud, and regret.
Real-world example:
Customer: "cancel order 1837" (or "I don't want it anymore").
Bot cancels immediately without responding with something like: "Confirm cancellation of order 1837? (1) Yes (2) No".
Effect:
Accidental cancellation, arguments, rework. Worse: the customer can say "I didn't ask for this" and you have no clear proof.
4. Lack of Idempotency
Chat duplicates. Webhooks duplicate. The user resends. If repeating a command generates a duplicate effect, you charge twice and destroy trust.
Ex.: every critical command needs a command_id and an idempotency_key.
Real-world example:
Customer asks to "PAY order 1837 via Pix".
WhatsApp resends / webhook duplicates / customer clicks twice.
The system generates two Pix charges or records two payments/credits.
Effect:
Financial chaos and loss of trust. In a pharmacy, this turns into annoying immediate support (and chargebacks when it's a credit card).
5. No "Go Back" path / low-cost correction
If the user makes a mistake and needs to start from scratch, you are charging a cognitive tax. This kills conversion.
Real-world example:
Flow asks: "Enter your full address".
Customer mistypes the number ("123" instead of "132").
Bot: "Invalid entry. Restart service by sending ‘menu’".
Effect:
The person gives up. The cost of correcting is higher than buying somewhere else.
6. Losing context
Making the user repeat what they just said is the fastest way to look stupid and disrespectful. Context isn't a luxury; it's a requirement.
Real-world example:
Customer: "I want Dorflex and delivery today".
Bot asks for ZIP code. Customer responds.
Bot: "Perfect, which product would you like?" (forgot Dorflex and "delivery today").
Effect:
Seems stupid/disrespectful. The user starts to "distrust" and asks for a human.
7. Overly open-ended questions
"How can I help?" without structure leads to chaos. You need structured language, short options, and objective questions.
Real-world example:
Bot starts with "How can I help?"
Customer sends: "I'm in pain, have a fever, and need something for a child".
The bot tries to "chat," asks generic things, and fails to structure triage (age/weight, allergies, urgency signs).
Effect:
Mess and risk: in healthcare, open questions lead to long, ambiguous answers, and the flow doesn't advance safely.
8. Operating without an evidence trail
If you don't record what was requested, confirmed, and executed, you can't audit or recover.
Ex.: each confirmation should generate an event of type confirmed(action, actor, timestamp).
Real-world example:
Customer confirms: "you can substitute with a generic" (or "you can change the brand if you don't have it").
Later they complain: "I didn't authorize this exchange".
You don't have a structured record of "YES, I authorize substitution" associated with order 1837.
Effect:
You lose the dispute and it turns into a loss. An evidence trail is what saves you in exchanges, deliveries, and substitutions.
9. Ignoring anti-fraud
A phone number provides implicit identity, not perfect authentication. High-risk actions require progressive friction.
Real-world example:
Someone with the customer's WhatsApp (stolen phone, cloned SIM, or relative) asks:
"Change the address of order 1837 to X Street, number Y" and "confirm payment on card ending 1234".
System accepts simply because "it's the customer's number".
Effect:
Diverted delivery + fraud. High-risk actions need progressive friction: extra confirmation, validation by known data, or a human step.
10. Bot that over-improvises
If the same intent generates different responses all the time, the user loses predictability. A conversational interface needs protocol, not creativity.
Real-world example:
Customer asks twice at different times: "Do you have Ozempic?"
One time the bot replies "Yes, we do. Want to reserve it?"
Another time it replies "We don't sell that type of product"
Or it changes the options format every time ("yes/no", then "1/2", then "type confirm").
Effect:
The system seems unstable. User loses predictability and starts to doubt (or just gets annoyed).
In order to best disseminate this content, in addition to releasing one very dense and complete article about the technical parts of each concept I used in WhatsApp-first from FullAgenticStack, I will also try to break it down into smaller, concise, and independent articles. In the course, I will demonstrate in my real code how each concept was implemented or corrected.
Would you like me to adjust the tone of any specific section or help with the technical articles mentioned?
Top comments (0)