Sales and marketing handoffs in manufacturing can fail quietly. A campaign produces a form submission, a salesperson receives a record without plant, role, project, or timing context, and the resulting rejection is later described as “poor lead quality.” The actual defect may be a missing field, a routing rule, a duplicate, or an owner who never saw the alert.
This checklist is for marketing operations, sales operations, demand teams, plant or industry specialists, and leaders responsible for the handoff. It tests the system with evidence. It does not define a universal lead score, claim that a manufacturing inquiry is qualified, or replace privacy, accessibility, or contractual review.
Define the handoff contract
Write the exact transition being tested: from which marketing state to which sales state, for which offer, buyer group, geography, and response path. “Lead sent to sales” is incomplete if the receiving team uses another definition of accepted work.
The contract should state minimum fields, source context, consent or permission state where relevant, routing owner, response expectation, rejection reasons, escalation route, and the system of record. Keep unknown separate from rejected. Missing evidence is a defect to investigate, not a reason to invent a status.
Build a test matrix
Use synthetic or safely bounded records to cover ordinary and difficult paths:
| Case | Input condition | Expected result | Evidence | | — | — | — | — | | Complete inquiry | required fields and valid route | record created and assigned | event, CRM ID, owner | | Missing field | required context absent | held or rejected with reason | validation log | | Duplicate | same contact or account signal | deduplicated or linked | duplicate rule result | | Out of scope | service or geography excluded | safe redirect or reason code | disposition | | Urgent route | agreed urgency signal | correct priority and owner | timestamp and audit trail | | Correction | source value updated | downstream record corrected | before/after trace | | No response | owner or capacity unavailable | escalation or queue state | alert and exception log |
Do not use real customer or employee data merely to make a test look realistic. A synthetic record should exercise the logic, not reproduce a person.
Gate 1: capture and validation
Confirm that the form, landing page, event, or import accepts the intended fields and rejects invalid values. Check labels, required-state messaging, error recovery, keyboard use, and the path a user follows after submission.
The W3C WCAG overview is a technical reference for headings, labels, focus, contrast, and accessible error handling. It is not a jurisdiction-specific legal opinion. Accessibility belongs in handoff QA because a submission that cannot be completed is not a reliable input.
Record field definitions, source identifiers, timestamp, version, and expected destination. If a field is collected but nobody uses it in qualification or routing, question whether it belongs in the contract.
Gate 2: identity and source trace
Verify that a new record receives a stable identifier, source and campaign context, creation time, and a trace to the originating interaction. Test what happens when the same person uses another device, submits twice, or appears under a known account.
For event names and parameters, the GA4 events reference can help document a platform-neutral event contract. It does not prove that the handoff is complete or that the lead is valuable.
A QA record should show the event, CRM record, routing result, and correction path. Do not infer a successful handoff from a dashboard total alone.
Gate 3: routing and ownership
Test assignment by geography, product, industry, account, language, urgency, and exception. Manufacturing organisations often have specialist or regional owners; the rule must say what happens when two rules match or no rule matches.
Use a visible queue for unassigned records. Confirm that the alert reaches the owner, that an owner can acknowledge it, and that escalation is triggered when the expected response does not occur. Do not hide a failed assignment inside a general “unqualified” bucket.
Gate 4: sales acceptance
Define the evidence required for sales acceptance. It may include an in-scope company, a relevant role or buying influence, a problem the offer addresses, a reachable route, and a next action. The exact contract belongs to the company; do not copy a generic score.
Use mutually understandable disposition reasons: duplicate, out of scope, no current project, wrong role, unreachable, existing relationship, or needs another service. A free-text note can supplement the reason but should not replace it.
The GOV.UK Service Standard offers useful prompts about user needs, joined ownership, measurable behaviour, and reliable service delivery. It is a process reference, not a manufacturing lead-qualification standard.
Gate 5: data quality and correction
Check that values are complete, valid, current enough for the decision, and corrected consistently downstream. Record the source, definition, date, limitation, and owner for every field that affects acceptance or routing.
The NIST Information Quality Standards can structure questions about context, reliability, utility, and correction history. It does not turn a handoff into a performance benchmark.
If a CRM field is redefined, version the rule and identify the affected records. Do not overwrite the past without an audit note. A clean-looking report with no correction trail is a QA failure.
Rate defects by consequence
Use severity that reflects harm to the process:
| Severity | Example | Release treatment | | — | — | — | | Blocker | record routed to the wrong organisation or sensitive field exposed | stop release and contain | | High | accepted record disappears or no owner is notified | fix before release | | Medium | source context missing but record remains recoverable | owner and deadline required | | Low | label or non-critical note unclear | schedule correction |
Attach reproduction steps, expected result, actual result, evidence, owner, and retest date. Do not lower severity to meet a release date.
Gate 6: privacy and access
Handoff systems can contain contact, account, operational, and commercial information. Define purpose, access, retention, correction, deletion, and suppression. The NIST Privacy Framework can structure the review; it is not authorisation for a new data flow.
Check role-based views, exports, alert content, shared inboxes, and copies created by integrations. A record should be removable from a route without leaving uncontrolled duplicates in another system.
Gate 7: claims and messages
Manufacturing marketing may mention safety, performance, efficiency, production, or business outcomes. Confirm that the handoff does not convert an unverified marketing statement into a sales promise. Route claims through the appropriate technical, contractual, and legal review; the checklist records the gate but does not replace that review.
Keep approved claims, source dates, and prohibited promises visible to the receiving team. If the message is too broad to support, repair the message before optimising the route.
Gate 8: reporting and reconciliation
Reconcile a bounded sample from capture through assignment, response, acceptance, and next action. Keep platform events, CRM states, sales dispositions, and commercial outcomes in separate columns. A count of forms is not a count of accepted opportunities.
Ask what changed, which records are missing, what the denominator is, and whether any definition or routing rule changed during the test. The reviewer should be able to reproduce the conclusion from the evidence log.
Make the release decision
Release only when blocker and high defects are closed, medium defects have owners and dates, synthetic cases pass, privacy and claims holds are acknowledged, and rollback is tested. The release record should include version, scope, sample, defects, decision owner, monitoring window, and stop rule.
If evidence is incomplete, release a narrower route or hold the change. “No error found” is not proof that a path was tested.
Roll back safely
Pause the handoff when wrong-owner routing, duplicate creation, missing consent, unsafe access, silent field changes, or unowned queues appear. Restore the last known-good rule, preserve affected records for controlled review, notify owners, and document the exposure.
Do not delete rejected records or rewrite disposition history to improve the acceptance rate. A defect record is part of the evidence needed to prevent recurrence.
Run the first QA cycle
Choose one offer and one manufacturing segment. Create seven synthetic cases, trace each through the contract, record defects by severity, and run a retest after corrections. Hold a release review with marketing, sales, operations, and the data/privacy owner.
The practical output is a handoff QA checklist with acceptance criteria, test cases, defect severity, evidence, owners, release gates, and rollback. A publication gate should later verify live overlap, canonical intent, links, source freshness, language, privacy, claims, accessibility, and implementation. Keep this local noindex draft separate from an operational guarantee.
How did this article land?
Choose one reaction. You can change it anytime.