Unifying a Fragmented Lead-to-Sales Journey
Service Blueprint & WhatsApp CX Design for a Dubai-Based Automotive Group

A Process With No Single Owner

The existing lead-to-sales journey was entirely manual, and it showed in the customer experience: late responses to new leads, no unified way to track where a lead actually stood, and long wait times with no visibility into the cause. Ownership of a lead moved across four different roles with no shared system connecting them. The business's answer was a new CRM. My job wasn't to build the CRM — it was to make sure the customer experience was designed into it, rather than assumed.

Blueprinting the Future State

I mapped the end-to-end future-state journey, from first lead capture through to sale close, blueprinting two layers at once: what the customer experiences, and what has to happen behind the scenes for that experience to hold up. That meant mapping the customer journey stage by stage, identifying where notifications and surveys needed to sit in the flow, and mapping backend handoffs across all four roles so a lead didn't lose momentum — or visibility — moving between them. The work was less about inventing a new experience and more about making sure the new system didn't quietly rebuild the old one's blind spots in different software.

Designing for Leads and Customers Already in the System

A chatbot was already in development for brand-new leads when I joined. My scope was the three personas that come after that first contact:

Existing Lead

Someone who'd already spoken to a sales advisor but hadn't yet purchased. The core design problem was continuity: the bot couldn't start from zero without undoing the relationship a human advisor had already built. I designed the flow to branch on whether an advisor had made contact and where the person stood in the test-drive process, so the bot picked up the conversation where the human left off. Since live advisor handoff wasn't available in this system, "Speak to an advisor" became "Request a callback" or "Request a follow-up call," so the promise matched what the backend could deliver.

Existing Customer, With and Without an Active Service Booking

For customers with no open booking, a simple top-level menu: book a service, request assistance, or see more options. For customers with an active booking, status-based branching — Scheduled, In Progress, Ready for Pickup — so the message and available actions matched where their car actually was.

Across both, I made deliberate cuts: Roadside Assistance was removed once we confirmed it was insurance-handled, not something the business could act on, and separate complaint categories were merged into one "Request Assistance" entry point, since customers don't think in a company's internal category names when something's gone wrong.

Reflection

This was a different kind of test than my earlier research-led work: no room for a multi-week discovery phase, four stakeholder roles who each had their own definition of "done," and a live system being built in parallel. It reinforced something I keep coming back to — the customer experience rarely breaks at the visible touchpoint. It breaks in the handoff no one owns.