Website enquiries not converting? Check these handoffs

Separate a traffic problem from a handoff problem

Write down where the journey appears to fail. Few relevant visits, few form submissions and many unanswered enquiries are different problems. A design change cannot repair a disconnected inbox.

Review the page alongside the ad, search query or referral that brought the visitor there. Does it answer the same question? Can someone tell what you offer, who it is useful for and what happens after the call to action?

Treat your explanation as a hypothesis. Without enough observations, a low conversion rate does not tell you whether the offer, traffic, form or follow-up caused it. Start with observable failures and record what you cannot yet measure.

Submit the form as a visitor would

Use a clearly labelled test enquiry and a test inbox. Try a phone as well as a desktop. Check keyboard navigation, labels, validation messages and whether a failed submission keeps the information already entered.

• Submit a valid enquiry and confirm that it is stored.
• Leave a required field empty and check that the error identifies the field.
• Try a repeated submission and check for duplicates.
• Test a delivery failure in a safe test environment.
• Confirm that success appears only after the server accepts the enquiry.

Do not collect information simply because the form builder supports it. Ask for what the team needs to respond. Explain sensitive requests and avoid inviting medical, financial or other confidential details into a general contact form.

Follow the record into the CRM or inbox

Find the exact test enquiry in the destination system. Check its source, requested service, owner and next action. An email notification is not evidence that the CRM record exists, and a record is not evidence that someone has accepted responsibility.

Use a test label that contains no customer information. If the request lands in a shared inbox, agree who checks it and what happens during absence. For CRM assignment rules, use the separate lead-routing guide linked below.

Check booking as a separate outcome

A click on “Book a call” only proves that the visitor clicked. Confirm a test booking with your team, then check the calendar entry, time zone, confirmation and cancellation or rescheduling route. Cancel the test appointment afterwards.

If the calendar opens on another domain, test that transition on mobile. Check whether the booking provider supplies a confirmed-booking event or webhook. Keep button clicks and confirmed bookings separate in reports.

An unavailable slot should lead to a clear alternative, not a dead end. Use an appropriate contact route and state when someone will respond. Do not promise availability your team cannot staff.

Measure successful actions without exposing form details

Google Analytics recommends the generate_lead event for a submitted form or request for information. Define exactly which successful action triggers it on your site and test that it does not fire merely when the submit button is clicked. [1]

Google prohibits sending personally identifiable information to Analytics. Keep names, email addresses, phone numbers and free-text enquiry details out of event parameters and page URLs. [2]

Keep customer records in the approved business system. Use analytics for aggregate behaviour and respect the consent setup that applies to your site. Visitors who decline analytics, browser restrictions and failed requests can create differences between analytics counts and stored enquiries.

Compare the number of accepted submissions, valid enquiries, first human responses and confirmed next steps over a consistent period. Document exclusions such as spam, duplicates and tests. Do not treat a gap between systems as proof of lost customers until you have checked how each system counts.

Fix one failure and retest the whole journey

Prioritise a submission that disappears over a cosmetic change. Then address incorrect routing, unclear confirmation messages and unnecessary form friction. Keep an owner and a retest date for each fix.

After a change, repeat the original test on both desktop and mobile. Check the downstream record as well as the page. A successful frontend test can still leave a broken integration behind it.

Once the handoffs work, test messaging or layout changes with a clear hypothesis. Keep records of what changed and avoid claiming a conversion improvement from a handful of visits. The aim is a reliable path to a useful conversation, not a higher count of button clicks.