Validating Customer Replies in a WhatsApp Bot (So Bad Data Never Slips Through)

A WhatsApp bot that asks "what's your email address?" and silently accepts "idk" as the answer isn't collecting an email address - it's collecting a string, and the difference only becomes a problem later, when whatever downstream process relies on that field (a confirmation send, a CRM sync, an appointment reminder) breaks on bad data nobody caught at the source.

The fix is validating a reply at the moment it's captured, not after the fact. A bot step that asks a question should be able to declare what kind of answer it expects - an email address, a phone number, a number, a date, a plain yes/no, one of a specific list of choices, or a custom pattern for anything else - and reject anything that doesn't actually match, before it ever gets saved as a usable variable.

What happens on a failed validation matters as much as the check itself. The wrong response is silently accepting bad data anyway, or dead-ending the conversation entirely. The right response is re-asking - sending a clear, specific hint ("that doesn't look like a valid email - could you send it again?") and waiting for another reply, on the exact same question, for as long as it takes to get something usable. No conversation should ever advance on a variable the bot never actually validated.

Yes/no questions are a smaller but common trap: a customer might type "yes," "yeah," "sure," or "ok," and all of those should mean the same thing to whatever branch checks the answer afterward. Good validation doesn't just check that an answer is affirmative or negative - it canonicalizes it, storing a clean "yes" or "no" regardless of exact phrasing, so a downstream if/else comparing against "yes" works reliably instead of silently failing on a variant it didn't anticipate.

The same idea applies to a fixed list of acceptable answers - "Small, Medium, or Large" - where the bot should match against the list case-insensitively and store back the canonical option, not whatever casing or spacing the customer happened to type. Anything genuinely custom (an order ID format, a postal code, an internal reference number) is exactly what a raw pattern-matching rule exists for, as an escape hatch past the common built-in types.

The broader point is that a chatbot's usefulness downstream is capped by the quality of what it captures upstream - an automation that sends a confirmation to "idk" or books an appointment for an unparseable date has technically "completed," but produced nothing usable. Validating at the point of capture, with a genuine retry loop instead of a shrug, is what actually makes a WhatsApp bot's collected data trustworthy enough to act on automatically.