Before redesigning your website, test what happens after an enquiry

A visitor has read your service page and sent an enquiry. What happens next? If the message reaches an unattended inbox, a more attractive homepage will not fix the handover.

Before planning a redesign, test the short journey from a customer asking for help to a named person responding. You can do this with one clearly labelled test enquiry and a small checklist.

Start with one realistic request

Choose a service you actually provide. Open its page on your phone, without logging into the website administration. Try to find the next step as a customer would: request a quote, ask a question or arrange a call.

Note anything you have to guess. Does the form explain what information is useful? Does it ask for a delivery address before you even know whether the company can help? Can you read the labels and correct a mistake without losing the rest of your message?

Use a company-controlled email address for the test. Do not enter a real customer's details. If colleagues receive enquiries, tell them the message is a test so it does not create unnecessary work.

Follow the message beyond the success screen

A “Thank you” message confirms what the visitor sees. It does not prove that someone in the business received the enquiry.

Check the destination independently. Open the shared inbox or customer management system and find the actual record. Compare it with the form: the service requested, message and reply details should still be present. Note whether the source page is recorded, especially when several service pages use the same form.

If a notification arrives but the customer record does not, record that as a partial result. If neither arrives, check spam and the configured destination before changing the website design.

Give each enquiry an owner

A shared inbox can make messages visible without making anyone responsible for them. Decide who checks new enquiries, who covers absences and what happens outside working hours.

Keep the first version simple. A named owner, a status and a next action may be enough. For example: “New request — Anna — clarify dimensions tomorrow.” That is a working example, not a promise of a particular response time.

Only advertise a response time that the team can consistently meet. An automatic acknowledgement can explain the next step, but should not pretend that a person has reviewed the request.

Add automation where it has a clear job

An integration can copy a request into the right system, assign it to a colleague or remind the team about unanswered messages. An assistant can help collect missing information. Neither should silently turn an uncertain request into a confirmed quote, booking or delivery promise.

Write down what the automation may do and where a person takes over. Keep one place to check failures. If the integration stops, someone should be able to find the original enquiry and respond without reconstructing it from several notifications.

Use the findings to brief a website team

Your test should leave you with a short list of observed problems rather than a general feeling that the site looks old. Record the page, the action attempted, the expected result and what actually happened. Fix missing messages and unclear ownership first; then improve the page and form around the customer's task.

AI PILOT works on websites, promotion and business automation. When discussing a project with our team, bring one example of this enquiry journey: where the visitor starts, where the request arrives and who should answer. It gives the project a concrete business outcome to test.

Repeat the same check after a release or a change to the inbox, form or integration. A website is ready to receive enquiries when the whole path works, not just when its pages look finished.