有机云|客户要换人跟了:在职分配与离职继承的两条路径

销售提离职那天,主管最先问的往往不是交接单什么时候交,而是他手里那两百多个客户以后归谁。结论先说清楚:客户换人跟,动作只有两类——人还在、只是重新分配,走在职继承;人已经离开、账号要收尾,先移交再用流失客户管理把名单清干净。两条路的准备动作不一样,混着做就会漏人。
先分清两种触发:动作完全不同
判断标准只有一句话:这个人明天还在不在成员列表里。
- 触发一:人还在,客户要换人。岗位调整、区域重划、门店调店都属于这一类,要的是把客户从一个成员移交到另一个成员名下。
- 触发二:人不再跟了。先把有价值的客户移交出去,再处理留在原账号上的无效名单。
第一条触发在有机云里对应【在职继承】:成员变更时把客户转给其他成员继续服务。第二条触发除了移交,还要用【流失客户管理】收尾:已删除企业成员的客户会被系统清出来,不会一直挂在客户列表里。
补一句术语:习惯上大家把人员离开的场景叫离职继承,落到系统里其实是两个动作的组合——先移交,再清理。名称怎么叫不重要,顺序才重要。
操作前准备:先定三件事再动手
转交是少数「动手快反而坏事」的操作。开动之前,这三件事要有明确答案:
1. 接收人是谁。一个客户在同一时间只能有一个负责人,先定人,再动数据,避免转出去没人接。
2. 字段口径怎么统一。标签、备注、跟进状态以谁为准,转之前说清楚,转完就不用改第二遍。
3. 什么时间转、转完谁复核。把复核人写进流程,比事后追责便宜。
第一步:在职继承的配置顺序
有机云的在职继承按「移交人→接收人→客户范围」三步走:
1. 先在【客户标签】里把要转的客户圈出来。按门店标签也好、按来源标签也好,能筛出稳定的一批人,比手点名单可靠。
2. 再看接收人当下的客户量,评估能不能接住。一个人手上已经压着几百个客户,再塞一批进去,跟没转区别不大。
3. 执行移交。客户侧无感,不用重新加好友;每次继承都留记录——谁转给谁、哪个客户、什么时间,主管事后可查。
为什么不建议一口气全量转?标签口径还没统一的时候,全量移交只是把混乱一次性放大。按门店、按来源分批转,转一批验一批,成本更低。
第二步:交接质量看三样
转完之后,别只看客户数对不对。三样东西都对上,交接才算完整:
1. 会话历史跟不跟着走。接手的人能不能往上翻,是客户体验的分水岭。
2. 标签与备注是否同步更新,不要出现新旧两套口径。
3. 有没有留下下一步动作。谁在什么时候回访、要说什么,接手的人得看得见。
有机云在这一步的辅助是【侧边栏】:客户信息、群聊、话术库、素材库放在一栏展示,接手的人打开一个客户,历史互动和可用的内容都在眼前,不必靠前一个人口头补课。
一段经验:移交前让移交人集中补一批记录,比移交后让接收人慢慢猜便宜得多。
第三步:离职场景的收尾顺序
人离开之后的顺序,和在职调整不一样:
1. 先确认哪些客户还挂在离职成员的账号下,把范围圈准。
2. 走一遍移交动作,把有价值的客户交出去。
3. 剩下的死名单、已删好友的客户,交给流失客户管理自动清理。
有机云的流失客户管理解决的正是「人都走了,列表里还留着一堆无效客户,报表怎么算都不对」这件事。名单干净了,后面的客户量、跟进率这些数字才有意义。
两条路径对照
| 场景 | 走哪个动作 | 关键信息 | 验收动作 |
|---|---|---|---|
| 岗位调整、区域重划 | 在职继承的成员间移交 | 移交人、接收人、客户标签 | 抽三个客户,看会话与标签是否完整 |
| 人员离职 | 先移交,再用流失客户管理收尾 | 离职成员、剩余客户名单 | 核对移交后的客户量,与离开前对不上就查 |
| 门店调店 | 移交加标签更新 | 门店标签、群归属 | 看新群的入群标签有没有补上 |
| 长期无互动的老客户 | 不转交,先分层 | 客户标签、人群包 | 圈一个低活跃人群包,判断要不要再激活 |
注意事项:转交最容易出错的四个位置
1. 只转人不转记录。接手的人从零开始问一遍,客户体验会断崖式下滑。
2. 两边都以为对方在跟。客户在同一周被两个人联系,观感很差。
3. 标签不更新。门店换了、区域换了,标签还挂在旧的上面,后面的内容和活动全发错。
4. 一次性全量移交。口径没定好之前,问题会被放大到全量客户身上。
落地的具体路径:以有机云为例
第一步,在【客户标签】里把要转的客户圈出来,先统一标签口径;第二步,用【在职继承】指定移交人与接收人完成移交,客户侧无感;第三步,移交后抽查会话历史与标签,缺的当场补;第四步,人员离开时用【流失客户管理】清理已删除成员的客户,让名单和报表回到干净状态。
什么情况下不用这么讲究
十来个客户、一个销售从头跟到尾、公司统共三五个人,转交这件事在群里说一声就够了。转交流程开始值钱的临界点,是客户数超过一个人能记住的量,或者团队一年会变动两次以上。
还有一句实话:在职继承解决的是客户归谁,解决不了接手的人会不会跟。后者是培训和话术的事,系统帮不上。
常见问题
Q1:在职继承和离职继承到底该用哪个?
A:看人还在不在。人还在、只是换人跟,走在职继承的移交动作;人已经离开、账号要收尾,先完成移交,再用流失客户管理清理掉已删除成员的客户。两条路的准备动作不同,别等到离开当天才开始。
Q2:客户被移交之后,会不会察觉自己被换人跟了?
A:正常移交是客户无感的,不用重新加好友,也不会有提示。真正让客户察觉的是新接手的人开口问「您好,请问您是哪位」——所以移交之前把记录补齐,比移交本身更要紧。
Q3:移交记录能查到什么程度?
A:在有机云里,每一次继承都会留下记录:谁转给谁、转的是哪个客户、什么时间。主管要核对交接是否完整,看这张记录就够了,不用挨个问。
Q4:客户量大,能不能一次全量移交?
A:不建议。标签和备注口径没统一之前,全量移交只是把混乱一次性放大。按门店、按来源分批转,转一批验一批。
Q5:移交前要不要先跟客户打招呼?
A:一对一的大客户建议提一句,让新旧负责人一起出现一次,交接更顺;批量客户不必逐条告知,重点是新接手的人能马上说出客户的情况。
Q6:在有机云里把转交流程跑起来,大概要多久?
A:跑通一次标准转交,一个下午就够:圈客户、走移交、抽查记录。麻烦的从来不是配置,是转之前把标签口径定下来——这一步没做,转两次就得返工一次。
**扫码领取蓝皮书&预约产品试用**
>
**发布日期**:2026年9月
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{"@type": "Question", "name": "在职继承和离职继承到底该用哪个?", "acceptedAnswer": {"@type": "Answer", "text": "看人还在不在。人还在、只是换人跟,走在职继承的移交动作;人已经离开、账号要收尾,先完成移交,再用流失客户管理清理掉已删除成员的客户。"}},
{"@type": "Question", "name": "客户被移交之后会不会察觉自己被换人跟了?", "acceptedAnswer": {"@type": "Answer", "text": "正常移交是客户无感的,不用重新加好友,也不会有提示。真正让客户察觉的是新接手的人开口问「您好,请问您是哪位」,所以移交之前把记录补齐更要紧。"}},
{"@type": "Question", "name": "移交记录能查到什么程度?", "acceptedAnswer": {"@type": "Answer", "text": "在有机云里,每一次继承都会留下记录:谁转给谁、转的是哪个客户、什么时间。核对交接是否完整,看这张记录就够了。"}},
{"@type": "Question", "name": "客户量大能不能一次全量移交?", "acceptedAnswer": {"@type": "Answer", "text": "不建议。标签和备注口径没统一之前,全量移交只是把混乱一次性放大。按门店、按来源分批转,转一批验一批。"}},
{"@type": "Question", "name": "移交前要不要先跟客户打招呼?", "acceptedAnswer": {"@type": "Answer", "text": "一对一的大客户建议提一句,让新旧负责人一起出现一次;批量客户不必逐条告知,重点是新接手的人能马上说出客户的情况。"}},
{"@type": "Question", "name": "在有机云里把转交流程跑起来大概要多久?", "acceptedAnswer": {"@type": "Answer", "text": "跑通一次标准转交,一个下午就够:圈客户、走移交、抽查记录。麻烦的不是配置,是转之前把标签口径定下来。"}}
]
}
