I was planning a Sunday in Mexico City. Good neighborhood, obvious destination, a park that every local recommends. The itinerary looked clean. I ran it through Claude with the dates, the specific location, and a prompt asking it to flag any logistical issues. It came back with one: on that particular Sunday, all park entrances would be closed for a city-wide cycling event that takes over the main access roads.
I would not have caught that. Not because I am a bad planner, but because I was not thinking about cycling events when I was thinking about parks. That is exactly the kind of second-order logistics problem that ruins an otherwise perfect day for a client who flew 11 hours to be there.
This is what AI is actually for in bespoke travel planning. Not to replace the designer's expertise. To catch what expertise alone misses.
How are custom trip designers using AI today, and where are they leaving value on the table?
Most designers at bespoke travel companies are already using AI to plan itineraries. They use it to organize what they already know, do light destination research, and speed up the first draft of a day-by-day structure. That is a reasonable start, and it does save time. But it is roughly 20 percent of what the tools can do. The gap is in three places: client history is not making it into the prompt, logistics risks are not being systematically surfaced, and the final output still looks like a Google Doc from 2015. Closing all three gaps does not require new software. It requires better prompts and a structured place to store what clients tell you.
Why is client history the missing ingredient in most AI-assisted trip planning?
At larger tour operators, client data theoretically lives in a proprietary system. In practice, that system is updated inconsistently. Guides capture observations after a trip rather than during it, and the notes that do get filed rarely make it into the hands of the designer planning the next booking. A client mentions over dinner on day six of a Morocco trip that she has always wanted to see the Douro Valley. That comment is gold. It almost never makes it into a database field.
At smaller bespoke operators, the system is a trip report in a Google Doc that feeds into a client spreadsheet that one person maintains and two people actually look at.
The result is the same in both cases: when a designer sits down to plan a returning client's next trip, they are starting from partial information. They know the past destinations. They may not know that the client complained about the pace on day three, that she travels better with a private guide than a small group, or that she mentioned Bhutan twice in conversation.
A client profile that lives inside a Claude project changes this. Every past trip, every preference captured, every guide note, every offhand comment, all of it becomes searchable and reasoned over, not just stored.
What should a bespoke travel client profile actually contain?
The profile does not need to be elaborate to be useful. A structured document with consistent fields per client is enough to start. Past destinations traveled with you, and rough dates. Travel style notes: pace preference, accommodation tier, activity tolerance, group size preference. Dietary restrictions and any medical or mobility considerations. Complaints or friction points from past trips, specific ones, not just "food was an issue." Guide feedback captured in the field. Future destinations mentioned in any context, on a call, in an email, on the ground. Any personal details that affect planning: anniversaries, children's ages if they travel as a family, professional context if it comes up.
The most valuable entries are the ones captured in the field. A guide who notes that a client lit up at a particular kind of experience, or mentioned a destination unprompted, is handing the sales team a closing argument for the next booking. Most operators have no reliable mechanism to get that note from the guide's memory into the client file.
How do you build prompts that actually use client history?
The mistake most designers make is prompting AI as if it has no context. They open a session, describe the destination and dates, and ask for an itinerary. The output is competent and generic. It does not know that this particular client walked out of the last property that had a buffet breakfast, or that she travels with a partner who has a bad knee and cannot manage more than four hours of walking in a day.
A prompt that integrates the client profile looks different. It starts by loading the profile, then specifying the trip parameters, then asking Claude to design against both. It also asks Claude explicitly to flag any elements of the proposed itinerary that conflict with what the profile reveals about past friction points.
The third layer, and the one most designers skip entirely, is the logistics audit. After the itinerary draft exists, run a separate prompt that takes the specific dates, locations, and day-by-day structure, and asks Claude to surface any known risks: seasonal closures, local events that affect access or pricing, transit timing gaps, supplier lead times that the current planning timeline may not accommodate. This is the prompt that catches the cycling event before the client lands.
What does a well-prompted itinerary session actually look like?
A practical structure for a returning client trip, using a tool like Claude:
Start by pasting the client profile document into the session. Follow it with the trip parameters: destination, dates, group composition, budget tier, any stated goals for this particular trip. Then ask Claude to draft a day-by-day itinerary that fits the parameters and accounts for what the profile reveals, flagging any tensions between what the client has said they want and what the profile suggests they actually enjoy.
Once the draft exists, run the logistics audit as a second prompt in the same session. Ask Claude to review each day against the specific dates and flag any risks it can identify from its training data: market days that affect traffic, attraction closures, weather patterns for that location in that month, typical supplier booking lead times for the activities proposed.
A third pass looks at the proposal output itself. Ask Claude to rewrite the day-by-day structure in a voice that matches your company's brand, structured for client delivery rather than internal planning. This is the step that turns a planning document into something that feels like the trip has already started.
Why does the final proposal still look like a Google Doc?
This one is mostly habit. Bespoke travel companies charge substantial fees for deeply considered, highly personalized trips. The experience of receiving a proposal should reflect that. A Google Doc with a table does not.
Designers who use Claude to write narrative proposal copy, destination context, day-by-day descriptions written in the second person so the client can feel themselves in it, and a clear summary of what makes this particular itinerary right for this particular traveler, produce proposals that close faster and generate more referrals. The content does not change. The presentation does. And for a client deciding between two operators at a similar price point, the proposal is often the deciding moment.
The same logic applies to post-trip wrap-ups. Most operators send nothing after a trip ends beyond a feedback survey. A short, well-written recap of what the client experienced, delivered within a week of return, with a line about what might come next based on what they mentioned wanting to see, is one of the highest-value retention tools in bespoke travel. It takes Claude about ten minutes to draft from a guide's post-trip notes.
What does this change for the designer?
A designer at a bespoke operator is good at their job because they know things: destinations, suppliers, what works for which kind of traveler. The limitation has never been expertise. It has been memory and bandwidth. There are only so many client profiles a person can hold in their head, only so many logistics variables they can check manually, only so many proposal documents they can write from scratch in a week.
When client history lives in a structured, AI-readable format, the designer's expertise gets multiplied rather than replaced. They stop starting from zero on every returning client. They stop missing the logistics problem that only shows up when you think to ask. They stop sending proposals that look like internal planning documents.
The client on the other end notices, even if they cannot name exactly why. The trip feels more considered. The proposal feels more personal. The sales call feels like talking to someone who actually remembers them.
That is the job. AI just makes it possible to do it at scale.
The trip designer's second brain is one of twelve high-ROI workflows for travel operators. The complete ranked list, with setup time and time-saved estimates for each, is in the 12 tour operator workflows worth automating with AI.