5 Design Principles for a Fast & Reliable AI WhatsApp Bot

There’s a lot of excitement around AI WhatsApp Chatbots right now. And for good reason.

For many organisations, especially in the social sector, WhatsApp Bot is where users already are. It’s familiar, accessible, and scalable.

But most teams end up with something that is slow to build, expensive to run or unreliable in real-world use

Over the last year, we worked on multiple AI Bot projects and had some amazing learnings along the way! We realised something important:

👉 The challenge is not AI.

👉 The challenge is designing the system around it.

This is a reflection of 5 decisions that made the difference.

1. Start with a simulated Prototype instead of Integrating APIs

In most projects, progress is blocked by one thing: “We’re waiting for APIs.”

And in reality, most chatbot interactions don’t depend on live data!

So we chose not to wait. We built a working prototype without any integrations.

We simulated responses.

Tested multilingual flows.

Explored edge cases.

What this helped us do:

• Validate the interaction before the system

• Get early feedback

• Refine the structure without dependency

Take-away: Don't start with integration. Start with interaction.

2. AI Chatbot UI Plugin Over Full Integration

A chatbot project can quickly turn into a frontend overhaul. New interfaces. New flows. Heavy coordination.

We avoided that.

Instead, we built a lightweight UI snippet that could be embedded directly into the client’s existing landing page.

Take-away: No redesign. No heavy lifting. Just plug and play.

3. We Chose Simplicity (When Risk Allowed)

When the first API became available, we had a choice:

Route everything through a backend layer OR Call the API directly from the frontend

We chose the latter.

Because:

• the data was public

• the risk was low

• and speed mattered

This removed unnecessary steps like IP whitelisting and backend deployment.

Of course, this won’t work for every system. It's only safe when data is public and low-risk.

Take-away: Good system design is not about always adding layers. It’s about knowing when you don’t need them.

4. We Made Prompts Easy to Change

One of the biggest bottlenecks in AI systems is prompt engineering and iteration. and though it has the word 'engineering' in it, trust us it has been little to do with it!

The best way to build right infrastructure for prompts is to keep it outside the code. Let the product or business team:

• Write the first version of prompt during building stage

• Let me test the response and make changes during QC and Pilot phase

• And post launch, give them the flexibility to make changes in real time and on demand so the bot is responding to the user in the most efficient manner

If every change requires a developer, progress slows down.

So we kept prompts Editable by non tech teams. In plain English.

This meant:

• faster testing

• easier collaboration between teams

• no deployment cycles for small changes

Key Take-away: If your system makes it hard to change behaviour, it will be hard to improve it.

5. We Stopped Asking AI to Do Everything

This was the most important shift. It’s tempting to let AI handle everything:

• understanding intent

• doing calculations

• making decisions

But that leads to:

• higher costs

• slower responses

• inconsistent outputs

So we changed our approach. We moved logic into code.

• Calculations → handled programmatically

• Data retrieval → via APIs

• Classification → rule-based where possible

And we used AI for one thing:

👉 Turning outputs into human, conversational responses

But its also important to find the right Balance between what kind of decision making to be left for AI or retained at code level. For e.g. this Principle will not apply to Agentic AI Bots

Key Take-away: AI for expression, not computation.

Designing for AI WhatsApp Bot Constraints

Building on WhatsApp comes with its own set of constraints. Unlike web-based chatbots:

• You can’t stream responses → users experience delay

• Webhooks must be acknowledged quickly → or events get retried

• Duplicate messages can occur if not handled properly

What we did:

• Acknowledged webhook events immediately

• Processed responses asynchronously

• Sent replies as outbound messages

• Added idempotency checks to avoid duplicate responses

But this created a new challenge:

Outbound messaging depends on queues. And at higher volumes, queues can slow things down. It requires robust queue, retry, and monitoring strategies to ensure a great experience to users.

Every design decision solves one problem—and introduces another.

The Framework in One Line

Looking back, this is what changed:

• Don’t wait for APIs → simulate first

• Don’t build heavy systems → keep integration light

• Don’t over-engineer → choose simplicity when possible

• Don’t lock prompts in code → enable iteration

• Don’t overuse AI → use it where it adds value

A Final Thought

There’s a lot of focus today on choosing the right model. But in real-world systems, especially in the social sector, that’s rarely the deciding factor.

🎥 You can watch our detailed Webinar on this here

📄 Access the slide deck here

If you’re building something similar, we’d love to exchange notes. Please do write to us at contact@impactyaan.com.