Why leads from your website never arrive

Google Ads is running. Sessions in GA4 or Plausible look healthy. People spend two minutes on the landing page and reach the button. The CRM is empty. The phone does not ring.

The first reflex is to blame the traffic: wrong people, cold leads, a weak offer. Headlines get rewritten. Creatives rotate. Targeting is rebuilt.

Check whether the form accepted and delivered the request before attributing the missing lead to the offer or audience. A visible form can still fail after submission.

The delivery chain

A submit is not one action. The lead walks five independent layers:

1. The browser — input, client checks, the network request.
2. The site’s server — accept, validate, persist.
3. Transport — SMTP, a messenger API (Telegram or WhatsApp), or a CRM write.
4. The receiving service — auth, anti-spam, folder routing.
5. The desk — a push, an inbox, a card on a board.

A failure at any boundary can prevent receipt. Measure attempts and outcomes for each stage before estimating compound reliability; this page does not report a measured loss rate.

Cause 1. Synchronous send in the request

One candidate fault is synchronous outbound delivery without independent durable acceptance. Inspect the actual request path rather than assuming a CMS plugin uses this design.

The visitor hits send. The same web request tries to talk to Gmail, Microsoft 365, or api.telegram.org. The browser waits.

If the remote side is slow, a proxy may return 504 while the backend continues or fails. A timeout alone does not tell you whether the downstream action happened. If persistence was tied to a successful mail send, the lead was never stored. The person leaves. There is no record that they existed.

Cause 2. Messenger APIs that time out

Teams move lead alerts into Telegram or WhatsApp because mail is slow. The API is still a network call from the server.

Network failures can leave a send attempt failed or unresolved; a missing response is not proof that the receiving service did nothing. A one-shot library call with a long timeout makes the form itself hang.

Separate durable acceptance from outbound delivery. Reconcile ambiguous responses or use duplicate protection before retrying; choose retry timing from the service response and task requirements.

Cause 3. Mail as if it were a queue

Mail was designed as best-effort, not as a lead bus. Firms still use it as the only channel.

Credential revocation or expiry can interrupt sending. Check the provider response and authentication configuration rather than inferring the cause from silence.

Missing or misconfigured sender authentication can contribute to rejection or spam placement; inspect the receiving provider’s evidence. Sales does not live in the junk folder. A week-old lead is not a lead.

Cause 4. Invisible validation on a phone

Check the actual device mix when data is available. On a phone, an obscured validation error can block the form. On a small screen a small interface fault is a wall.

Four or five fields. Name and number filled. Send. The number was typed without the expected mask, or the consent box was cleared by accident. The field goes red. The keyboard covers it, and the page does not scroll to the error.

The visitor taps again. Nothing. They conclude the site is dead.

Cause 5. Blockers and third-party widgets

A pasted CRM widget, a quiz builder, a “lead collector” script.

Privacy tools may block third-party form resources according to their active rules. The form is a blank, or a button that does not click.

If the form is gated on a CAPTCHA and the CAPTCHA script never loaded (CDN, network, privacy mode), submit is blocked with no explanation.

Cause 6. No sending state, no double-submit guard

If the button text does not change, there is no spinner, and the control stays enabled, a pause can prompt repeated taps. An unprepared backend gets a race, duplicates, or a CRM that treats the burst as abuse and blocks the IP.

A ten-minute pass

1. Phone, private window, deliberate error in the number. Does the viewport move to the error, and is the fix obvious?
2. Same page with an ad blocker on. Is the form visible and usable?
3. Send on throttled mobile data. Loader? Button disabled?
4. A real device, a real test lead. Inbox or spam? Telegram or WhatsApp notice?
5. Ask where leads are stored if the mail gateway or the messenger is down at that second. “Nowhere” means the funnel is a sieve.

How a lead should be stored

No external service — mail, messenger, CRM — is allowed to decide whether the person is kept.

A proposed pattern, consistent with the transactional outbox approach:

1. Durable acceptance. Store the lead or outbox record before dispatch, using a mechanism with appropriate concurrency, access, retention and recovery controls. A local append-only file is one possible component, not proof that those requirements are met.
2. An accurate acceptance response. Confirm only the state actually reached, such as durable storage. Measure response time for the agreed workload rather than promising a fixed latency.
3. Background delivery. Send through the agreed destinations with durable attempt records, bounded retries and reconciliation of uncertain effects.
4. Reviewed recovery and alerts. Choose secondary destinations only when the workflow and data permissions justify them. Multiple channels do not by themselves guarantee receipt.

If leads are dropping, or visitors report silence, the first job is this chain — not a new headline. A usability pass on the same landing is the sibling check: can a person complete the job once the pipe is sound.