The handoff is where the engine leaks

In brief: A campaign can bring in the right enquiry and still leave sales without what they need to follow up. Check what arrives, when it becomes usable and who deals with anything missing before changing the campaign.

Where do B2B SaaS acquisition engines leak between ads, forms and CRM? At the interfaces. Click IDs drop between form and analytics. Offline conversion feedback arrives too late for the platform import window. Routing SLAs start before the record becomes visible. The leak sits between two systems that both report success.

Before I change a campaign that’s bringing in enquiries but little pipeline, I want to see what happened to those enquiries.

The form might be working and the record might be in the CRM. But the person expected to follow up could still be missing the reason somebody got in touch, or may not have seen the record at all.

So I follow a few enquiries through the process. I check what was saved, who could use it and how long the buyer waited. That helps me separate a campaign problem from something that went wrong after the enquiry came in.

I covered the form and tracking work in Most tracking problems are form problems. This is what I check after that, as the information moves between systems and people.

The same check applies earlier too, when buyer research becomes a campaign brief or that brief becomes an ad. I want to know whether the next person has what they need to do the work.

Stage failure vs handoff failure

A stage failure happens within one part of the engine: a campaign reaches the wrong audience, or a scoring model qualifies unsuitable accounts. A handoff failure happens when one stage’s output doesn’t meet the next stage’s needs, and neither stage looks broken from the inside.

Both sides of a failed handoff usually report success, because each one records it at a different point.

Google’s GA4 Measurement Protocol, which accepts events sent directly to Analytics, returns an HTTP success response when it receives a request. That response can still accompany malformed data or an event that isn’t processed.¹ A sending integration that counts successful requests has therefore measured something different from usable events in Analytics.

The same distinction applies to a lead assigned to a queue. A recorded assignment doesn’t establish that the intended seller can see the record, understands the reason for contact, or has acted on it.

What the next stage needs to receive

I write down what the next person or system needs, what counts as received, and who handles anything missing. That’s the handoff contract. The thing being passed might be a campaign brief, a qualified record or a conversion event.

I write it from the receiving side. These are the questions I want answered:

Two enquiries from the same person can update one contact. That doesn’t mean an enquiry was lost. Submissions, contacts and opportunities are three different units, and comparing their totals without preserving the relationships between them can manufacture an apparent loss.

The acceptance condition also needs to be specific. For a demo request, I might require a saved CRM record with the request attached and an owner who can access it. The subsequent response has a separate deadline. An email saying the integration ran satisfies neither condition.

Five handoffs I’d check

Positioning to campaign

The buying situation is usually the first thing to fall out of a positioning decision on its way to an ad. A brief keeps the broad benefit and drops the situation that made it land, and the ad that follows is faithful to the brief’s wording while speaking to a different audience.

So I want the campaign brief to preserve the intended buyer, the situation that creates demand, the alternative they use today, and the evidence behind the proposed claim. The voice-of-customer positioning guide covers how that research gets done. The job at this point is to carry its findings into something a campaign owner can use.

April Dunford separates the positioning record from the messaging developed from it, and recommends dating that record so the last review is visible.² That distinction gives me two artefacts to compare.

I take the highest-spend live ads and trace each central claim back to the brief and its supporting customer evidence. I also check the landing page against the same buying situation. If the ad makes a promise the page cannot support, the translation needs attention before another creative test.

The contract preserves the audience and the basis for the claim while leaving room for creative judgement. A headline needn’t repeat an interview quotation to address the buying situation it describes. I’d keep the links to evidence beside the brief so a new writer can follow the reasoning.

CRM outcomes back to advertising

The outcome most worth feeding back to a campaign is usually the one furthest down the funnel. It’s also the one most likely to arrive too late for the platform to accept it.

As at September 2026, Google’s guidance says standard offline conversions uploaded more than 90 days after the associated last click won’t be imported. Enhanced conversions for leads has a 63-day limit after that click.³ Those are different limits, and the time spent waiting for the deal to progress consumes the same interval as the export delay.

I’d compare the actual distribution of click-to-stage times with the limit for the import method in use, then include the delay between reaching the stage and uploading it. If closed-won outcomes arrive too late, an earlier meaningful stage may be a better candidate for bidding feedback. Which stage deserves that role needs checking against the company’s own outcomes. The demand-generation guide covers how I choose between them. The only question now is whether the chosen outcome can arrive while the platform can still use it.

The contract names the CRM transition, conversion action, matching identifier, occurrence time and upload deadline. It also names the campaign goal that uses it. Google’s primary actions within selected standard goals are used for bidding; secondary actions normally serve observation, with custom goals as the documented exception.⁴

For a sample of eligible outcomes, I check the destination diagnostics and goal settings after delivery. Seeing a conversion in a report doesn’t, by itself, establish that it is the signal guiding the campaign.

Qualification to sales follow-up

Sales needs to know why the person qualified when they were assigned. The current score may already have changed.

