查看原文
其他

AI + CRM 提高企业的 "绩" 和 "效"

詹坤林 58技术 2022-03-15

导读

2020年Q4,我们开展了黄页CRM商机智能分配项目,上线了机器学习分配模型,在各城市ABTest上线模型期间,将直销团队密歇根商机组的转出商机数提升了31.8%,将电销团队60秒有效通话商机数提升了 62%。


本文收益:了解58销售工作流程,了解CRM逻辑,了解个性化搜索排序、推荐、AI技术在CRM中的应用。


阅读时长:本文共7000字,阅读时长10分钟。

背景

2020年6月,我们AI Lab接手了CRM智能化算法工作。2020年9月,AI Lab、营销平台部(CRM)、LBG黄页业务方三方联合启动了商机智能分配项目,将机器学习和推荐技术应用于CRM,为每个销售人员分配适合其跟进的商机,优化成单转化,以提高销售团队业绩,进而提升业务线收入。

黄页销售团队包括直销、电销两种工作场景:

直销场景:

直销场景下销售人员会通过拨打电话、微信聊天(电话沟通后和用户加微信)、线下外访等方式持续跟进用户。在传统工作模式下,一个销售人员需要全程负责从拿到商机到成单整条链路上的所有工作。

2020年,黄页业务线对直销模式下销售人员工作流程进行了改革,打造了"密歇根"工作模式,在各个城市中将原始一个销售团队拆分成商机组、销售组两个工作组:商机组人员的任务是拨打商机电话以筛选出有可能购买58会员的用户,若用户有一定意向则这类商机被称作有效"转出"商机,"转出"的意思是指这些商机会被转给销售组工作人员,之后该商机就由销售组人员持续跟进,如电话联系、微信沟通、外访,直至成单,整个工作流程如下图所示:

图 传统工作模式 vs 密歇根工作模式

在密歇根工作模式下,商机组的销售人员只会参与整条成单链路上的第一个环节,通过拨打一通电话来判断商机是否可转出,工作非常纯粹,不再需要参与后续深入的跟进、外访等,商机组需要产生更多的转出商机,每个销售人员的业绩指标是转出商机数量。经过商机组的过滤,销售组的销售人员拿到的商机都是有一定意向的用户,销售组只需做好后续的深入跟进、外访等工作,专心提高最终的成单数量。

相比传统工作模式下一个销售人员需要全程参与成单链路上的所有工作,密歇根模式将销售流程进行拆解,商机组和销售组各司其责,整个销售团队的工作效率变得更加高效。

电销场景:

电销场景下销售人员是全流程线上通过拨打电话、微信聊天等方式跟进用户,与直销的差别是无线下外访环节。电销场景下无密歇根工作模式,销售人员需全程负责从拿到商机到成单整条链路上的所有工作。

CRM商机分配逻辑

商机即潜在58会员信息,包括公司名称、行业、地址、联系人、联系电话等信息。CRM系统中包括新增商机、历史商机两类:新增商机指每日新流入的商机,销售人员从未触达过,这类商机量少,但成单可能性相对较高,成单周期相对较短;历史商机指销售人员跟进过但没有成单的商机,这类商机经过长期积累,数量巨大,但成单可能性低,成单周期较长。在日常工作中,销售人员大部分时间都是在跟进历史商机,一个商机往往需要销售人员花数月时间跟进多次才能最终成单

在密歇根工作模式下,CRM系统设计了一系列功能模块来支持销售人员获取商机,具体如下图所示:

密歇根模式下销售人员获取商机流程

基础概念介绍

  • 公海:公海库里存储的是历史存量商机,商机对所有销售都可见,系统通过商销匹配模块将公海商机推送给销售,销售通过一键申领模块从公海库搜索商机。

  • 临时库:销售人员有一个临时库,从公海库获得的商机在销售跟进后可以绑定到个人临时库,绑定后只有销售自己可见。临时库中的商机有有效期限,一般为数天,若某条商机超过时限,会被系统释放到公海库。销售可以自己主动将临时库商机释放至公海。

  • 私有库:销售人员有一个私有库,销售可以从公海、临时库中将商机转移至私有库,私有库也仅销售自己可见。私有库中的商机也有有效期限,时限比临时库更长。销售可以自己主动将私有库商机释放至公海。

  • 沉寂库:若一些商机跟进多次无效果或者用户反感,质量差,系统会将其转移至沉寂库,不再可见。

