A website enquiry arrives. An automatic email confirms receipt. Then what? The visitor may have a straightforward question, a problem to explain, or an early idea they are not ready to buy. Your team needs a way to respond that fits the request without making the visitor repeat everything.

This is a workflow question as much as a website question. Before adding another form field or notification, decide who takes responsibility once someone presses send.

Give the enquiry a named owner

Choose a person or role to review new enquiries during your stated working hours, with a backup when that person is unavailable. A shared inbox can be the collection point, but “everyone can see it” is not the same as “someone owns it”.

Record who is handling each request. If it moves to another colleague, make that transfer explicit and include the context already gathered. The person asking for help should not have to discover your internal organisation by receiving several unrelated replies.

Government service guidance on setting up user support emphasises planning the support service and learning from the requests it receives. For a small business, a practical starting point is to treat follow-up as ongoing work with an owner, not an occasional inbox clean-up.

Separate acknowledgement from a useful reply

An acknowledgement tells the sender that the message arrived. It does not answer the question. Be clear about that difference in your wording. State a realistic response expectation that your team can maintain, including any relevant working-hour limits.

A useful first reply shows that someone understood the request. Briefly reflect the need, answer what you can, and ask only for the information needed to take the next step. Avoid sending a long company introduction when the visitor asked a specific question.

Do not promise a quotation, a solution or a deadline before you have enough context. If a colleague needs to review the request, explain that and say what the sender should expect next.

Make the next action specific

Consider a fictional enquiry: a retailer wants to connect an online catalogue to an existing stock system. A reply saying “we offer integrations” does not move the conversation far. A clearer response asks which systems are involved and suggests a short discussion to understand how stock is currently updated.

Internally, record the next action as “send two suitable meeting times after the customer confirms their systems”, not “follow up”. Where a date matters, include the date and time zone. If the team is waiting for the sender, record what is needed rather than leaving the request in an ambiguous open state.

A simple record can contain:

  • The original question and how the person prefers to be contacted.
  • The colleague responsible for the next action.
  • The latest useful response.
  • The next action and its agreed date, if there is one.
  • The current outcome or the reason work is waiting.

Collect enough context, not everything

A short enquiry form should help someone start a conversation. Ask whether each field helps you route or answer the request. If you do not need a piece of information at this stage, avoid collecting it just because a form builder makes it easy.

Provide an appropriate way to share sensitive material if it becomes necessary later; do not invite people to put passwords or private records in a general message box. Keep follow-up relevant to the request. Receiving an enquiry is not a reason to add someone to unrelated promotional messages.

Review any automated acknowledgement using a real test submission. Check that it arrives, makes sense on a phone, and gives a working way to reply. Also confirm that the team receives the enquiry and can recognise who owns it.

Review the unanswered questions each week

Set aside a short review for requests that have no owner, are waiting beyond an agreed date, or have repeated unanswered questions. Look for patterns in the questions themselves. If several people cannot find delivery information, that may be a content problem to fix on the website.

Start with a few clear observations rather than a large dashboard: unassigned requests, first replies still due, and next actions overdue. Define each measure so colleagues interpret it consistently. Avoid treating the number of replies sent as proof that a customer's need was met.

Try the journey from the visitor’s side

Submit a sample question, trace it through the inbox, and ask a colleague to handle it using the agreed process. Could they find the message, understand the need, and identify the next action without asking around?

That small rehearsal can reveal a more useful improvement than another button on the website. The aim is a conversation with a clear owner and a clear next step.

For a broader team exercise, see how to map a business process before automating it.