Building an AI-powered Travel Platform from PDF Upload to Live Online Tour
I. Client Story
Travel agents already have the tours — they just cannot get them online quickly.
Our client is a travel platform startup building a new model for how independent travel agents sell tours online. The founders observed a specific friction in the way agents work today: most agents have already invested significant effort into building tour packages and marketing materials, typically as PDF documents they email to clients or share through messaging apps. The tours are real, the agent knows them well, and the PDF already exists. But the moment the agent wants to sell that same tour through any online platform, the agent has to re-enter everything manually — destinations, itinerary day by day, inclusions, pricing tiers, photos. Most agents are not willing to do this. The work stays offline, and online sales never scale.
The startup's thesis is that generative AI can remove this barrier entirely. If an AI platform can read an agent's existing PDF and turn it into a structured tour ready to sell online, the friction disappears. Agents keep working the way they already work. The platform handles the conversion to a structured, bookable format. And once tours are in the system, the platform can do something traditional tour booking sites cannot: let end customers customize tours themselves, or use an AI chatbot to get personalized travel advice that adjusts the tour to their preferences.
Adamo is partnering with the startup to engineer this platform — from the AI extraction pipeline to the agent-facing tour management interface, the end-customer booking experience, and the AI chatbot for customer support.
II. The Challenge
Technical challenges between vision and product:
- AI extraction from unstructured tour PDFs at production quality
Tour PDFs vary wildly in structure. Some are clean templates with consistent headings. Others are dense brochures with mixed layouts, embedded images, and inconsistent formatting. The AI extraction must work reliably across this variation, producing structured tour data accurate enough to publish without manual cleanup. Demos that work on one PDF format are not the same as production systems that handle the real diversity of agent documents. - AI chatbot that gives useful travel advice, not generic AI responses
Generic chatbots are easy. A travel chatbot that understands the tours actually available on the platform, factors in destination knowledge, and can adjust recommendations to a customer's stated preferences is significantly harder. The chatbot must ground its responses in the platform's actual tour catalog rather than generating plausible-sounding but incorrect travel suggestions. - End-customer tour customization without breaking pricing logic
Letting customers self-customize a tour is a feature most platforms avoid because the back-end complexity grows fast. Customer changes affect pricing, inventory, supplier rules, and itinerary feasibility. The platform needs an architecture where customers can adjust tours meaningfully while the system handles the downstream impact correctly.
III. Our Approach
Vertex AI for generative capability, Next.js and NestJS for the platform stack.
1. Vertex AI on Google Cloud for the generative core
The AI features are powered by Vertex AI on Google Cloud, using Gemini models for PDF extraction and the customer-facing chatbot. We chose Vertex AI over alternatives for three reasons: enterprise-grade reliability for production AI workloads, strong document understanding capability with Gemini for the PDF extraction use case, and Google Cloud's broader ecosystem fit (including Maps integration). The platform's AI pipeline is built around Vertex AI's enterprise agent capabilities rather than ad-hoc API calls, which gives us a foundation that can evolve as the platform's AI scope grows.
2. Next.js for the frontend, NestJS for the backend
Next.js powers the user-facing experience for both agents and end customers — server-side rendering for fast page loads, App Router for clean routing, and a component architecture that supports both the agent tour management interface and the customer booking flow. NestJS handles the backend services: agent authentication, tour data management, customer accounts, booking orchestration, and the integration layer to Vertex AI. We picked NestJS for its TypeScript-first design and structured architecture, which matters when the API layer grows past the simple CRUD level.
3. PostgreSQL as the source of truth
Tour data, customer accounts, bookings, and chat history all live in PostgreSQL. We chose PostgreSQL over alternatives because tour structures are relational by nature (tours have days, days have activities, activities have suppliers and pricing), and PostgreSQL's reliability characteristics fit a platform that will handle real bookings and real money. We are designing the data model with the AI workflows in mind — structured extracted data from PDFs lands in PostgreSQL in a format the AI chatbot can query when answering customer questions.
4. Google Maps for destination context
Google Maps integration provides destination context throughout the platform — for agents while building tour itineraries, for customers reviewing tour locations, and for the AI chatbot when it discusses specific destinations. The integration is set up so location data flows consistently across the platform rather than being re-implemented in each module.
IV. What the platform delivers:
Four capabilities defining the platform:
1. PDF-to-tour AI generation
Agents upload an existing tour PDF, and Vertex AI extracts the tour structure — destinations, itinerary, inclusions, pricing — into the platform automatically. Agents review and adjust the extracted tour, then publish it for sale. The friction of manual data entry is removed from the agent workflow.
2. Online tour catalog for end customers
Once tours are in the system, the platform presents them to end customers in a structured, browsable catalog. Customers can search by destination, date, price, and tour type. The catalog is built to handle the variety that comes with agent-generated tours rather than a single curated brand voice.
3. Customer-driven tour customization
End customers can adjust tours within defined parameters — modifying dates, swapping accommodations within an approved set, adjusting group size, or adding optional activities. The platform handles the downstream pricing and feasibility logic so customer changes flow through to the agent's view correctly.
4. AI chatbot for personalized travel advice
Customers can interact with an AI chatbot that knows the platform's tour catalog and the destinations they cover. The chatbot helps customers find tours matching their preferences, answers destination questions, and surfaces tour customization options the customer might not have considered. Built on Vertex AI with grounding in the platform's actual tour data, not generic AI responses.
V. What the platform is designed to enable
When live, the platform is designed to enable a category of travel agents who currently cannot easily move their business online — agents whose tours exist as PDFs, who have not adopted online booking platforms because the manual data entry is too high a barrier. By using generative AI to remove that barrier at the upload step, the platform aims to bring agent inventory online that would otherwise remain offline. For agents, this means reaching customers beyond their immediate network without changing how they build tours. For end customers, this means access to a wider variety of tour packages and the ability to customize tours within the platform itself rather than going back and forth over email.
The AI chatbot is designed to support customers through the longer decision cycle that travel purchases typically involve, surfacing relevant tours and answering destination questions in real-time rather than requiring customers to wait for agent responses. The platform's architecture — Vertex AI for generative capability, PostgreSQL as the structured source of truth, Next.js and NestJS as the operational stack — is built to support these capabilities at production scale once the platform launches.
Adamo will update this case study with actual Solution Impact framing after the platform goes live, replacing the 'designed to' language with measurable outcomes and qualitative observations from production usage.