So the receiving record should carry the qualification reason, the fit and engagement scores it held at that moment, the evidence behind them, the relevant account, the requested next action and the original timestamp. The scoring and lifecycle guide covers why I keep fit and engagement apart, and both need to travel with the record. In a simple sales process, person-level qualification can be enough to trigger follow-up. The seller still needs to establish whether there is an opportunity.

GitLab’s published response timer for a marketing-qualified lead (MQL) begins when a record is both qualified and assigned. Specified status changes stop it, and working hours and timezone settings affect the reported duration.⁵ That illustrates why a response target needs start and stop conditions before its results are interpretable.

I’d keep both timings: from the buyer’s enquiry to the response, and from assignment to the owner’s first action. Otherwise a record can wait unassigned, or move between owners, while the reported service target looks satisfactory.

My check follows a sample through assignment, visibility, acknowledgement and actual activity. I also read the return information to see whether rejection reasons separate an unsuitable account, an existing opportunity, poor timing and inability to reach the person. “No response” describes contact attempts; it doesn’t establish poor fit. I’d also check whether late handling or a routing mistake contributed before using the rejection to change qualification rules.

Form submission to CRM and analytics

After the browser work is fixed, there are still several receipts to distinguish: the submission was accepted, a record was saved, the record became available to its owner, and an analytics destination processed its event.

The Measurement Protocol behaviour above is one reason I wouldn’t accept a successful network response as the final check. Google provides a separate validation endpoint for inspecting events, and events sent there do not appear in reports.⁶ Validation and production receipt need separate evidence.

The contract should connect the accepted submission to the saved CRM record and to any permitted measurement events, while keeping their identifiers and purposes distinct. It should also explain what happens when the CRM is unavailable and how a retry is recognised.

The shared ID I described in the forms guide also needs to reach the fields each platform expects. LinkedIn deduplicates across sources only when the same eventId arrives on the Insight Tag event and the Conversions API event in the same account, and it then discards the Conversions API event and counts the Insight Tag one.⁷ The event_id in that dataLayer push is an internal identifier. It does nothing here until both delivery paths carry its value into the fields LinkedIn expects.

I’d test a new contact, an existing contact, a repeated legitimate enquiry and a retry after a timeout. The retry should preserve the identity of the original submission; a later genuine enquiry needs its own identity even if it updates the same contact.

Marketing automation to CRM

A connected status doesn’t describe what happens when two systems write to the same field.

HubSpot documents that its two-way Salesforce mapping uses the most recent value and propagates deletions in either direction. It also says that adding a mapping doesn’t retrospectively sync existing values.⁸ A field can therefore be mapped correctly today while older records remain incomplete.

Timing creates another source of mistaken assumptions. Adobe documents a five-minute pause after each Marketo-to-Salesforce sync cycle.⁹ That describes a pause between cycles; it gives no end-to-end promise that every change will become available within five minutes.

GitLab documents what an interval like that can do to a qualification. When RingLead merges duplicate records in Salesforce, the activity on both records combines and the person’s score rises, which can trigger the MQL stamp campaign in Marketo before the merge timestamp has synced across from Salesforce. GitLab puts that Salesforce-to-Marketo latency at around five minutes, longer during backlogs, against a two-minute wait step in the campaign. The stamp therefore fires before the rescoring automation can correct the score, and the false qualifications have to be reversed by hand. The response-time data on those records can’t be removed at all, only excluded from a report.¹⁰ Database maintenance ends up looking like fresh buyer interest.

For fields that drive routing or qualification, I write down every permitted writer, the rule for conflicting values, blank and deletion behaviour, and whether historical records need updating. If enrichment contributes a value, I also want its source, observation date and an explicit unknown state when there is no match.

My check includes a new record, a populated existing record, a cleared value and competing updates, along with the merges, imports and enrichment jobs that run on a schedule. I then inspect the resulting field history and any automation it triggered. A merge or an import can change a commercial decision even though no buyer did anything new.

Times to separate

Several failures survive a technically valid transfer. A status can retain its spelling while its qualification criteria change. A writer can replace a value that another process treated as verified. A rejected record can disappear from the view used to count successful deliveries.

Every move from customer evidence to brief, brief to ad, or CRM stage to conversion action asks someone to preserve a meaning in a different format. I keep the source definition attached wherever that translation affects a decision.

I also separate these four times for every handoff:

• Occurrence time: when the buyer did something
• Saved-record time: when the system recorded it
• Availability to receiver: when the next person or system could act on it
• Action time: when the next action actually happened

A single “synced at” field cannot explain where a buyer waited. Alongside completed-item timings, I look at the oldest unresolved record, which completed-item averages leave out entirely.

Where I start

I begin with checks that use existing records and configuration, then add monitoring once I know what it needs to detect.

