If your small business website gets visitors but no enquiries, first check whether a request can reach someone who can answer it. Then check whether your reports count that request correctly. These checks help separate a contact problem from unsuitable traffic or a service page that leaves people uncertain.
Start with one important service page and follow its contact route all the way into your business. The result should give you something more useful than a general impression that the website needs work: a specific fault to fix, or a reason to investigate the traffic and offer more closely.
Run an enquiry test you can repeat
Tell the person who handles enquiries that you are running a test. Agree where the request should arrive, who will look for it and when you will check. Use your own contact details and a clear message such as TEST-ENQUIRY-A. Do not include customer information or make a paid booking just to test the route.
Write down the page address, date, time and time zone, device, browser and connection. Note your cookie-consent choice too. Open the service page on your phone, find its contact option and submit the labelled request once. Save the confirmation wording or a screenshot, then ask the receiving person to find the matching message.
Copy this worksheet into your notes. Fill the “What actually happened” column with what you saw, including times and error wording. Replace the suggested owners with names. If a check is unavailable, record that rather than marking it as passed.
| Action tested | Expected evidence | What actually happened | Interpretation | Next owner |
|---|---|---|---|---|
| Open the service page and find the form | The contact option leads to the intended form | Record the page and result | A wrong destination needs a link or navigation fix | Website maintainer |
| Submit one labelled test request | Clear completion or error feedback | Record the wording and time | A success message alone does not confirm receipt | Website maintainer |
| Find the request at its destination | The matching message in the agreed inbox or customer system | Record arrival time, or not found at the check time | If missing, trace delivery and routing before assuming the form works | Website maintainer with inbox administrator |
| Ask the analytics owner to check this submission | The intended enquiry event, once, if configured and permitted by consent | Record the event name and count, or not checked | Missing or repeated events need a tracking check, separate from delivery | Analytics maintainer |
| Tap the phone link and make an arranged test call | Correct number in the dialler; the call reaches the intended business | Record both results | A click count cannot establish that a call connected | Website maintainer or phone-system owner |
| Ask the recipient to reply to the test | The assigned person can read the request and reply successfully | Record who handled it and the outcome | A received but unhandled request needs a clearer response process | Enquiry-team lead |
You can check the page, message receipt and reply without developer tools. Give the analytics check to whoever maintains your reporting; they should confirm what the event is intended to measure and whether this test should appear under the current consent settings. Do not weaken consent controls to make a test show up.
One successful test confirms that particular route under those conditions. Repeat it for other important forms, devices and contact routes, and after a repair. It does not establish that every visitor can complete every enquiry.
Two fictional outcomes, two different fixes
Consider a fictional painting company testing its estimate form. The following are alternative outcomes of a single test submission, not client results or conversion benchmarks.
- The screen says the request was sent, but the receiving team cannot find it at the agreed check time. Record that gap and ask the website maintainer and inbox administrator to trace the request, including its destination and spam filtering. The cause is still unknown. Investigate delivery before buying more traffic or commissioning a redesign.
- The request arrives, but the analytics maintainer confirms that the event intended to record one enquiry fired twice for that submission. The business received one test enquiry. Repair the duplicate tracking and retest before using that event count to judge results. Two recorded events are not evidence of two enquiries.
The results point to different work. The worksheet keeps the observed result attached to the person who can investigate it, instead of turning every problem into a design request.
Check what your reports call an enquiry
A phone-link click, a submitted request, a genuine enquiry and a qualified prospect describe different stages. Keep their counts separate. An enquiry is qualified only when it meets your business's stated criteria, such as the service needed and the area you cover.
Google Analytics recommends separate events for lead generation and qualification. Those recommended events need appropriate implementation; their names do not mean your website already measures them. Ask your analytics maintainer to compare the intended event with the test result, rather than relying on the label in a dashboard.
Keep names, email addresses, phone numbers and enquiry text out of Analytics. Google's guidance on personally identifiable information also addresses information exposed through page URLs and user-entered fields. Keep customer records in the appropriate business system. This is a tracking precaution, not a complete privacy-compliance assessment.
Look at the visits that could become customers
Once the contact route works, look beyond the total visitor count. Separate visits to advice articles from visits to service and quote-request pages. Review the sources bringing people to those pages and the locations your reporting makes available. A country-level figure is only a broad clue for a business with a local service area.
For Google Search traffic, Search Console's Performance report lets you examine queries, pages, countries and devices. Start with the available queries leading to your chosen service page. Are people looking for work you actually take on? Search Console describes Google Search activity, so use your other reports to examine advertising, referrals and other sources.
For paid search, compare the search term, ad and destination page. If an ad offers a specific repair, the page should explain that repair and how to request it. Google Ads' landing-page guidance recommends matching the destination to the ad and keywords. If the mismatch begins before the visitor arrives, changing page colours will leave that problem unresolved.
Remove the uncertainty around your offer
Read the first screen of the service page without relying on what you already know about the business. A visitor should be able to identify the service, where it is available and the next step.
For the fictional painting company, “Interior painting for homes in Richmond Hill” gives a reader more to work with than “Quality solutions you can trust.” A button labelled “Request a painting estimate” explains the action. The nearby copy can say what information is needed and whether a site visit is part of preparing an estimate.
Explain relevant limits as well. If you only handle certain types of work, say so. If the price depends on the job, explain the factors you need to assess. Only state a response time your team can support.
Put evidence beside the decision it helps with: permitted photographs of relevant completed work, genuine reviews, or qualifications you can substantiate. Describe the work accurately and label concepts as concepts. A visitor should be able to understand what the evidence demonstrates without mistaking an illustration for a client result.
Use the form as a customer would
Try the page on a real phone over mobile data as well as Wi-Fi. Check whether text remains readable when enlarged, whether a banner covers the contact controls and whether you can complete the form without fighting the layout. Record a specific obstacle rather than simply calling the page unfriendly.
Ask only for information needed at this stage. A detail may be necessary to assess a request, or it may be something your team can collect later. There is no useful universal field count for every service.
The W3C Forms Tutorial recommends clear labels and instructions, appropriate validation, and feedback about errors and completion. Check those states as well as the empty form. These checks support usability; they are not a full accessibility audit.
If loading or an unresponsive control gets in the way, record the page and conditions for your developer. For the performance side of that investigation, see ZXP's guide to website speed.
Follow the request beyond the inbox
A delivered request still needs someone to handle it. Confirm who checks each inbox, missed-call list or customer system, including when the usual person is away. Make sure an automatic acknowledgement does not leave the team assuming someone else has replied.
Keep a simple record of genuine enquiries, which ones fit your services, and their outcomes. Broad reasons such as “outside service area” or “service not offered” can help identify a targeting or page-clarity problem. Suitable requests left unanswered point to a response-process problem. Avoid copying unnecessary personal details into marketing reports.
Choose the next change from the evidence
For each proposed fix, write down the observation it addresses, who owns it and how you will test it again. Restore failed contact routes before spending time on cosmetic changes. Once the route works, choose a focused improvement based on the traffic, page or response evidence you have collected.
Record the change date and compare complete periods using consistent page, traffic-source and device groupings where available. Allow for changes in campaigns, seasonal demand and the time customers take to decide. When enquiry counts are small, a change of one or two can make a percentage look dramatic. Keep the underlying counts visible, and do not treat a short before-and-after comparison as proof that your edit caused the result.
If the evidence points to website work, explore ZXP's website services or prepare a project brief describing where the enquiry path needs work.
Sources & references
- 01[GA4] Recommended events
Google
- 02
- 03
- 04
- 05Forms Tutorial
W3C Web Accessibility Initiative
A perspective from the ZXP team.
Designed to help you ask better questions and take a clearer next step.



