Define a successful website enquiry
Before testing buttons, decide the outcome of each journey. A call should open the correct number that someone can answer. A form should accept the details, confirm submission and deliver the message to a monitored inbox. A booking should show real availability and be recorded for both customer and business.
Opening a page, pressing a button or seeing a success message checks only part of that process. An enquiry can disappear later: in a redirect, a mobile field error, an old automation or an abandoned mailbox.
Write the expected end of each route. That separates technical faults from unresolved responsibilities. If nobody knows who should receive a service's enquiries, changing the form alone will not fix it.
- Correct number opened for a call
- WhatsApp addressed correctly with useful initial text
- Form received with enough information to reply
- Booking recorded on both sides
Start where the customer arrives
Do not always start on the homepage. Open the link from Google, Instagram, an advert, directory or QR code. Try an old bookmarked address too. The first problem may precede the content: a wrong redirect, unexpected language, empty basket or missing page.
Use a private window or a device where you are signed out. Remembered language, location, sessions and consent may give you a different route from a new visitor. Open each published language directly as well as testing the selector.
Ask what a visitor without context would understand. Does the page confirm the right service? Are price, service area and next step consistent with the original link? A technically valid route can still lose an enquiry if it misses the reason for the visit.
Test each contact route on a real phone
Use your thumb. Tap the phone link and check the number in the dialler. Open WhatsApp and check the recipient and opening text. Fill the form with realistic test details, change a field, trigger an error and check you can correct it without starting again.
For bookings and quotes, reach the last safe step. Review calendars, dropdowns, privacy boxes, totals and confirmations. Rotate the phone, enlarge text and go back. Keyboards covering buttons, overlapping fields and lost state after a page or language change are easy to miss on desktop.
One working route does not validate another. The phone link may be right while the form fails. One language may complete a booking while another returns an error. Each public combination needs a complete test.
- A real phone, as well as a narrow browser window
- Each published language separately
- Field errors that can be corrected
- A clear confirmation after submission
Check form delivery, not just submission
Send an identifiable test, such as ‘test’ with the date. Find it in the intended inbox, spam folder, CRM or calendar. Confirm the details are present and allow a response. A notification keeping the name but losing the phone number or selected service has not completed its job.
Check what the sender receives too. A confirmation should explain receipt, a realistic response expectation and what to do for urgent requests. An outdated promise or a no-reply address can add friction immediately after the enquiry.
Where tools are connected, identify each step: website, form provider, automation, email and CRM. Note the last place the test appears. This narrows the investigation and helps avoid replacing a whole system for one broken connection.
Fix the cause and keep a repeatable test
When several buttons fail similarly, look for the shared source: a route, centrally stored number, automation or language setting. Repairing only the visible button leaves the same problem elsewhere.
Repeat the exact failed journey after the fix, then a similar route that already worked. Record entry URL, device, expected result and date. You need a test another person can repeat, rather than a long report.
Repeat these checks after releases, tool migrations, phone changes, new campaigns or language changes. A site may still load while enquiries stop arriving. The useful health check is a request received from beginning to end.
- Shared cause located
- Failed journey repeated after repair
- A working route checked for regressions
- Owner and date of the last test
