新增app推广：怎样与销售承接流程对接
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3cbeec997d8e.html
📄
新增app推广：怎样与销售承接流程对接
新增app推广与销售承接对接的核心，是把推广端获取的用户或线索，按统一字段、统一分层、统一交接动作交给销售，并在交付后回传结果。判断对接是否成立，不看推广花了多少钱，而看一条线索从进入系统到销售首次跟进之间，是否有人负责、有时限、有状态、有回传。适用前提是推广与销售属于不同角色、需要多人协作；如果只有一个人既推广又成交，本方法可以简化，但不能省掉字段和状态记录。
先定义交接对象：用户、线索还是注册
新增app推广常见三种结果：安装用户、注册用户、留资线索。三者承接方式不同。安装用户通常由产品内引导或运营承接，销售不直接介入；注册用户要看是否留下可联系信息；留资线索才进入销售跟进。对接前必须写清楚：推广端交付的到底是哪一种。若把安装量直接当销售线索，销售会认为质量差，推广会认为销售不跟进，返工由此产生。
可执行的检查项：在推广需求文档里写一句“本次交付对象为____”，并列出必填字段。例如假设某次投放只要求手机号，则字段为手机号、来源渠道、进入时间、用户意向标签；若没有意向标签，销售只能盲打，承接效率会下降。
统一字段与分层标准，减少来回确认
多人协作时，返工大多来自字段不一致。推广端说“高意向”，销售端理解为“已咨询价格”；推广端记录“点击”，销售端需要“可拨通”。因此要建立一张交接表，至少包含以下内容：
- 用户标识：手机号、设备号或注册ID，按实际可联系性选择。
- 来源信息：渠道、活动、素材或推广位，用于后续判断哪类来源更值得跟进。
- 行为信息：注册、试用、加购、预约等关键动作及发生时间。
- 意向分层：用可观察行为定义，如“已提交表单”与“仅浏览页面”分开。
- 交接状态：待分配、已分配、已首次跟进、已转化、无效，状态由谁修改要写明。
分层标准不要用“热、温、冷”这类主观词，除非每个词都有对应行为。例如假设定义“A层：提交表单且留下可拨通号码；B层：注册但未提交表单；C层：仅安装”。销售按A到C依次跟进，推广端也按同一分层复盘，双方才能对同一批数据说同一件事。
设定交接动作与时限，明确谁做什么
对接流程要落到具体动作，而不是“及时跟进”。可以按以下顺序执行：
- 推广端在用户完成关键动作后，将记录写入约定位置，并标记来源与分层。
- 系统或指定人员按规则分配给销售，分配规则提前写清，如按地区、按渠道或轮询。
- 销售在约定时限内完成首次联系，并把结果改为“已首次跟进”或“无效”，无效需选原因。
- 推广端定期查看未跟进、无效占比和转化状态，用于调整投放，而不是只看前端数量。
时限和分配规则属于协作约定，不是平台固定功能，需要团队自己确认。验收信号可以设为：任意抽查一条记录，能回答“谁在什么时候拿到、什么时候首次跟进、结果是什么”。如果答不出，说明流程没有真正对接。
用回传结果校准推广，而不是混用指标
推广端常看点击、安装、注册成本，销售端常看跟进量、成交周期和成交金额。这两类指标不能混在一起比较。正确做法是：推广端保留前端指标，销售端回传后链路状态，双方在同一张表里看“来源—分层—跟进结果”。
例如假设某渠道安装量高但A层线索少，销售跟进后无效占比高，那么问题可能在推广承诺与产品实际不匹配，而不是销售不努力。反过来，如果A层线索多但大量停留在“待分配”，问题在交接环节。区分“可能原因”与“已经定位的原因”：前者需要继续查分配记录、跟进记录和用户行为，后者要有具体记录支撑，不能凭感觉断言。
验收与下一步
对接完成后，做一次小范围核对：从推广端随机取若干条记录，沿字段、分配、首次跟进、结果回传走一遍，看是否闭环。若闭环成立，再扩大范围；若不成立，先修字段和状态，不要急着增加推广量。下一步可以直接把现有交接表拿给推广和销售各填一列，标出双方理解不一致的字段，先统一这些字段再谈优化。
