The visitor saw a thank-you. Is the lead already lost?

Not yet. A thank-you is a message on the page. A lead is a row, a mail or a card someone can open. Submit one lead yourself, with a phone or address you control, and look in the place the team actually reads. If the row is there, the team is looking in the wrong room. If it is not, the request that should have written it is the bug. A new form is a later conversation.

Someone copies leads into the CRM by hand. Is the form the problem?

The form can be fine and the leads still disappear the afternoon that person is busy. Write down the fields they copy and the system they paste into. That list is the missing step. A new form with the same fields, still copied by hand, is the same afternoon with a different button.

The button spins and the thank-you never comes. Do we still look for a row?

Yes. The browser can give up while the server is still writing, or the write can fail with it. Note how many seconds the button stayed busy, and how large the answer was. Then look for the row you just typed. A spinner is not the lead. The row is.

When is a new form actually the right work?

After one watched submit. If the row is written, the team can find it, and the page finishes in a time a visitor will wait, the form is not the leak. Replace it when the fields themselves are wrong, or when you have decided the sentence the form must produce and the current one cannot. Bring the note: the screen, the place you looked, and what the one submit did.

The form says thank you, and the lead never shows up

The visitor was thanked. The person who should call them has an empty list. Look once before you pay for a new form.

A visitor fills the form, the page thanks them, and the person who was supposed to call has nothing to open. By lunch this has become "the site is losing leads". The next proposal is a new form, a new plugin, or a fresh contact page. The lead was already supposed to land somewhere a person can read. That somewhere is the thing to open first. A new button does not tell you where the last one went.

You can still replace the form later. You should not replace it while you have not watched a single submit. The thank-you and the lead are not the same event. One of them can succeed while the other never happens. Until you know which, the rebuild is a guess with a price on it.

1. Name the screen, and name the place a person reads

"We are losing leads" mixes three facts. Someone typed something. The page said it worked, or it never finished. Someone looked somewhere and did not find a row, a mail or a card. Those are a screen, a message and a room. A new form is a fourth idea. It does not belong in the sentence yet.

Write the three before anyone opens a builder. The screen is the page and the button, not "the site". The message is what the visitor actually saw: a thank-you, a spinner that never stopped, or an error they closed. The room is the one place a human is supposed to read the lead tomorrow. An inbox. A spreadsheet. A card in the CRM. A row in an admin list. One place. "The system" is not a place.

Add who looked, and how long after the click. A lead in a mailbox nobody opens is unread, not lost. A thank-you screenshot is not what they typed. If you cannot name the room, the team is looking in a different building.

The page and the button, in one line a person who was not in the meeting can find.
What the visitor saw. Thank-you, a spinner, or an error. Not "it didn't work".
The one place a human reads the lead. Inbox, sheet, card or admin row.
Who looked, and how many minutes after the submit.
Whether anyone still has the values the visitor typed. A thank-you screenshot does not count.

2. A thank-you is not a saved lead

The page decides to show a message. A different piece of code writes the row, sends the mail or creates the card. Either one can fail on its own. Teams argue about the form because the message is the only part they can see. The write is the part that pays the salary of the person who should have called.

The page can thank the visitor and never write the row. That happens when the front of the site treats a slow answer as success, or shows the message before the request has returned. It happens when the server answers "ok" and a later job, the one that was supposed to open the CRM card, fails where nobody is looking. It happens when the mail goes to an address that belonged to someone who left, and the row exists in a table the current team does not open.

The opposite starts the same argument. The visitor never sees the thank-you, closes the tab, and the row is already in the admin list. The project then redraws a form that saved the lead.

A third shape is not a bug in the button. Someone copies leads into a sheet or a CRM by hand. The form may be fine. The step into the room where sales actually works was never built, so the leads vanish the afternoon that person is in a meeting. A new form with the same fields, still pasted by hand, is that same afternoon. The fields they copy, and the system they paste into, are the work.

3. Watch one submit before you change anything

