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.

Often the leak is not psychology. The form is broken, intermittent, or sending into a void. The site still looks well.

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.

If any one layer fails ten percent of the time, the compound reliability is already poor. Several weak layers and sales sees less than half of the people who tried.

Cause 1. Synchronous send in the request

This is the common architectural fault on small and mid-size sites. It is how most CMS plugins and naive scripts still work.

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, the reverse proxy hits its timeout (504). The script dies. The visitor sees a network error. 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.

Firewalls, packet loss, and flaky routes turn a single 10–15 second attempt into a lottery: three leads arrive in a second, the fourth hangs and dies. A one-shot library call with a long timeout makes the form itself hang.

The fix is not “try Telegram harder in the request.” It is a transport that retries fast, and a write-ahead log so a failed push does not erase the person.

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.

App passwords and OAuth tokens rot when someone changes the mailbox password or turns on a new second factor. The site gets an auth refusal and goes quiet.

Missing SPF, DKIM, and DMARC: mail sent as info@yourdomain is dropped or filed as spam. Sales does not live in the junk folder. A week-old lead is not a lead.

Cause 4. Invisible validation on a phone

Most commercial traffic is a phone. 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.

uBlock, AdGuard, and built-in browser shields will kill a script whose URL or class names look like a tracker. 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 1.5 second pause is enough for four 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 working pattern:

1. Write-ahead log, in the same request. The payload hits a local append-only file (or equivalent) before any outbound call. If the rest of the network is dark, the record still exists.
2. A fast 200 to the visitor. Confirmation in a few hundred milliseconds. The person is not held hostage to SMTP.
3. Background delivery. Telegram, WhatsApp, CRM, and mail run out of band, with short retries. A mail outage is not a form error.
4. More than one channel. Messenger plus CRM plus mail. One vendor’s bad afternoon is not a silent day.

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.