Onboarding for AI-First Products: Teaching Users to Talk

The hardest moment in any AI-first product is the first one. The user opens the app. They see a chat interface. A blinking cursor. And they freeze.

Not because the interface is confusing. A chat box is one of the simplest UI elements in computing. They freeze because they do not know what to say. Twenty years of using search bars, forms, and filter dropdowns have trained them to interact with travel products in a specific way: type a destination, pick dates, hit search. Now there is no form. No search button. Just an empty text field and an AI waiting.

This is the cold start problem for AI-first products, and if you do not solve it, nothing else matters. The best AI agent in the world is useless if the user stares at the chat and then closes the app.

The cold start problem

Cold start has two dimensions. The AI knows nothing about the user. And the user knows nothing about the AI.

The first dimension is technical. Without any preference data, travel history, or context, the AI cannot personalize anything. It is a blank slate helping a blank slate. The first conversation will be slower and less impressive than the tenth conversation because the AI has no accumulated knowledge to draw on.

The second dimension is psychological. Most users have only interacted with basic chatbots. Their expectations are set by customer service bots that say "I didn't understand that, please choose from the following options." They expect the AI to be limited, frustrating, and ultimately unhelpful. This low expectation creates a low willingness to invest effort.

Both dimensions need to be addressed in the first sixty seconds. If the first interaction is clunky and generic, the user's preconceived chatbot disappointment is confirmed. If the first interaction is smooth and useful, the user's expectations recalibrate. "Oh. This is different."

Preference collection without the survey feel

Before the first conversation, we need some basic information. Where the user is based, what kind of travel they do, any strong preferences. The traditional approach is a survey. Ten questions, multiple choice, takes three minutes.

We hate surveys. Users hate them more. Completion rates for onboarding surveys in consumer apps are dismal, especially on mobile where each question means another tap and another screen. People skip them, fill in random answers, or quit during the survey and never reach the actual product.

Our approach is to collect preferences through a short conversational exchange that feels like a conversation, not an interrogation. When a user opens Nowah for the first time, the AI says something like: "Hey, I'm Nowah. I help people book trips by having a conversation instead of filling out search forms. To get started, I'd love to know a little about how you travel."

Then a few lightweight questions, embedded in the chat flow, with quick-tap answers available. "Where are you based?" (with suggested cities and a text option). "Do you travel mostly for fun, work, or both?" "Any airline you're loyal to?" "Window or aisle?"

Three or four questions. Under a minute. Each answer is a message in the chat, so it feels like a conversation, not a form. The quick-tap options remove the friction of typing while the text option is always available for people who want to say something specific.

The key design decision: these questions are optional and skippable. If someone wants to jump straight to booking, they can type "find me a flight to Miami" at any point and the AI will pivot. Preference collection is useful but never a gate. The product should deliver value even with zero prior context.

Teaching by doing

The real onboarding is the first booking. Not a tutorial. Not a walkthrough. Not a series of coach marks pointing at UI elements. The first time the user successfully books a trip through conversation, they understand the product.

This insight shapes our entire onboarding strategy. We do not explain what Nowah can do. We show it by doing it. Conversation starters (the quick-tap suggestions below the chat input) are designed to trigger a booking flow, not a demo.

"Book a flight" is the first suggestion. Not "Tell me about yourself" or "What can you do?" Those lead to explanatory text that feels like a FAQ. "Book a flight" leads to the AI asking where and when, searching live inventory, and presenting three options with real prices. Within three minutes, the user has seen the core value proposition in action: tell the AI what you want, it finds it, you book it.

We want time-to-first-booking to be as short as possible. That is our onboarding north star metric. Not time-to-complete-onboarding-survey. Not time-to-explore-all-features. Time-to-first-booking. Because the first booking is the moment the user understands what makes an AI travel agent different from a search engine. Every design decision in the first-time experience optimizes for reducing that time.

The AI is slightly more proactive during the first conversation than in subsequent ones. If the user says "flights to London," the AI does not just ask about dates. It briefly explains what is happening: "I'll search live flights for you. I'll show you three options based on price, schedule, and your preferences." This narration serves as a tutorial without feeling like one. The user learns the interaction model by watching it happen on a real task.

Conversation starters that demonstrate capability

The blank chat screen is a canvas of possibility, which sounds nice but is terrible for onboarding. Possibility paralysis is real. When you can say anything, you often say nothing.

Conversation starters are pre-written prompts that sit below the chat input, ready to tap. They serve two functions: they reduce blank-screen anxiety, and they demonstrate the AI's capabilities through example.

Our starters are carefully selected:

