August 21, 2026 · Maksim Shchegolev

Inbound Lead Audit: Find Out Where Your Leads Are Lost

An inbound lead audit compares 4 counts over one fixed period: requests that arrived, records created, records with a named owner, and records with real work logged. Each gap is traced to one layer and confirmed with evidence the team can see, which is why the answer is almost never the layer everybody suspected at the start.

Want this checked on your own site? Run the free AI visibility check, or order the full audit.

An inbound lead audit is a fixed diagnostic that answers one question with evidence: between the moment a request arrives and the moment somebody actually works it, where does volume disappear, and how much of it. It is not a conversion review and not an opinion about the funnel. It is a reconciliation of counts, layer by layer, against records your team already stores.

This guide owns the method: the symptom catalogue, the confirming evidence, and the ranking. It owns no metric definition and no repair. Every layer below names the guide that carries the fix.

In one sentence

An inbound lead audit compares four counts over one fixed period: requests that arrived, records created, records with a named owner, and records with real work logged. Each gap is then traced to one layer, confirmed with evidence the team already stores, ranked by what it costs, and handed to the guide that owns the fix.

What is an inbound lead audit, and what is it not?

An audit is a counting exercise with a fixed scope. You choose a period, assemble the evidence, produce four numbers, explain every gap between them, and stop. What makes it useful is the stopping: an audit that drifts into strategy, tooling opinions and rep performance stops being falsifiable, and an unfalsifiable audit cannot be argued with or acted on.

The confusion is worth resolving early, because most of what is sold as a lead audit answers a different question than the one you asked.

Two things follow from that table. The audit produces no revenue estimate, because turning a count of lost records into a revenue figure requires assumptions the audit has not tested. And the audit assigns no blame, because every finding in the catalogue below can be produced by a system with competent people in it.

Why does an analytics review miss most of the leakage?

Because web analytics stops at the edge. Google’s documentation on traffic source dimensions describes how a session gets attributed to a source and campaign, which is exactly the right job for acquisition analysis and exactly the wrong tool for handling analysis. Analytics can tell you a form was submitted. It cannot tell you whether a record was created, whether anybody owns it, or whether a human ever called.

The second half of the blind spot is the mirror image. CRM reports count what exists in the CRM. A request that never became a record is invisible there too. So the most expensive category of loss, requests that arrived and were never entered into any system, is missing from both of the two reports every team already looks at. No standard dashboard shows it, which is why teams can watch their numbers weekly for a year and never see it.

Add the channels that never touch a website at all: inbound phone calls including the missed ones, chat apps, an old sales alias that still forwards to one person’s inbox, a marketplace or partner portal that emails a notification, a referral typed directly to a rep. Each of those can be a healthy source and an invisible one at the same time.

Response lag is the visible tip of this. A Harvard Business Review audit published in 2011 covered 2,241 US companies and found a median first response of 42 hours among the firms that answered at all. That study is old and describes one sample, so treat it as a description of how bad unmanaged handling gets rather than a current benchmark. The mechanism is what still applies: nothing in the record obliged anyone to act, and no report showed that nobody had.

What evidence do you need, and over what period?

Gather the evidence before you form a hypothesis. The order matters, because an audit that starts from a suspicion tends to find that suspicion.

That last row causes more failed audits than any technical problem. If there is no written routing rule, no written response window and no written qualification definition, you are not auditing, you are inventing a standard retroactively. When the rules are missing, record that as finding number one and audit against the weakest defensible version: every request gets a record, every record gets an owner, every owned record gets a first attempt.

Choosing the period. Use one closed period, never a rolling window, and align it to whole working weeks so weekend arrivals are not split across boundaries. It has to be long enough that your follow-up cycle completed inside it: if the sequence runs fourteen days, records created last week are still in flight and will look abandoned when they are not. It also has to be long enough to survive one absence and one campaign spike, because a single week is mostly noise. A workable starting template is one full quarter for the four counts and one recent full month for the detailed layer read, adjusted to your own cycle length rather than copied.

