What a custom field actually changes
Every conversation starts with an information gap. The visitor knows their order number, their plan, the page they gave up on and the thing they already tried. The agent knows none of it, and the first ninety seconds of a great many chats are spent closing that gap one question at a time. Custom fields are the mechanism for closing part of it before anybody types.
In the dashboard the page is called Custom Fields, and the control on it is the Custom Field Builder. It sits under visitor intake, and the framing in the product is worth repeating because it is the whole discipline in one line: add fields when your team needs more context before or during a conversation, and only for data the team actually uses in routing, qualification or follow-up.
That qualifier matters more than it looks. A custom field is not free. It is a question a stranger has to answer before they are allowed to ask you something, and every one of them is a place where a visitor decides this is more effort than it is worth and closes the tab. The right number is the smallest number that changes what the agent does.
Where the fields appear
There are two places a field can surface, and it is easy to configure one while thinking about the other.
The first is the pre-chat form, shown when someone starts a conversation during staffed hours. This is the high-traffic surface and the one where every extra field has a measurable cost, because the visitor is trying to reach a person and the form is in the way.
The second is the offline message form, shown when nobody is available and the visitor is leaving a message instead. The economics here are reversed. There is no live agent to ask a follow-up question, so anything you fail to collect now becomes an email round trip tomorrow. An offline form can reasonably ask for more than a pre-chat form, and the builder lets the same field set differ between the two surfaces rather than forcing one compromise across both.
Design them separately and deliberately. The most common mistake is a single field set tuned for offline completeness, quietly applied to the live form where it suppresses the chats you were trying to encourage.
The field types, and when the type matters
The builder offers ten input types, and choosing well is not cosmetic. The type decides how easy the field is to complete on a phone, and whether the answers are consistent enough to be worth reporting on later.
- Text and Text Area -- short answers such as a company or SKU, and longer freeform description respectively.
- Integer, Decimal and Currency -- quantities, IDs, measurements, and formatted money values such as an order total or a budget.
- Phone and URL -- contact numbers for a callback, and the page or site the visitor wants to talk about.
- Yes or No -- binary questions, which route far more reliably than a free-text answer to the same question.
- Multiple Options and Gender -- pick lists, for answers that should stay standardized.
The dashboard's own design checklist gives the rule that matters most here: use dropdowns when the answer should stay standardized across reports and automations. Free text is kind to the visitor and hostile to everything downstream. Ask for a plan name as text and you will collect Pro, pro, PRO plan and the middle one, which cannot be routed on and cannot be counted. The same question as a pick list is one tap and one canonical value.
Choosing fields that earn their place
A useful test before adding anything: name the decision the answer changes. If the answer would route the chat to a different team, change which article the agent opens first, or determine whether this is a sales conversation or a support one, the field earns its place. If the answer merely gets read and nodded at, it does not.
Order matters too, and the guidance in the product is to put the highest-value field near the top so visitors understand why you are asking at all. A form that opens with an order number reads as competent. A form that opens with a job title reads as a lead-capture gate, and people treat it accordingly.
Be even stingier with required than with fields in general. A required field converts a hesitant visitor into a bounced one, and the builder tracks your required count separately precisely because it is the number most worth watching. Reserve it for data without which the conversation genuinely cannot proceed. Everything else can be optional and asked again by an agent in the rare case it turns out to matter.
Watch what happens to your chat-start rate after you change the set. This is the one change in a chat deployment with an immediate, visible effect on volume, which makes it unusually easy to evaluate honestly: change the form, wait a week, compare. If volume fell and nothing about the conversations improved, the extra field lost.
What not to ask for
A chat widget is a public surface on a public page. It is not an authenticated channel, and it should never be used as one.
That rules out an entire category of tempting fields: passwords, full card numbers, security answers, government identity numbers, and anything else that would let whoever holds it act as the customer. A pre-chat form is a plausible-looking place to type such a thing, which is exactly what makes asking for it dangerous. Ask for the last four digits, an order reference, or a case number instead -- enough to look someone up, not enough to become them.
The same restraint applies to data you merely might want. Every field you collect is a field that lands in transcripts, exports and anywhere else conversations are stored, and it stays there under whatever retention policy you have set. Collecting less is the cheapest privacy control available, and it needs no configuration at all.
Making the answers useful after the chat
Fields collected and never used are the normal failure mode, so close the loop deliberately. The answers travel with the conversation, which means they are visible to the agent handling it and present on the record afterwards -- so they can be used to route, to prioritize, and to break down reporting by something more meaningful than volume.
Custom data is also where invitation context lands. When a proactive invitation fires, the rule that triggered it is stored as custom data so the agent picking the chat up can see why the visitor was invited rather than guessing. That arrow runs one way, and it is worth being precise about: invitation rules are evaluated on visitor behaviour -- the page they are on, time on it, scroll depth, referrer, whether they have visited before -- and the result is written into custom data. Your intake fields are not conditions those rules read.
Pair the field set with visitor monitoring and the two halves of the picture fit together: the fields say what the visitor told you, the monitor says what they were doing. Between them an agent can open a conversation already knowing the plan, the page and the path, which is the entire point of asking anything in the first place.
Review the set on a schedule. Field sets accumulate; nobody has ever been assigned the job of removing one. Twice a year, take the list to the people who actually handle chats and ask which of these they have used this month. The answers are usually shorter than the form.
Custom fields sit alongside the window-level switches for asking for an email or a phone number. Choosing what your chat window shows and allows explains how those interact, including the combination that rewrites itself on save.