Where Leads Disappear Between the Form and Payment - and How to Measure It

Leads most often disappear at handoff points: the phone field, an embedded form, the transfer into a customer database, the queue for a first reply, and the payment step. To find the exact spot, you place two analytics events at each handoff - one for the attempt, one for the success - and calculate the loss rate with a single formula.

How to measure how many leads you're losing

A lead's journey has five stages: a person fills out a form, the form sends data to the CRM (the customer records system - the software where every inquiry is stored), a manager replies, the customer receives an invoice, and the customer pays.

At the boundary between each stage, the analytics system records two events. On the form: attempt is "Submit clicked," success is "form sent without error." On payment: attempt is "Pay clicked," success is "payment confirmed." The gap between the two is the loss at that handoff.

Loss rate = 1 - (successes / attempts)

Here is a teaching example with made-up numbers to show the logic. In one week the form recorded 500 submit attempts, and 460 went through. The math: 1 - (460/500) = 0.08. Eight percent of attempts failed. One person can click Submit several times, so to count people rather than clicks, tie the events to a visitor or session and follow the same people through every handoff that follows.

Apply the same formula to every subsequent handoff: how many of those 460 submissions appeared in the CRM, how many got a reply, how many received an invoice, how many paid.

That turns "something feels off with our leads" into a number attached to a specific step - one the team can actually work on.

How a phone-number check cut off real customers

One company pulled analytics data on every failed form submission and failed chat initiation. Over several measurement periods the failure count kept climbing: 2, 5, 17, 33.

The cause turned up in a recent site update. Developers had added a pattern check to the phone field - a validation rule that inspects the number a person types and either allows or blocks the form submission. Nobody asked them to; they just wanted to keep garbage data out of the database. The rule was written carelessly, and anyone whose number didn't match the expected pattern simply couldn't submit.

A single form field serves two different interests. For a developer, the priority is protecting the database from bad input. For a business, the priority is letting a person leave an inquiry. These goals don't conflict, but you have to test for both.

Concretely: check that the database is protected, and also check that a person with a real number - typed in any format they're used to - can actually submit the form.

One field, one sloppy validation rule. By the last measurement period: 33 failures.

Where leads vanish between the form and the customer database

Behind a form sits a chain of decisions: the phone field with country code, the handoff of fields to the CRM, the payment integration, error handling. Teams write forms almost from scratch on every project, and mistakes show up in the same spots every time.

The smarter approach is to build a set of tested components - reusable code blocks, each solving one of these tasks - and reuse them rather than starting over.

Another weak link: forms embedded inside an iframe. An iframe (short for inline frame) is a piece of a third-party page inserted inside your own page. Embedding a ready-made form is faster than building one from scratch.

One company built a campaign landing page in a site builder - a service that lets you assemble pages from drag-and-drop blocks without a developer. The form on that page sat inside an iframe, produced errors, and lost leads. They rebuilt the page with their own components: the form connected directly to the CRM, every form field mapped to the right CRM field, payment was wired in, and errors were handled properly.

But not every loss has a technical cause. Another company went through chats, emails, and call records to understand why leads weren't reaching sales. Among the reasons they found was the most ordinary one: someone forgot to pass the lead along.

The handoff from form to manager is a gap just like any other. It needs its own analytics event.

Why response times slow down toward the end of the queue

A company that buys and sells cars and parts receives inquiries into a sales team queue. The first twenty deals in the list look exemplary - fast replies, leads worked by 7 a.m., sales closed.

By the thirtieth or fortieth deal, responses lag. Gaps in timing appear. The manager's replies turn careless.

That manager, from 7 a.m. every day, does the same things on repeat: ask for photos of the car, confirm the scratches, look up prices for similar cars on listing platforms.

Speed is everything in this business. A seller typically sends their car details to five different sites, and whoever responds first has a better chance at the deal. At night the managers sleep; the leads pile up.

This means response speed has to be measured across the full queue - nights and end of day included - rather than against the first leads in the list.

The suggestion was not to add more notifications for the manager (those add work), but to automate the initial processing of incoming leads. And to stop making managers fill in the CRM by hand: they do it poorly, and the client's data can be pulled in automatically.

