Forms inside a chat: when a flow beats a conversation

A flow is a form inside the chat: several screens of structured input that come back as data rather than as sentences to interpret. It is the right tool when you need six specific facts, and the wrong one when you need to understand a problem.

Where a form wins

• Many required fields. An insurance claim, a loan application, a delivery address with a landmark.
• Validated input. A date that must be real, an ID number with a checksum.
• Repeatable, identical requests. The hundredth one should not cost a person the same as the first.
• Data you will process, not read. If the answers go into a system, they should arrive as fields.

Where a conversation wins

When you do not yet know what to ask. A customer saying "the delivery came damaged" needs somebody to look at a photograph and decide, and no form gets there faster. Putting a form in front of that person reads as an obstacle, because it is one.

Building one that people finish

1. Say how long it is up front. "Four questions, about a minute."
2. Ask only what you will use. Every optional field is a reason to abandon.
3. Pre-fill everything you know. You have their number and probably their name; asking for them again says you were not paying attention.
4. Leave a way out. Somebody whose situation does not fit the form must be able to reach a person without finishing it.
5. Confirm in the chat afterwards. The form closing is not a receipt.

The fallback that has to exist

Not every client renders a flow. Something has to happen for the recipient who sees nothing useful, and it cannot be silence - which is the same rule interactive messages follow, for the same reason.