← Back to blog

Required Phone Fields and Form Submit Rate: What to Watch

Kazem Hegaze·Landing pages & forms·
formsconversion rate
A required phone field adds friction between visitors and completed submissions.

Making a phone number required is one of the most common form changes in B2B and lead gen, and one of the most common causes of a lead drop nobody logged. Sales asks for phone numbers, the field becomes required, and submit rate falls the same day.

What the change actually does

A required phone field changes two things at once:

  1. Fewer people finish. Phone is higher-friction than email: people know it means a call.
  2. The ones who finish are different. Some of the loss is junk you didn't want; some is real buyers who weren't ready to be phoned.

That second point is why this is a judgment call and not a bug. The right question isn't "did submit rate fall?" It will. The question is whether the qualified leads you keep are worth the ones you lose.

Watch submit rate, not just lead count

Lead count mixes traffic and conversion together. Form submit rate, submits divided by form views, isolates the form itself, so a change to the form shows up cleanly. Run your before and after numbers through the form submit rate calculator to see the size of the move.

Look at the same window before and after the change, with comparable traffic sources. Comparing a weekday to a weekend, or paid to organic, will tell you nothing.

What else to watch

  • Mobile vs desktop. Typing a phone number on mobile is worse; the drop is usually larger there.
  • Validation strictness. A rule that rejects valid international formats or spaces silently blocks submissions. Test with real numbers, including non-local ones.
  • Error visibility. If the error message renders off-screen, people don't fix the field; they leave.
  • Downstream quality. Are the calls actually connecting, or are the numbers now fake?

Worked example: is the trade-off worth it?

Illustrative numbers. Take a form that gets 2,000 form views a month. Before the change, 200 people submit (a 10% submit rate). Sales qualifies 40 of them, mostly because the rest never answer email.

After phone becomes required, form views stay at 2,000 and submits fall to 150 (7.5%). That's a 25% drop in submit rate, and the client's dashboard says "leads are down a quarter." But sales can now call everyone, and qualifies 48.

MetricBeforeAfter
Form views2,0002,000
Submits200150
Submit rate10%7.5%
Qualified leads4048
Qualified per submit20%32%

In this case the change is working, and the right move is to explain it, not revert it. Now run the same numbers with qualified leads falling to 30: the form lost 50 submits and sales got nothing for it. That's a revert.

The point of the exercise is that neither raw leads nor submit rate alone can answer the question. You need the form-level number and the downstream number side by side.

How to tell a trade-off from a broken field

A deliberate required field and a broken phone field can produce the same headline drop. They look different once you dig in:

SignalExpected trade-offBroken field or validation
Size of the dropModerate, stable after day oneSharp, sometimes close to zero
Device splitSomewhat worse on mobileOne device or browser collapses
Country splitSimilar across countriesNon-local numbers fail far more
Validation errorsFewMany on the phone field
Qualified leadsHold or riseFall with submits

To check validation errors, look in your form tool's analytics if it reports field-level errors, or add a GA4 event on validation failure. If you have neither, test it yourself.

How to test the phone field properly

Most broken phone fields are only broken for some inputs, so a single test with your own number proves little. On a real phone, not desktop responsive mode, try:

  1. A local number typed with spaces, dashes, and brackets.
  2. The same number with the country code and a plus sign.
  3. A number from another country your client sells to.
  4. Autofill from the phone's saved contact card.
  5. A deliberately wrong number, to see whether the error message appears next to the field and stays on screen.

Also check that the field uses a telephone input type, so mobile users get the numeric keypad. A phone field that opens the full keyboard is slower for everyone.

Then confirm the submission end to end: the request succeeds in the browser's network tab, the submit event fires once in GA4 DebugView or your tag manager preview, and the lead appears in the CRM with the phone number in the right property.

Common misreads

  • "Leads are down, so the change failed." Not if qualified leads held. Report both numbers.
  • "Submit rate barely moved, so the field is fine." Check where the drop concentrates. A small blended drop can hide a large drop on one browser or in one country.
  • "Phone numbers are up, so quality is up." Fake numbers (555, 123456) also count as phone numbers. Check connect rates with sales.
  • "It's the phone field." Maybe. If the same deploy changed the form embed, the CTA, or the tracking, isolate which change came first before you blame the field.

How to decide

Give the change a defined window, keep everything else stable, and compare submit rate against qualified leads, not raw leads. If submit rate falls 20% and qualified leads rise, keep it. If both fall, revert.

If you need the number but not the friction, options include making phone optional, asking for it after submit on the thank-you step, or explaining why you need it next to the field.

Rolling back cleanly

If you decide to revert, change only the phone field (make it optional, or remove it) and note the exact time. Leave everything else on the form untouched so the recovery, if it comes, can be attributed to that one change. Compare the next week's submit rate against the pre-change baseline, not against the depressed week.

Example

Illustrative scenario. An agency made phone required for a client on a Monday. Form views held, submits fell noticeably, and the client saw "leads are down" by Wednesday. The change was intentional, but nobody had told the client, so a deliberate trade-off looked like a broken funnel for two days.

How Quarkad helps

Quarkad tracks form-level events and detects form changes such as a field being added, so a change to the form shows up as a submit-rate movement rather than a vague "leads are down." When the field change and the drop line up in time, the incident says so, which also makes the trade-off easy to explain to a client. See landing page conversion drop and form monitoring.

Related

FAQ

How much does making phone required cost in submit rate? It varies by audience, offer, and device; there's no universal number. Measure it on your own form rather than trusting a benchmark.

Is optional-but-visible better than required? Often, yes: you still collect numbers from people willing to share them without blocking the rest. Test it against your qualified-lead numbers, not raw volume.

How long should I run the change before deciding? Long enough to collect a meaningful number of qualified leads in both periods, which on most B2B forms means weeks, not days. Sales follow-up takes time, so judge quality on leads that have had a chance to be called.

Should I use a phone validation library? Use one that accepts international formats and normalises input, rather than a strict pattern that only matches one country. Then test it with real numbers from every market you sell to.

Does a required phone field hurt ad platform optimisation? Fewer conversions can give the ad platform less signal to optimise on, especially at low volumes. If submits fall sharply, watch campaign delivery and cost per lead in the weeks after the change.

Required Phone Fields and Form Submit Rate: What to Watch | Quarkad