The same company had a built-in AI auto-responder in their CRM - a program that answers customers without a human manager involved. It handled standard questions fine, and started producing nonsense when questions got slightly more complex.

The knowledge base - the information the auto-responder draws its answers from - was solid. The instructions - the text defining how to reply and what to avoid - were written carelessly. That's fixable.

The difference between this kind of auto-responder, a rules-based bot, and an agent that chooses its next action within a defined set of allowed steps is covered in a separate article.

How a billing error silently redirected people for years

In one product, whenever an invoice failed to generate, the code sent the user to the home screen instead of back to their order.

People who hit this error didn't come back to pay.

The code was written years earlier when the payment system was first integrated - a quick placeholder, the kind of thing you write intending to replace it later. The team was good and rewrote a lot over time. This corner they left alone because it "kind of worked."

The placeholder quietly ran for several years.

The problem surfaced when analytics events were connected to the code. Each event became traceable to the screen where it happened and the code that triggered it. That's how the redirect to the home screen after a billing error was found.

What to show someone when a payment fails

A service with millions of international users analyzed payment failures. Four causes showed up, and each one calls for a different response to the user.

• Card details not entered - check the analytics first: some of these events turned out to be a tracking error, and the people involved went on to complete purchases anyway.
• A temporary failure in the bank or payment network, unrelated to the buyer - offer a retry.
• Insufficient funds - say so clearly and offer a different payment method; a retry won't help here.
• Card not accepted (common when a card issued in one country is used through a bank in another) - suggest a different card. This can be flagged at the point of card entry, before the attempt even goes through.

Many sites show only "something went wrong" on a payment error, leaving the person with no idea what to do. The error message should reflect the type of failure, and the order shouldn't disappear.

One more loss point: split payments. When a customer wants to pay in parts or in two separate transactions, and the manager has to manually create each payment link, the payment waits for the manager to be free. That work can be automated, and each payment can be logged in the CRM immediately.

Ten points where leads get lost

If you're compiling your handoff numbers in a spreadsheet, a separate walkthrough covers building a dashboard - a summary report with charts - using an AI agent and checking the formulas.

Point	What to check	What event to count
Phone field	Validation doesn't reject real numbers, country code handled correctly	Submission rejected by validation
Embedded form in a site builder	Every submission reaches the company	Form submissions vs. received leads
Submission error	User sees a clear message, entered data is not lost	Submission error
Transfer to CRM	All fields arrive and land in the right places	Lead created in the system
Transfer to sales	Every lead has an owner	Manager assigned
First reply	Speed across the full queue, including nights	Time to first reply
Auto-responder	Passes unusual questions to a human	Handoff to human
Invoice generation	On error, user stays in the order and sees what to do	Invoice error and next screen
Payment decline	Message depends on the type of decline	Decline code (reason flag)
Retry and split payment	Link created without manual manager work	Retry attempt after decline

If the events are already set up, you can walk through this table against your existing analytics in a day.

Majento builds the form-CRM-payment connection and automates lead handling. More detail on the marketing automation and custom software development pages.

Questions and answers

What loss rate is normal?

There's no universal benchmark. If the loss rate on your form rises after a site update, look for what changed in the code. If losses hold steady without an obvious reason, check the analytics itself - in one service, some of these events turned out to be a counting error, and the people involved purchased anyway.

Where do you start when you have almost no analytics?

One handoff. Pick the most obvious one - the inquiry form - and add two events: submission attempted and submission succeeded. Look at the gap over a week. If it's significant, find the cause there. If it isn't, move on to the next handoff.

Do you have to leave a site builder?

Not necessarily. A site builder is a tool for assembling pages quickly, and it isn't itself the cause of lost leads. The question is how the specific form works: does data reach the CRM, are fields mapped correctly, are errors handled. If the form is losing leads, find the cause first - then decide whether to replace the form or the whole page.

Why can't you just say "try again" for every payment error?

Because a retry helps when there's a temporary failure on the bank or payment network's side. If someone doesn't have enough funds, a retry won't change anything. If a card isn't accepted because of the country where it was issued, they need a different card. One generic message hides the reason and leaves the person with no way forward.

To check where your site and sales pipeline are losing leads, message us on Telegram or email hello@majento.ai.