A customer enters their telephone number, taps Send and is told it is invalid. Removing the spaces makes it work. Or their mobile is accepted, but the office landline they want you to call is refused.
Before spending more on traffic, check whether your enquiry form accepts the contact details your customers actually use. A formatting rule can block an otherwise useful enquiry before your team ever sees it.
The repair starts by finding where rejection happens: in the browser, on your website’s server or during transfer to your CRM. Then agree which numbers the business needs to accept and test the complete route.
Reproduce the rejection before changing the form
Ask for the page address, device, browser, exact error wording and the step at which it appeared. Handle the customer’s actual number privately; use a number your team controls for routine tests and screenshots.
With permission from whoever receives test enquiries, try that controlled number in its familiar national format, with and without spaces, and in its correctly formatted international form. Repeat by typing, pasting and using browser autofill. Keep the other answers the same so that you are testing the phone field.
- Typing stops or characters disappear: investigate the field’s length limit or an input mask that controls the format.
- The browser refuses submission: inspect the field’s built-in constraints and the page’s validation code.
- The website responds with an error: inspect the form handler’s server-side rules.
- A success message appears, but the CRM has no enquiry: inspect the saved submission and integration response.
These are starting points for investigation, rather than proof of a particular fault. Give your developer the reproducible failure, including whether removing punctuation changes the outcome.
Decide what counts as an acceptable contact number
A general callback form and an SMS verification form have different requirements. If your team will telephone the customer, decide whether a landline is acceptable. If a mobile is essential for a specific service, explain that before someone fills in the form.
The GOV.UK Design System’s phone-number guidance recommends collecting numbers only when needed, explaining their purpose and clearly identifying any UK, international or mobile requirement. It also recommends accepting familiar punctuation and country codes, and using autocomplete="tel" to support autofill.
For a business enquiry form, our starting recommendation is to make telephone optional when an email reply is a workable alternative. Where a callback is the service being requested, requiring a number makes sense. The label, acceptance rules and follow-up process should all reflect that choice.
Do not assume a customer’s telephone country must match the address where they need your service. Someone arranging work at a UK property may use an overseas mobile.
Check the field, keyboard and formatting rules
Use a telephone input for telephone details
Ask your developer to inspect the actual page markup, rather than relying on the form builder’s field label. MDN’s telephone-input documentation explains that type="tel" supports telephone entry and may provide a suitable mobile keypad. It does not automatically enforce one telephone-number format.
If a telephone input refuses a particular format, inspect any added pattern, length restrictions or custom validation. A rule written around one sample number may reject a legitimate alternative. A character limit can also leave too little room once spaces, brackets or a country code are included.
A number input is a different control. MDN describes type="number" as a numeric input; it should not be chosen merely because telephone details contain digits. Ask the developer to preserve phone values as text throughout storage and transfer, including any leading zero needed in the submitted national format.
Test the formatting behaviour on a real phone
Watch what happens when you paste a number, replace a selected section or move the cursor into the middle. Check whether an automatic country selector adds information that the user has already supplied. A field that looks tidy in a desktop demonstration may still be awkward to correct on mobile.
Ask for the acceptance rule to be documented in plain English before approving new code. “Accept our supported countries’ phone numbers with familiar separators” is a useful requirement. “Make this example pass” leaves the next customer’s problem unresolved.
Align the website and CRM checks
A more tolerant browser field will not fix a server that still rejects the same input. W3C’s form-validation guidance recommends accommodating different telephone notations and confirms that validation must also happen on the server, because browser-side checks can be bypassed.
Have the developer compare the submitted value, the website’s validation decision and the value passed to the CRM. Use a controlled test submission to establish where the first unexpected change or rejection occurs.
If the destination requires a standard international representation, agree how the integration will produce it from supported input. Avoid ad hoc fixes that remove every leading zero or add a country code without first understanding the number. Keep extensions separate where the receiving system supports them.
Also test a deliberately rejected submission. If the CRM refuses the record, agree whether the website should retain a recoverable enquiry or show a useful failure message. A customer-facing success message should not leave your team unaware that delivery has failed.
The acceptance rule needs to work at every stage. Record which component owns validation and which component handles formatting, so a later plugin update does not quietly introduce a second, conflicting rule.
Understand what a validation library can prove
If your developer uses a telephone-validation library, ask which one, which version and which country assumptions it applies. Google’s libphonenumber FAQ explains that a valid number range does not establish whether a particular number is assigned to someone or reachable. It also cautions against routinely requiring a number to belong to the user’s stated region.
Use that distinction when reviewing a failure. Was the number unparseable, outside the library’s known ranges, excluded by your own country restriction or rejected because it was classified as the wrong type? Those outcomes call for different decisions.
Check the installed package against its maintained release history. The 27 October 2026 libphonenumber release contains mostly metadata changes. That is a reason to check the data behind a verdict, rather than assuming an older installed copy is definitive.
Our recommendation for an ordinary enquiry form is to avoid adding an ownership-verification step solely to make the data look cleaner. Decide whether verification serves a real operational need, and distinguish it from simply helping someone enter a callback number.
Make rejection useful and recoverable
A red border alone does not explain the problem. W3C’s current explanation of error identification says an automatically detected input error must identify the affected item and describe the error in text.
Tell the customer what they need to change. If the service requires a mobile, say so. If an international number needs a country code, explain that. Do not tell someone to remove spaces when the real fault is your own unnecessarily narrow rule.
As part of the repair, require the form to preserve the customer’s other answers, make the phone field easy to find and allow correction without starting again. Check the error with keyboard navigation as well as touch.
Prove the repair through to a usable enquiry
Agree a small set of acceptance tests that reflects your customers and contact process. Include:
- A supported mobile and, where callbacks allow it, a landline.
- National and international representations of a controlled number.
- Spaces, brackets, pasted input and browser autofill.
- An overseas number where your business accepts those enquiries.
- A blank optional field, or a clear error when the field is required.
- An incomplete number that should produce a helpful rejection.
Run the tests on the mobile and desktop browsers your customers use. For each accepted submission, confirm the expected website record, inbox message or CRM entry exists and contains the intended phone value. Check that the colleague handling the enquiry can interpret it correctly. Make any test call only to an agreed number your team controls.
After release, repeat the original failing case on the live page. Record the rule, the repair and the checks completed. Do not infer an increase in enquiries from a successful test alone; assess actual enquiry quality after the change.
Telephone validation is one part of a usable enquiry journey. Our web design service covers websites built around clear customer actions. If your form is blocking genuine contact details, talk to BuzzBoost about checking the route from customer input to a usable enquiry.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
