B2B RFQ 报价请求页上线前 QA 检查清单

B2B 报价请求页不只是收集留言。它应该帮助合适的买家说明需求，帮助销售团队快速判断是否匹配，也要让搜索引擎理解页面的商业意图。

很多 RFQ 页面的问题并不大，但会影响后续流程。表单问得太少，必填字段挡住了高质量买家，产品规格藏得太深，CRM 交接丢失上下文，或者页面只覆盖泛词，没有覆盖真正准备询价的搜索需求。上线前 QA 的目的，就是把这些风险提前暴露出来。

先决定这个页面到底要筛选什么类型的询盘。制造业报价、批发账户申请、企业演示预约、定制项目咨询、经销商申请，所需要的字段和跟进规则都不一样。如果一个页面想同时服务所有场景，表单通常会变得很模糊。

测试前先用一句话写清楚理想询盘。例如：合格买家可以围绕某个产品系列，提供数量、地区、时间和规格信息，从而让团队判断是否适合报价。

• 写清主要询盘类型，以及负责跟进的团队。
• 定义哪些询盘应该接收，哪些应该分流，哪些应该过滤。
• 在表单附近说明提交后会发生什么。
• 确认导航、服务页、产品页和 CTA 指向的是同一个意图。

RFQ 表单通常需要比普通联系表单更多的信息，但每个新增字段都应该有理由。必填字段要回答一个会改变销售下一步动作的问题。选填字段可以让买家补充更多上下文，但不应该成为阻碍。

不要只测试空字段校验。用真实销售场景来测试：有明确规格书的买家、还在比较方案的买家、来自不支持地区的买家，都应该有清晰可预期的路径。

• 当公司名称、工作邮箱、国家或地区、买家角色会影响筛选时，应该收集。
• 产品、服务或应用场景尽量使用可控选项，减少后续整理成本。
• 数量、预算区间、时间计划、合规要求，只在销售会使用时设置。
• 需要时支持上传图纸、需求 brief、产品清单或技术文件。
• 隐私同意、错误提示和提交成功信息都要和报价跟进相关。

不要把所有购买信息都藏在表单后面。高意向访客通常需要先判断是否值得提交报价请求。搜索引擎也需要可见内容来理解你的服务、支持类别、应用场景、限制条件和适配范围。

页面不需要变成完整目录，但应该回答买家提交前最常见的问题。把能帮助买家自我筛选的信息放在页面上，再用表单收集每个项目不同的细节。

• 列出支持的产品系列、服务类别、行业或应用场景。
• 如果最小起订量、服务地区、交期范围或项目门槛重要，就应该说明。
• 告诉买家哪些信息有助于团队准确报价。
• 链接到相关产品页、服务页、价格页、案例页或资源内容。
• 如果价格取决于规格，不要在页面上承诺固定报价。

RFQ 页面有机会覆盖很有价值的底部漏斗搜索词，但前提是页面可收录，并且在站内有足够清晰的链接关系。上线前要检查标题、描述、H1、正文、结构化数据、canonical、语言替代和内部链接。

页面文案要足够具体，才能吸引合适买家。普通联系页式的泛泛文案，很难覆盖 quote、pricing、wholesale、supplier、custom、manufacturer、project 等高意向搜索需求。

• Title 和 H1 要同时表达服务内容和询价意图。
• 确认 canonical、robots、noindex、sitemap、hreflang 和本地化 URL 正确。
• 从相关服务页、产品页、案例页和资源内容添加内部链接。
• 确保追踪参数不会生成可收录的重复 RFQ URL。
• 检查移动端布局，避免表单字段、辅助说明和 CTA 重叠。

浏览器显示提交成功，并不代表 RFQ 流程真的完成。更重要的是，正确的人是否及时收到足够完整的上下文，并且能够高质量跟进。

用生产环境真实路径做测试提交。需要覆盖通知、CRM 字段、线索来源、归因、附件、语言、地区、产品兴趣，以及任何自动分配负责人规则。

• 确认 CRM 字段映射保留了筛选信息和来源上下文。
• 检查邮件、Slack 或任务通知是否发送给正确负责人。
• 测试自动回复文案、发件人身份、reply-to 行为和垃圾邮件情况。
• 验证附件传递和文件大小限制。
• 定义预期响应 SLA，以及在哪里监控遗漏跟进。