Overview
As Product Designer and System Architect, I designed a WhatsApp conversational assistant for travel agency operators. The goal was to eliminate the repetitive manual work that consumes hours of their day without delivering real value to the client.
The core insight: operators already live in WhatsApp. They don't need to learn a new tool — they need the tool they already use to be smarter.
The Challenge
Travel agency operators lose hours every day on tasks that deliver no value to the client:
Itineraries from scratch
Copy-pasting from old files, manually editing every detail. A 15–20 minute process per request.
Scattered data
Client information spread across chats, notes and memory. No central system — everything depends on remembering.
The main challenge wasn't technical, it was behavioral: getting the operator to adopt the system without asking them to change how they work.
Design Process
The design started by defining what the system would NOT do — a harder and more valuable discipline than defining what it would. Three non-negotiable constraints guided every decision.
Fixed channel
WhatsApp and WhatsApp only. No new apps, no dashboards, no onboarding. The operator is already there — the system goes to them.
Natural language
The operator writes the way they speak. No commands, no numbered menus, no special syntax. The system interprets the intent.
Immediate value
Value from the very first message. No prior setup, no lengthy training, no visible learning curve.
The 3 Core Capabilities
1. Itinerary Generator
The operator describes the trip in natural language. The bot extracts destination, duration and traveler profile, then generates a base itinerary structured by days and activities.
- Before: 15–20 minutes of copy-pasting from old files.
- Now: 1 message. The system interprets and generates.
- Real inputs: "Trip to Cusco for 4 people", "Itinerary to Cancun for the Johnson family".
2. Automatic Client Capture
When the operator requests an itinerary while mentioning the client, the system automatically detects name, destination, number of travelers and date.
No form. No extra step. Registration happens as a side effect of the work the operator was already doing.
3. Document Search
The operator requests any document from the repository in natural language. The system returns the most relevant result with a direct link.
No more manual folder browsing. "Find the standard contract" → instant result.
Results & Success Criteria
Itineraries generated from a single WhatsApp message. Before: 15–20 minutes.
Additional steps to register a client. Capture happens invisibly.
Core features that deliver 100% of the operational value. Nothing more needed for the MVP.
Key Design Decisions
WhatsApp as the only channel
vs. a custom app or web platform. Operators already live there. Zero adoption friction.
Natural language, no commands
vs. numbered option menus. Commands create dependency. Natural language is faster.
Capture as a side effect
vs. explicit form. Any extra step reduces adoption. Invisible capture is more powerful.
3-feature MVP
vs. full system from day one. Validate before scaling. Less = more focus = faster adoption.
Project Gallery
Project Learnings
-
01
Defining what NOT to build is more valuable than defining what to build
Starting with a list of exclusions protected the project's focus. The discipline of saying no was the most important design decision of the MVP.
-
02
Designing for the existing channel removes the adoption barrier
No one had to be convinced to adopt a new tool. The system went to where the operator already was. That's invisible design.
-
03
Metrics must be defined from day one
I'd do this differently: define upfront how many itineraries per week, how many document searches. Without data, MVP validation is just perception.