惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

雷峰网
雷峰网
MongoDB | Blog
MongoDB | Blog
D
Docker
Martin Fowler
Martin Fowler
人人都是产品经理
人人都是产品经理
GbyAI
GbyAI
Jina AI
Jina AI
酷 壳 – CoolShell
酷 壳 – CoolShell
M
MIT News - Artificial intelligence
腾讯CDC
阮一峰的网络日志
阮一峰的网络日志
H
Hackread – Cybersecurity News, Data Breaches, AI and More
N
Netflix TechBlog - Medium
B
Blog RSS Feed
云风的 BLOG
云风的 BLOG
Blog — PlanetScale
Blog — PlanetScale
Vercel News
Vercel News
The Cloudflare Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
有赞技术团队
有赞技术团队
G
Google Developers Blog
Stack Overflow Blog
Stack Overflow Blog
I
InfoQ
U
Unit 42

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
线索的生命周期管理:召回、静默、释放和激活
爱吐槽的徐教授 · 2024-05-27 · via 人人都是产品经理

前几篇文章,我们分享了线索生命周期中的分发和分配,这篇文章,我们来分享其中的召回和激活,希望能帮到大家。

线索的生命周期管理中,非常重要的“线索分发”和“线索分配”,由于在之前已经花了非常多的笔墨阐述,所以在此不再过多延展。

接下来我简单结合一些业务场景,讲述下线索生命周期的其他管理手段。

一、线索召回

线索的召回从执行方式来看,分为两种,手动召回和自动召回。手动召回一般是业务根据筛选条件,圈选线索后召回;自动召回是根据业务配置的规则,将符合规则条件的线索通过定时任务自动召回。
以召回的目标来区分,主要有以下3种召回目标:从自动化任务中召回,从分配的流程中召回以及从归属的销售坐席中召回。

自动化任务中召回

在区分线索价值后,我们一般会将高价值的线索分配给销售坐席手动拨打(可以避免自动化任务流程中客户的流失),然后将低价值的线索分配给自动化任务,例如预测外呼、智能外呼,经过筛选后,再转接给销售坐席。如果低价值的线索,已经处在自动化任务的流程中,但又由于因为客户自发产生的新活跃行为,更新变成了高价值的线索,基于业务规则,这条线索就应该从自动化任务中移出,通过高价值线索的分配策略重新下发。在这种情况下,我们就需要去将线索召回。这线索召回的基础逻辑判断基点是线索质量,同时需要配合一些特定召回规则,最终满足各种业务场景的需求。

分配流程中召回

分配流程中的召回,其业务逻辑与“自动化任务中召回”其实是一致的,一般也是因为有高价值类型的线索产生了更新,所以需要调整分配的策略。相比较于前者,分配流程中的召回在实现逻辑上可能会更为简单一些。因为分配的流程中召回只需要考虑CRM系统的内部的程序逻辑,而在自动化任务中召回,存在线索已经在预测外呼、智能外呼队列中了,在这种情况下,我们还要去考虑如何与这些crm依赖的外部系统如何逻辑兼容。

从归属的销售坐席手中召回

与前两者有显著区别的是,从归属坐席手中召回线索的原因不是因为线索的价值提升。原因很简单,当销售坐席已经触达客人,经过努力,客户产生了更深度的用户行为,从而提升了线索价值,这种情况下,如果因为线索价值提升而召回线索,不符合公平原则。从归属的销售坐席手中召回,一般有两种场景:第一种场景,销售高频繁的入离职,我们需要解决销售离职后线索处理问题。第二种场景,在职的销售线索跟进不及时或无效果,需要对这些线索进行处理。常用的召回手段,除了将线索将线索直接召回到线索池,也可以通过转派给其他坐席或销售团队。

二、线索的静默与释放

线索释放与线索召回的区别

将线索分配给销售人员后,为了提升线索的利用效率,也为了督促坐席及时跟进线索,我们对于销售持有线索的时间周期,一般会设定一个有效期。一旦到达了有效期,这样的线索就需要进行回收释放。

线索的回收释放与线索的召回的区别在于,线索的召回是对线索的正常生命周期的强行干预,而线索的回收释放,是系统设定的常规的线索生命周期流程。

线索静默

线索的静默是线索释放过程中一个重要环节。