1. Compare definitions separately. Ask the campaign, operations and sales owners what makes a record qualified, what they receive, and when their responsibility starts. Compare those answers with the live rules. Disagreement gives the record inspection a specific question.
2. Inspect important fields over time. Check the daily proportion populated for the identifiers, qualification reasons, owners and timestamps that affect the next action. Compare abrupt changes with releases and imports. Sample populated values too, because completeness doesn’t establish correctness.
3. Reconcile the same set of records across a boundary. Start with identified submissions or transitions and classify each as accepted, pending, rejected or deliberately excluded. Preserve links through merges and allow for the agreed processing delay. Comparing yesterday’s submissions with yesterday’s new contacts alone will miss those distinctions.
4. Trace outcomes backwards. Follow a small sample of won, lost and unworked records to the original request and campaign. Inspect the timestamps and decision context at each transfer. Starting only with won deals would exclude the records that never reached sales.
5. Exercise the path and inspect its exceptions. Add a clearly marked synthetic enquiry to check technical delivery, keeping test data out of commercial reports and bidding. Read the existing sync errors, import diagnostics and unresolved retries as part of the same check.

A synthetic enquiry helps detect a broken delivery path. It cannot establish that the meaning of “qualified” stayed consistent across real records, or that all segments receive the same treatment. I keep real-record reconciliation alongside it.

When the symptom is disagreement between reports, I use the analytics and attribution guide to establish what each view is measuring. I use CRM stages and amounts for recorded pipeline and revenue, while still checking associations and definitions. The aim is an explained difference on a known basis, rather than forcing every total to match.

Start with one handoff

I wouldn’t document every field. With one form and a queue somebody checks, missing records may already be easy to spot, and writing down every property would create maintenance work without changing how anyone handles an enquiry. A neglected register could also give false reassurance after the system changes.

So I’d start with the information that determines buyer treatment, identity, suppression, money or reporting. One maintained document and a view of unresolved records may be enough. Each row should answer a question someone needs when operating or changing the system.

That document has to travel with the change. If the qualification criteria are revised, the routing filters, conversion mapping and reporting interpretation need reviewing at the same time. Recording the effective date lets someone later distinguish a real performance change from a changed definition.

I want a clear way to tell when the next person or system has received what it needs. My default is that the sending owner retains responsibility for delivery and unresolved rejection until the receiving side’s acceptance condition is met. After acceptance, the receiving owner is responsible for the next action and its deadline.

That still requires a person to review the exception view. Shared ownership is workable when it names who checks today’s failures, who can repair them, and who covers an absence. Without that detail, a record can remain between two otherwise well-run stages.

The handoff I’d document first is the one whose failed records currently have no reviewer. Write down the artefact being passed, the evidence of acceptance, the allowed delay and the person responsible while it waits. Then attach a real unresolved record and follow it until somebody can use it.

Frequently asked questions

Where do B2B SaaS acquisition engines leak between ads, forms and CRM?

At the interfaces between systems. Click IDs drop between form and analytics. Offline conversion feedback arrives too late for platform import windows. Routing SLAs start before the record becomes visible. Both sides of a failed handoff usually report success because each records it at a different point.

What is a handoff contract?

A written record of what the next person or system needs: the meaning and identity of what’s being passed, the required content, the acceptance condition, who owns delivery and next action, how failures are handled, and how the definition is verified and changed.

How is a handoff failure different from a campaign or stage failure?

A stage failure happens within one part of the engine—a campaign reaches the wrong audience, or scoring qualifies unsuitable accounts. A handoff failure happens when one stage’s output doesn’t meet the next stage’s needs, and neither stage looks broken from the inside.

Why do offline conversions miss the Google import window?

Standard offline conversions uploaded more than 90 days after the associated last click won’t be imported. Enhanced conversions for leads has a 63-day limit. The time spent waiting for a deal to progress consumes the same interval as any export delay.

What should travel with an MQL to sales?

The qualification reason, the fit and engagement scores at the moment of assignment, the evidence behind them, the relevant account, the requested next action and the original timestamp. The current score may already have changed by the time a seller sees the record.

---

I’m usually engaged with client work, but I take on a small number of growth-stage B2B SaaS projects each year. If the engine between marketing and sales isn’t producing the outcomes you expect, tell me what you’re building.

Sources

1. Google for Developers, “Measurement Protocol reference,” transport behaviour. developers.google.com (opens in new tab) ↩

2. April Dunford, “A Product Positioning Exercise,” October 2019. aprildunford.com (opens in new tab) ↩

3. Google Ads Help, “Guidelines for importing offline conversions,” upload timing. support.google.com (opens in new tab) ↩

4. Google Ads Help, “About primary and secondary conversion actions.” support.google.com (opens in new tab) ↩

5. GitLab Handbook, “MQL SLAs,” timer conditions and business-hours reporting. handbook.gitlab.com (opens in new tab) ↩

6. Google for Developers, “Validate events,” Measurement Protocol validation server. developers.google.com (opens in new tab) ↩

7. LinkedIn, “Deduplication,” Insight Tag and Conversions API. learn.microsoft.com (opens in new tab) ↩

8. HubSpot, “Map HubSpot properties to Salesforce fields,” sync rules and existing values. knowledge.hubspot.com (opens in new tab) ↩

9. Adobe Marketo Engage, “Understanding the Salesforce Sync.” experienceleague.adobe.com (opens in new tab) ↩

10. GitLab Handbook, “Ringlead,” section on merge timing and false MQL stamps. handbook.gitlab.com (opens in new tab) ↩