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.
- Status, date and owner visible to staff.
- Reply states the next action.
- Closure distinguished from sending a message.
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.