官网线索到 CRM：打通方式、字段映射与去重
一、断点不在表单，在收完之后没人跟
先划清本篇的边界：表单可靠性与反垃圾讲的是表单能不能收到、垃圾询盘怎么挡；线索归因讲的是一笔询盘的功劳怎么算。本篇只讲中间那一段：线索从站上流进 CRM 的链路怎么搭、字段怎么对、重复怎么并、失败怎么补。表单是收口，归因是口径，本篇是管道——管道漏了，前面两件事做得再好也白搭。
我们排查过的线索流失案例里，极少是”表单收不到”，多数是收到的线索卡在邮箱和表格里。
| 断点形态 | 平时的表现 | 实际代价 |
|---|---|---|
| 线索躺在共享邮箱 | 每天人工翻邮件分派 | 假期与人员变动时漏跟 |
| 手工抄录进 CRM | 每条抄录 2–3 分钟 | 漏抄、抄错字段、延迟以天计 |
| 抄录丢来源信息 | CRM 里只剩姓名和邮箱 | 销售无法判断优先级与背景 |
| 重复线索不合并 | 同一客户三条记录 | 两人同时跟进，报价口径不一 |
| 同步失败无人知 | 中间环节静默报错 | 线索消失且无人察觉 |
最后一行最危险：前三类问题看得见，静默丢失连”丢了”这个信号都没有。所以本篇第五节专门讲失败兜底，它不是可选项。
二、先定义线索生命周期状态
搭管道之前先定状态，因为打通方案要做状态回写，没有状态定义就没法设计回写什么。一套最小可用的生命周期是五个状态。
| 状态 | 定义 | 停留时限参考 |
|---|---|---|
| 新线索 | 已落库，未做首次响应 | 首次响应不超过 24 小时 |
| 已联系 | 已首次接触，等客户回复 | 3–7 天内二次跟进 |
| 报价中 | 已发报价，商务谈判进行中 | 每周至少跟进一次 |
| 成交 | 签单或预付款到账 | 转入订单交付流程 |
| 无效 | 垃圾、错目标、超期无回复 | 归档保留记录，不删除 |
两个设计要点。第一，”无效”要保留记录而不是删除：三个月前被判无效的询盘，可能在客户换了岗位后重新激活，历史记录是再触达的依据。第二，每个状态配上停留时限，CRM 的价值才真正兑现——超时未动的线索自动提醒，比销售凭记忆跟进可靠得多。状态定义还要写成一句话文档存进 CRM，新销售入职先读这个，再读首封跟进邮件的写法。
三、三种打通方式对比
| 方式 | 时效 | 成本量级 | 主要风险 | 适用规模 |
|---|---|---|---|---|
| 插件直连 CRM API | 秒级 | 插件年费几百至两千元 | CRM 改版后字段映射失效 | 月询盘 100 条以上、多表单多语言站 |
| Webhook 加中间层 | 分钟级 | 中间层月费几十至几百元 | 链路长，故障点多一层 | 月询盘 10–100 条 |
| 定时导出 CSV 导入 | 天级 | 人工每周 1–2 小时 | 延迟大、导入易产生重复 | 月询盘不足 10 条的过渡期 |
落到建议上：月询盘 10–100 条选中间层，搭起来最快，改表单字段也只改一处；100 条以上、或者表单多、有中英文双语站各自收询盘的，直接上插件直连 API，减少中间环节。多语言站点每多一个语言子站，字段映射就多一份要维护，其隐性成本在多语言插件的隐藏成本一篇里有展开。CSV 导入永远只能是过渡方案——它的延迟以天计，而 B2B 询盘的首次响应时限是 24 小时，两者差着一个数量级。
四、字段映射与来源数据
打通方案里最容易出错、也最晚被发现的环节是字段映射。出错的表现不是”传不过去”，而是传过去了但全是脏数据，几个月后做客户分析时才集体暴露。
| 站上字段 | CRM 字段 | 必填 | 类型与约束 |
|---|---|---|---|
| 姓名 | 联系人姓名 | 是 | 文本，50 字以内 |
| 公司 | 公司名或账户名 | 是 | 文本，去重主键之一 |
| 邮箱 | 邮箱 | 是 | 格式校验，去重主键 |
| 电话 | 电话 | 建议 | 强制带国家区号，如 +86、+49 |
| 国家 | 国家或地区 | 是 | 下拉枚举，禁止自由填写 |
| 需求类别 | 业务类型 | 建议 | 枚举：询价、技术、售后、代理 |
| 来源渠道 | 线索来源 | 是 | UTM 组合或来源枚举 |
| 落地页 URL | 来源页面 | 建议 | 文本，255 字以内 |
| 提交时间 | 创建时间 | 是 | 带时区的标准时间格式 |
三处最常见也最伤的映射错误：国家做自由文本，同一个国家在 CRM 里出现五种写法，按国家统计全部失真；电话不带区号，回拨失败率极高，欧洲客户尤其明显；提交时间不带时区，跨时区团队对”今天几点来的询盘”各说各话。字段映射表要做出来归档，CRM 或表单任何一侧改字段，先对表再上线。
来源数据带多少过去，另一张表说清楚：
| 来源数据 | 处理方式 | 建议去向 |
|---|---|---|
| UTM 五个参数 | 全量传递 | CRM 自定义字段 |
| 来源站点 referrer | 全量传递 | CRM 自定义字段 |
| 广告 click id | 全量传递 | CRM，供广告平台回传 |
| 设备与语言 | 摘要拼接为单字段 | CRM 单字段 |
| 完整行为轨迹 | 不传 | 留在站上分析工具 |
分界逻辑是：CRM 里的销售要用来判断”这是谁、从哪来、想要什么”的数据，必须跟着线索走；逐页浏览轨迹属于行为分析，留在站上，塞进 CRM 只会让记录页臃肿且没人看。
五、去重与失败补偿
去重规则
同一客户重复进来是常态而不是异常：他可能先问询价表单、再提交技术表单，可能在中英文两个站各问一次，也可能隔两周换个邮箱再来。去重规则按四种场景定。
| 场景 | 处理规则 |
|---|---|
| 邮箱相同 | 自动合并为同一线索，新提交内容追加为动态记录 |
| 邮箱不同、公司域名相同 | 不自动合并，标记关联并提醒销售人工判断 |
| 同一表单短时间重复提交 | 10 分钟内同一邮箱只建一条 |
| 多语言站点重复提交 | 按邮箱合并，语言字段取首次提交值 |
主键选”邮箱加公司域名”的组合：邮箱是个人级唯一键，公司域名兜住”同公司多人分别询价”的场景。只用邮箱做主键会漏掉同公司多联系人；只用公司名做主键会误伤同名公司。两条边界：免费邮箱（gmail 等）的公司域名没有去重价值，退回只按邮箱；收购兼并后的域名变更，要人工跑一次合并，机器判断不了企业关系。
失败补偿
链路上任何一环都可能失败，兜底设计的原则只有一条：任何失败都不允许静默丢线索。
| 失败类型 | 兜底动作 |
|---|---|
| 请求超时 | 进重试队列，按 5、30、120 分钟间隔重试三次 |
| 字段超长或格式错 | 本地留档加即时告警，人工补录 |
| CRM 限流 | 排队延迟发送，不丢弃 |
| CRM 授权失效 | 立即告警，线索先落本地库，恢复后补传 |
兜底的共同底座是一个本地留档：线索在离开站上之前先写入站内数据库或表格，之后同步成功与否都查得到。补一个每日对账动作——比对站上提交数、中间层发送数、CRM 入库数三个数字，对不上当天查。管道的可靠性不是设计出来的，是对账对出来的。
六、上线测试与首周对账
上线不是配置完点一下保存，而是用五个测试用例把链路打一遍。
| 测试用例 | 预期结果 |
|---|---|
| 正常完整提交 | 全字段入库，来源数据完整无缺 |
| 必填缺失提交 | 表单侧拦截，不产生脏数据 |
| 超长文本提交 | 截断或拦截，CRM 侧不报错 |
| 重复提交 | 去重生效，只建一条 |
| 停用 CRM 凭据后提交 | 线索落本地，恢复后自动或手动补传 |
每个用例要同时在两侧核对：站上显示提交成功，CRM 里逐字段比对是否一致，重点看国家、电话区号和时区这三处惯犯字段。
上线后第一周执行每日对账：下班前核对表单提交数、中间层发送数、CRM 入库数，三个数字一致才算当天收工。第一周抓出来的问题——通常是某个表单没接上、某个字段映射遗漏——集中在这一周修，成本最低。第一周之后降为每周一次对账，稳定运行一个季度后降为每月，配合月度维护节奏执行即可。
七、什么时候不用 CRM
打通方案是为跟进流程服务的，询盘量撑不起跟进流程时，先别建管道。
| 条件 | 建议 |
|---|---|
| 月询盘不足 10 条 | 共享邮箱加在线表格即可 |
| 只有单人做销售 | 邮箱规则加表格跟进记录 |
| 询盘量尚未稳定 | 表格过渡，稳定后再上 CRM |
过渡方案不等于凑合：在线表格的列结构直接按第四节的字段映射设计，国家用下拉、时间带时区、来源字段照常记录，将来迁 CRM 时按列导入，几乎不返工。真正要避免的是反过来的路径——先买了 CRM，线索还是靠手抄，管道一直没搭， CRM 沦为一个昂贵的通讯录。判断时机看一个数字：当手工处理线索的时间超过每周两小时，或者出现过第一次”假期漏跟丢单”，就是动手上管道的时候。需要按站点情况设计线索落库方案，可以通过联系我们说明现状。
FAQ 常见问题
写在最后
线索管道是独立站里投入产出比最确定的一类改造：表单每天在收询盘，管道决定这些询盘是被 24 小时内跟住，还是躺在邮箱里过期。它不需要高深技术，需要的是三件到位的事——字段映射先对表、失败必有兜底、上线先对账。
落地顺序建议：先定线索生命周期状态，再按询盘量选打通方式，最后把五个测试用例和每日对账写进上线清单。量小的时候用表格过渡，不丢人；量大了还靠手抄，才丢钱。记住一句话就够了：管道的价值不在于自动化本身，在于任何一条线索都不允许静默消失。