功能模块介绍:

  • 新增商机分配:每日新流入的商机会由系统分配给销售人员,新流入商机质量高,为保证公平,分配方式是每个销售轮流获得一条。

  • 商销匹配:系统会将公海库中的部分商机主动分配给不同销售人员,每天仅分配一次,在销售上班前分配好,分配数量较少,每人几十条,并且一条商机只能被分配给一个销售,该过程在产品功能中被称作"商销匹配"。

  • 一键申领:密歇根商机组销售人员可以在系统界面上从公海库中筛选商机,销售人员可以根据商机品类、来源等属性字段做筛选,每次可以筛选出几十条,全部跟进完之后才能进行下一次筛选,该功能被称作"一键申领",即从系统中申领商机。这里本质上是一个搜索功能,系统基于Elasticsearch(ES)构建了一套商机搜索引擎。密歇根销售组也有一键申领功能,某个销售在跟进商机(商机组转过来的商机)过程中,也可以释放、绑定商机,释放的商机会被存入一个中间库,其他销售可以通过一键申领功能从中间库筛选商机。

  • 转出商机分配:商机组形成的转出商机会由系统随机分配给销售组的某个销售,这里后续将切换为由机器学习模型来分配。

需要说明的是,商机组的销售人员只有临时库(超时时间24小时),没有私有库。商机组每天的工作是不断打电话,为了防止骚扰用户,CRM限制了一个商机在一天只允许打通一次,打通后销售即可很快判断出是否能转出,不能则可以直接释放回公海,销售没必要将这类商机放到自己的临时库或私有库,因为第二天又有大量新的商机需要处理。这里临时库的作用是存放当前没打通的商机,销售可以选择其他时间再拨打,但若24小时内没处理,自动会释放至公海。

电销模式下销售人员获取商机流程基本和密歇根模式下的商机组一致,如下图所示,不再赘述。

图 电销模式下销售人员获取商机流程

为了便于大家理解,以上描述是对实际流程进行了精简,CRM实际逻辑会更加复杂,这些内容和本文核心目的无关,未做描述。

AI助力CRM:定义问题、确定优化目标

从CRM中销售人员获取商机的流程可以看出这是一个典型的信息分发问题,CRM作为分发引擎在商销匹配模块主动给销售人员推荐商机,在一键申领模块销售人员会主动从系统中搜索商机,我们可以利用机器学习和推荐技术来提高搜索和推荐的效果,以提高最终的成单转化率。

旧系统的缺陷:

在我们接手CRM智能工作之前,CRM系统中已经运行了一个机器学习模块——商机打分。商机打分模块构建了一个以成单率为目标的机器学习排序模型,每日凌晨商机打分模块会对公海库中的每条历史商机计算一个分值,即模型预估出的商机成单率。公海库中的历史商机会按照商机分值排序,在商销匹配模块商机会由一个规则逻辑按照分值从高到低依次分配给不同销售人员,剩余未被分配的商机会进入商机搜索引擎,当销售人员在一键申领场景筛选商机时,搜索引擎会按照商机分值排序返回商机列表,销售人员可以跟进这些商机,在跟进完所有商机后可以继续筛选。

上述方法存在优化目标不直接未充分利用销售人员特征两个问题。首先,商机成单链路长,一个历史商机从某个销售人员第一次跟进到最终成单一般要经历数月,期间会经历数十次跟进,甚至流经多名销售人员(商机被释放回公海后会分配给其他销售人员),单次跟进和最终成单难以构成直接关联关系,而且成单周期长,模型效果难以快速评价,无法进行算法模型的敏捷迭代;成单正样本少,模型正负样本极度不均衡,难以发挥效果。除此之外,在商销匹配、一键申领模块中分配出的商机仅是按照静态商机分值排序,没有使用销售人员侧的特征信息,未实现个性化排序。尽管如此,商机打分模块还是在CRM系统中起到了关键作用,并奠定了一定数据、算法基础。

我们的方案:

我们不直接优化成单率,而是关注成单链路上的数据漏斗,优化链路上各中间环节指标。直销密歇根模式下各个环节业务关注的指标是:商机组拿到商机后,需要通过一通电话来判断商机是否可以转出,关注转出商机数量;销售组拿到商机组的转出商机后,关注首次跟进形成的60秒有效电话商机数,这也很容易理解,用户愿意和销售聊更久才更有可能成单;成单是终极指标。这里的数据漏斗是:转出数 -> 60秒有效通话商机数 -> 成单数,只要提升漏斗前面的数量,成单数也会提升。电销模式下,业务关注电销人员拿到商机后首次跟进形成的60秒有效电话商机数,成单是终极指标,数据漏斗是:60秒有效通话商机数 -> 成单数

密歇根模式下各环节的优化目标

机器学习模型适合优化最直接的目标。在密歇根模式下,可以在商机组的商销匹配、一键申领、新增商机分配模块上线算法模型,优化转出数;在销售组的转出商机分配、一键申领模块上线算法模型,优化60秒有效通话商机数。在电销模式下,可以在商销匹配、一键申领、新增商机分配模块上线算法模型,优化60秒有效通话商机数。

在CRM系统里,销售拿到一个商机列表后需要拨打跟进列表中的所有商机,用户接通后与其沟通,售卖58会员。我们可以借鉴推荐系统中用户的 "曝光 -> 点击 -> 转化" 行为路径,定义出销售人员的 "拨打商机 -> 接通商机 -> 形成转出商机"、"拨打商机 -> 接通商机 -> 形成60秒有效通话商机" 行为路径。在一个新闻推荐系统中用户是基于个人兴趣去点击新闻,若对新闻内容有更深的兴趣会在阅读完后评论、分享新闻。在我们的场景中,从商机被拨打到接通更多是取决于商机,例如商机联系人(用户)当前是否方便接电话、是否反感陌生电话、是否曾经被频繁拨打过、是否有购买会员的意愿等等,从接通到是否形成转化取决于销售个人话术经验、商机联系人的意愿等。这里的核心是对用户意愿度、销售个人经验的建模。

基于这样的定义,若要提高商机组转出商机数可以提升拨打转出率(转出商机数 / 拨打商机数)、提高60秒有效通话商机数可以提升拨打60秒有效通话商机率(60秒有效通话商机数 / 拨打商机数),这类比推荐系统中的曝光转化率(CTCVR)。此外,业务方还关心接通转出率(转出商机数 / 接通商机数)、接通60秒有效通话商机率(60秒有效通话商机数 / 接通商机数),即CVR,该指标反应了接通一个商机后形成转化的沟通成本,CVR越高成本越低,销售效率越高,工作信心也越大。这里CTCVR是主要指标,决定了最终业务结果,CVR是辅助指标,相关指标详细定义如下图。

图 模型优化目标定义

技术实现

问题定义清楚后具体的技术实现就变得简单了,我们只需ABTest上线算法模型和原始逻辑做对比,持续优化算法效果即可。

我们可以看到商销匹配是系统主动推的一个过程,可以采用个性化推荐算法来实现,一键申领是销售主动搜的一个过程,可以采用个性化搜索排序算法来实现

销售人员每天大部分时间是在一键申领场景工作,密歇根商机组的销售人员在该场景下跟进的商机数量占每天总跟进数的70%~80%,产生的转出商机数占每天所有转出商机的60%~70%,电销模式下也类似,优化一键申领场景能够更容易取得收益。因此,项目中我们首先从优化一键申领场景开始,这里大概介绍一下密歇根商机组和电销一键申领场景的技术实现。

原始逻辑是基于检索条件(由商机品类、来源等字段组成)从ES搜索引擎中搜索出满足条件的商机,并根据成单率分值从高到低返回 K 条商机给销售人员。

初期为了加快项目进度,我们直接在原始的搜索逻辑上加了一层机器学习排序模型,首先由搜索引擎召回出按成单率排序的M条商机,M要比K大,在系统性能允许的情况下越大越好,然后由一个排序模型来对这M条商机做精排,最终返回topK条给用户。

