Why website enquiries go missing, and how to fix the handover
A form submission is only the start. Trace website enquiries through your CRM, assignment rules, and replies, with a practical checklist for testing the handover.
Areza Digital
Your contact form says the message has been sent. The visitor closes the tab. Somewhere behind the page, an email, a workflow, and a customer record are supposed to get the right person involved.
That is where an enquiry can disappear without anything looking broken on the website.
The fix starts with a simple question: can you follow one enquiry from the visitor’s submission to a named person replying? If the answer involves checking three inboxes and asking around, the handover needs work.
Separate receiving a message from dealing with it
Imagine a small consultancy with a website form, an automation workflow, and a CRM. This is an illustrative example, not a client case study.
The form sends the message to the server. The server starts the workflow. The workflow looks for an existing company, creates an enquiry, and assigns it to an account owner. Someone then replies.
Those are separate events. A successful first step says nothing about whether the last one happened. Even an HTTP 202 Accepted response means a request has been accepted for processing; it does not establish that the processing finished successfully. MDN explains that distinction.
Decide what the website can truthfully confirm. If the message is safely recorded but still waiting to be assigned, say it has been received. Do not say someone has reviewed it, or promise a response time the team has not agreed to meet.
Give every handover something you can check
Draw the route on one page. Name the system responsible for each step and the evidence it should leave behind. Start with the route you actually have, including shared inboxes and manual steps.
Swipe or scroll to compare.
| Step | Evidence to look for | What should happen if it fails |
|---|---|---|
| Receive | A saved submission with an ID and receipt time | Keep the message available for recovery; show an honest failure if it was not saved |
| Create the enquiry | A CRM record linked to that submission ID | Put the submission in a retry or review queue |
| Assign | A named owner, or an explicitly monitored unassigned queue | Notify the person responsible for triage |
| Acknowledge | A recorded attempt to send the receipt, with its result | Flag delivery failure without losing the enquiry |
| Reply | A human reply associated with the enquiry | Surface overdue enquiries against the team’s agreed response window |
The important detail is the link between records. An inbox full of messages and a CRM full of contacts do not, by themselves, show whether every enquiry made it across.
Keep operational logs small. Record the submission ID, stage, time, and error category. Avoid copying the full message and personal details into every alert just to make troubleshooting convenient.
Check the live workflow, not just the test run
If you use n8n, check which webhook URL the website calls. Its Webhook node has separate test and production URLs, and its response can be configured to return immediately or wait for later workflow steps. Those choices affect what a successful form response actually proves. See n8n’s Webhook documentation.
A useful end-to-end check begins on the deployed form and ends in the destination record. Use clearly marked test details. Inspect the matching execution and record, then have the intended recipient confirm they can see and act on it.
Do not stop because the workflow editor shows a green tick. Check the actual field values too. A record with an empty message, the wrong company, or no owner is not a successful handover.
Make ownership a rule, including the awkward cases
“Send it to sales” is not an assignment rule. It leaves unanswered questions: which salesperson, what happens when they are away, and who watches the inbox before someone claims the message?
Write a short decision table. Existing customers might go to their account owner. New enquiries might be routed by service or territory. If neither rule finds a person, the enquiry should enter a visible queue with a named person responsible for reviewing it.
Give that fallback the same attention as the main route. Test a company the CRM does not recognise. Test an inactive owner. Test a message with no service selected. Optional form fields should not quietly become mandatory assumptions inside the workflow.
Start with the few rules the team can explain and maintain. Add more only when there is a clear operational reason.
Expect retries without creating duplicates
A request can time out after the receiving system has already saved it. Retrying blindly can create another record. Never retrying can leave a message stranded.
Use one submission ID across the initial attempt and its retries. Before creating a destination record, check whether that submission has already been processed. The aim is for repeated delivery of the same event to have one business outcome, often called idempotency.
The receiving system also needs to enforce one record per submission ID. Checking first and saving later can still create duplicates when two requests arrive together. Use the destination’s documented idempotency support where available; Stripe’s API is one example, though each system has its own rules.
An email address is not enough for this. The same customer can send two different, valid enquiries. Treat those as separate submissions, while keeping a retry of one submission attached to its original ID.
Distinguish temporary failures from problems that need a person. A short service outage may justify a limited retry. An invalid field mapping needs correction. Set a retry limit, keep failed items visible, and agree who deals with the queue when that limit is reached.
Test the failure paths before calling it finished
Run these checks in a safe test environment, then verify the normal route on the live form with test details. Do not deliberately interrupt a production CRM to simulate an outage.
Swipe or scroll to compare.
| Test | Expected result |
|---|---|
| A valid new enquiry | One enquiry, the right details, and a visible owner |
| The same event delivered twice | One enquiry associated with the original submission ID |
| The CRM is unavailable in a test run | A recoverable item, a bounded retry, and a visible failure state |
| An email address is invalid | A clear field error before acceptance, with the rest of the message preserved |
| No assignment rule matches | The enquiry enters the monitored fallback queue |
| A receipt email cannot be delivered | The saved enquiry remains available and the delivery problem is recorded |
The visitor’s side matters too. Error feedback should identify the problem and help the person correct it; success feedback should confirm the outcome. That is the purpose of W3C’s guidance on form notifications.
Measure the handover, not only the button click
A form-submission event in analytics can help you understand website activity. It cannot prove a customer received a reply.
Review the number of received submissions against destination records. Look at time to assignment, time to first human reply, and the age of the oldest unresolved failure. Choose a review rhythm that fits the team’s enquiry volume. For a quiet inbox, checking each message may be more useful than building a dashboard.
You may discover that the form is fine and the missing piece is a fallback owner. Or that the assignment rules work but a changed CRM field broke record creation. Fix the specific gap first.
If your website, inbox, and CRM are leaving too much to memory, we can help connect the systems and make the sales handover easier to follow. Bring one recent enquiry and the route it was meant to take. That is a useful place to start.