Exclusions are a documented count, not a cleanup. Test submissions, obvious spam, internal traffic and known partners all get removed, and each removal is recorded with its number and its rule. The sentence “we took out the junk” is where an audit stops being reproducible, and the size of the junk category is itself frequently a finding.

The reconciliation check: four counts that have to line up

This is the part almost nobody runs, and it is the part that catches leaks no layer owns. Four counts, one period, same channels in each.

A. Arrived. Requests that reached any channel edge: form submissions in the provider’s own log, inbound calls including missed and abandoned ones, chat conversations started, emails to the sales addresses, portal and marketplace notifications.

B. Created. Records that exist in the CRM for that period and those channels.

C. Owned. Of B, records with a named owner who is an active user and was not on leave for the whole window.

D. Worked. Of C, records with at least one logged outbound attempt inside the window your policy defines.

Count A is the hard one, and its difficulty is diagnostic in itself. If assembling “how many requests arrived last month” takes two days and five exports, you have already found a reporting layer problem before you have looked at a single record. Teams with a working Lead Hub get count A for free, which is most of the argument for having one.

Two traps will corrupt the reconciliation if you let them. First, decide whether you are counting events or people, write it down, and keep it consistent across all four counts. One buyer who calls, then submits a form, then messages on chat is three events and one person, and mixing the two conventions produces gaps that look like leaks and are arithmetic. Report both numbers if you can: the event count sizes the workload, the person count sizes the market. Second, deduplication legitimately reduces B below A, so quantify it separately instead of treating it as loss. A merge log with counts turns an unexplained gap into an explained one.

Anything still unexplained after those adjustments is the number to put at the top of the report. It is the only figure in the audit that no existing dashboard in the company produces.

How does the layer-by-layer diagnostic work?

Seven layers, in the order a request passes through them. For each one: the observable symptom, the confirming evidence from data you already hold, and the guide that owns the repair. Work them in order, because a finding at an early layer changes the denominator of every layer after it.

Capture and identity: did the request become a record at all?

Capture loss is the cheapest loss to find and the most expensive to leave. Nothing downstream can recover a request that exists only in a form provider’s log.

The inventory in row five is worth doing on its own even without an audit. Every published phone number, every form endpoint, every chat entry point and every email alias, listed against the source value it produces in the CRM. Anything on the list with no corresponding source value is an uncontrolled channel, and uncontrolled channels are where the largest single-cause leaks hide.

Identity loss is subtler because nothing disappears. The buyer exists, twice, and each copy holds half the history. Confirm it by normalizing keys in the export rather than in the CRM: lowercase emails, phones to one international format, company names stripped of legal suffixes. Then count exact duplicate keys inside the period, and separately count records created in the period whose key matches a record older than the period. That second number is returning buyers being treated as strangers, which is both a leak and an insult to the buyer.

If a rise in identity problems started on a specific date, look for a new landing page, a new integration or an import. Duplicates are almost always introduced by a change, not accumulated by drift.

Qualification and assignment: did anyone become responsible?

Qualification is audited as a record, not as a judgment. You are not asking whether the calls were graded correctly, you are asking whether a decision was made, when, and on what.

Definitions belong elsewhere: what counts as qualified lives in AI lead qualification, and the boundary where marketing hands to sales lives in the MQL to SQL handoff. The audit only establishes whether the decision was recorded at the moment it was supposedly made.

Assignment is where the sharpest single number in the whole audit lives: the count of records with no owner. The target is zero, there is no defensible reason for it to be anything else, and almost every team has a number above zero that nobody has looked at.

Salesforce documents lead assignment rules with ordered entries and a default owner for records that match nothing, which is a good reminder of what to look for during the audit: a working fallback. Check the current product behavior in the documentation rather than assuming it. Precedence, fallback queues and reassignment rules belong to the lead routing playbook.

A departure deserves its own check. When a rep leaves, their open records usually stay assigned to a disabled user and vanish from every list that filters by active owner. Run the ownerless count and the deactivated owner count as two separate numbers, because the second one hides inside a passing result for the first.

Response and follow-up: did the work actually happen?