Pick one lead you are willing to create yourself. Use a phone or an address you control, so you can recognise the row and so you are not putting a stranger's details through a path you do not trust yet. Fill the form the way a customer does, on the live site if that is the only place the form runs. If you have a separate environment where this path runs without a customer in it, use that. Do not invent one in the middle of the argument. One honest submit is enough.

Then look, in this order, and write what you see. Did the button stay busy, and for how many seconds? Did the thank-you appear before the request finished, or after? In the room you named, is there a row with the values you just typed, not a similar row from last week? If the room is an inbox, is the mail in spam, in a shared box, or addressed to a person who no longer works there? If the room is a CRM, is the card on the right account?

That last question matters on a product several customers share. A lead can be saved and still be invisible to the person who is looking, because it landed under another account. The row is not missing. It is in the wrong room. The usual places that mix-up shows up are covered in where a shared product mixes customer data. Check the account before you call the form broken.

If nothing was written, look for an error from the minute you pressed the button. Silence is a finding too. It means the failure is not being recorded, which is why the team can only see the thank-you. One watched submit replaces the argument about forms in general. You have a row, or you have a request that did not produce one. Both are smaller than "the site loses leads".

A phone or address you control, so the row is recognisable and not a stranger's.
The seconds the button stayed busy, and whether the thank-you arrived before the request finished.
The row, the mail or the card, with the values you just typed. A similar row from last week does not count.
Spam, a shared mailbox, and a former employee's address, if the room is an inbox.
The account the card landed on, if more than one customer shares the product.

4. When the page never finishes

Sometimes there is no thank-you because the screen never gets there. The visitor waits, the button stays busy, they leave. From the outside this looks like a lost lead. It is a different failure from a thank-you with no row, and it is the one people describe as the page hanging. Treat it as its own note. Do not fold it into "the form is old".

Watch the request that runs when they press the button. You want three things: how long it took, how large the answer was, and whether this request is the one that writes the lead or a request that only paints the page. A lead step that hangs is often one of those, not the whole site. The wider pass, before anyone pays for a new look, is what to check before a redesign. Stay on this button until you have its seconds.

Size is easy to shrug off. A short answer is a form doing its job. An answer measured in hundreds of kilobytes is the page waiting on bytes the visitor did not ask to read. The browser can give up while the server is still writing, or the write can fail with the wait. Look for the row anyway. A visitor who left, and a row that exists, is a slow page. A visitor who left, and no row, is a failed write. They are different jobs. Cut a heavy answer to what this screen needs, or let the click record the lead and finish the rest after the thank-you. Do that after you have timed it.

5. What to do with the one submit

Match the fix to the finding and leave the rest of the site alone. If the row is there and the team looks in a mailbox, point them at the row, or send the mail to the box they already open. If the thank-you shows and the row is never written, keep the form and fix the write. If a later job was supposed to create the card, read that job's failure. The button colour will not mention it.

If a person copies leads by hand, the field list you wrote down is the integration. Build that step, or accept out loud that a person is the step and give them a time of day when they are not in meetings. Pretending the form will become reliable on its own is how the next busy afternoon gets the same name.

If the page hangs on one slow or fat answer, that answer is the work. A redesign of the contact page ships the same wait in a new frame. Park the redraw until the seconds have moved.

Leave a note the next person can read without calling you:

The screen, the room, and what one watched submit did.
The seconds and the size, if the page never finished.
Whether a person is still the bridge into the CRM, and which fields they carry.
What you will not rebuild until this note is wrong.

When to bring in a specialist

You can name the screen, send one lead, and see whether a row appeared. Ask for help when the thank-you and the row disagree and nobody can see the request, when the lead is supposed to land in a CRM or an accounts tool and the only bridge is a person, or when the click hangs and you cannot open the answer.

That is the work I take: follow the path from the button to the place a person reads the lead, on the system you already have. Services cover that recovery and the connections around it. Selected work is the same kind of situation, with each result kept next to the operation that produced it. If you want a second look, message me on LinkedIn. Send the screen, the room you expect the lead in, and what happened when you submitted one. Leave the passwords out.