排序模型我们选择了XGBoost模型,优化目标为CTCVR,特征上使用了商机特征、销售特征、行为特征、电话语音文本内容特征等。我们最终是想优先提高CTCVR,其次再提高CVR,因此在离线模型实验中我们会关注CTCVR、CVR两个任务的AUC,这些指标的定义见前文第3节内容。通过不断优化,模型在线上ABTest期间取得了明显收益:

  • 在密歇根商机组中CTCVR(拨打转出率)相对提升了 31.8%、CVR(接通转出率)相对提升了 13%。

  • 在电销场景中CTCVR(拨打60秒有效通话商机率)相对提升了 62%、CVR(接通60秒有效通话商机率)相对提升了 41.2%。

目前,线上已100%流量切换至模型。这里需要注意的是,我们的场景和常见的搜索推荐场景不一样的地方是物品(商机)具有互斥性,一个商机由系统分发给了某个销售后就不能再分发给其他销售,这是为了防止多名销售同时跟进用户造成骚扰。

初期阶段的工作其实很简单,但可以看到机器学习模型发挥了巨大机制,效果提升明显。我们继续优化,升级了召回策略,增加了多路检索召回,这里以密歇根商机组一键申领场景为例做介绍,首先使用模型计算出商机的多个分值,除原始的拨打成单率外,还计算了拨打转出率、接通转出率、拨打30秒有效通话商机率(转出商机一般都满足30秒有效通话这个条件)、接通30秒有效通话商机率,然后这些分值在每天凌晨ES更新索引时写入索引,最终线上检索时,可以分别检索出按照这些分值排序的商机。我们也增加了基于FM模型、DNN双塔模型的向量召回,由于最终推出的商机要满足一键申领里销售的筛选条件,向量召回的商机需要经过一层过滤,一般过滤完后数量相对较少。我们选择部分城市ABTest上线了多路召回,上线后模型效果每日稳定提升,拨打转出率(CTCVR)相对提升了20%、接通转出率(CVR)相对提升了19%,目前多路召回在逐步扩量中。在排序模型上,近期我们在密歇根商机组一键申领场景上线了MMoE多目标模型,同时优化接通转出率(CVR)和拨打转出率(CTCVR),MMoE模型ABTest上线后相比XGBoost模型每日有稳定提升,拨打转出率(CTCVR)相对提升了11.9%、接通转出率(CVR)相对提升了10.8%。一键申领场景下个性化搜索排序系统的架构类似推荐系统,如下图所示,这里详细的模型优化细节在后续文章中再做介绍。

图 密歇根商机组一键申领个性化搜索排序

这里需要注意的是ABTest实验的设计,由于销售人员(用户)数量有限且不同销售人员的经验有很大差别,我们不能根据用户来分流,只能采用随机分流的方式,以消除用户经验差异对效果对比的影响。当销售人员在一键申领场景下点击筛选按钮请求后端系统时,系统会将请求随机分发至算法模型或原始逻辑。另外,在销售作业场景下,由于影响因素多,相关指标在不同日期并不会稳定,在对比模型效果时,我们需要看当日ABTest的数据,不同日期前后对比基本无效。下图是线上真实的每日拨打转出率趋势图,可以看到不同日期波动很大。

总结和展望

从我们在一键申领场景取得明显收益可以看出定义机器学习模型优化目标的重要性,机器学习模型适合优化最直接的目标,并需要能快速获得反馈评价,这样才能持续优化。当前,我们主要优化了一键申领场景下的效果,未来将在其余各个模块上线算法模型,提升效果,同时我们也会关注成单数据,由于成单周期一般为2~3个月,当前由于上线时间短,在成单数据上还没看到稳定数据。此外,CRM产品层也会考虑引入推荐功能,当前商销匹配每天仅分配一次商机,不能起到决定性作用,而一键申领本质是一个搜索系统,当销售人员不清楚自己到底该搜索哪些品类的商机时,系统推荐的方式可能是更好的选择。往往一个信息分发系统同时会有搜索、推荐功能,可以由用户自由选择,最大化分发效率。

