> ## Documentation Index > Fetch the complete documentation index at: https://docs.tied.com/llms.txt > Use this file to discover all available pages before exploring further. # Pre-chat form > A short form before the conversation opens. Every field you add is a filter, so add as few as possible. *"Pre chat forms enable you to capture user information before they start conversation with you."* The **Pre Chat Form** tab on a web chat inbox. Useful, and easy to overdo — this page is mostly about the second half of that. ## The settings | Setting | Detail | | - | - | | **Enable pre chat form** | **Yes** / **No** | | **Pre chat message** | Placeholder: *"This message would be visible to the users along with the form"* | | **Pre chat form fields** | A table of every field, with columns **Fields**, **Label**, **Placeholder**, **Key**, **Type** and **Required** | There is no single toggle for "required" — each field's **Required** column below decides that individually. Save with **Update Pre Chat Form Settings**. ## The field table Each row is one input on the form. | Column | What it is | | - | - | | **Fields** | Whether the field appears at all | | **Label** | What the visitor reads above the input | | **Placeholder** | The hint inside the empty input | | **Key** | Where the answer lands on the contact record. Standard fields use their own key; your [custom contact attributes](/contacts/attributes) appear here under theirs | | **Type** | Text, email, number, and the types your custom attributes were defined with | | **Required** | Whether the visitor can start without it | **Every answer lands on the contact record**, not just on the conversation. So a field collected once is available on the next conversation, searchable, and usable in a [segment](/contacts/segments) — which is what makes asking worth anything at all. ## Write the message as a reason, not a greeting The **pre chat message** appears above the form. It is the only chance you get to explain why a person who wanted to ask a question is instead looking at a form. ```text Weak theme={null} Please fill in your details to start the chat. ``` ```text Better theme={null} So we can pull up your order and reply if you close the tab — just your email, nothing else. ``` The second version gives a reason and sets an expectation about length. Both measurably reduce the number of people who close the widget at this step. ## Every required field costs you conversations **A pre-chat form is a filter, and it filters out people who would have become customers exactly as efficiently as it filters out people who would not.** Someone with a pre-sales question and thirty seconds of patience does not fill in a form. They leave, and you never learn they were there. A workable test for each field: *if this were blank, could we still help them?* If yes, it is not required. Usually only one field survives that test — an email address, and only because you genuinely cannot reply later without it. Consider what you can get without asking: * **The email address** — if the visitor is signed in to your product, [identity verification](/channels/web-chat#identity-verification) already tells you who they are. Do not ask them to type what you know. * **The order number** — the agent can look it up once it knows who they are. Asking a customer to fetch their own order number so your agent can look up the order is work you moved onto them. * **The topic** — the first message is the topic. A "what is this about?" dropdown is a question the customer is about to answer anyway, in better words. **There is no setting for who sees the form — it shows whenever it is enabled.** What changes per visitor is which *fields* appear inside it: combined with [identity verification](/channels/web-chat#identity-verification), a field the visitor is already identified by — name, email or phone — is suppressed automatically, field by field, so a signed-in visitor is never asked to retype what you already know. An anonymous visitor still sees every field you configured. ## Pre-chat form or email collect box? Two different mechanisms and you want one, not both. | | Pre-chat form | Email collect box | | - | - | - | | **When** | Before the conversation opens | Inside a conversation already started | | **Asks for** | Any fields you configure | An email address | | **Blocks the conversation** | Yes, if fields are required | No | | **Set on** | This tab | **Enable email collect box**, on [Settings](/channels/inbox-settings) | If all you need is a way to reply later, the **email collect box** gets you that without standing between the visitor and their question. Reach for the pre-chat form when you genuinely need structured data before routing — and then ask for the minimum that makes routing possible. ## What it does not do * **It does not verify anything.** A visitor can type any name and any email. Only [identity verification](/channels/web-chat#identity-verification) proves who someone is, and until it is on, your agent will correctly refuse to discuss an account. * **It does not route.** Collecting a field does not act on it. Use an [automation rule](/automation) to label or assign based on what came back. * **It does not apply to other channels.** This is web chat only. On Apple Messages, WhatsApp and SMS you already have a verified phone number or Apple ID, which is better than anything a form could tell you. ## Next Knowing who someone is without asking them. Defining the fields this form can collect. Everything else the visitor sees first. The email collect box, and the rest of the tabs. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.