AI copilots are onboarding, just sneakier
AI copilots are framed as a productivity feature — "do work faster" — and shipped by feature teams. This framing is correct on the surface and misleading underneath.
Every AI copilot in a product is doing onboarding, whether the team thinks of it that way or not. It's teaching the user what the product can do, what good prompts look like, and where its limits are. The teams that recognize this ship better copilots. The teams that don't ship demos.
The teaching that's happening even when nobody's teaching
Watch a user interact with a copilot for the first time:
- They type a question.
- They get an answer.
- They look at the answer and update their mental model of "what this thing can do."
- The next question is shaped by that mental model.
That sequence is onboarding. The copilot is the teacher; the user's first few prompts are the lesson. Whatever the copilot does in those first three exchanges sets the user's expectations for the rest of the relationship.
If the copilot is great in the first three exchanges and bad in the next ten, the user concludes "the product is great but unreliable" and stops trusting it. If the copilot is mediocre in the first three exchanges, the user concludes "AI is overhyped" and stops using it altogether. If the copilot refuses or punts on the first three exchanges, the user concludes "this is just a chatbot" and never comes back.
So the early prompts are not neutral test queries. They're the activation surface, the same way the first sixty seconds of a SaaS product are the activation surface. They have to land.
What that implies for design
If copilots are onboarding, the design implications follow:
- Suggest first prompts. Don't drop the user in front of a blank input field. Show three example prompts that demonstrate the range of what the copilot is good at. The user picks one or types their own — either way, they've now seen what good prompts look like before they tried to write one.
- Show what the copilot can't do, early. A good error path on the first failed prompt does more for trust than ten successful prompts. "I can't access your email" is a better answer than a hallucinated answer dressed up to look real.
- Calibrate the response length to the first interaction. A 200-word response to "what can you do?" is a tour. A 30-word response with three actionable suggestions is an empty state done right.
- Track the user's prompt sophistication over time. A new user types "summarize this" and gets a generic summary. A returning user has been here before — they should be able to type "summarize this in 5 bullet points, focused on next steps" and get something different, because the copilot has learned what kind of summary they tend to want.
Where AI breaks the existing onboarding playbook
Two patterns that worked for non-AI products and don't work here:
The product tour pattern. A copilot's range is too large to tour. Any tour will demonstrate three or four use cases out of thousands; the user sees the tour and concludes "oh, this is a tool for those four things" — and then never tries the fifth. The problem with the tour isn't that it's a tour; it's that the surface area is too large for a tour to be representative.
The "sample data" pattern. Sample data was a way to show what a populated product looked like. There's no equivalent for a copilot — there's nothing to populate. The replacement is the "suggested prompts" surface, which serves the same teaching function in a different shape.
The metric that matters
For non-AI products, the activation metric is "completed first meaningful action." For AI copilots, it should be "ran the second successful prompt."
The first prompt could have been an accident, a test, or an example the user clicked. The second one is the user actively coming back to the surface with a real intent. If the user's second prompt fails or feels disappointing, the copilot has lost them — even if the first prompt was perfect.
Most teams measure first-prompt success rates. The interesting number is the second.