The Form Said “Thank You.” So Where Did the Enquiry Go?

There is a form on the website. The fields are neat, the button stands out, and after you click it a message appears: “Thank you! We’ll be in touch.”

The client closes the page. The manager carries on with the day. Each assumes the other is about to do something.

By the evening, neither has contacted the other.

A form can look as if it works even when the enquiry never reaches the place where someone is waiting for it. Or it can pass the data on correctly, only for the enquiry to disappear among other messages or remain without an owner. From the outside, these situations look very similar: the client waits, and the business says there are no enquiries.

To figure out what happened, check the whole route. “Thank you” is only one part of it.

First, a person fills in the fields. Then the website has to send the data to a handler. After that, the enquiry may be stored in a system and sent by email, messenger, or CRM. Finally, someone responsible for client replies has to see it.

The route depends on the specific website. On one site, the record is first created in the CRM and an email only notifies the team. On another, the form sends an email and there is no separate list of enquiries at all.

MDN’s documentation on sending form data explains the basic setup: the browser sends data to a server, and what happens next depends on the implementation. The server may display the data it received, store it, send an email, or do something else. So a response appearing in the browser does not by itself confirm that the enquiry reached the manager.

For the check, separate four questions: did the website accept the enquiry, was a record saved, did a notification reach the right channel, and did a person take the enquiry in hand? Each needs its own confirmation.

Imagine a hypothetical appliance repair company. When the website was launched, the form was set to send email to the owner. Later, an administrator and a work chat were added. Everyone assumes that enquiries now go there. In fact, no one changed the address.

This problem does not call for a new design. You need to know the current route and agree on the right one.

Ask the person responsible for the website where enquiries are stored, who receives notifications, and which address or chat is currently specified in the settings. Then check that the business can access that destination. A former employee may be the only administrator, an inbox may be full, or chat notifications may be turned off.

Do not settle for “by email.” You need a specific work address the business can access, and a person who checks it.

If you have to track down a contractor who stopped replying long ago just to carry out a check, sort out access first. We wrote about this in “The Contractor Disappeared. What’s Left of Your Website?”.

Open the form as an ordinary visitor, preferably on a phone. Fill it in with your own test contact details and add a clear label to the message: “FORM TEST.” Record the actual date and time you sent it separately.

Tell the person responsible about the test so they do not start arranging a fictional repair. But do not tell them which folder the message should be in if you want to check the usual workflow.

Write down when you sent it and what the website showed. Then check the planned destinations: a record in the CRM or another storage system, an email in the inbox, a message in the chat. For email, check spam and other folders too.

Ask the person responsible to find the test by its label and repeat the details they received: name, contact information, and enquiry text. This checks both delivery and content. An email may arrive without a phone number or with the wrong service name, while the sending system reports success.

One successful test confirms this specific run. It does not prove that everything works on every device and at all times. Start with the main route, then check other important forms and pages.

If the website did not accept the enquiry, the form and request handling need to be checked. The user should see a clear status, not a success message after an unsuccessful attempt.

If the website accepted the data and a record was saved, but the notification did not arrive, check the next part of the route: the recipient, email or integration settings, and the sending service’s response. The button’s appearance is unlikely to help here.

If the message is there but no one saw it, find out who checks the channel and how a new enquiry stands out from the other messages. If someone saw it but no one replied, you need rules for assigning the work.

This table is useful to bring to a conversation with the developer:

Stage What counts as confirmation Who can help check Form submission The actual result of the request and a correct status for the client Person responsible for the website Storage A record of the test enquiry, if the system is designed to keep one Website or CRM administrator Notification The test email or message in the intended place Channel owner and developer Follow-up A person confirmed the details and took the enquiry in hand Manager or owner

If the system does not store enquiries, say so. Do not invent a log just to make the table look complete. Discuss separately whether storage is needed and how it should be used.

Even if the form code ran, an email can be rejected or end up somewhere the manager is not expecting. The sender’s setup matters.

For example, Gmail’s sender requirements include domain authentication through SPF or DKIM among the basic conditions. Requirements differ for high sending volumes. These rules apply to delivery to personal Gmail accounts; they do not automatically apply to every email system.

Do not change domain records yourself based on a random online instruction. Give the email administrator the specific test, time, recipient address, and what you found in the sending results. They can check the requirements for your sender and recipient.

Also agree on which address the form uses to send the message and where a reply goes. Otherwise, a manager might click “Reply” and write to the technical sender instead of the client.

Let us continue with our hypothetical repair company. The route has been configured, and messages now arrive in a shared chat. The owner sees a new enquiry and assumes the administrator has picked it up. The administrator sees that the owner is online and assumes the same about them.

The technology did its part. That does not make things any easier for the client.

Decide who checks new enquiries, how they mark one as being handled, and who picks it up when that person is away. For a small team, a simple record with an owner and next action is enough. What matters is that it is visible to everyone involved.

Check the promise on the website too. “We’ll call in five minutes” is a poor fit if someone can submit the form at night and the team only works during business hours. Write what the business can actually deliver, then organize the work around that promise.

The message to the client should reflect the actual status. If the system has only accepted an enquiry on the website, do not claim that a manager is already reading it. Include a specific response time only after the team has agreed to it and can maintain that routine.

A form may have worked at launch and then stopped after an email change, a website update, a service replacement, or a move to another chat. Repeat the test after changes that affect the enquiry route.

Choose a routine and owner the team can keep up with. If the website is an important sales channel, one scheduled test enquiry may be more useful than another look at the traffic graph. Set the frequency according to enquiry volume and the consequences of missing one, not an all-purpose tip from the internet.

Ask the developer to explain how the team finds out when sending fails and whether enquiries are saved if the notification does not arrive. Test the backup channel too: a second button that leads to the same broken address does not provide an alternate route.

Here is a ready-to-send message for the first check:

If ads are bringing people to the site but there are few enquiries, it is useful to check this before increasing the budget. Other possible reasons are covered in “Ads Are Running, but There Are No Enquiries”.

Start today with one test. Follow it to a specific person and check the details they received. Then “Thank you” will stand for a little more than a nice animation.

The hypothetical business, check table, and message templates are editorial examples. The actual route depends on how your website is implemented.