When form submissions and CRM lead counts disagree, the missing number may represent loss, delay, rejection, deduplication or a reporting definition—not one broken sales team.
The fastest diagnosis is a checkpoint ledger. Give one test submission a privacy-safe trace identifier, record when it crosses each system boundary and reconcile counts for a fixed window. Do this before changing lead scores or asking representatives to respond faster; a process cannot work a record it never received or owned.
Define the same population in every system
Choose one form, environment, time zone and timestamp rule. Exclude internal tests consistently or label them explicitly. Decide whether the source count means button clicks, validated submissions or server acknowledgements. A front-end event can fire even when validation or network delivery later fails, so it cannot automatically serve as the CRM denominator.
Build checkpoints from submit to ownership
Record validated submit, server receipt, integration acceptance, CRM create-or-update result, deduplication decision, queue or owner assignment and first human action. Each checkpoint needs a count, timestamp and error destination. Use opaque trace IDs rather than placing email addresses or other personal data in logs.
Separate missing, delayed and merged
A record may arrive after the reporting cutoff, update an existing contact, enter a rejected queue or be quarantined by spam rules. Reconcile individual test traces and aggregate counts. If the CRM uses assignment rules, inspect unmatched conditions and default queues. Salesforce documentation treats fields, queues, capture and assignment as distinct configuration layers; the audit should do the same.
Repair the control, then replay safely
Fix the narrowest failed boundary and test again with a labelled record. Replaying historical submissions can create duplicates or unwanted outreach, so define the recovery population, deduplication key and owner before reprocessing. Monitor both delivery rate and time-to-assignment after the change; a pipeline that eventually arrives may still violate the team's operating target.
Lead checkpoint ledger
| Checkpoint | Evidence | Failure class |
|---|---|---|
| Validated submit | Server acknowledgement and trace ID | Client validation or request loss |
| Integration accepted | Provider receipt and response | Authentication, schema or rate limit |
| CRM result | Created, updated, rejected or merged | Mapping and deduplication |
| Owner assigned | Queue/user plus timestamp | Routing rule or capacity |
One-hour audit setup
- Freeze one time window and time zone.
- Create privacy-safe test trace IDs.
- Count every boundary with the same inclusion rule.
- Inspect rejects, merges and default queues.
- Define safe replay before recovering records.
Lead leakage becomes manageable when “missing” is replaced with a named boundary and observed result. The ledger turns blame into a reproducible operations problem.