"Book a flight" shows that the AI can handle the core use case. It is the most direct path to first value.

"Plan a weekend trip" shows that the AI handles ambiguity and multi-step planning, not just simple search.

"Find a hotel" shows that the AI covers accommodations, not just flights.

We rotate starters for returning users based on their history and context. If someone has a trip coming up in two weeks, the starter might be "Check my flight status" or "What's the weather in Tokyo next week?" These contextual starters demonstrate the agent's memory and proactive capabilities to users who have moved past the initial onboarding.

The phrasing of starters matters more than it seems. "Book a flight" outperforms "Search for flights" because "book" implies the AI handles the entire process, not just the search. "Plan a weekend trip" outperforms "Where should I go this weekend?" because the latter suggests the AI only gives suggestions, not that it actually plans and books.

Every starter is a promise. It says: "Tap me and the AI will do this thing." If the AI cannot deliver on that promise reliably, the starter should not exist. We test every conversation starter against a battery of follow-up scenarios to make sure the AI handles the resulting conversation well.

Progressive complexity

New users should see Nowah's simplest capabilities first: search a flight, see options, book one. Only after they trust the basics should they discover the advanced features: multi-city trips, preference memory, proactive suggestions, trip management.

We enforce this through the AI's behavior, not through feature gates. The AI does not mention advanced capabilities in early conversations. It does not say "I can also track your passport expiry dates and monitor price changes for your favorite routes" during the first interaction. That is overwhelming and irrelevant.

Instead, advanced features surface naturally as the user's behavior creates the right context. After a few trips, the AI might say: "I noticed you always fly United. Want me to prioritize United flights by default?" This introduces the preference memory feature at the moment it becomes relevant.

After a booking, the AI might say: "I can monitor this route and let you know if prices drop before your trip." This introduces price tracking at the moment the user has a reason to care about it.

This progressive disclosure approach means that users discover new capabilities over weeks and months, not in a five-minute onboarding tour that they will not remember. Each discovery feels like the AI getting smarter rather than the user unlocking features.

Why most chatbot onboarding fails

If you have ever opened a chatbot and seen "Hi! I'm BotName. I can help you with: [bullet list of 15 things]. Choose a topic to get started!" you have experienced the most common chatbot onboarding pattern. It is also the worst one.

Here is why.

The menu-style greeting turns the chat into a phone tree. The user is not having a conversation. They are navigating a menu that happens to be displayed as a chat message. This sets the wrong expectation for everything that follows. The user thinks they need to select from predefined options rather than express themselves naturally.

The capability list is overwhelming. Fifteen things the chatbot can do, none of which the user cares about right now. They came to book a flight. They do not need to know about cancellation policies, loyalty programs, and currency conversion at this moment. The list creates choice paralysis.

The canned greeting feels robotic. "Hi! I'm BotName!" is not how a helpful agent would introduce themselves. It is how a call center script begins. It immediately signals "this is an automated system" rather than "this is a capable agent that will help you."

We avoid all of these patterns. Nowah's greeting is brief, natural, and action-oriented. It says who it is, what it does, and invites the user to start. The conversation starters below the greeting channel the user toward real tasks, not topic selection. The AI's first response to a real request demonstrates capability through action, not through a list of features.

The best onboarding for an AI-first product is no visible onboarding at all. The user opens the app, says what they want, and the AI delivers. The "onboarding" is the experience itself. Every conversation teaches the user something new about what the AI can do, naturally, in context, when it is relevant.

Measuring onboarding success

Time-to-first-booking is our north star, but we track several supporting metrics.

First-session retention: does the user come back after their first conversation? If the first conversation was impressive, they do. If it was a disappointment, they do not. This metric tells us whether the cold start experience is working.

Preference collection rate: what percentage of users provide at least basic preference data during onboarding? High rates mean the conversational approach to preference collection feels natural. Low rates mean it feels like a chore.

First-message content: what do users actually type first? If most first messages are generic ("hello," "hi there"), our conversation starters are not doing their job. If they are specific ("flights to Bali," "plan a trip to Italy"), the starters are working.

Drop-off point: where in the first conversation do users stop engaging? If they drop after seeing flight results, our card design needs work. If they drop before results, the search flow feels too slow or the AI's questions feel annoying. The drop-off point tells us exactly where the first-time experience breaks.

Getting onboarding right is the highest-leverage work in an AI-first product. Everything else, the preference memory, the curation quality, the proactive suggestions, only matters if the user gets past the first conversation. We obsess over those first sixty seconds because they determine whether the user ever experiences everything we built.

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.