Manage website enquiries after submission

Define enquiry types and destinations

List the requests that actually arrive: quotations, appointments, support, partnerships, press and general questions. Give each type an owner and a fallback route. A category selector should not be the only way to reach the right person; decide how a wrongly classified message will be reassigned.

Ask only for information needed to start. A complex request can be clarified in a later exchange. The form design guide covers entry, errors and confirmation for visitors; this guide continues after submission.

• Enquiry types and owners identified.
• Misclassified messages handled.
• Fallback route when ordinary delivery fails.

Test delivery and message clarity

Send trial enquiries from a phone and desktop. Check the on-screen confirmation, any acknowledgement, the actual receiving inbox and the content delivered. Visitors must know whether the request went through or further action is needed. A success screen alone does not prove that email or notification arrived.

Try accented text, an invalid address, an empty optional field and an attachment if offered. Avoid spreading sensitive details across an overly broad notification list. Document what happens when a message is lost or rejected so staff can investigate without asking the visitor to start again.

The W3C form notification tutorial offers accessible success and error examples; verify their behaviour in the published form.

• On-screen confirmation and internal delivery checked separately.
• Error cases and special characters tried.
• Message access limited to relevant staff.

Follow the request to a useful answer

Use a few understandable states: new, assigned, awaiting information, handled and closed. Retain receipt time and current owner. Priority should reflect the request, not only arrival order; a problem with an existing service may need a different path from a sales enquiry.

The first answer should restate the need and specify the next step. Ask a focused question if information is missing. Do not promise an automatic response time that the team cannot meet. Sending a reply is not the same as resolving the request: confirm that the person received what they needed and close the case for a clear reason.

Fictional tracking dataset, frozen at review time: 20 unique enquiries comprise 6 new, 5 assigned, 4 awaiting information, 3 resolved pending verification and 2 closed. Here “resolved” means that a solution has been proposed but closure still requires a check; 18 enquiries therefore remain unclosed. This vocabulary is a scenario convention to agree with the team, rather than a standard imposed on every tool.

Of the 18 unclosed enquiries, 2 have no owner and 3 have exceeded an internal deadline defined for the test. One enquiry belongs to both groups, so 2 + 3 − 1 = 4 distinct enquiries need attention, not 5. Identify them by reference and record the next action and authorized deputy. An automated acknowledgement neither assigns an enquiry nor justifies closing it.

• Status, date and owner visible to staff.
• Reply states the next action.
• Closure distinguished from sending a message.

Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.

• GOV.UK : Government Data Quality Framework

  GOV.UK, consulted 22 October 2026: data quality and uniqueness. The statuses, deadlines and calculations are our fictional example.

Review volume, access and corrections

Weekly or monthly, according to volume, compare received requests, unowned items, late replies and delivery problems. Read a small sample of complete journeys rather than looking only at a conversion total. If website analytics and sales follow-up use different systems, explain the discrepancy.

Set a retention period suitable for the purpose and applicable obligations, then review access and deletion. Reassign open requests when someone leaves the team. The measurement guide helps choose useful indicators without collecting excessive data.

The French data-protection authority explains how to set retention periods by purpose and applicable rules; no single period suits every request.

• Unowned requests detected.
• Access and retention reviewed.
• Whole journey periodically tested.

Count new cases rather than every submission

Fictional example: one day produces 12 form submissions: 9 new enquiries, 2 follow-ups linked to existing cases and 1 identified internal test. Twelve describes submissions, not twelve separate sales opportunities. Connect exchanges through a verified reference; do not automatically merge every message from the same email address.

This example therefore records 9 new cases. That does not mean 9 customers or 9 sales. Retain the reporting period and the definition of each measure, and leave uncertain matches for review. Track enquiry quality and commercial outcomes separately.

Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.

• Read the measurement guide

  Define the measures used for follow-up.

Have a colleague accept the handover before an absence

Fictional case: DEMO-42 needs further information when its owner goes on leave. Prepare a handover containing the reference, the last useful exchange, the information still needed and the next internally agreed deadline. Forwarding an email alone does not establish that someone has taken over.

The replacement confirms access to the necessary information and accepts the next action. The team can identify one current owner. When the original owner returns, check the actual case status before replying again, so that the visitor receives no conflicting commitments.

• Test the handover with a wholly fictional case.
• Confirm who owns the next action.
• Close or reassign the handover after checking the outcome.