Measure the first response from arrival time, not from record creation time. The difference between those two timestamps is your integration delay, and measuring from creation hides exactly the leak you are hunting. If arrival time is not stored on the record, that is a finding at the capture layer and it blocks a defensible response measurement until it is fixed.

Then refuse to look at the average. Report the full distribution and three numbers beside it: the share above your policy threshold, the count of records whose first attempt never happened at all, and the same two figures for after-hours arrivals separately. A healthy median coexists comfortably with a group nobody ever touched, and the untouched group is the actual loss.

The limbo count in row six is the most useful follow-up number that exists, and it takes one query. A record with no open task and no closed outcome is not being worked and is not being counted as lost. It is simply gone, while still appearing in the pipeline as if it were live. Teams that track nothing else from this guide should track that one number weekly.

Two honest caveats. Work that happens on a personal phone or a personal chat account is invisible to this measurement and will be reported as loss, so check whether your channel coverage is complete before accusing anyone. And a logged attempt is not proof of a real attempt, since a call logged with a three second duration is a click, not a conversation. Where the activity export carries durations, look at them.

Reporting and attribution: can you see any of this?

The reporting layer is audited last and fixed first in only one case: when nobody can agree on the numbers, every other finding will be disputed rather than acted on.

The cleanest test takes an hour. Pick one number that leadership sees weekly, then recompute it from raw exports without touching the dashboard. If the two disagree, find out why before anything else in the report is discussed. The usual causes are a filter nobody remembers, a date field that is not the one people assume, records excluded by an owner filter, or two definitions of the same word living in two tools.

Attribution problems and handling problems are easy to confuse. A channel that appears to produce nothing may be producing requests that are lost at capture, assigned to nobody, or attributed to direct after a redirect stripped the parameters. Do not cut a channel’s budget on audit evidence until the four counts for that channel specifically are clean.

Is it a leak or a capacity problem?

These two produce almost identical dashboards. Response times rise, follow-up thins out, untouched records accumulate. The difference is whether the work was physically possible, and you settle it with arithmetic rather than argument: for each rep, records assigned per working day and attempts logged per working day, across the period, using the roster for the denominator.

That last row is the reliable separator. Headcount has no effect whatsoever on whether an arriving request becomes a record, so any gap between counts A and B is a leak by definition, no matter how busy the team is. Run the reconciliation before anyone is allowed to say the word capacity.

The honest third answer is both, and it is common. A genuine capacity problem gives everyone a satisfying explanation, and under its cover the process problems stop being investigated. Report them separately: capacity findings go to a staffing or automation decision covered in AI SDR versus human SDR and inbound automation ROI, leak findings go to the layer owners.

How do you rank findings by cost instead of by ease?

The standard failure mode of a good audit: fourteen findings, the team fixes the three easiest, all three are in the reporting layer because reporting is the least disruptive thing to change, and a quarter later nothing has improved. Ranking by effort feels like momentum and reliably produces none.

Rank by cost. Cost here means affected volume, not money, and this guide will not convert one into the other. What you can compute from your own data is the number of records affected in the period, the layer at which they were lost, and whether they can still be contacted. Turning that into a revenue figure requires assumptions about close rates and deal values that the audit has not tested, and that calculation belongs to inbound automation ROI with its assumptions written down.

Do not build a weighted score out of those six. Sort by affected volume among findings that are standing, recoverable and well evidenced, break ties by evidence strength, and only then apply the practical filter: does this fix have a named owner, and can it ship this quarter. Findings that fail the practical filter stay on the list with a note, they do not get quietly reordered to the bottom.

One deliberate exception to volume ranking. A finding that makes other findings unmeasurable jumps the queue regardless of its own size. Missing arrival timestamps, an unwritten routing rule and a source field that gets overwritten are all in that category: until they are fixed, the next audit produces the same uncertainty as this one.

What does the audit output look like?

One table, one row per finding, and nothing else that matters. Adjectives, tool recommendations and named individuals as causes all belong outside the document.

