Context

Rasayel is a shared inbox built on top of the WhatsApp Business API. When we started this project, automations were almost non-existent. Within two years, the chatbot builder became one of our core differentiators and a key driver of revenue.

I led the product/design work on the chatbot builder end-to-end: from problem framing and discovery through to interaction design, rollout and ongoing iteration.

• Team: 4-5 engineers / only designer who also covers PM & lead role. Work with CEO who is mostly focused on growth.
• Stage: PMF with SMBs, expanding to mid-market.
• Time: Need to show ROI within quarter. 1/3 of my time spent on other projects.
• Platform: Bound by the WhatsApp Business API limits (24h window, template approvals, message types etc).
• Users: Support managers automating FAQs, sales managers qualifying leads, ops managers routing inquiries. Often non-technical, migrating from mature competitors expecting parity from day one. In smaller teams, a single founder or ops lead wears all hats; in mid-market, dedicated roles emerge.
• Company Goal: $500k ARR within 12 months.

Starting Point

At that stage, our chatbot is pretty basic: pick a trigger, send messages, set conditions, and hook up basic API calls.

As we got initial traction, a new constraint showed up, courtesy of our SDR Ashraf:

"We cannot compete yet with high-ACV deals who have advanced workflows currently set on ManyChat, MessageBird, etc."

We had PMF for smaller accounts and signals from high ACV, but struggled to win or expand with larger, more sophisticated teams with comprehensive workflows. They pushed the builder much harder — and hit its limits.

Problem Discovery

Discovery

I ran 20+ discovery sessions with high-ACV accounts and churned customers, while also mining support tickets to understand where the bot fell short.

The pattern was clear: as flows grew, they became hard to maintain. Fallbacks were rigid, integrations too basic, and power users hit walls fast—no loops, no jumps, no global conditions. The question became: how do we turn this from "works for basic support" into a real automation platform?

In short: integration depth (CRMs, API calls), AI capabilities, assignment and routing, and flow flexibility all came up as gaps. We sharpened these into concrete needs during solution discovery.

Defining Success

After some back and forth, we gained clarity on problems and were able to define clear ways for us to evaluate success for our upcoming investment.

Solution Discovery

Identifying key workflow opportunities

Exploration

Mapping the ideal customer workflow

The first thing we did is map the ideal customer conversations and workflow for our customers. So if a high ACV deal came to us with their workflows, what would it entail? We had many answers from our interviews and I jumped into mapping these workflows to try to define the ideal workflow.

My goal was to identify foundation and critical missing gaps in what we have today.

Granular & usability issues

This exercise highlighted the key pieces we missed. But since quality also mattered — support and sales managers spent hours in this workflow builder maintaining complex flows — we also wanted to make sure to capture granular pieces of feedback. I organised company-wide "empathy sessions" where we would split into 4 teams, each was requested to build a specific type of flows using the current product.

This led to many small paper cuts discovery, but also exposed some key bugs and issues. For instance, we discovered many issues with our API calls node, not returning clear messaging when being tested.

Prioritising the 1→10 Roadmap

While our intuition sharpened a lot by then and we had a good idea of what to do, we ran a quick RICE for our own peace of mind.

I translated the discovery work into a RICE-style prioritisation board:

• Each feature idea (from "global fallbacks" to "AI-based nodes") was scored on:
  • Reach (how many high-ACV deals / existing accounts it would unlock),
  • Impact on our proxy metrics,
  • Confidence (based on how many customers had explicitly asked for it),
  • Effort (design + eng)
• This helped us debate trade-offs in a shared, transparent framework, instead of random feature requests.
• Each page had a clear investigation of the codebase (I used Cursor to detail the current system and options for any solutions). This allowed us to have fruitful scoping discussions.

Solution Themes

Rather than a long feature list, we framed the 1→10 evolution around a few themes.

1. Fallbacks & error-handling

From discovery, it was obvious that "what happens when the user goes off-script?" is the heart of any bot.

We:

• Moved from global, centralised fallbacks to contextual fallbacks per node or segment, so teams could fine-tune behaviour per step. Read tradeoffs
• Added safer defaults (e.g., repeat question once, then hand over to agent).
• Surfaced fallbacks visually on the canvas so you could see where the bot was fragile.

2. Canvas & node design for complex flows

As bots grew, the original opinionated layout became a constraint. Discovery sessions with support managers running 50+ node flows showed they wanted more freedom to organise and navigate their workflows.

We:

• Reworked the canvas with zoom, pan, drag-and-drop, and performance improvements so it could handle hundreds of nodes smoothly.
• Standardised node anatomy (icons, headers, ports) to make scanning large graphs easier.
• Clarified "what this node does" by baking key information and high-frequency actions directly into the node, while keeping deeper settings in the sidebar or a popover. Read tradeoffs

3. Power nodes & integrations

High-ACV customers needed the bot to plug cleanly into their stack.

We shipped:

• HTTP request nodes to talk to CRMs and back-office systems.
• Nodes specialised for sales/support use cases (e.g., capture lead data, create CRM records, assign owner). Read tradeoffs
• Flow-control nodes (jumps, splits, waits) to cover more advanced scenarios.
• The foundations for AI-based nodes (intent detection, info collection) as the next step.

4. Analytics

To support both customers and our own roadmap decisions, we added bot analytics: drop-off rates, button CTRs, volume going through each path.

Building analytics surfaced several design decisions:

• Scope: Two use cases emerged — business outcomes (meetings booked) vs. flow performance (drop-offs, conversion). Users saw bots as a proxy for outcomes, so we prioritised flow metrics first.

• Relativity: Percentages could be relative to flow entry or the previous node. We showed both but defaulted to flow entry for clearer conversion visibility.

• Unique vs Total: Users can loop through flows multiple times. We defaulted to unique users (more telling) but surfaced totals to highlight the gap.

• Versioning: Edits reset analytics to preserve data integrity. Not ideal for typo fixes, but detecting "breaking" vs "non-breaking" changes was scoped out. Read tradeoffs

---

Outcome

Over time, the chatbot builder evolved from a "nice to have support bot" into a WhatsApp-native automation platform.

• Sales could confidently lead with "automation" as a core USP, not just "we also have a bot".
• We unlocked and retained larger, high-ACV customers who needed sophisticated flows and integrations.
• The chatbot became one of the key features differentiating us vs. competitors like ManyChat and MessageBird.