线索一旦释放,就存在将线索分配给其他销售坐席的可能性。假设A坐席在线索有效期即将到达的时间点,触达客人并且促使用户产生了更深度的用户行为,甚至出现了即将要出单的情况,在这种情况下,线索被回收释放,又分配给了B坐席,最终客户在B坐席手中出单。这种情况会产生内部的纠纷与矛盾,为了避免这样的矛盾,我们一般在线索回收前,会将线索处于静默状态,既不允许原坐席继续跟进,也不会让线索分配给新的坐席。一旦用户产生新的活跃行为,我们可以基于线索的激活规则,将线索重新分配给原销售坐席。

线索的回收释放

线索的释放规则与分配规则一样,需要优先注重效率,但同时兼顾公平。同业务线内,同一个销售坐席,获得的不同的线索类型,可以根据业务的需求,设定不同的回收释放逻辑;同样类型的线索,针对于不同级别的客服,也会有不同的回收释放逻辑。回收释放的逻辑,除了考虑线索类型、客服级别外,同时也要考虑销售坐席对线索的关键销售阶段的跟进程度。比如,我们对于线索类型为“基金商品留资用户”的用户,定义了5个销售阶段:开场白、介绍产品、待支付、已成交、复购其他产品。开场白、介绍产品阶段,可以使用默认的5天线索有效时间;当坐席通过沟通,促成了客户的待支付行为,我们可以将线索的有效时间延长1天,给予坐席更多的时间,将线索转化为成交客户;当用户成交后,我们将线索有效时间延长7天,希望坐席可以推荐客户更多的产品,产生复购行为。这样的释放时间的调整,完全可以基于回收释放规则来实现。

三、线索的激活

线索的激活也可以区分为两类:第一种是在线索静默期内的激活,第二种是线索回收释放后,需要重新激活分配给原坐席。

静默期内激活

其实在上文“二、线索的静默与释放”中提到过,如果用户在回收释放的静默周期内,产生了活跃行为,我们是可以将静默线索重新激活为有效线索,让原坐席继续跟进的。

如果需要进一步细化激活规则,我们可以将线索的激活原因,区分为“坐席原因产生活跃行为”和“非坐席原因产生的活跃行为”。非坐席原因产生的活跃行为包括了“用户自行浏览APP”、“用户浏览投放广告”等。基于公平的原则,因为“坐席原因产生的活跃行为”,我们一般是要无条件分配给原坐席的。但是同样的,基于效率原则,如果是因为“非坐席原因产生的活跃行为”,我们可以根据坐席的等级来决定线索激活策略:高等级销售可以将线索直接恢复,低等级的客服因其能力原因可能没法直接获取该线索,需要将线索强制从静默阶段唤醒,再根据运营设定的分配规则进行重新分配。

释放后的激活——定向分配

线索释放后,已经回归线索池,在这种情况下,是否仍需要将一些特定线索激活分配原坐席呢?

这同样是需要由业务策略决定的。

举例,如果A坐席推荐用户购买了某个需要周期付费的产品,在付费了一段时间后,停止了续费,而这个时候,用户的线索应该早就已经释放回收到了线索池。公司从业务维度一般会将催续费业务和新单业务拆分为两个业务线进行服务,普通的催缴任务不会由新单业务的销售坐席承担催续费的任务。但是,A坐席是直接促成用户出单的销售人员,对用户的需求更为了解,也更应该为用户断缴行为负责,所以在这种情况下,我们是可以通过一些释放后的激活规则,将线索分配回给A坐席的。

再比如,首次分配的线索,销售坐席和客人的沟通中,并没有直接促成客人出单,但是成功通过企微添加了客户的微信。在后续企业微信的沟通中,坐席通过持之以恒的努力,让用户产生了活跃行为,这时产生了新的线索,这样的新线索也理应分配给原坐席,才符合我们的公平原则。

线索释放后的线索激活,这样的客户本质上其实可以认为已经是一条新的线索,更准确地来讲,这种线索的激活是一种定向分配规则。

四、小结

业务的流程阶段、线索的分类、客服的等级,贯穿于整个线索生命周期的管理过程中。只有搭建足够灵活和可扩展的系统基础功能,才能定义出各种精细化的运营规则。所以,在CRM系统的建设过程中,产品经理需要尤其关注对于系统基础功能的建设。

本文由@爱吐槽的徐教授 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。