网站对接 CRM：怎样确认客户咨询没有丢失

页面显示“提交成功”，不等于咨询已经进入 CRM。验收网站时，请开发团队展示三个结果：已保存的提交、对应的 CRM 记录、负责跟进的人。如果处理在中途停止，团队应该能查到停在哪一步。

网站对接 CRM，就是把表单数据交给销售系统，再按约定创建咨询、关联联系人并分配负责人。可以使用 CRM 自带的表单、现成连接插件，也可以通过 API 开发对接。应根据实际流程选择，而不是默认需要定制开发。

先定义什么叫“已收到”

区分三个状态：网站保存成功、CRM 确认写入、销售人员收到任务。邮件或 Telegram 通知可以辅助提醒，但不能单独证明这三步都已完成。

CRM 暂时不可用时，网站可以先可靠地保存咨询，稍后再传送。这时可以告诉访客“已收到”。如果连保存都失败，就不能显示成功，应提供重试或其他联系方式。回复时限也应先与销售团队确认。

选择便于维护的接入方式

先检查现成表单或连接器是否支持所需字段、分配规则和故障恢复，并要求演示。定制代码并不会天然比现成工具可靠。

队列可以把接收和处理分开，但需要有人关注积压和失败的消息。对于规模小、流量稳定的网站，单独引入队列服务未必划算。应比较维护工作，而不只是初次接入成本。

• Microsoft — Queue-based load leveling

除了联系方式，还要传哪些信息

做一张字段对应表，列清表单内容和网站补充的数据分别写入 CRM 的哪里。常用信息包括咨询内容、所选服务、页面地址、表单标识、接收时间和已知访问来源。还要检查 CRM 的必填项和可选值：网页自由输入的文字，可能不能直接写入固定选项字段。

提前决定保留首次已知来源、本次咨询来源，还是两者都保留。没有 UTM 参数，不代表用户一定是直接访问；也可能只是无法确定来源。不要为了让报表完整而编造渠道。

CRM 密钥应留在服务器端。明确谁能查看错误日志，避免把日志变成所有人都能访问的客户留言副本。

重试同一次提交，不等于客户再次咨询

看一个假设场景：网站保存 S-104，CRM 创建 C-208，但确认响应丢失。网站只看到请求超时。如果不核对结果就再次创建，可能多出一条记录。

同一次咨询重试时，应继续使用原提交编号。如果 CRM 的 API 支持幂等，可以让多次请求只产生一次操作结果；否则需要另行设计记录匹配和核对机制。只在创建前查询一次，无法防止两个同时到达的请求生成重复记录。请求超时也不代表第一次保存失败。

如果这位客户第二天询问另一项服务，那是新的咨询 S-105。可以关联已有联系人，同时按销售规则保留新需求。把手机号相同的提交全部删除，会漏掉真实咨询。

• Microsoft — Retry pattern

验收时要演示失败场景

下表是测试环境中的预期结果，不是某款 CRM 的实测成绩。每个表单、弹窗和语言版本都应检查。记录提交标识，才能在网站和 CRM 中核对同一条咨询。

上线后由谁处理问题

交接时应拿到字段对应表、重复发送与新咨询的处理规则，以及错误查看和恢复说明。指定处理故障的人，约定数据多久应到达 CRM，并让开发人员演示修复后如何恢复传送而不产生重复记录。

不能只比较新商机数量。有些咨询会关联已有联系人或商机。应按提交标识核对接收和传送状态，并区分测试、垃圾信息及待处理任务。统计工具里的“点击提交”事件不足以证明咨询已被接收。

与 Neaptide 讨论网站项目中的 CRM 对接时，请提供网站地址、CRM 名称、表单清单，以及不含个人信息的目标记录示例。说明老客户再次咨询时应如何处理，以及由谁代表销售团队验收。

• 下载假设事件记录
• 怎样比较网站开发报价
• 讨论网站与 CRM 对接