# Capture & Qualify Leads With Chat Forms | onmsg

> Use Form and One-field steps with required fields and validation to gather requirements before handoff, capture after-hours enquiries, and keep context for the team.

URL: https://onmsg.app/guide/capture-and-qualify-leads-with-conversation-forms/
Last-Modified: 2026-09-08

Decision guide

# Capture and Qualify Leads with Conversation Forms

Use Form and One-field steps with required fields and validation to gather requirements before handoff, capture after-hours enquiries, and keep context for the team.

Published September 8, 2026 · 5 min read

![A conversational form collecting enquiry details inside a website chat](/images/featured/modern-3d-illustration-of-a-conversational-form-co.webp)

## A form that behaves like a conversation

Most website enquiry forms fail in the same way: they ask for everything at once, before the visitor has any reason to trust that filling it in will be worth their time. The abandonment happens somewhere around field four.

A conversational form asks the same questions in sequence, after the visitor has already engaged. By the time the 

Visual Bot Flow Builder

[/features/visual-bot-flow-builder/ →](/features/visual-bot-flow-builder/)

 reaches a Form step, the visitor has said what they want and got something useful back. The questions read as part of the exchange rather than a toll gate.

![A Form step settings panel showing required fields, input types and validation rules](/images/content/modern-3d-illustration-of-a-form-step-settings-pan.webp)

## Two steps, two jobs

**One field** collects a single value, an email address, a phone number, a quantity. Use it when that is genuinely all you need. Someone asking about parts availability should not be handed a five-field form to leave an email address.

**Form** collects several fields together, with required fields, input types and configurable validation. This is the qualification step: the moment you gather what your team would otherwise spend two messages chasing.

The distinction matters more than it sounds. Matching the weight of the ask to the weight of the request is most of what separates a form people complete from one they abandon.

## What to actually ask

Work backwards from the first thing your team does with an enquiry. If the first action is checking whether the address is in range, ask for the address. If it is looking up an order, ask for the order number. If it is a phone call, get the number and a good time.

A workable default for a service business:

| Field | Why | Required? |
| --- | --- | --- |
| Name | Addressing them properly in the reply | Yes |
| Contact method (email or phone) | You cannot follow up without one | Yes |
| Location or address | Decides whether you can serve them at all | Usually |
| What they need, in a sentence | Routes it to the right person | Yes |
| Timing or urgency | Decides the order you work the queue | Optional |

Five fields is a lot for a chat. Four is comfortable. Anything past six should probably be split across two steps or asked by a person once the conversation is live.

## Validation earns its keep quietly

Configurable validation and input types stop the small nonsense that costs real time: an email address with a missing dot, a phone number written as “call anytime”, an empty required field submitted by someone in a hurry. Each one of those turns a complete enquiry into a follow-up message, and follow-up messages to people who have already left rarely land.

Set input types so the mobile keyboard matches the field too. A numeric keypad for a phone number is a small courtesy that measurably reduces mistyping.

## After hours is where this pays off most

![A qualified enquiry summary card with contact details and requirements handed to a team inbox](/images/content/qualified-enquiry-summary-card-with-contact-detail.webp)

An enquiry at 9pm cannot be answered at 9pm. It can be captured properly. Put a By availability branch above the form so the offline path says plainly that nobody is around, then runs the same Form step. Offline message intake keeps the details in retained conversation history, and the morning starts with a workable enquiry instead of “hi is anyone there”.

The difference between those two outcomes, repeated across a month of evenings, is usually the strongest argument for putting chat on a website at all.

## Context travels with the conversation

Whatever the form collects moves with the conversation into the 

Shared Team Inbox

[/features/shared-team-inbox/ →](/features/shared-team-inbox/)

 when it hands off. The teammate who picks it up sees the answers alongside the full history, so they open with “I can see you’re in Northfield and need this before Friday” rather than “hi, how can I help?”.

That is the qualification payoff. Not a lead score, just a person who does not have to ask the first three questions again.

## Keep it honest

