KAYAK · 2025–2026 · Embedded conversational search
Moving KAYAK's AI into the booking funnel
A standalone AI travel site nobody came back to, rebuilt as a conversational layer inside the core booking flow. +14% booking revenue. Now live on kayak.com.
- Role
- Product Designer · intent model, response system, widget architecture
- Team
- 1 staff designer, 1 PM, front-end and back-end engineering
- Timeline
- April 2025–April 2026
- Surfaces
- kayak.com desktop and mobile web
What I owned: the intent taxonomy and behavior spec, the custom-GPT behavioral simulation, the response anatomy, the vertical widget system, and the comparative widget study.
What I shared: experiment design with the PM; panel architecture and visual direction with the staff designer; model and retrieval approach with back-end.
What I inherited: the existing Trips drawer pattern, which I extended rather than replaced.
What the work returned
Method: 50/50 randomized across desktop and mobile web, US traffic. Revenue excludes ads. Every core funnel metric stayed neutral. The de-risking held, and nothing we shipped cost anything.
At a glance
01Onboarding to AI Chat
Standalone page → embedded drawer, zero context switching.
02Multi-intent output
Single rich-text response → simultaneous flight and hotel widgets with follow-ups.
03Responsive chat
Congested mobile modal → streamlined single-line input with curated prompts.
The stakes
Where the pressure was actually coming from
KAYAK is metasearch. The business runs on people arriving from Google and converting into bookings, and in 2025 that pipe started narrowing: AI Overviews and answer engines were absorbing the queries that used to become clicks. Two weeks after we shipped the first AI experiment into the core site, Booking Holdings took a $457M writedown on KAYAK, attributed directly to Google shifting free SEO traffic to paid.
The honest read, then and now: this was a traffic-acquisition and margin problem well before it was a booking-share one. Nobody was losing bookings to ChatGPT. They were losing the cheap top of the funnel, which is exactly where an AI-assisted entry point competes.
of Booking Holdings room nights come from LLM referrals, and flat
written down on KAYAK, attributed to Google shifting free traffic to paid
The damage wasn't where everyone assumed. AI wasn't taking the bookings; it was taking the free traffic that used to produce them. Which is why the answer was an AI entry point at the top of the funnel, which is where the loss actually was.
That framing set the bar for everything below. The goal was never to ship a chatbot. It was to give travelers a reason to start their search on KAYAK.
The ghost town
A capable AI no one came back to
KAYAK launched KAYAK.ai in April 2025: a standalone, chat-first travel site, separate from the core booking platform. It could answer complex travel questions, match deals to niche preferences, and check live flight status, then hand users to KAYAK.com to book.
Publicly it was framed as a sandbox: "a creative sandbox for our tech teams to innovate." Internally, the sandbox had a retention problem. Despite significant marketing and infrastructure spend, organic traffic stayed thin and internal cohort data at 30 days showed almost no one coming back. Both things were true at once, and the second is what the referral analysis was responding to.
But the referral data told a different story. I dug into traffic between KAYAK.ai and the core platform, and the small group who did cross over behaved unlike anyone else: 5x the click-through of any other referral channel.
User volume & click-through · June 2025
| Product | Total traffic | Click-through rate |
|---|---|---|
| KAYAK.com | ~50% | ~10% |
| KAYAK.ai | ~7% | ~45% |
A signal worth acting on, with a caveat. Tiny audience, outsized intent, but this population self-selected, so the gap can't carry the weight of a platform decision on its own.
The tempting read is that AI-assisted search creates intent. I don't think that's what the data said. Anyone who sought out a separate AI travel site in 2025 was already an unusually motivated traveler. The 5x was at least partly, maybe entirely, selection. The likelier direction is that intent caused the AI usage.
That mattered, because it determined what to do next. An observational signal from a self-selected population can't justify a platform rewrite. It can only justify an experiment designed to produce a number selection can't explain. So the finding wasn't "AI drives intent." It was narrower and more useful: KAYAK.ai's technology wasn't the problem. Asking users to go somewhere new for it was.
The bet
Test the thesis before the rebuild
If the barrier was the destination, the fix wasn't a better KAYAK.ai. It was removing the destination and reframing the goal around the traveler.
“How can we land more users on KAYAK.ai?”
“How can we integrate AI better into the KAYAK ecosystem?”
That reframe turned one vague question into two things we could actually measure.
Two testable hypotheses
Users will adopt AI chat when it's embedded in KAYAK.com, not a standalone destination.
Users who engage with AI chat will lift KAYAK's core metrics: conversion and revenue.
The full vision, persistent multi-turn chat, carried real dev cost and migration risk. So I pushed for the cheapest test of the thesis first. Freeform text in the existing form would have needed a new backend to constantly tell natural language apart from structured airport queries. A separate AI mode avoided that, and gave us two things: risk isolation (if the experiment broke, only the experiment broke) and clean data to attribute any lift to AI.
What the test returned
On the gap between the first two numbers: conversion moved 2% while revenue moved 14%, which means the lift came mostly from what people booked, not how many booked. AI-assisted sessions skewed toward longer and multi-vertical itineraries. Explaining that gap matters more than the number itself. A number you can't decompose reads as something handed to you; a number you can explain reads as something you understood.
The revenue confirmed the thesis: embedding AI in a familiar flow converts. And the ceiling showed up immediately. NLP Search was single-turn by design, so people submitted one query and stopped: no refinement, no follow-up, no cross-vertical exploration. Behavior matched the architecture exactly. The experiment had proven the thesis and simultaneously proven its own limits.
Intent taxonomy & behavior spec
Classify, or infer?
Before any visual design, the hardest problem was how the AI should decide. I explored two ways to turn a prompt into a response, and the choice shaped everything downstream.
Dest. →
Precise, but it assumed people think in search parameters. Add hotels, cars, activities and the grid multiplies, 3 × 3 × 3 × … exponential complexity.
Routes into KAYAK.com
Routes into KAYAK.ai
Infer intent, then resolve ambiguity. Sort a prompt into a rough bucket, then clarify within it in one step, so a vague prompt never dead-ends and new dimensions don't explode the model.
To align engineering and PM on that behavior before a mock existed, I mapped the intent logic as a jobs-to-be-done flow, then translated it into a runnable custom GPT. Stakeholders could type real prompts and watch the system respond, so we iterated the system prompt as a shared behavioral contract, not a static spec.
The behavioral spec
A jobs-to-be-done flow mapping every input type to a query category and calendar state.
Run it, don't read it
The same logic as a custom GPT, so the team could test prompts live instead of reviewing a doc.
Scaling up
From one input to a conversation
With the revenue signal in hand, we built what we'd envisioned from the start: an omnipresent chat. The Chat v1 drawer launched site-wide, reachable from the front door, results, and detail pages. For the first time, users could have a conversation with KAYAK, not just search it.
Panel placement isn't cosmetic, it signals the AI's role. Left panels frame AI as a creative partner you co-create with; right panels frame it as a contextual assistant that stays out of the way. KAYAK Chat is the latter, so it belonged on the right.
Left panel
Reads as a creative partner, co-create over many rounds (Lovable, ChatGPT Canvas).
Right panelChosen
Reads as a contextual assistant, users stay on results, chat assists on demand.
KAYAK already had a right-side drawer for Trips. Reusing it meant zero new interaction model and a natural handoff: plan in chat, save to Trips in one motion.
The core craft
When the AI can say anything
Chat v1 was live. Then a single flight reply showed everything still wrong with it, three problems in one response.
Saving was the easy call, handed back to the Trips drawer. The other two were real design problems. Multi-turn chat made output non-deterministic: one prompt could return a list, a comparison, a clarifying question, or a multi-vertical plan. So instead of designing one layout, I defined a fixed response anatomy, a constant order any answer pours into.
When the model is wrong
What the system does when it isn't sure
An intent inference model buys resilience by accepting it will sometimes guess wrong. That's a design surface in its own right, so I specified how the system behaves at each level of certainty rather than treating failure as an edge case.
The structural decision underneath all of it: prices never live in the chat. The chat produces a widget; the widget points at a results page; the results page renders live inventory in its production layout. The model doesn't state a fare, so it can't be wrong about one. Provenance and pricing stay with the system of record.
| System state | Response | Status |
|---|---|---|
| High confidence, inventory found | Widget and summary, direct route to results | Shipped |
| Ambiguous parameters | Clarifying question before any widget | Shipped |
| Over-constrained or thin inventory | Widget with an explicit caveat and a broaden-search affordance | Specified |
| Out of scope or unanswerable | Graceful decline, routed to conventional search | Specified |
| Price drift between response and click | Live re-verification on the results page, never in chat | By architecture |
| Model or API failure mid-stream | Partial-state recovery and retry | Known open |
Confidence, mapped to response. The most reliable way to prevent a confident wrong answer is to architect the system so it never has to make the claim.
From the backend
Product KPI
UX requirements
To decide how much of a result belongs in chat versus the page, I tested three widget patterns with nine users, unmoderated. Pattern B, a condensed summary with thumbnails, won. But the scorecard was the small result. The real finding was how differently people framed the panel.
Hypothesis · untested
Reference Builder
0 / 9
Persona 1
Chat-as-Destination
2 / 9
Persona 3
Results-Page Purist
2 / 9
Persona 2
Chat-as-Wayfinder
5 / 9 · won
The majority read chat as a wayfinder. Not a place to act, but the fastest route to the right page. That pointed the direction: chat orients and routes, it doesn't replace the results page.
Nine unmoderated participants is discovery-grade evidence for a platform-grade decision, and it didn't settle the direction on its own. It agreed with two things we already had: the single-turn ceiling in the experiment usage data, and Fullstory replays showing users scrolling results out of view. Three independent signals pointing the same way is what made the call, rather than the sample of nine.
The fourth quadrant is a hypothesis rather than a finding. The "Reference Builder", someone who front-loads constraints into chat as a thinking aid, then hands that understanding to conventional search, kept suggesting itself in the data, but no participant cleanly fit it. It's on the list to test, well short of the list of things we know.
So each response generates a vertical widget: a compact anchor in the panel, linked to a full results page in KAYAK's production layout where people already know how to act. The relationship stays predictable, one widget, one page, one state: apply a filter, a new URL spins up a new widget.
What almost shipped instead
The two calls I'd have to defend
The full chat drawer, first. The original plan was to build the persistent multi-turn experience up front. It was what everyone wanted and what the vision documents described. Arguing for a single-input experiment instead meant deliberately shipping something less ambitious than the team was ready to build, and being the person slowing it down. It bought a revenue number and a documented ceiling for a fraction of the cost, and the ceiling is what made the eventual architecture obvious rather than speculative.
The parametric classifier. Nine clean scenarios, fully specifiable, easy for engineering to estimate. It would have shipped faster and broken on the first prompt that didn't think in search parameters.
Collaboration & ownership
Owning behavior, not just screens
- Product
- Engineering
- User research
The highest-leverage work lived upstream of the UI: the intent logic, the behavioral contract, and the research that engineering and PM aligned on before mocks existed. I owned the experience from de-risking the test scope through the shipped drawer and its measured impact.
Reframe
Turned "make KAYAK.ai better" into a testable thesis: AI embedded in the flow people already use.
De-risk
Shipped NLP Search as a single-turn tracer bullet, at +14% booking revenue with neutral impact on core metrics.
Define
Set the intent inference model and a fixed response anatomy, prototyped as a runnable custom GPT.
Validate
Tested widget patterns with nine users; the framing, not the scorecard, steered chat toward a wayfinding layer.
Ship & measure
Launched Chat v1 site-wide, lifting engagement +123% over NLP Search with about 80% more messages per user.
Where it landed
Chat now ships alongside search
kayak.ai now redirects to kayak.com/ai. The standalone site folded into the core platform, which was the thesis, and it's verifiable in one click. Go use it →
Chat v1 lifted engagement +123% over NLP Search, with 80% more messages per user. The honest caveat on the first number: comparing a multi-turn chat product to a single-turn search input is close to comparing a conversation to a sentence. The artifact was designed to produce more turns, so more turns is a weak claim. Messages per user is the number I'd defend. It says people who started a conversation kept going, which is the specific thing the single-turn ceiling said we couldn't do.
Shown as a band rather than a point. The public figure is "single-digit percentage," and I'd rather draw the uncertainty than invent a decimal. The model works: over 100,000 conversations a month. Discovery doesn't. That gap is the honest limitation, and it's the thing I'd take on next.
We proved the model. We haven't proved people can find it.
The strongest evidence for the architecture is external: AI users are 10× more likely to start a search with no fixed destination or date. AI owns the top of the funnel; conventional search owns the decision. KAYAK's CPO put it the same way the work concluded internally: "the right model is not chat instead of search, but chat working alongside search."
-
Ask before answering
One clarifying step costs seconds and saves users from dead-end sessions.
-
Classify intent, not query
A deal-hunter and a trip-planner can type the same words and need completely different responses.
-
Replace recaps with actions
7 of 9 users called text summaries "noise"; proactive follow-ups outperformed them every time.
-
Prototype with real data
Static mocks can't test an intent-driven system. Design for unknown outputs, not known inputs.
-
The most valuable work wasn't the UI
It was the behavioral specs, classifier logic, and research that made the UI possible. When those clicked, the pixels followed.