The handoff that loses people
Someone has been talking to your assistant for four minutes. They have described their situation, asked two follow-up questions, and decided they want a quote. The assistant says: "Great — head over to our contact page and fill out the form."
You have just asked a person who is already engaged to leave the conversation, load a new page, and re-type things they have already told you. Some fraction of them will. The rest close the tab.
The alternative is not "have the AI ask for the details in chat," which sounds natural and works badly. Free-text collection over several turns is where structured data goes to die. People give you a phone number with no country code, an email with a typo, a date as "next Tuesday-ish." The assistant then has to validate conversationally, which means more turns, which means more places to drop out. And if the person is using voice, asking them to spell an email address out loud is close to hostile.
The right answer is a form — but rendered inside the conversation, at the moment the person has already decided.
When a form beats asking
Not everything should be a form. The test is whether the data has a shape.
| Situation | Ask in chat | Show a form |
|---|---|---|
| "What are you trying to solve?" | Yes — the answer is prose | No |
| Name, email, phone | No | Yes |
| A date and time preference | No | Yes |
| "Which of these three plans fits?" | Either | Yes, if it feeds a routing decision |
| Follow-up clarification | Yes | No |
| Anything you will paste into another system | No | Yes |
The pattern: if a human is going to read it, chat is fine. If a system is going to parse it, use a form. Mixed intent is common and fine — describe the problem in prose, then hand over contact details in fields.
There is a second axis that matters just as much: whether the person has decided yet. A form shown before there is a reason for it is an interruption. A form shown thirty seconds after the assistant answered the question that mattered is a convenience. The moment is doing most of the work here, which is exactly why a static contact page cannot compete — it has no way to know when the moment arrived.
Designing the fields
The field types worth having are the ones a browser can validate and a phone can adapt its keyboard for: short text, email, telephone, number, date, long text, a select with fixed options, and hidden fields that carry context the person should not have to supply.
A few rules that hold up:
- Three to five visible fields. Every field is a decision, and decisions are where people stop. If your form has nine fields, at least four of them are being collected because someone once asked for them, not because anyone uses them.
- Use the specific type, not text. An email field gets you a keyboard with an @ key on mobile and free format validation. A generic text field gets you neither, plus a support ticket about the typo.
- Selects for anything you will filter on later. "Which service are you interested in?" as free text produces forty spellings of the same three answers. As a select it produces three.
- Hidden fields carry the context. Which page they were on, which assistant they spoke to, which marketing source brought them. The person should never be asked to supply something you already know.
- Snake_case keys, human labels. The label is what the visitor reads; the key is what your CRM sees. Keeping them separate means you can rewrite the label for clarity without breaking whatever consumes the data.
- Say what happens next. The confirmation after submit is the single highest-attention moment in the whole interaction. "Thanks — we will email you within one business day" retains people. "Submitted." does not.
Two ways to present it
There is a case for showing the form and a case for not showing it.
Present the panel when the person needs to see and control what is being submitted — contact details, anything they might want to correct, anything with a legal flavor. The panel appears in the conversation, the assistant stops narrating over it, and the person fills it in at their own pace.
Let the assistant fill it silently when the data has already been said out loud. If someone spent the last two minutes telling a voice assistant their name, their company, and what they need, making them re-enter all three into a panel is a punishment for having been thorough. In that case the assistant submits what it gathered and confirms in one line.
The failure mode to watch for is the assistant narrating around an open form — "so, can I get your email?" while an email field sits on screen. That reads as a bug even when everything is working, because the interface is asking for something it has already asked for. When a form is open, the assistant should get out of its way.
Where the submission goes
A form is only as good as its delivery, and this is where a surprising number of in-chat forms fail quietly. The panel shows a success message, the visitor leaves happy, and nothing arrives anywhere.
Two destinations cover almost everyone.
Notify your team
The submitted fields plus the conversation that led to them, emailed to whoever handles new enquiries. This requires no engineering at all, which matters, because the whole point of a conversational form is to remove steps.
Post to your own endpoint
A webhook to a URL you control, signed so you can verify it came from us and retried if your server has a bad minute. This is the one you want if a CRM or helpdesk should own the record.
What should never happen is a form with no destination that reports success anyway. If nothing is configured to receive a submission, the honest behaviour is to fail loudly rather than show a green tick over a lead that went nowhere. We treat a form with no destination as an error on purpose — a visible failure gets fixed, a silent one gets discovered a month later.
Test it as a visitor, not as an author
The last mile of form design is that authors and visitors see different things. The person building the form knows what every field means, has the tab order in their head, and never tests on a phone in portrait.
Preview the form the way a visitor meets it: from inside a real conversation, on the narrowest screen you support, after a question that would plausibly lead to it. Half the problems surface in the first ten seconds — a label that made sense in the builder and not in context, a required field nobody can answer, a select whose options do not include the common case.
Forms are one half of "the AI cannot finish this alone." The other half is knowing when to stop collecting and get a person involved, which is covered in human handoff done right. If your goal is specifically qualified leads rather than support, chatbot lead generation goes deeper on qualification questions, and reducing cart abandonment covers the ecommerce version of the same timing problem.
You can build and preview conversational forms in the dashboard at hiroi.ai — worth trying with your real intake questions rather than a test one, since the field count is where most of the argument happens.