回到本文的标题《AI + CRM 提高企业的“绩”和“效”》上来,我把标题起得很大,是为了吸引大家的阅读,但本质上前面所讲的技术内容仅为个性化搜索排序,实现方式类似推荐系统,但取得了不错的收益。个人认为发展了数十年的搜索、推荐技术并不能算作AI,因为搜索、推荐系统几乎不需要人工介入,所有评价数据都可以自动获取得到,然而近几年AI浪潮的火热让大家把各类传统的机器学习系统都归类为AI。而基于语音、NLP、图像技术打造的各类感知类、认知类应用可以算作AI,这些应用都需要人工标注训练数据,机器去学习人的经验。

在CRM中我们也应用了语音质检、语音对话这些AI技术:

  • 密歇根商机组销售人员可能会产生不合规的转出商机,我们需要对形成转出商机的电话做语音质检,这里可以使用语音识别技术将录音转译为文本,并使用NLP技术挖掘出语义标签,由机器来自动质检。除了密歇根转出商机质检外,我们还上线了销售高危行为质检,可参考《AI技术如何打造智能语音质检系统》。

  • 销售和用户的沟通录音可以转译为文本,然后挖掘各类语义标签,形成通话摘要,提升销售工作效率。

  • 密歇根商机组的销售人员的工作是通过拨打一通电话来判断商机是否可转出,工作很标准化,机器人在标准化流程中能发挥作用,这里可以使用智能外呼机器人来辅助销售外呼,当前该项工作正在开展中,待后续文章详细介绍。

未来,我们还将探索销售话术学习系统、话术陪练机器人的落地。

个人感想

本节纯为个人观点,从黄页商机智能分配项目中谈自己的两点看法:
  • 保持开放协作的精神。"开放协作"是58企业文化价值观中的一条。本次项目由AI、CRM、黄页业务方三个团队共同完成,这样的项目组里大家必须保持开放协作的精神,为同一个目标而努力。首先本项目是对CRM历史旧逻辑的升级,CRM中相关的规则逻辑代码需要升级去请求AI侧提供的排序服务来完成,这是AI在植入CRM,CRM团队有一个开放的心态来和AI团队合作。其次,商机在CRM展示后,销售在后续具体跟进中所有的数据埋点需要CRM团队去开发,两个团队需要紧密配合。再者,AI团队迭代算法模型产生的阶段性效果需要及时传递。AI和CRM尽管是两个团队,但在项目中需要当做一个团队,相互信任、协同合作。当然,这里最重要的黄页业务需求方,相信AI和CRM的技术实力,支持对CRM做技术升级,愿意付出时间去配合落地。本次项目里,项目组成员很好的践行了开放协作,最终取得了不错的效果,感谢项目组里的每位成员。

  • 坚持长期主义,积累总会有爆发点。这是去年在参加一门培训课程时,一位大咖所说的话,在本次项目中深有体会。本次项目我们使用搜索个性化排序(类似推荐排序)技术解决了问题,对于项目组同学来说是一个新项目,而对于我个人来说这是一件很熟悉的事情。本人自12年参加工作至2019年3月一直从事推荐系统方面的研发,19年3月团队架构调整,主要从事NLP、语音方面的工作。个人对推荐仍保持着较浓厚的兴趣,一直坚持跟进推荐领域的进展,这让我再次开展推荐相关工作得心应手。我们做技术的需要坚持长期主义,持续沉淀,我们积累的技术经验在未来某个时间点可能就会有一个爆发点。

作者简介

詹坤林,58同城AI Lab负责人、算法资深架构师、技术委员会AI分会主席,目前主要负责AI相关产品规划和技术研发,致力于推动AI技术在58同城的落地,打造AI中台能力,以提高前台业务人效、收入和用户体验。目前负责的主要产品包括智能客服、语音机器人、语音分析平台、语音识别、智能写稿、AI算法平台、CRM商机智能分配系统等。
曾任腾讯高级工程师,从事推荐算法研发。硕士毕业于中国科学院大学。

    部门简介

    58同城AI Lab隶属TEG技术工程平台群,成立于2018年5月,部门前身为智能推荐部,目前部门规模为60~70人,包括产品经理、后端、数据、算法开发人员。

    AI Lab旨在推动AI技术在58同城的落地,打造AI中台能力,以提高前台业务人效、收入和用户体验。
    部门介绍,具体见:58同城AI Lab部门介绍
    持续招聘,具体见:58同城AI Lab招聘产品经理、开发工程师

    欢迎关注部门微信公众号:58AILab

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存