Your customer clicked “Send”. Did their message reach you?

This fictional example illustrates a problem you cannot spot by looking at the home page. A website can load quickly and look good while one of its most important functions fails. The customer's message may never reach the server, may fail to reach the email recipient or may sit in a system nobody checks.

Enquiries can also fall because demand, your offer or the audience seeing your advertising has changed. Before making bigger changes, however, check that messages are arriving at all. Submit a test enquiry and establish whether it reaches the person who should respond.

What happens after someone clicks the button

For the customer, clicking “Send” means waiting for an answer. For the business, the work is only beginning. The browser must send the data, the server must validate and process it, and the message may then go to email, a customer relationship management system, or CRM, or a task list.

Different failures can occur at each stage. A useful test establishes what each confirmation actually proves.

Not every business needs a complex sales system. A small team may simply need to agree where enquiries are stored, who checks them and who covers for that person when they are away. A thank-you message on the customer's screen does not establish that this process works.

Try your form as a new customer would

Start with the form customers reach from your most important service page or advertisement. Open that exact page on a phone. Use a browser in which you are not signed in as a website administrator. Administrators may see a different interface or face different restrictions from ordinary visitors.

Let the colleague receiving enquiries know in advance. Use an email address you can access, and clearly identify the message as a test. Do not enter a real customer's details or trigger an actual order or payment if the form is connected to those processes.

1. Record the page address and test time. If there are several languages or forms, note which one you are testing. This helps the technical team find the relevant request.
2. Complete every required field. Watch for validation messages, attachment handling and any checks against automated submissions. In a separate attempt, leave a required field empty. Check whether the message clearly explains what is missing and whether your other entries are retained.
3. Save the result shown on screen. Does the form confirm receipt, report an error or display a loading symbol indefinitely? If it fails, is there another way to make contact?
4. Find the actual enquiry. Check the intended mailbox or CRM record. If needed, look in the spam folder and the organisation's email quarantine, where suspicious messages may be held.
5. Check the reply. Ask the responsible colleague to respond to the test message. Confirm that the reply reaches the correct address and makes clear which enquiry it concerns.

One successful attempt establishes that this particular enquiry reached its recipient. It does not prove that every form, language, browser and business-system connection works. Choose the most important variations based on how your customers use the website.

What the thank-you message really means

The message after submission should reflect what has happened in the system. If the enquiry has been accepted and saved in the company's records, the form can confirm receipt. If only an attempt to send it has begun, claiming successful receipt would be misleading.

The technical team should establish exactly when the thank-you message appears. A click or just any server response is insufficient, because the response may itself contain an error. Some systems place enquiries in a queue for later processing. Receipt should then be confirmed only after the queued task has been durably saved. A promise to save it later is not proof of receipt.

When something fails, the visitor needs to know what to do next. Explain which field needs correcting and how, or offer another contact method. The message should also work with a screen reader, which presents screen content through speech or Braille. Do not leave someone guessing whether their enquiry has disappeared or will arrive later.

Clear success and error messages are covered in the W3C accessibility tutorial on form notifications.

A failure can happen before an email is sent

Visitors can often fix an empty required field or a mistyped email address themselves. Browser-side validation helps them notice the problem immediately. Data must still be checked on the server, because browser restrictions can be bypassed. A correctly formatted address does not establish that the mailbox exists.

This distinction is explained in the MDN guide to form validation.

Failures can also come from the JavaScript that runs the page, spam protection, an attachment size limit or a server problem. If the issue appeared after a module update, a hosting move or the introduction of a new form, those changes are a useful starting point. They help direct the investigation but do not prove the cause.

A developer should compare the browser's request with the server's response and the record of how the enquiry was processed. Establish what the system managed to do before the failure. A screenshot of an error does not always show whether the enquiry had already been saved.

Sending an email is not proof of delivery

This distinction is easy to miss on websites built with PHP. The PHP function mail() can report success when an email has been accepted for sending. PHP's documentation explicitly states that this does not mean the email reached its destination.

The return value is explained in the PHP mail function documentation.

If the form uses an external email service, check the individual message's status and any error reports. Acceptance into a sending queue, rejection by the recipient's server and successful delivery are different events. A message accepted by the recipient's server can still land in spam or quarantine. A delivery status does not establish that an employee read it.

Examples of these statuses appear in Amazon SES sending activity documentation. Check the documentation of your actual provider for the exact names and meanings.

Do not change sender settings by guesswork. Establish which service sends the email, which domain it uses and whether the receiving server can verify its origin. SPF identifies servers permitted to send on behalf of the technical sender's MAIL FROM domain. This can differ from the domain the recipient sees in the From field. DKIM adds a verifiable digital signature that helps establish the message's origin and whether the signed content has changed.

DMARC checks whether the domain that passed SPF or DKIM aligns with the domain visible in the sender field. It is sufficient for either one of those checks to meet the condition. The domain's DMARC policy also states the requested treatment of messages that fail. These settings help authenticate the sender, but they do not guarantee placement in the inbox.

