Voice-First AI: Engineering Travel Booking for Speech
Describing a complex trip verbally is faster than filling 5 form screens. Here is how we built voice input that understands travel vocabulary.
Try describing this trip to a search form: "I want to fly from New York to London next Thursday, then take the train to Paris for a few days, and fly back from Paris on the following Tuesday. My wife is meeting me in Paris, so she needs a separate flight from Chicago arriving around the same time as my train."
On a traditional OTA, that's at least four separate searches across two different interfaces, plus manual coordination of dates and timing. It would take fifteen minutes minimum.
Spoken aloud, it takes about twelve seconds.
Voice is the most natural interface for travel planning because travel requests are complex, contextual, and hard to decompose into form fields. We built Nowah with voice as a first-class input method, not an afterthought. Here's the engineering behind it.
One sentence vs. five form screens
The density of information in a spoken travel request is remarkable. In a single sentence, a user can express: destination, dates, flexibility, preferences, constraints, budget signals, and multi-traveler logistics. A form-based interface would spread this across five or more screens.
Mobile travel bookings now account for over 60% of all online travel bookings. On a phone, typing complex multi-part queries is painful. Voice eliminates that friction entirely.
But converting speech to a useful booking action involves more than plugging in a speech-to-text API. Travel has a unique vocabulary challenge, a tolerance challenge, and a context challenge.
The vocabulary problem
Travel is full of words that speech-to-text systems struggle with. City names that sound similar (Lyon vs. Leon, Nice vs. niece). Airport codes that are nonsensical when spoken ("I usually fly out of L-A-X"). Airline names that are proper nouns. Hotel brands that sound like common words. Date expressions that are ambiguous ("next Friday" means different things depending on when you say it).
We handle this with a post-processing pipeline that runs after initial transcription. The pipeline:
Resolves travel entities. When the transcription includes something that looks like a city, airport, airline, or hotel name, we match it against our reference data. "Nice France" and "niece France" both resolve to Nice, France. Context disambiguates: "Nice" in a travel conversation is almost certainly the city, not the adjective.
Normalizes dates. "Next Thursday," "the Thursday after this one," "March 12th," "mid-March," and "around the second week of March" all get converted to date ranges that our search system understands. We handle relative dates (next, this, following) by anchoring to the current date and conversation context.
Handles airline codes and abbreviations. "AA" becomes American Airlines. "BA" becomes British Airways. "I usually fly United" maps to the carrier, not the adjective.
Manages accents and pronunciation. City names are pronounced differently by speakers of different languages. "Paris" from an English speaker sounds different than "Paris" from a French speaker. Our entity resolution is phonetically flexible.
Handling ambiguity in voice
Text input gives users time to be precise. Voice input is naturally vague. People speak in fragments, change their mind mid-sentence, and use pronouns without clear referents.
"Find me, um, flights to, well, somewhere in Italy. Actually, maybe Spain. Somewhere with good weather."
A rigid system would choke on this. Our approach is to treat voice input the same way we treat text input: extract what's clear, flag what's ambiguous, and ask about the rest.
From the input above, we extract: destination is Europe (Italy or Spain), preference for good weather, no dates specified, no budget specified. The agent responds conversationally: "Italy and Spain both have great weather. Any dates in mind? That'll help me narrow down the best options."
Context from agentic memory helps too. If this user has traveled to Barcelona twice before and just said "somewhere in Spain," the agent can infer a reasonable starting point. "Paris" from a user who always flies out of JFK probably means Paris, France, not Paris, Texas.
Voice search is growing over 20% year-over-year in travel queries. As more users default to speaking instead of typing, handling ambiguity becomes a core competency, not an edge case.
The voice-to-response pipeline
From the moment the user stops speaking to the moment they see the agent respond, here's what happens:
- Audio capture. The app records the voice input with noise cancellation applied at the device level.
- Speech-to-text. The audio is transcribed using a speech recognition service optimized for conversational English with travel vocabulary hints.
- Post-processing. The travel entity resolution pipeline cleans up the transcription, resolving city names, dates, airlines, and other travel-specific vocabulary.
- Intent extraction. The cleaned text goes through the same natural language understanding pipeline as typed messages. The AI extracts structured parameters and decides what action to take.
- Agent processing. The agent's observe-think-act loop executes normally: searching, ranking, presenting, or asking for clarification.
- Streaming response. The response streams back through our server streaming pipeline, with text appearing in real time.
The latency budget is tighter for voice than for text. When you type, there's a natural delay between finishing your message and expecting a response. When you stop speaking, you expect the AI to respond almost like a human conversation partner. We target first-token response within about a second after the user finishes speaking.
Multimodal switching
People don't stick to one input mode. They might start a conversation by typing, switch to voice when they need to describe something complex, and switch back to text when they're in a quiet office.
We designed for seamless switching between text and voice within the same conversation. The agent doesn't care how the input arrived. It processes the text the same way whether it was typed or transcribed. The conversation context persists across mode switches.
The UI reflects this too. The voice input button is always available alongside the text input. There's no separate "voice mode" to enter and exit. You just tap the microphone when you want to speak and start typing when you want to type.
Accessibility as a design driver
Voice-first design started as a mobile convenience feature but it has profound accessibility implications.
Users with motor disabilities who can't easily type complex queries can speak them instead. Users with visual impairments can interact with the entire travel planning flow through voice. Users who speak English as a second language often find it easier to describe what they want verbally than to construct a formal written query.
We think about accessibility not as a compliance checkbox but as a design constraint that makes the product better for everyone. A system that handles imperfect, ambiguous, context-dependent voice input well is also a system that handles imperfect typed input well. The engineering that makes voice work (robust entity resolution, context-aware disambiguation, graceful handling of incomplete inputs) improves the text experience too.
Voice input is supported for hands-free trip planning, which means someone can plan their next vacation while cooking dinner, driving (passenger seat, please), or walking through an airport. One voice sentence replaces five form interactions on traditional OTAs. That compression matters, and the engineering to make it reliable is worth the investment.
Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.