Your site gets traffic and no calls. Here's what's broken, in order.

Diagnose in this sequence. Each step is measurable, and fixing step four while step one is broken changes nothing.

Does the page load and respond? Measure it in Core Web Vitals field data; the usual fixes are images, scripts and hosting. Is the offer legible on a phone? Open it on a phone. Is the phone number tappable? Tap it. Does the form ask only what the job needs? Count the fields. Is the form reachable and usable? Audit it with a keyboard and check the labels.

Steps one and two decide whether the visit survives. Steps three to five decide whether a surviving visit can act. The thresholds for step one are published, and CLS matters here more than it sounds, because a layout that shifts under a thumb moves the button out from under it.

For step five, labels are the common failure and WebAIM's guidance on accessible forms is the reference; the success criteria themselves are in the WCAG 2.2 quick reference. This is not a compliance aside. A form a screen reader cannot label is a form some of your buyers cannot submit.

Often because the page asked them to do work before it gave them a reason to.

No specific claim in the first screen. "Quality service since 1998" is not a reason. A named service, a named area, and a price or a range is.

The proof is below the decision. Reviews, license numbers and job photos placed beneath the form arrive after the moment they were needed.

Too many fields. Baymard's benchmark put the average checkout at 11.3 form fields in 2024, against the 8 it finds most sites actually need. A quote request is not a checkout and the number does not transfer; what transfers is the direction, measured over ten years of testing: fields users must consider are the cost.

One path only. A form and no phone number excludes the buyer who wants to talk now, and in service work that buyer is often the one with the urgent job.

What we are not claiming: a specific percentage recovered per field removed. We have not measured that on service sites and the published research is e-commerce.

Check that the traffic is the traffic you think it is, then work the order in section 01.

Two diagnoses that get skipped. The traffic may be wrong rather than the page: sessions arriving on an informational page from an informational query are not buyers in-market. Before redesigning anything, split the landing pages by intent and ask whether any of them is a page where a purchase could happen.

And the calls may be arriving uncounted. A phone number rendered as text and dialed from a phone generates a call with no record. Call tracking exists because "no calls" and "no recorded calls" look identical in analytics and have opposite fixes.

Then the order: responsiveness, legibility, tappability, field count, form accessibility. The instrumented version of this is what the inspection runs.

Traffic with no phone calls is a phone problem before it is a website problem. Four failures, in order, and none of them shows up in analytics.

One: the number is not a link. A number rendered as text cannot be dialed by a tap. The mechanism is the anchor element's tel: scheme, and the cost of omitting it is a mobile visitor memorizing digits and retyping them into a dialer. We hold ourselves to one formatting rule here: the E.164 form for machines, the readable form for people, never mixed in one place.

Two: the calls are not counted. The uncounted-call problem from the section above applies with full force here: call tracking is the instrument that makes this question answerable at all.

Three: nobody answers after hours. Emergency inquiries do not keep business hours, and an unrouted call outside them is a lost job rather than a missed call.

Four: the form is the only path. It excludes the buyer with an urgent job, who in service work is often the most valuable one.

Diagnose in that order. Tappable, counted, routed, then whether a second path exists. None of the four is a design problem and all four are cheaper than a redesign.