A quiet week is not a design problem until you name the break. A person may never reach the form. A person may click and leave while the button is still busy. Thank you may appear on the site while no record is saved where the team works. Or the record may exist and nobody calls while the request is still fresh. Each case kills a conversation in a different way. A redesign can ship all five again.

Teams ask for a redesign because the symptom is easy to say. “The site does not bring leads.” But a lead path has several steps. A person has to see the offer, understand the next action, wait through the click, land in a place the team actually checks, and get a reply fast enough to matter. If one step breaks, the week looks empty. If you fix the wrong step, you spend the budget and keep the same result.

1. The form path: thank you is not a lead

Start with one submission you control. Use your own phone number and your own email. Write down the page and the button. Then write down where the team looks in the morning: an inbox, a spreadsheet, a CRM card, or an admin list. “The system” is not a destination. If two people name two different places, you already have one reason the site “does not bring leads.” The data may be arriving somewhere else.

Send the test and split the check in two. First: did thank you appear on the site. Second: did a record with your data appear where the team actually works. Those are separate steps. One part shows the message. Another part saves the row. They fail separately. A success message shown too early, a background task that dies quietly, a mailbox nobody owns anymore, or a row written into a tool nobody opens can all produce the same screenshot and the same empty morning.

If someone still copies the name and phone number from an email into the CRM by hand, that copy step is part of the path. A new button does not remove it. Write down which fields they copy and where they paste them. The longer walkthrough is what to check when thank you appeared and the lead never shows up. Stay with this page until you have run one full test. Do not open a redesign estimate from a thank-you screenshot.

2. The wait: people leave before the record exists

Sometimes thank you never appears. The person waits. The button stays busy. The person closes the tab. In a weekly report this looks the same as “no leads.” It is not the same failure. The step after the click did not finish in time for a real person.

Time that one request. Count the seconds until the button is free again. Check how large the response is. Check whether the request saves the lead or only changes what the person sees. A short response usually means the form did its job. A heavy response often means the person waited for something they did not need. The browser can also stop waiting while the server is still trying to save. So look for the record even when the person left.

The split is simple. The person left and the record exists: the finish is slow. The person left and the record does not exist: the save itself failed. A new visual does not change either fact. If the rest of the site is slow too, what to time before a redesign is the wider pass. This check stays on the button that is supposed to create the lead.

3. The button: the person cannot tell what happens next

A working form still fails when nobody clicks. Read the button like a stranger would. “Submit,” “Send,” and “Learn more” do not say what the person gets or when someone will reply. If the only clear action sits too low on a long page, many people never reach it. If three buttons compete, people often choose none.

Ask one person outside the team to say, out loud, what they think will happen after the click. If they cannot explain the next step in one sentence, the break is in the call to action. Fix the words and the placement of that one button before you redraw the page. The offer above the button has to promise the same thing. A headline about a free visit and a button about a newsletter are two different offers. People will not guess which one you meant.

Check the same path on a phone, because that is where a lot of paid traffic lands. The button has to be easy to reach. The fields have to match what your team actually uses later. Every extra field gives a person one more reason to leave. A missing phone number creates a lead nobody can call. Write the shortest field set that still lets someone on your team call back the same day.

4. The tracking: you cannot see which path works

A site can produce leads and still look empty in the report used for decisions. The event fires when thank you appears, even if the save failed. Or the event never fires, so a working path gets turned off. Or three tools each show a different number, and the meeting argues about the count instead of calling the people who wrote in.

Pick one definition and write it down. For this check, a lead is a record in the place the team works from. Not a click. Not a thank-you view. Then compare one day. How many test and real submissions landed in that place. How many the report counted. If those numbers disagree, the report is not ready to decide a budget. Do not “fix the site” to match a report that counts the wrong moment.

Campaign labels matter only after that definition is stable. If every ad points to the same page and the saved record does not store which ad sent the person, you cannot tell a useful path from a wasteful one. Save one label on the record at the moment of the save. Do not rebuild it later from memory. If the label is missing, say so. A missing label is a tracking gap. It is not proof that the page failed.

5. The follow-up: the lead arrived and nobody called

This feels unfair to the site, and it is the most common quiet week I get asked to redesign. The record exists. The phone number is real. Nobody called until the person had already hired someone else, or until the request had gone cold. The site did the job it was given. The step after the site did not.

Write three lines. Who calls. From which list. By when. “The sales team” is not a person. “When we can” is not a time. If the page promises a same-day reply, the list has to be opened the same day. A shared inbox with no owner fails this check even when the form is perfect. If the lead is supposed to become a CRM card and someone still copies it by hand, the delay often lives in that copy step. The shape of that break is in what usually breaks between a form and the CRM.

Look at ten recent records, not a dashboard. For each one, note whether someone called and how many hours passed. You do not need a perfect CRM history. You need to see whether follow-up is a habit or a hope. If most records have no call, stop paying for more traffic until the call exists. More visitors will only add more untouched rows.

What to write down before anyone talks about a new design

One afternoon is enough for a first pass. Do the five checks in order. Do not jump straight to the one that sounds like a redesign.

The note should decide the next purchase. A missing record is a path fix. A slow click is a timing fix. A vague button is a copy fix. A report that lies is a tracking fix. A pile of untouched records is a follow-up fix. A new design is reasonable only after those are named, and only for the parts the note still blames on the page itself. Buying the design first is how the same five reasons show up on a newer site.

When the checks need a specialist

Your team can run the test submission, read the button, and review ten records. Ask for help when the record and the thank-you message disagree and nobody can inspect the request, when the lead is supposed to land in a CRM and a person still sits in the middle copying fields, or when the report and the working list never match and nobody owns the event. The job is not a new site. The job is to make one path produce a record a person will actually call.

Services cover that path: the form, the save, and the handoff into the tool the team already opens. Selected work keeps each result next to the operation that produced it. If you write, send the page, the place you expected the lead, and what one test did. Leave passwords out of the first message.