The 80% Drop

Decision snapshot.

The metric said demand collapsed. The traffic did not.

After a significant CRM migration, reported inbound form submissions dropped sharply. Historically, the business saw a steady stream of leads. The new reporting suggested that demand had nearly disappeared.

But website traffic did not show a comparable collapse. That mismatch changed the starting assumption. The safest question was not “why did customers stop converting?” It was “where did the end-to-end customer path stop being observable?”

I split one symptom into four layers.

1. Capture

Can the user actually see and submit the form? Does dynamically loading it change the behaviour? Does the browser show a request, error or blocked response? Do different form patterns behave differently?

2. Consent

Are tracking and consent capabilities enabled and aligned to the intended marketing use cases? Is behavioural visibility available under the expected consent states?

3. Identity

Once captured, can the record resolve to the intended person or account? Are the required source objects, fields and relationships actually available for the desired segmentation and reporting?

4. Attribution

Even if a lead exists, can marketing connect it back to the form, landing page, campaign or flow that generated it?

Then we found a concrete breakpoint at the system boundary.

Some forms worked when rendered as simple standalone embeds, but became slow or unpredictable when loaded dynamically inside the website experience. The implementation crossed browser JavaScript, iframe behaviour, CORS and Salesforce form technology, with different teams owning different parts of the chain.

That made the troubleshooting approach more important than the product label. We reproduced the failure, separated page behaviour from platform behaviour and translated the evidence into specific actions for the web and Salesforce teams.

For the unstable embedded experiences, the team moved toward a visitor-facing external form connected through Salesforce Form Handler, with explicit field names, conditional logic, hidden values, staging and end-to-end testing defined before production.

The visible form problem was real, but it was not the whole problem.

The broader audit surfaced gaps across capture, consent, identity, attribution and operations. Fixing only the JavaScript / embedded form issue would have improved one breakpoint while leaving the organization unable to fully trust the customer data chain.

The answer was sequencing, not one giant rebuild.

I recommended restoring trust in dependency order so each phase created evidence for the next.

Attribution is useless if capture is unreliable. Segmentation is risky if identity is unresolved. A polished dashboard is dangerous if the underlying event chain is not trustworthy.

The work moved through specialists. My job was to keep the handoffs intact.

I did not need to own every line of production code to own delivery. I needed to make sure the context, evidence, decision and acceptance criteria survived each handoff.

Rollout was part of the recommendation.

The proposed rollout starts with a controlled form set and known test records. Client and operating teams need expected behavior, documentation, monitoring and an escalation owner before the pattern expands.

Submission volumes, support issues and stakeholder feedback would then be compared with the baseline. This is a rollout and validation approach, not evidence that every phase was completed.

The output was a proof plan.

For each known test record, check browser acceptance, the created or updated record, conditional and hidden values, consent, intended identity, campaign attribution and the corresponding report. Include opt-outs and other negative cases.

No quantified recovery is claimed in this public composite.

What I would do differently before the next migration.

I would define the observability baseline before migration begins: expected form volumes, canonical test records, known page behaviours, source-to-report lineage, named owners for every system boundary and an explicit enablement / adoption plan for the teams who will operate the new process.