Ask for what you will use. A field you collect and never look at is friction with no return, and visitors are better at sensing that than we tend to assume. And remember what these steps are: they collect and route enquiries. onmsg is not a booking engine or a checkout, so if the next step in your process is taking payment, plan for that to happen elsewhere.

## Where to place the form in the conversation

Placement matters as much as content. The same four fields will perform very differently depending on when they arrive.

**Too early**, before the visitor has had anything useful, reads as a toll gate, and abandonment is high.

**Too late**, after a long AI exchange, often means the visitor has their answer and no longer needs to leave details.

**About right** is after intent is established and after one piece of value has been delivered. They said what they wanted, they got something useful, and now the form is a natural next step rather than an interruption.

In practice that usually means: greeting, Choices step for intent, a helpful message or AI answer, then the Form. Four steps, and the fourth is the one that earns the enquiry.

## Reading abandonment

If people are dropping out of the form, the transcripts will usually tell you where.

**Dropping at the first field** means the form arrived too early, or the framing did not explain why you are asking.

**Dropping at one specific field** means that field is unclear, too personal for the stage, or asking for something the visitor does not have to hand.

**Completing but with rubbish values** means the field is required and the visitor did not want to give it. That is a signal to make it optional rather than to add stricter validation.

Each of those is a small edit on the canvas. The point of building the form inside a flow is that you can respond to what you see rather than redesigning a page.

Read next: 

building a greeting-to-handoff flow

[/guide/how-to-build-a-greeting-to-handoff-flow/ →](/guide/how-to-build-a-greeting-to-handoff-flow/)

, or 

how the shared inbox routes and assigns conversations

[/guide/how-the-shared-inbox-routes-and-assigns-conversations/ →](/guide/how-the-shared-inbox-routes-and-assigns-conversations/)

.

## Learn more about Visual Bot Flow Builder

A drag-and-drop builder for website conversations, with 11 step types for greeting, capturing enquiries, branching, and handing off.

Read the feature page

[/features/visual-bot-flow-builder/ →](/features/visual-bot-flow-builder/)

FAQ

## Questions people ask about this

### Can I make certain fields required?

Yes. Form steps support required fields, input types and configurable validation, so you can insist on a contact method before the conversation continues and reject a phone number that is obviously not one.

### What happens to details captured after hours?

Offline message intake keeps them in retained conversation history, so the enquiry is waiting in the inbox when your team starts. Pair a By availability branch with the widget's after-hours behaviour so the message matches the reality.

### Does the team see what the form collected?

Yes. Context travels with the conversation into the shared inbox, so whoever picks it up sees the answers alongside the full message history rather than a separate notification.

## Related guides

### Branching by Page, Availability and Saved Answers

Serve different flows by page (pricing vs homepage), route by availability (online vs offline), and branch by saved answer, practical examples of each.

Read guide

[Branching by Page, Availability and Saved Answers →](/guide/branching-by-page-availability-and-saved-answers/)

### How to Build a Greeting-to-Handoff Flow, Step by Step

Walk through assembling a real onmsg flow: start with a greeting, branch by enquiry type, collect details with a form, add an AI Agent step, and route to a person.

Read guide

[How to Build a Greeting-to-Handoff Flow, Step by Step →](/guide/how-to-build-a-greeting-to-handoff-flow/)

### The 11 Flow Step Types in onmsg, Explained

Every onmsg flow step type explained: AI Agent, Question, Choices, One field, Form, Message, Image or video, Pause, By answer, By availability and By page.

Read guide

[The 11 Flow Step Types in onmsg, Explained →](/guide/the-11-flow-step-types-in-onmsg/)

### Visual Flow Builder vs Scripted Chatbot: What's the Difference?

Compare a visual, no-code flow builder with hand-coded and scripted bots, maintenance, speed, and who each suits, and see why non-technical teams prefer a canvas.

Read guide

[Visual Flow Builder vs Scripted Chatbot: What's the Difference? →](/guide/visual-flow-builder-vs-scripted-chatbot/)

## Want to try this on your own site?

No credit card required.

Start free

[https://chat.onmsg.app →](https://chat.onmsg.app)