Inquiry is in the form but missing in CRM: where to look for the gap

Start with one enquiry you can trace

Choose a real enquiry that can be investigated without copying unnecessary personal data. Record its source, time with time zone and internal reference. Find the corresponding events in the form handler, integration and CRM. Access to one system does not prove what happened in the next.

A difference between total counters is only a clue. Spam filtering, retries, duplicate detection and different reporting periods can explain it without a lost enquiry. Compare the same event and the same period. If a stage has no usable record, mark that visibility gap instead of concluding that nothing arrived.

• Keep the original request reference through every stage.
• Check both accepted and rejected requests.
• Avoid placing names, contact details or full form bodies in general error logs.

Separate acceptance from completion

A success message in the browser does not by itself prove that a CRM record exists. Inspect what the form endpoint actually acknowledges: receipt, durable storage, addition to a queue or completed CRM processing. A later notification is another separate step.

Draw the path and define the success condition at each boundary. Inspect field validation, integration permissions, queue state and the CRM response. A request may be accepted by the form and rejected later because a required field is missing or a token no longer has the necessary access.

• Use stable event references, recorded status and timestamps.
• Show the visitor a confirmation that matches the action actually completed.
• Make downstream failures visible to the responsible person.

Recover the enquiry without creating a duplicate

Before replaying a failed request, check whether the CRM already saved it. A connection can fail after the CRM commits a record but before the integration receives the response. Repeating the creation blindly can then produce a second lead.

Use an idempotency key where supported, or an explicit deduplication rule tied to the request. Decide which errors are retryable, how retries stop and who investigates a permanent failure. A missing required field needs correction; repeated delivery alone will not repair it.

• Preserve the original payload securely only as long as needed.
• Check partial completion before replay.
• Record the recovered CRM reference and the recovery result.

Close the operational gap

A saved lead can still be overlooked if it has no owner or its notification fails. Verify assignment separately from creation and define where failed requests are reviewed. The person responsible needs enough context to resolve the issue without unrestricted access to all customer data.

After the repair, test an ordinary request, a duplicate, a rejected field and an unavailable downstream service in an isolated test environment. Confirm both the CRM result and the visitor-facing message. Then monitor the real route with an agreed review owner and retention policy.

A practical next step

Start with the route that loses visibility today. We can review its boundaries, error handling and ownership before proposing a larger CRM redesign.

Discuss this workflow

Continue with

• When a Business Needs a Client Portal and When a Form Is Enough
• AI Automation ROI: What Companies Actually Save

Distinguish between accepted, recorded, and notified

A form may submit data successfully while the CRM rejects it due to a required field or changed permissions. The CRM may create a record, but the notification to the team never arrives. These events have different consequences: in the first case you need to recover the record, in the second — only retry the notification.

One contact can have multiple tasks

A repeated button click should not create a new deal. Yet a new task from the same client may be a separate opportunity. That is why the identity of a person, company, request, and deal are different things. An "one email — one deal forever" rule will lose repeat sales.

An error must have an owner

A transient failure can be retried. An invalid field or revoked access cannot be fixed by retrying. Set a retry limit and a queue for submissions requiring attention. For each failure, show the stage, the last attempt, and the next action without exposing secrets or full client message text in the shared log.

How to accept the first small rollout

Start with one source, one request type, and your existing CRM. Before launch, verify a standard request, an empty required field, a retry of the same event, temporary CRM unavailability, and a notification failure after a successful write. Test contacts must be clearly separated from real ones.