B2B CRM handoff QA checklist before launch

A B2B website launch is not finished when the contact form submits. The real workflow starts after the visitor clicks send: the lead should enter the CRM, keep its source context, route to the right owner, trigger the right notification, respect consent rules, and show up in reporting without manual cleanup.

This checklist is for B2B website redesigns, service pages, pricing pages, gated content, partner inquiry flows, and maintenance work where website leads move into HubSpot, Salesforce, Pipedrive, Zoho, Airtable, or a custom CRM. Run it before launch, after any form rebuild, and whenever routing, attribution, or sales ownership changes.

Do not start QA by sending a random test form. First define the lead states the business actually cares about. A demo request, quote request, enterprise inquiry, partner request, job application, support ticket, and spam submission should not all land in the same place with the same urgency.

Write a small qualification matrix before testing. It should list the form, audience, expected lifecycle stage, deal or pipeline rule, owner rule, notification rule, SLA, and fallback owner. That matrix becomes the source of truth when one test lead lands in the wrong queue.

• Separate sales-ready inquiries from newsletter signups, support requests, vendor messages, careers submissions, and low-intent content downloads.
• Define what fields change priority: company size, region, budget, service need, product interest, existing customer status, or requested timeline.
• Decide whether incomplete submissions should create leads, tasks, support tickets, or only analytics events.
• Name the person who can approve routing rules when sales, marketing, and operations disagree.

A CRM handoff often breaks because the visible form is tested but the hidden fields are not. Name, email, company, phone, message, and service interest are only the obvious fields. Hidden fields may carry page path, campaign source, language, region, consent, product interest, referrer, experiment variant, and spam score.

Build a field map with one row per website field. Include the field label, input type, validation rule, CRM property, required status, fallback value, owner, and whether the value is visible to sales. If a field is calculated or added by middleware, mark where that transformation happens.

• Check required fields, optional fields, hidden fields, calculated fields, select values, checkboxes, file uploads, and multi-step form state.
• Confirm select values match CRM option values exactly, including capitalization, punctuation, language, and archived options.
• Test long company names, non-English names, accented characters, phone formats, free email domains, and empty optional fields.
• Make sure error states are useful when the CRM rejects a value instead of only showing a generic website error.

A B2B team can lose a lot of signal if attribution is stripped during the handoff. The CRM should keep the source that marketing needs and the context sales needs. That usually means UTMs, landing page, conversion page, referrer, first-touch source, last-touch source, content offer, and sometimes language or market.

Create a test lead set for each important traffic path. Submit from direct traffic, paid campaign URLs, organic landing pages, partner referral links, email links, social links, and multilingual routes if they exist. Then compare the CRM record with analytics and the form payload.

• Test UTM source, medium, campaign, term, content, landing page, referrer, conversion page, and timestamp.
• Confirm attribution survives consent banners, redirects, canonical URLs, URL cleanup, multi-step forms, embedded forms, and page reloads.
• Check whether first-touch fields should remain locked while last-touch fields update on later submissions.
• Validate that internal staff tests, spam, and staging submissions can be excluded from campaign reporting.

Routing is where a working form can still fail the business. A lead may be created correctly but assigned to the wrong territory, sent to a former employee, skipped by a round-robin rule, or delayed because the notification depends on a field that changed name during the redesign.

Test the routing matrix with realistic sample leads. Use different services, regions, company sizes, languages, partner types, and existing customer states. Then check the CRM owner, team queue, task creation, email or Slack notification, confirmation email, and sales SLA timestamp.

• Verify owner assignment by region, service, account status, deal size, language, product interest, and fallback rule.
• Check notifications for sales, marketing, support, partners, and the submitter when each one is expected.
• Confirm unavailable users, deactivated accounts, holidays, and empty round-robin pools have a fallback.
• Time the full path from website submit to CRM record, notification, task, and report update.

Consent should be tested as part of the CRM handoff, not as a separate legal afterthought. A lead can enter the CRM while marketing subscription, privacy consent, data processing basis, region, language, and retention rules are wrong. That creates operational risk and makes later segmentation unreliable.

Test consent combinations the same way a real visitor would experience them. Submit with newsletter opt-in, without newsletter opt-in, from different regions, with different language routes, and after changing cookie consent. Then verify the CRM fields, list membership, workflow triggers, and confirmation copy.

• Confirm required consent copy, optional marketing opt-in, privacy policy links, and region-specific fields appear where needed.
• Verify consent timestamp, consent source, form name, page URL, locale, IP or region rule, and subscription status in the CRM.
• Make sure a sales inquiry does not automatically create a marketing subscription unless the user opted in.
• Document who owns future changes to consent text, legal links, CRM properties, and subscription workflows.

Duplicate logic is easy to ignore until launch traffic starts. A returning prospect may submit a pricing form after downloading a guide. An existing customer may request support through a sales page. A partner may use a personal email first and a company email later. The CRM needs rules for those cases.

Run tests against new contacts, existing contacts, existing companies, open deals, closed customers, disqualified leads, and unsubscribed contacts. Check whether the CRM should update a record, create a new deal, add an activity, create a task, reopen a lead, or block the submission.

• Test duplicate email, duplicate company domain, alternate email, existing customer, partner, competitor, and blocked domain cases.
• Check whether lifecycle stage updates are allowed to move forward, move backward, or stay locked.
• Verify that repeated submissions append form activity and message history instead of overwriting useful context.
• Confirm retry behavior when the CRM API is down, rate-limited, or partially accepts a submission.

The final QA step should happen with the people who will use the leads. Ask sales to open the record, understand the context, prioritize the inquiry, and take the first action. If they need to ask where the lead came from, what the person wants, or what should happen next, the handoff is not complete.

Then check reporting. A launch can look successful in the CRM while analytics, dashboards, campaign reports, and pipeline reports disagree. Compare a known test lead set across the website, analytics, CRM, notification logs, and sales dashboard.

• Confirm sales can see source, page, message, service interest, company, region, consent, and recommended next action.
• Check dashboards for lead count, qualified lead count, conversion source, service interest, owner, SLA, and pipeline value.
• Create a saved test view or report that launch owners can use during the first week.
• Decide how to label and remove test leads after QA without breaking attribution reports.