📍 WDQWDWQD987AAAAA:216.73.216.70
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /02819dc0e61b.html
📄

移动广告推广_怎样与销售人员核对线索

与销售人员核对线索，核心不是问“这条线索好不好”，而是把每条线索的状态、来源、跟进动作和结果逐项对齐，找到双方口径不一致的具体位置。移动广告推广的线索往往来自表单、电话、在线咨询或应用内行为，销售看到的是“人”，投放看到的是“记录”，核对就是让这两套信息能一一对应。

核对前先统一线索定义

很多争议不是数据错了，而是双方对“线索”的理解不同。投放端可能把一次表单提交、一次电话拨通、一次咨询会话都算作线索；销售端可能只把接通并有意向的才算有效线索。核对之前，先用一句话写清本次统计的口径，例如：

• 线索指用户在移动广告落地页提交手机号且未重复的记录。
• 有效线索指销售首次接通、确认有需求且未明确拒绝的记录。
• 无效线索指空号、重复提交、明显误触或明确表示无需求。

口径写下来之后，后面所有对比都以它为准。否则会出现投放说“给了100条”，销售说“只收到60条”，其实差在重复号码和无效号码的算法上。

准备一份可逐条对照的清单

不要只对总数。总数一致不代表明细一致，总数不一致也不代表每条都错。准备一张表，至少包含以下字段：

1. 线索标识：手机号后四位、提交时间或系统编号，用于定位同一条记录。
2. 来源信息：哪个移动广告推广计划、哪个落地页、哪个时间段。
3. 投放端状态：已提交、已去重、已下发、下发失败。
4. 销售端状态：未联系、已联系未接通、已接通有意向、已接通无需求、已成交。
5. 时间戳：提交时间和首次跟进时间。

字段不必多，但必须能唯一对应。如果销售系统里只有姓名没有手机号，或者投放报表里只有汇总没有明细，就要先解决数据可对齐的问题，再谈原因。

实施核对：先对明细，再对差异

把投放端导出的线索明细和销售端导出的跟进明细放在一起，按线索标识做匹配。匹配结果通常分三类：

• 两边都有且状态一致：这部分不用讨论，直接确认。
• 两边都有但状态不一致：例如投放记为“已下发”，销售记为“未收到”。这类要查下发通道、接收账号、通知方式，而不是先怀疑线索质量。
• 只有一边有：投放有、销售没有，可能是下发失败、被拦截、进了错误账号；销售有、投放没有，可能是销售自行录入、老线索复用或渠道归属填错。

最关键的一步是把“只有一边有”的记录逐条列出来并追问去向。这一步能直接暴露是技术链路问题、归属规则问题，还是人为记录问题。只对总数会把这三类问题混在一起，最后变成互相指责。

验证差异原因，区分可能原因与已定位原因

发现差异后，不要直接下结论。先提出可能原因，再用证据验证。例如销售说“没收到线索”，可能原因包括：下发接口失败、短信或通知被拦截、接收人账号变更、线索被分配到其他销售、销售未及时查看。验证方式分别是：

• 查下发日志：该条记录是否成功发出、返回什么状态。
• 查接收端：对应账号是否在线、是否更换、是否有屏蔽规则。
• 查分配规则：该时间段线索是否按区域或轮转规则分给了别人。
• 查跟进记录：销售是否在提交后一定时间内有查看或拨号动作。

只有拿到日志、截图或系统记录，才能说“已经定位的原因”。否则只能写“可能原因”，并注明还需要什么证据。这一步决定了后续是修技术、改规则，还是调整销售跟进要求。

维护核对机制，避免下次重新吵一遍

核对不是一次性的。移动广告推广的线索会持续产生，建议固定一个短周期，例如每天或每周，做一次小范围抽查，而不是等到月底对总数。维护动作包括：

• 固定导出时间和字段，双方用同一份模板。
• 对反复出现的差异类型做标记，例如“下发失败”“归属错误”“重复提交”。
• 每次核对后更新口径说明，把新出现的边界情况写进去。
• 把核对结果反馈到投放端和销售端各自的动作上，而不是只留一份对账表。

如果差异集中在某类来源或某个时间段，就针对那部分加查；如果差异分散且金额小，可以按抽样比例核对，不必每条都追。判断标准是：差异是否影响结算、是否影响后续投放决策、是否反复出现。

下一步，先和销售确定本次核对的时间范围和线索定义，然后各自导出同一时间段的明细，按线索标识做一次匹配。匹配出的“只有一边有”的记录，就是最值得优先追问的部分。