B2B CRM 交接上线前 QA 检查清单

B2B 网站上线，不是联系表单能提交就结束。真正的流程从访客点击发送后才开始：线索应该进入 CRM，保留来源上下文，分配给正确负责人，触发正确通知，遵守同意与隐私规则，并且不用人工清理就能进入报表。

这份清单适合 B2B 网站改版、服务页、价格页、资料下载、合作伙伴询盘流程，以及任何把网站线索同步到 HubSpot、Salesforce、Pipedrive、Zoho、Airtable 或自建 CRM 的维护工作。上线前、表单重做后、路由或归因规则变化后，都应该跑一遍。

不要一上来就随便提交一个测试表单。先定义业务真正关心的线索状态。演示申请、报价咨询、企业询盘、合作伙伴申请、求职、支持工单和垃圾提交，不应该都进入同一个地方，也不应该有同样的处理优先级。

测试前先写一张小型资格矩阵。字段包括表单、受众、预期生命周期阶段、商机或管道规则、负责人规则、通知规则、SLA 和兜底负责人。当某条测试线索进入了错误队列，这张表就是判断依据。

• 区分销售就绪询盘、订阅注册、支持请求、供应商消息、招聘提交和低意向资料下载。
• 定义哪些字段会影响优先级：公司规模、地区、预算、服务需求、产品兴趣、现有客户状态或期望时间。
• 决定不完整提交应该创建线索、任务、支持工单，还是只记录分析事件。
• 指定一个能最终确认路由规则的人，避免销售、市场和运营各说各的。

CRM 交接经常出问题，是因为只测试了可见表单，没有测试隐藏字段。姓名、邮箱、公司、电话、留言和服务兴趣只是显眼字段。隐藏字段可能还包含页面路径、活动来源、语言、地区、同意状态、产品兴趣、referrer、实验版本和垃圾分数。

做一张字段映射表，每个网站字段一行。写清字段标签、输入类型、校验规则、CRM 属性、是否必填、兜底值、负责人，以及这个值是否应该让销售看到。如果字段由中间层计算或补充，也要标明转换发生在哪里。

• 检查必填字段、选填字段、隐藏字段、计算字段、下拉选项、复选框、文件上传和多步骤表单状态。
• 确认下拉值与 CRM 选项完全一致，包括大小写、标点、语言和已归档选项。
• 测试超长公司名、非英文姓名、重音字符、电话格式、个人邮箱域名和空的选填字段。
• 当 CRM 拒收某个值时，错误状态应该有用，而不是只显示一个笼统的网站错误。

如果交接过程中归因丢失，B2B 团队会失去很多判断信号。CRM 既要保留市场团队需要的来源，也要保留销售团队需要的上下文。通常包括 UTM、落地页、转化页、referrer、首次来源、最近来源、内容资源，有时还包括语言或市场。

为每个重要流量路径准备测试线索。从直接访问、付费广告 URL、自然搜索落地页、合作伙伴推荐链接、邮件链接、社交链接和多语言路由分别提交。然后把 CRM 记录与分析工具和表单 payload 对比。

• 测试 UTM source、medium、campaign、term、content、落地页、referrer、转化页和时间戳。
• 确认归因数据不会因为 Cookie 同意横幅、重定向、canonical、URL 清理、多步骤表单、嵌入表单或页面刷新而丢失。
• 检查首次来源字段是否应该锁定，同时允许最近来源字段在后续提交时更新。
• 确认内部员工测试、垃圾提交和 staging 提交可以从活动报表里排除。

路由是很多表单看似可用、实际业务失败的地方。线索可能成功创建，却被分配到错误地区、发给已经离职的人、被轮询规则跳过，或者因为改版时字段名变化，导致通知没有触发。

用真实样本测试路由矩阵。覆盖不同服务、地区、公司规模、语言、合作伙伴类型和现有客户状态。然后检查 CRM 负责人、团队队列、任务创建、邮件或 Slack 通知、自动确认邮件，以及销售 SLA 时间戳。

• 按地区、服务、账户状态、商机规模、语言、产品兴趣和兜底规则验证负责人分配。
• 在预期场景下检查销售、市场、支持、合作伙伴团队和提交者是否收到对应通知。
• 确认不可用用户、停用账号、假期和空轮询池都有兜底方案。
• 记录从网站提交到 CRM 记录、通知、任务和报表更新的完整耗时。

同意状态应该作为 CRM 交接的一部分测试，而不是单独留给法务。线索可能进入了 CRM，但营销订阅、隐私同意、数据处理依据、地区、语言和保留规则都不对。这会带来运营风险，也会让后续分群不可靠。

像真实访客一样测试不同同意组合。分别提交订阅营销、不订阅营销、不同地区、不同语言路由，以及改变 Cookie 同意后的表单。然后检查 CRM 字段、名单归属、工作流触发和确认文案。

• 确认必要同意文案、可选营销订阅、隐私政策链接和地区特定字段出现在应该出现的位置。
• 在 CRM 中验证同意时间戳、同意来源、表单名称、页面 URL、locale、IP 或地区规则，以及订阅状态。
• 销售询盘不应该自动创建营销订阅，除非用户明确勾选。
• 记录未来谁负责修改同意文案、法律链接、CRM 属性和订阅工作流。

重复规则很容易被忽略，直到上线流量进来才暴露。一个回访潜客可能下载过资料后又提交价格页表单。现有客户可能通过销售页请求支持。合作伙伴可能先用个人邮箱，后用公司邮箱。CRM 需要有这些场景的处理规则。

用新联系人、已有联系人、已有公司、开放商机、已成交客户、已判定不合格线索和退订联系人做测试。检查 CRM 应该更新记录、创建新商机、追加活动、创建任务、重新打开线索，还是阻止提交。

• 测试重复邮箱、重复公司域名、备用邮箱、现有客户、合作伙伴、竞争对手和被屏蔽域名。
• 检查生命周期阶段是否允许向前推进、向后回退，还是保持锁定。
• 确认重复提交会追加表单活动和留言历史，而不是覆盖有用上下文。
• 确认 CRM API 宕机、限流或部分接收提交时的重试行为。

最后一步 QA 应该让真正使用线索的人参与。请销售打开记录，理解上下文，判断优先级，并执行第一个跟进行动。如果他们还需要问线索从哪里来、对方想要什么、下一步该做什么，说明交接还没有完成。

然后检查报表。一个上线项目可能在 CRM 里看起来成功，但分析工具、仪表盘、活动报表和销售管道报表互相不一致。用一组已知测试线索，在网站、分析工具、CRM、通知日志和销售仪表盘之间对照。

• 确认销售能看到来源、页面、留言、服务兴趣、公司、地区、同意状态和建议下一步动作。
• 检查仪表盘里的线索数、合格线索数、转化来源、服务兴趣、负责人、SLA 和管道价值。
• 创建一个上线第一周能使用的测试视图或报表。
• 决定 QA 后如何标记和移除测试线索，同时不破坏归因报表。