产品经理在创造AI,到底在创造什么
编辑导语:在商场里经常会看到AI机器人,帮助顾客解答各种问题,以免在顾客找不到工作人员时不知道应该怎么办;AI已经运用到生活中了,提高我们的效率,减少人工的成本;本文作者从AI客服的角度进行分析,我们一起来看一下。
今天想聊的,是最近在做的一个需求:会话智能总结。
这个需求的背景是这样,客服对接待的每通会话都会做总结,包括选择业务分类和填写备注。
这个过程客服遇到的问题是,接待压力大,而需要筛选的分类数量太多,选择小结需要同时兼顾速度和准确性;随之带来的是客服认为选择成本高,影响接待效率。
所以我们想利用AI对用户&客服的会话内容做分析,自动生成总结,不需要客服费尽心思思考,从而帮助客服提升接待效率。
一、遇到的问题
在与算法大大定义总结的分类相关业务意义时,却发现事情远没有那么简单;对于会话选择哪个小结,整个部门没有一个明确标准。
比如某些会话中,用户会咨询多个意图,但现场客服为了省时间只会选择一个,此时质检人员也会认为客服是对的;而我去咨询分类规则制定的业务部门时,他们却希望客服能够选择多个,保证小结的精准性。
可能有人说,那就按照业务部门的意思就好了,客服只是执行者;我曾经想过这个思路,但很快就在与算法同学的讨论中否决了自己。
AI智能总结的能力是有限度的,不能全部交由AI判断,还是需要在AI推荐后由客服确认提交,从降低选择成本去提升效率,而非零成本;此时,若按照业务定义去推荐,客服会认为与自己的选择不一致,不会采纳AI的推荐,从而认为AI是(sha)错(bi)的——这样会导致客服不仅需要选择分类,还要删除分类,成本不降反升。
二、问题背后原因(5Why)
因为一直做的都是B端业务,该类情况在之前的接触中也是经常见到。为什么会出现这种情况,我们可以试着用5Why方式探讨一下。
- 为什么会出现偏差—>业务规则制定过程没有准确同步给客服;
- 为什么会出现同步不准确—>业务人员优先考虑先上线,后完善并同步(然后没有然后—->跟改天请你吃饭的道理一毛一样);
- 为什么会考虑先上线—>业务经常变动,所以及时上线才是最重要的;
- 为什么业务会经常变动—>业务不成熟;
- 业务为什么会不成熟—->公司快速发展中;
所以说到底就是业务不规范导致的管理层预期与客服实际执行有偏差。
如果在成熟度高的业务线,业务与客服对各类事情的预期和理解都是一致的,那这个问题基本不会存在;但全天下又有多少个公司是业务成熟度高的呢?
三、B端产品的困境:规范全流程OR优化一隅之地
从5Why中可以看到,这个问题在很多企业中都是一个高概率事件。
作为产品经理在落地B端产品,为企业提效的时候,往往都是从执行者的效率优化入手,比如钉钉是为了提升员工之间沟通的效率。
但在业务不规范的时候,应不应该去推动全流程的规范,再去讲究执行者效率呢?
还是钉钉的例子,假设现在公司每个部门之间的组织架构很乱,员工A要解决一个技术问题,但BCD三个部门都在互相扔锅,这个情况确实不能指望一个工作类IM工具帮忙解决;看起来要真正为组织提效,就应该规范化整个组织架构,再用上钉钉,才是最完美的。
经济学讲究“激励”,也就是会注重某个事件发生会导致的结果。
所以试想一下,当我们不考虑全业务流的整合,而只是优化一隅之地的效能,最终结果可能执行效率确实有所提升,但业务还是一样乱,一看整体数据并没有提升多少,瞬间就傻眼了!
随之带来的影响是:业务认为产品不行,如果是甲方爸爸甚至不会买单或者不会续费;而产品却认为我确实提供了能力且有效果数据,你怎么能不认可呢,美其名为有限度的服务。
我猜想这可能也是国内B端产品发展缓慢的原因之一;当业务成熟度不高,业务方希望通过第三方帮忙提供解决方案去整体提效,但乙方却只能提供部分能力,这是一个什么有意思的现象呢?
相当于女方结婚要求男方有车有房有存款,但男方只有存款,且还是少量;尴尬的是,女方(甲方)又不可以同时找有车的,有房的,有存款的;但同时有的优质男士又少见。
作为B端产品,规范业务流程又谈何容易?先不说乙方,就算是同在一个公司,产品经理去推动其他部门的业务规整也是吃力不讨好的一件事。
但也不是无解,产品经理一定是解决当下问题且兼顾将来的一个角色;所以在优化执行效率的同时,需要想办法去推动业务的规范化,但实际推动者以及推不推得动的结果,与产品经理的关系就不大了。
说白了,B端产品提供能力是基础服务,提供解决方案才是核心服务。
要跟业务方讲清楚内在的逻辑和影响面,给出规范化的建议和方案(让业务方自个儿去推动);这也是为什么说TOB产品经理必须是行业专家,才能知道能做什么,不能做什么;不能做什么的情况下又能再做什么。
“老婆,虽然我现在没车没房,但是在我的规划中,这两年可以通过你我的共同努力,好好攒一笔钱,两年后可以攒到房子首付,第三年再搞个家用车也是可以的;所以相信我,我能给你带来幸福的!”
四、AI困境:COPY客服OR COPY业务
回到AI这个话题,我思考的另一个角度是:当我在做智能客服产品的时候,我在做什么?
如果我们是为了提升客服效率,按照他们的日常操作选择小结,就相当于我们CTRL C/CTRL V一个客服;如果我们copy的是业务,那还是回到最开始的问题,对客服效率可能不增反降。
这个问题的本质,应该是AI能为人类做什么。
虽然有点大,但我一直认为,AI的使命应该做人类做不好的事情,解放人类去做其更擅长的事情,从而实现比现有社会分工更有效率的人机分工。
假设我们只帮助客服提升其选择小结的效率,那如果有一天咨询量减少了,客服有时间慢慢做选择,此时我做的智能小结所带来的效率提升意义就不大了。
而这件事,客服做得不好的地方在于,客服由于理解偏差,没办法完全按照业务要求选择分类(5why分析导致该现象的必然发生)。
所以,我最终决定,这个需求所创造的AI,是CTRL C/CTRL V业务部门,而非客服部门。
其所带来的负面影响(与客服理解不一致),可以通过推动业务人员与客服的宣导来尽量缩小偏差(如同B端产品提供解决方案类似);也可以梳理会话总结的相关分类的知识库文档,解答客服对AI小结的不解之处;同时,也能让客服从AI推荐的小结中,理解每个会话准确的小结方式,反向又推动了信息的一致性。
所以,AI应该是COPY业务心中的金牌客服!
本文由 @steseven 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
读后感:不论是机器客服还是人工客服,都要遵从业务制定的规则和指标。解决问题,要解决根本。
这和我之前做的政务热线的坐席辅助功能/业务一样。