Domain alignment is explained further in Amazon SES documentation on DMARC.

A contact-form email is usually sent using a company-controlled domain with correctly configured sending authentication. After validating the submitted data, the visitor's address can be placed in Reply-To, which specifies where replies should go. Putting the visitor's address in From can make it appear that the website is sending on another domain's behalf and cause authentication to fail.

This separation of sender and reply addresses is also recommended for its plugin in the Contact Form 7 configuration documentation.

Authentication requirements and differences between sender categories are explained in Google's email sender guidelines. They apply to email sent to personal Gmail accounts. Check other recipients' requirements with their respective providers.

Save enquiries so you can find them when something fails

If the only copy of an enquiry is in an email the system is trying to send, diagnosing a failure and establishing what happened become harder. Depending on the business's needs, the enquiry can first be saved in a protected record system, with email used to notify someone of the new entry.

This might be the existing CRM or a restricted area of the website administration interface. Define how long enquiries are kept and who may view them. A publicly accessible file containing every enquiry is not an appropriate solution.

Each enquiry can have an identifier, a unique number or code. This links the form-processing records, notification email and entry in the company's system. A technical log often needs only that identifier, the time, processing stage and result. There is no need to copy the customer's message into every technical record.

Plan for uncertainty about whether a request was received. A connection can fail after the data has been saved. Clicking the button again must not create a second order without checking. Connected systems need a way to recognise repeated requests. If the outcome of the first attempt is unknown, investigate it instead of retrying the action indefinitely.

Analytics and your enquiry records measure different things

Google Analytics enhanced measurement can record the start and submission of a form through the form_start and form_submit events. These describe a visitor's interaction with the form. An event alone does not establish that a CRM record was created or that the responsible employee received an email.

The events are described in Google Analytics enhanced measurement documentation. Submitting a form and receiving the enquiry in the company's system are separate stages.

In business reporting, count received enquiries, requests that fit your offer and completed sales separately. Google provides events for these stages too, including qualify_lead and close_convert_lead. Implement them around the actual process. They should represent a stage only when the business really has assessed the enquiry or completed the sale.

Individual lead-handling stages are defined in the Google Analytics recommended events list.

If the numbers differ, investigate. Compare the same time period and forms using the same time zone. Account for tests, repeated attempts, spam and measurement limitations. A discrepancy between two reports must not automatically be labelled lost customers or lost revenue.

When configuring analytics, check what data it receives. Do not send email addresses, phone numbers or the customer's free-text message to Google Analytics. Check page URLs and their parameters too, because personal information can reach analytics as part of an address.

The restrictions and common leakage routes are explained in Google's guidance on keeping personally identifiable information out of Analytics.

After the fix, check that the enquiry really arrives

Monitoring that checks only whether the home page is available will miss some form failures. According to the website's importance to the business, schedule a test that follows an enquiry from submission to receipt. A person can do this, or it can be automated after the test's boundaries are defined.

An automated test must be recognisable. It must not become a real sales task or distort campaign reporting. Use a dedicated test email address and a marker identifying the enquiry as a test. Agree how unnecessary test data will be deleted afterwards. Also verify that a failure alert reaches the responsible person.

If the email service fails, an alert sent through that same service may also fail to arrive. Provide another suitable notification route. Make clear who responds and what should happen outside normal working hours.

Test frequency depends on how important enquiries are to the business and how they are processed. An additional check is needed after significant changes to the form, hosting, email configuration or a connected system. A single test on launch day is not sufficient for the website's entire lifetime.

What not to do when enquiries disappear

Do not start by switching off every protective control. If valid enquiries are being rejected, identify the specific reason and adjust the validation or filtering rules. Removing every restriction can increase spam, making genuine messages even harder to find.

Do not post a file containing all customer enquiries into a public chat or send it to an unvetted support provider. Initial investigation often needs only a test submission, timestamp, enquiry identifier and error description. If real customer data is necessary, agree who will have access and how it will be transferred securely.

Do not rush to commission a new website simply because a form is broken. First establish the cause and impact. A configuration error may be repairable in the existing site. A broader rebuild should follow an assessment of its technical condition and the company's needs.

Website maintenance includes checking that enquiries arrive

CreateIT takes over, maintains and supports websites, including those built by other developers. We work with WordPress, WooCommerce, Drupal and bespoke systems. We check forms and integrations and look for new problems after changes. We start with what is getting in the way of your customers and your team.

In your first message, send the page address, briefly describe the problem and explain where the enquiry should arrive. The test time and details of recent changes are useful too. Do not send passwords or real customer enquiries in the initial message.

We can trace how the website handles a particular submission and where it ends up. That gives you a clearer view of what needs fixing immediately and what should be addressed through ongoing maintenance.

Read more about support after launch in our website support and maintenance service description.