Overview
As Product Designer and System Architect, I designed a WhatsApp conversational assistant for travel agency operators. The goal was to eliminate repetitive manual work that consumes hours of their day without creating real value for the client.
The core insight: operators already live in WhatsApp. They do not need to learn a new tool; they need the tool they already use to become smarter.
The challenge
Travel agency operators lose hours on tasks that do not add value for the client:
Itineraries from scratch
Copying and pasting from old files, then manually editing every detail. A 15-20 minute process per request.
Scattered data
Client information scattered across chats, notes, and memory. Without a centralized system, everything depends on recall.
The main challenge was not technical, but behavioral: getting operators to adopt the system without asking them to change how they work.
Objective
Design a WhatsApp AI assistant that reduced repetitive sales and operations work without forcing the team to adopt a new platform.
Sales speed
Move from manually assembled itineraries to generated responses from a clear natural-language message.
Invisible capture
Register clients and requests as a natural part of the conversation, with no forms or extra steps.
Operational control
Make document search and traceability easier so the agency can stay organized without daily friction.
My role and scope
I worked as Product Manager and product architect, defining the MVP scope, conversational flows, and functional logic of the assistant.
Product Manager
I prioritized the MVP around three use cases: itineraries, client capture, and document search.
Conversational design
I defined intents, responses, and rules so users could write naturally without learning commands.
Functional architecture
I organized the relationship between WhatsApp, client data, itinerary generation, and the document repository.
How I worked
The design started by defining what the system would NOT do, a harder and more valuable discipline than defining what it would do. Three non-negotiable constraints guided every decision.
Fixed channel
WhatsApp and only WhatsApp. No new apps, no dashboards, no onboarding. The operator is already there; the system goes to them.
Natural language
The operator writes as they speak. No commands, no numbered menus, no special syntax. The system interprets intent.
Immediate utility
Value from the first message. No prior setup, no long training, no visible learning curve.
Deliverables
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-paste from old files.
- Now: 1 message. The system interprets and generates.
- Real inputs: "Trip to Cusco for 4 people", "Itinerary to Mancora for the Perez family".
2. Automatic Client Capture
When the operator requests an itinerary mentioning the client, the system automatically detects name, destination, number of people, and date.
There is no form. There is no extra step. The record is created as a side effect of the work the operator was already doing.
3. Document Search
The operator requests any repository document in natural language. The system returns the most relevant result with its direct link.
The end of manual folder search. "Find the standard contract" → immediate result.
Impact
Itineraries generated from a single WhatsApp message. Before: 15-20 minutes.
Additional steps to register a client. Capture happens invisibly.
Core functions that deliver 100% of the operational value. Nothing else is needed for the MVP.
Gallery
Learnings and improvements
- 01
Defining what NOT to do is more valuable than defining what to do
Starting with the list of exclusions protected the project focus. The discipline of saying no was the most important design decision in the MVP.
- 02
Designing for the existing channel removes the adoption barrier
There was no need to convince anyone to adopt a new tool. The system arrived where the operator already was. That is invisible design.
- 03
Metrics must be defined from day one
What I would do differently: define from the start how many itineraries per week and how many documents searched. Without data, MVP validation is only perception.