When nobody is available, the chat window offers a form instead. Most of the time a visitor fills it in and it sends. Occasionally it refuses, the visitor tries once more, and then they give up and you never learn that they were there. The refusals are not random, and none of them are documented on the form itself, so this guide sets out exactly what a message has to satisfy before it is accepted.
The order the checks run in
Fields are checked first, one at a time, and the first failure is the one reported. Only after every field passes does a captcha challenge get looked at, if you have turned one on. That ordering is useful when you are diagnosing a report: a visitor who says the challenge never appeared probably tripped a field rule before reaching it.
Everything is trimmed of surrounding spaces before it is judged, so a stray space at the end of an address is never the problem. The checks run on our servers rather than in the page, which means a visitor cannot talk their way past them by editing the form, and equally that a browser extension mangling your page will not change the outcome.
The name field is stricter than you would expect
A name is required, has to fit in fifty characters, and is rejected outright if it contains anything that looks like a link or like code. In practice that means these all fail: a name containing ://, a name starting www., a mail-to prefix, a bracketed URL tag, or an HTML attribute. Anything with a tag-like fragment in it is refused for the same reason, and so is any control character.
This rule exists because the name is the field junk submissions abuse most, and it does its job. It also produces one predictable false positive worth knowing about: a company whose trading name is its domain. Somebody typing www.acme.co.uk where you asked for a name gets told to enter a valid name without links or code, which reads as an accusation when they were being helpful. If your audience is businesses rather than consumers, label the field Your name rather than Name and you will see it less.
Fifty characters is generous for a person and tight for a person plus a company plus a department. Ask for one thing.
What counts as an address
The address is required and has to be a bare, ordinary address. The checks are unforgiving in a way that is easy to hit by accident:
- It cannot be longer than 254 characters.
- It cannot contain two dots in a row.
- It has to be the address alone. A display-name form such as Jane Doe <[email protected]> is rejected, which catches people who copy a sender line out of their mail client.
- The domain must contain a dot and must not end with one.
The same validator runs on the pre-chat form as well, in every generation of the widget, so an address rejected in one place will be rejected in the other. That is worth knowing when a customer insists the address worked yesterday: it did, on a different form on a different site, not on ours.
The message, the subject, and the one that borrows from the other
The message is required and capped at five thousand characters. Line breaks and tabs are fine, other control characters are not. Unlike the name field, the message is not checked for links or markup, which is deliberate: people paste error text, stack traces and URLs into support messages, and refusing that would be worse than useless.
The subject is the interesting one. In the widget it is optional, and when it is left blank the first fifty characters of the message become the subject with a trailing ellipsis. That is why so many of your messages have subjects that trail off mid sentence: nobody wrote them, they were derived. If it matters to you that subjects read well in your queue, ask for one explicitly rather than relying on the derived version.
When a subject is supplied it faces the same link and markup rules as the name, and it has a soft ceiling of a couple of hundred characters. Past that, rather than refusing the message, the form moves the long subject to the top of the message body and stores a shortened version as the subject. The one case that does fail is a long subject on top of an already long message: if the two together would break the five thousand character limit, the visitor is asked to shorten the subject, which is confusing advice when the real constraint is the total. If you see that error reported, the fix is to shorten the message.
Custom fields have ceilings of their own
If you pass extra values along with the form, whether from your own page code or from configured custom fields, they are checked as a set:
- At most 32 values.
- Each label at most 120 characters, each value at most 2000.
- The whole payload at most 12000 characters.
- Labels are held to the same no-links, no-markup rule as the name; values may contain more or less anything printable.
These are comfortable numbers for hand-picked context and easy to exceed if you serialise an object and pass it wholesale. A shopping basket with thirty lines, or a session object with everything in it, will breach one of these ceilings and take the whole message down with it, reported as a custom field problem the visitor cannot act on. Send the handful of values an agent will actually read.
Which messages you can reword, and which you cannot
Four of the refusals come from your account's editable text: the missing name, the name-too-long message, the address message, and the missing subject. Those follow whatever wording and language you have configured. The rest are fixed English sentences built into the product, including the message length refusal, the links-or-code refusals and everything to do with custom fields.
That mixture matters if you run a non-English widget. Your visitors can meet three prompts in their own language and then one in English, on the same form, which looks broken even though it is working. You cannot fix that from the settings, so the practical mitigation is to keep visitors away from the fixed cases: state the character limit next to the message box, and ask for the name in a way that discourages people from typing a web address into it.
What to measure
Messages that arrive with derived subjects. A high share means nobody is filling the subject in, and your queue is being sorted by the opening words of a sentence. Worth a form change.
Complaints reaching you by other routes. Somebody who cannot send the form will email you or use a contact page. If those messages mention trying chat first, you have a rejection problem worth reproducing.
Your own long-paste test. Once a quarter, submit your own form with a two thousand word paste, a company-domain name, and an address copied from a mail client. Three minutes, and it tells you exactly what your visitors are meeting.
Put it into practice
- Label the name field clearly so businesses do not type their domain into it.
- State the message limit next to the box, because that refusal is fixed English.
- Ask for a subject if your queue is sorted by it. Otherwise expect derived ones.
- Pass a handful of custom values, not a serialised object.
- Remember the order: fields first, captcha second.
- Read the address rules before blaming the visitor. Copied sender lines fail.
- Test your own form quarterly with deliberately awkward input.
None of these rules are unreasonable on their own, and together they stop a great deal of junk from reaching your team. They are only a problem when nobody on your side knows they exist, because then a refused message looks like a broken product to the one visitor who was trying hardest to reach you. Knowing what the form checks turns a mystery into a one-line answer, and often into a small change to a label. Where those messages end up once they are accepted is covered in what a left message captures, and the same discipline applied to the live form is in the live chat feature tour.