A filled row reads like this, with placeholder figures standing in for your own counts rather than any real result: F3, capture layer. Requests arriving on the partner portal channel do not create records on days when the nightly sync fails. Evidence: portal export joined to CRM created dates by day, period April to June, script in the audit folder. Affected count: the daily gaps summed over the period, on an event basis. Recoverable: partly, contacts are still in the portal. Fix owner: named operations engineer. Owning guide: website lead capture. Status: open.

Close the document with a section titled what we could not measure. Channels with no exportable log, work done on personal devices, a period where the audit trail retention had already expired, records deleted before the export. That section prevents the report from claiming more certainty than it has, and it usually turns into next quarter’s instrumentation work.

Operator note. Circulating the findings table without a walkthrough is how audits die. The first reaction to a large capture finding is disbelief, and disbelief aimed at the numbers rather than the process buries the whole report. Present count A, count B and the join that produced the gap, in that order, and let people re-run it themselves. A finding somebody reproduced is a finding somebody will fix.

When is the diagnosis not a leak at all?

Sometimes the four counts line up, response times sit inside the policy, follow-up completes, and revenue is still short. That is a real and valuable result. It means the problem is upstream of handling, and the audit has just eliminated the most expensive assumption in the business.

The fastest single test is the loss reason distribution. If the leading reason is no response from the client or could not reach, the diagnosis is handling and this guide applies. If the leading reasons are price, timing or wrong fit, more speed will not help, and rebuilding the routing rules is expensive theater. This only works if loss reasons come from a controlled list; free text loss reasons tell you nothing, which is itself a finding for CRM automation.

How do you run this as a recurring review?

The first audit is expensive because you are building the evidence pipeline, not because the analysis is hard. Keep every export as a saved query, and the second one is a reading rather than a project.

The on-change row earns its place. Most leaks are introduced rather than inherited: a new landing page pointing at a different endpoint, a routing rule edited to cover a holiday and never reverted, a rep leaving with open records, a CRM field renamed, a chat widget swapped. Tie a short re-run to each of those events and the quarterly audit stops finding month old problems.

Verification is not optional and is usually skipped. A fix is closed when the same query returns a different number over a later period, not when someone says the change shipped. Keep the original query, run it again, record both numbers in the findings row.

Give the audit one named owner. In small teams that is whoever runs operations, in larger ones it is a defined function, and the boundary between that function and revenue operations is drawn in lead ops versus RevOps.

What to fix first, and where each fix lives?

Fix in layer order, not in severity order, with one exception: anything that makes other findings unmeasurable goes first. After that, capture before ownership, ownership before clocks, clocks before follow-up, follow-up before reporting polish. The logic is arithmetic. Improving follow-up on records that were never created changes nothing, and every downstream percentage is computed against a denominator the capture layer defines.

1. Instrumentation. Arrival timestamps, a source value per channel, a failure queue somebody reads, and the routing and response rules written down.
2. Capture. Close the gap between counts A and B, channel by channel, starting with the largest. Owned by website lead capture.
3. Identity. Deduplicate before assignment so ownership and history stop splitting. Owned by CRM automation for inbound.
4. Ownership. Drive the ownerless count to zero and add a fallback for every rule. Owned by the lead routing playbook.
5. Response. Start the clock at arrival and act on the tail, not the median. Owned by SLA and speed to lead.
6. Follow-up. Eliminate the limbo count: no record without either an open task or a closed outcome. Owned by the lead follow-up system.
7. Reporting. Publish the four counts as a standing report so the next audit is a reading. Owned by inbound lead reporting.
8. Re-measure. Re-run every query behind a closed finding on a later period and record the new number.

If several layers fail at once, the underlying question is architectural rather than a sequence of repairs, and Lead Hub versus CRM is where that boundary gets decided. The full module map sits in the lead ops stack, the interactive version of the same flow is on the OperStack home page, and scope options are on the pricing page.

Run it yourself first. The method above uses nothing you do not already have, and a team that produces its own four counts argues about fixes instead of about whether there is a problem. If assembling count A is the part that stalls you, a lead operations audit returns the four counts and the ranked findings table built from your own exports, with the queries handed over so you can re-run them next quarter without us. The same reconciliation, run by us against your export, is the free AI readiness assessment.