A Chatbot Builder for the WhatsApp Business API
Led the product design of Rasayel's chatbot builder, integrated and optimised for the WhatsApp Business API to enable automated interactions and scale conversations efficiently.
Role and Context
As product designer, I was responsible for identifying problems, prioritiszing them with our CEO, and scoping the solutions in a manner that would deliver value incrementally so we could validate our assumptions. I iterated on our chatbot builder for the WhatsApp Business API over 2 years.
The project started as an experiment, to validate the identified demand of automating WhatsApp conversations with a chatbot builder tool. The chatbot ultimaely became a core USP for our platform and we iterated on it for over 2 years.
Understanding the Problem
Understanding the problem was a challenge initially since chatbots address diverse jobs-to-be-done. Conversations vary from use case to use case (from qualification to basic support FAQ). This required us to find patterns of needs from our customers that we could map to a system.
We prioritized support use cases initially (pre-pivot to sales-focused ICP) to focus efforts and validate the core functionality before expanding to broader use cases.
How we got there?
Building the Solution
We approached development iteratively, starting with a proof of concept and expanding capabilities based on user feedback and market validation.
Proof of Concept
We started with the basics to validate viability. The first version was intentionally limited in scope to test core feasibility. We focused on inbound triggers with simple conditions, worked within WhatsApp's 24-hour messaging window, and built basic tagging and status changes. The canvas used an opinionated layout that later proved limiting as flows grew more complex.
Use cases expansion
We added more nodes to increase the number of use cases we could cover. Added HTTP request node to integrate external systems, prioritizing shipping new nodes over polish to validate market fit.
Enhanced Usability
Emphasized usability for complex flows. Rebuilt canvas with undo/redo, drag-and-drop, zoom, and performance optimizations to handle large bots smoothly.
Polish and Intelligence
Polished interactions, added analytics (CTR tracking), CRM integrations, and AI features: nodes for info collection, intent detection, and basic AI agents.
Thanks to customers who challenged each iterations.
.png&w=3840&q=75)
Core Challenges
As the only product person on this project while juggling multiple initiatives, effective prioritization became critical to our success. Customer expectations were high from day one—they were migrating from more mature competitors with extensive action libraries and robust fallback systems. We had to learn quickly and build solid foundations while managing time constraints.
Feature Prioritization
Early prioritization was straightforward—we had nothing, so building the basics was clear. Complexity emerged when deciding on use case-specific features like smart capture nodes for sales qualification, while our ICP was broadly "every business using WhatsApp." This friction sparked conversations that ultimately helped us refine our customer focus.
Simplicity vs Power
We constantly debated whether to keep things simple by blocking certain use cases (like restricting action nodes to only follow message nodes) or accept slightly more complexity to enable broader functionality. This balance shaped every design decision.
Flexibility vs. Opinionated Design
Balanced defaults (e.g., customizable fallbacks) with extensibility. For example, we initially restricted node positioning to ensure readability, but learned that as flows became complex, users needed flexibility to organize their layouts. This tension required constant iteration to maintain usability without overwhelming users.
Deep Dive
Evolution of the Interactive Message Node that can contain buttons
Node Design
The node architecture formed the foundation of the chatbot builder, making its design paramount to the platform's success. This presented several inherent challenges that required careful consideration. First, we needed to identify the right nodes that addressed specific user needs at the appropriate level of granularity. Second, these nodes had to be intuitively designed - easy to use and satisfying to interact with, especially considering that workflows could contain dozens or even hundreds of nodes. The user experience of each individual node was crucial to the overall platform usability. Through iterative development, we continuously refined the node system based on user feedback and learnings to achieve the optimal balance of functionality and usability.
Key tradeoffs and issues
Actions on Nodes vs Separated
Since flows were mostly conversational initially, we decided to have actions (like closing the conversation) on the message nodes. This ended up being confusing for some, but especially didn't make the life of our users easy as (1) they didn't know they had to do so and (2) their needs evolved to be sometimes more operational (e.g. close conversation after assigning).
Fallbacks at the Node Level
We quickly understood that fallbacks were the core of bots (essentially "what if user does x"). My initial intuition was that having fallback separated from nodes was better for the UX since they had 1 place to set them up, and I found that the ability to manage fallbacks differently dependent on the node or where you are in the flow was overkilled. This quickly proved itself to be wrong and as a consequence we placed contextual fallback on the nodes.
Lack of Design System
We started with message nodes, but as we expanded use cases, created many nodes. Nodes started looking differently and nothing was consistent. As a consequence, we rethought the visual anatomy of a node. We did it over multiple internal iteration with our front end engineer.
Editing Experience
This is something I still remain unsatisfied with, but we had to decide what, if anything could be edited from the canvas in opposition to be edited in the sidebar. We had different paths, opening a sidebar, a popover over the node in the canvas, or direct inline node editing on the canvas. Of course editing on the node itself came with the issue of zoom levels. Editing in the sidebar was making you lose some context. So we ended up going for a mix, some key infos/high frequency actions could be taken from the canvas on the node itself, but the rest had to be done in the sidebar or popover.
Outcome
Workflow that actually deliver value
From no automations to complex conversational flows integrated with the customer CRMs.
Fueled growth from 0 to 65k MRR
One of the key features allowing us to close deals within our ICP.
Differentiated from competitors
Flow is fully WhatsApp Native, allowing us to outcompete competitors.
The chatbot builder became a core differentiator for Rasayel, allowing us to close deals with customers using other platforms like WATI, Respond.io etc. It fueled our growth from 0$ to 65k$ in MRR, adding to our key differentiator like the quality of our inbox, and the depht of our CRM integrations. While there are many things I would want to do next, I am proud of the product's impact on the business and customers, especially accounting for the very limited resources we had.
We iterated on the features for 2.5 years, continually testing and discussing with our customers through dedicated Slack channels. As a consequence, the product was delivering on all key use cases while having a solid design system that we also iterated 2-3 times throughout the development process.