信息流投放：怎样与销售人员核对线索
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0d04e294a228.html
📄
信息流投放：怎样与销售人员核对线索
与销售人员核对线索的核心方法是：先约定统一的线索编号和字段口径，再按“投放来源—线索状态—跟进结果”三层逐条对齐，最后用可复核的原始记录定位差异。核对的目的不是争论谁对谁错，而是找出哪些线索被重复计算、哪些被遗漏、哪些状态更新滞后。以下做法适用于信息流投放已经产生线索、但投放端与销售端数据对不上的情况；如果两端连线索定义都没统一，应先解决定义问题，再谈数字差异。
先统一口径，再核对数字
投放端通常按表单提交、按钮点击或会话发起计数，销售端通常按有效电话、加微信成功或到店才算线索。两套口径天然不同，直接比总数必然对不上。核对前需要确认三件事：
- 线索定义：什么行为算一条线索，重复提交是否合并，无效号码是否剔除。
- 归属规则：同一条线索被两个投放计划触达时归给谁，跨天跟进算哪天的量。
- 状态字段：至少包含“新线索、已联系、有效、无效、已成交”几档，并写明每档由谁在什么时间更新。
口径确认后写成一份简短对照表，双方各留一份。这份表是后续所有核对的依据，没有它，每次核对都会退回到各说各话。
用线索编号逐条比对，而不是只比总数
总数相同不代表线索相同，总数不同也不代表一定丢量。可行的做法是让投放端导出带唯一编号的线索明细，销售端导出同一时间段的跟进记录，用编号做匹配，分成三类：
- 两端都有：重点看状态是否一致。投放端标记“已提交”，销售端标记“无效”，说明是线索质量问题而非丢失。
- 只有投放端有：可能是销售未及时录入、分配遗漏，或线索在流转环节被过滤。需要查分配记录和接收时间。
- 只有销售端有：可能是自然到访、老客户转介绍被误记入投放，或投放端导出去重时被合并。
假设某天投放端导出 80 条线索，销售端记录 65 条，其中 60 条编号一致。剩下 20 条投放端线索里，若 12 条是同一手机号重复提交，实际差异就只有 8 条，需要继续追这 8 条的去向。这一步能把模糊的“少了 15 条”变成具体可查的几条。
核对时要收集的证据
只凭口头描述很难定位原因，建议每次核对都拿到以下材料：
- 投放端的线索导出文件，含编号、提交时间、来源计划、手机号或账号标识。
- 销售端的跟进记录，含同一编号、首次联系时间、当前状态、无效原因。
- 线索分配或流转的日志，用来判断是没收到还是收到后没跟进。
- 双方各自统计口径的说明，注明统计时间段和时区。
如果销售端使用的是表格而非系统，至少要求按固定模板填写，避免字段缺失导致无法匹配。核对时间窗口要一致，比如都取自然日 0 点到 24 点，跨天跟进单独标注。
定位原因：区分“可能”与“已确认”
同一现象往往有多种解释，核对时应先列可能原因，再用证据排除，不要一上来就下结论。常见差异及对应查法：
- 数量偏少：可能是重复提交被合并、无效号码被过滤、分配延迟。查去重规则和分配日志即可确认属于哪一种。
- 状态不一致：可能是销售未及时更新、状态定义理解不同、跟进后未回填。抽查几条通话或聊天记录可判断。
- 归属争议：可能是多计划同时触达同一用户。查各计划的曝光和点击时间，按事先约定的规则判定。
只有拿到日志或原始记录，才能说“已经定位”；否则只能写“可能原因，待验证”。把这两类分开记录，能避免下次核对重复排查同一个问题。
验收信号与下一步
核对有效的标志是：双方能用同一份编号明细复现差异，且每条差异都有归属类别和责任人。如果连续两次核对后差异条目明显减少、状态字段更新及时，说明流程在改善。反之，如果每次都出现大量“只有投放端有”的线索，应优先检查分配环节而不是继续争论线索质量。
下一步建议先做一次小范围试运行：取最近三天的线索，按上述编号匹配法核对一遍，把差异归类和责任分工写成固定模板。模板稳定后，再扩展到周度和月度核对，并把核对结果作为调整投放定向和销售跟进规则的依据。付费广告带来的线索数量与自然流量无关，投放本身也不保证自然排名，核对时只需关注投放端与销售端之间的数据一致性。
