Question handling
Why new users cannot find an answer that is already written
The documentation is thorough. Every feature has a page. And the person who signed up twenty minutes ago still cannot work out what to do first, because thoroughness is not the same as sequence. This intent is nearly always a content problem wearing the costume of a support problem.
What they are really asking
They want to know the next single thing to do, and whether they have already missed something that will bite them later.
- how do i get started
- where do i start
- what do i do first
- how do i add my team
- how do i connect my account
- i've signed up, now what
- how do i import my existing data
- do i need to set anything up before i invite people
- how long does setup take
- is there a setup guide
The material that answers it
An assistant is only as good as the document behind it, and for this question the document usually exists but is written in the wrong shape. What each one has to contain to be answerable:
| A getting started page written in the order things must happen | Not a list of features and not a tour. A numbered sequence where each step is a task with an outcome. If two steps can genuinely be done in either order, say so, because a new user reading a list assumes the order is load bearing. |
|---|---|
| Prerequisites, gathered in one place | What they need before starting: an administrator on another system, a domain they control, a file in a particular shape, somebody else's permission. Discovering a prerequisite at step four is the single most common reason setup is abandoned halfway. |
| Each step written as a task, not as a feature | Invite your first colleague rather than user management. The vocabulary difference sounds cosmetic and is not: a new user does not know what your features are called, so material named after them will not match anything they type. |
| What done looks like at each stage | The screen they should see, the confirmation, the state that proves it worked. Without this people repeat steps they have already completed, or move on from a step that silently failed. |
| A short appendix for the two steps that fail most | Every product has them, and whoever handles onboarding knows exactly which. Writing those two up properly removes more contacts than documenting the other twenty steps again. |
How to handle it
Answer with the next action, not the feature list
Somebody asking where do I start needs one instruction. The assistant should give the first step and what they should see afterwards, then stop. A reply that summarises the whole setup is a reply they have to parse before they can act.
This only works if the material has an order in it. If the source is a features index, every answer will be an index too.
Lead with prerequisites when there are any
If a step needs somebody else, a credential, or an export from another system, that has to arrive before the step rather than inside it. The cost of a missed prerequisite is not a minute, it is a session abandoned and often not resumed.
Say how long each step takes
New users ration their time. Knowing that the import takes five minutes and that the identity setup needs a colleague and is best done tomorrow changes what they attempt now. It also prevents the specific frustration of starting a step there was never time to finish.
Name the finish line
Setup is complete when these three things are true. Without a defined end, users either stop early and get a poor first experience or keep configuring long past the point of usefulness. A stated finish line is also what lets the assistant answer have I missed anything, which is asked constantly and answerable only from your own definition.
When it stops being an answer
A step that has blocked and is not in the guide
Onboarding blockers are urgent in a way that other questions are not, because the customer has not yet formed any attachment to the product. If the documented path has failed, the handover should be immediate rather than after several more attempts.
Anything needing access, provisioning or a plan change
A limit reached, a feature not on their plan, an account that needs enabling. The assistant cannot see any of this and cannot change it. It should explain how the limits work in general and route the specific case.
Migrating real data in
Imports of live data are where a mistake is expensive and hard to reverse. The assistant can describe the supported format and the process, and it should hand over anything involving a customer's actual file, a one off shape, or a migration from a competitor.
How this one goes wrong
The reference manual answer to a beginner's question
A new user asks what to do first. The assistant returns an accurate, well cited paragraph about the configuration model, because that is what the documentation contains. The reply presumes the vocabulary the person signed up to learn.
The cost is the highest churn moment in the whole product. Somebody who cannot get started does not raise a ticket, they close the tab, and no support metric ever records it. The fix is not a setting on the assistant, it is one ordered page written for the person who has been here for ten minutes.
The same question, trade by trade
The pattern above holds everywhere. The wording, the escalation line and the material behind it do not, so there is a page per trade.
- For a law firmConflict check, identity, the client care letter and money on account. The sequence that has to finish before any work happens on a matter.
- For a accounting firmIdentity checks, agent authority and the professional clearance letter, explained at the enquiry stage rather than during the delay.
- For a mortgage brokerThe fact find, the consent to a credit search and the document gather. A product transfer, a remortgage and a purchase run it at three lengths.
- For a recruitment agencyRegistration steps, right to work documents and what happens before a first shift, answered at the hour candidates actually ask.
- For a marketing agencyAccess to the client's own accounts, the brand assets, the measurement check, and why month one produces less than month two.
- For a universityOnline enrolment, the document check, module registration and the card each unlock the next. Most questions here are ordering questions.
- For a private schoolUniform fittings, forms, the coach seat and the first morning. A summer of deadlines that arrived in one email nobody can find.
- For a online courseWhere to start, how much of a week it needs, and getting live session times into a calendar in the right time zone.
- For a SaaS companyImport limits, what an admin configures first and what trial work does at conversion. Onboarding answers that stop a week one stall.
- For a developer tools companyQuickstart questions are narrow, repetitive and decide whether an evaluation continues. What to index per language so the answer lands.
- For a fintech appAccepted documents, what a proof of address must show, and why a rejected photo is most of onboarding on a regulated money app.
- For a healthtech appEligibility by country and by age, the access code from a sponsor, and the questions asked at sign up. What a first afternoon really runs into.
Questions
- Can it walk somebody through setup interactively?
- It can answer each question as it comes, from your material, with citations back to the step. It cannot see their account or confirm that a step worked, so the material has to describe what success looks like and let the user check.
- What if our documentation is written for advanced users?
- Then this intent will keep failing regardless of configuration, because there is nothing else for it to answer from. One ordered getting started page fixes more here than every other change combined.
- Should onboarding questions be handed to a person more readily?
- Yes. A blocked new user is the most fragile relationship you have, and a fast handover during setup costs far less than the silent abandonment it prevents.
Keep reading
- Handling technical troubleshootingThe dominant failure is an answer taken from the wrong release. A refusal beats a confident step list for software nobody is running.
- Handling compatibility questionsAnswerable only if you publish a list. Inferring compatibility is the failure, and the price of a wrong yes is a return and a refund.
- Handling warranty and repairsCustomers conflate a manufacturer warranty, an extended plan and their legal rights. Keep the three apart and never close the third.
- Every question typeHandling patterns for the questions every support inbox gets.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.