B端产品经理的「AI产品错题本」

11 评论 3358 浏览 30 收藏 19 分钟

AI技术正在快速进步,不少人也开始思考是否可以在汹涌的AI浪潮下打造出出色的AI产品。那么,在打造AI产品的过程中可能出现哪些困难?这篇文章里,作者尝试提供我们一些具体AI产品落地实践的案例和故事,一起来看看本文的分享。

科技进步的初期往往是混乱且杂乱无章的,宣传声势浩大,实际成效却微乎其微。首先,某个科技概念下会出现一款代表性的爆款产品,随后,媒体和相关行业人士会大力炒作,以提高社会关注度,使其成为公众热议的话题。当前,各种媒体频道讨论的最多的科技新闻就是以ChatGPT和SORA为代表的生成式AI大语言模型技术。

大语言模型是否会引发新的科技革命还不确定,但确实有人已经通过它赚到了钱。有人通过出售如何使用AI工具的课程赚钱,例如清华大学的博士某一舟;也有人靠其他方式赚到了钱。

当然,最常见的是使用AI工具编写刷屏文章,或者用于自媒体的洗稿。在直播间里,展示一些由AI工具生成的图片和视频,与最新的AI技术产品新闻挂钩,“AI专家”就可以开始向热衷学习的“小白”销售课程了。

其实,现在AI大模型技术的待遇,和前几年的区块链和元宇宙所经历的开头一样的。火爆的技术和概念产品在被爆炒之后,到底如何落地到更为具体的业务领域,给工作和生活带来实际的影响,还需要时间来检验。不可否认,一些工作,例如视觉设计,电商文案确实受到了直接的冲击。但是,这种影响是否会延申到其它行业领域,以及以什么样的形式来影响,都是还是未知。

在Gartner在2023年发布的”AI炒作曲线”,生成式AI和大语言模型前后脚的处在“期望膨胀之巅”的最顶端。接下来都要经历一段幻想的破灭,然后技术概念的忽悠逐步归于平淡,返璞归真,才是真正大规模实际应用的开始。

从科技趋势来看,生成式AI和大语言模型一定会对互联网产品的打造带来影响,这是不可避免的事实。所以产品经理,特别是2B类型的产品经理,需要透过表象来正视这项科技。通过学习和使用,来体会它对产品的搭建带来的影响,以及给产品经理能力带来新的要求。

生成式AI在2B产品的现状

在实际的企业应用层面,基于大语言模型的2B产品并没有什么成功的落地案例或者爆品的出现。原因之一就是大语言模型本身的局限性。

将业务知识整理为训练大型模型的语料是一个巨大的工程,因为很多知识是隐性的,没有文档化,文字记录,而是通过口口相传或面对面交流的。将这种隐性知识整理成模型可以理解和消化的训练语料是一项重大任务。

虽然基础模型在通用事务和知识应用层面的质量很好,但在企业级应用和创建新产品时,现实却很骨感。如果没有将企业的业务知识有效地转化为模型需要的上下文,那么在日常工作中使用AI进行业务处理是无法得到想要的结果的。

2B产品经理是针对企业的业务活动和业务痛点来打造产品的。现在的产品开发过程当中,产品经理抽象和汇总了业务逻辑,然后提供给研发人员落实在产品当中。如果产品经理需要借助大语言模型来设计和搭建能够落地给企业用户使用的产品,首先的要求就是AI模型在业务知识上的可靠性。

我的失败产品

做为产品经理,我和团队在公司自研业务平台上,尝试了各种的AI产品的应用场景。可惜成功的寥寥无几,可谓广种薄收。从产品成功的角度来说,确实是乏善可陈。但是从工程的角度来说,我们的一次次失败,虽然无法告诉我们什么是成功,但是至少告诉我们什么情况下,一些表面看起来十分“正确”和“有价值”的产品是不成功的。

这个系列的撰写,就是想跳出媒体里那些抽象的焦虑贩卖,也打破理解AI底层复杂原理的知识瓶颈。给日常的普通人,或者正在从事产品经理岗位,而不得AI产品法门的朋友们提供一些具体AI 产品落地实践的案例和故事。

通常来说,大家在做产品的时候,总是偏好于关注什么是一个成功的产品,或者热衷于分析某个爆品,想告诉大家什么是对的。但是面对AI 这个新的生产力和技术来说,它的应用还远远没有成熟到可以通过以往的成功来支撑和引导未来的成功产品。

在现阶段,最重要的是通过不断的尝试来了解和体会,AI 是什么。在这个概念下,AI它不能做什么,它不是什么。只有清楚的了解了这个技术的边界和范围,我们才有可能更加在聚焦的在它可以做的,可以发挥能量的地方,做出成功的产品。

我把这个系列的文章命名为错题本的意义就在于此。希望能通过介绍在过往半年当中,我们失败的产品来给大家一些接地气的感受。为读者在未来的AI 产品搭建和实践当中做出自己成功的产品。

💡 Fail Fast, Learn Faster

错题本的产品清单

  1. 产品#1:用户情绪旅程图
  2. 产品#2:智能工单状态提示助手
  3. 产品#3:智能语音客服代表

我会按照以上顺序,为大家逐个介绍我们的失败产品。以下为此系列的第一篇。

产品#1:用户情绪旅程图

💔业务系统里,基于AI的产品:用户情绪旅程图,从出生到死亡不足2个月。

1. 业务痛点

无论你的企业是售卖产品还是提供服务,客服/售后都是必不少的业务环节,例如,家里的电器维修,保险理赔申请,网购投诉等等。通常,企业都会使用各式客服渠道来接收和管理用户请求。客服人员在接到用户诉求信息后,会在企业的业务运营系统里去快速查找相关的工单记录,采取相应的处理措施。

用招商信诺人寿保险来举例。当保险客户需要申请理赔,或者后续跟踪理赔进度的时候,用户可以打开招商信诺提供的APP客户端,然后在客户端提供的交互界面里,采用点击或者文本输入的方式提供与诉求相关的信息。

采用类似的方式获得信息后,一般企业运营系统将会分类处理:

  • 如果是创建服务工单,系统将依照业务流程指定的逻辑来执行相关的功能。 例如,依照客户对创建服务工单事项的描述,对应的服务类型被确定,然后系统里预设定的业务逻辑会判定出此工单的优先级。 接着运营人员会操作系统,指派对应的责任人,从而依次分发,按需处理。
  • 如果是追踪服务工单,系统会记录下来这次客户所提供的信息。当运营人员在操作系统处理该工单的时候,会参考相关的信息。

通过上面的描述,你会觉得整个服务处理过程已经相当结构化,按照运营流程按部就班,很有逻辑性。但是在这样的系统“理性”逻辑判定运行逻辑的背后,是丢失了为客户服务的“感性”部分。

在服务工单的整个生命周期里,会有不少的“感性”信息交流。无论是在创建工单期间提供的事项描述里,还是后期追踪进度的行为动作,例如,留言的内容,留言的次数,其它沟通渠道的交互行为等,都是用户感性情绪的表达。这个维度的信息,是现有运营系统平台没有关注的,也没有被收集归纳,落实到客服运营活动当中。

而“感性”部分的信息,在很多情况下是会转化服务工单本身的性质,从一个普通服务工单,变成一个高优先级的重要工单。如果处理不当,会极大的影响客户满意度,甚至带来高额的业务损失。

例如,暖气保修的默认SLA为一个48小时的普通服务工单。但是,在实际保修的案例里,如果在冬天,客户家中有新生儿或者老年人,急需稳定的暖气供应维持日常生活。又或者,在某保险申报案例里,客户已经多次联系客服人员处理事项,但是一直没有解决问题,客户关系已经十分紧张。这些在服务事态里所包含的“感性”信息是没有被“理性”的系统关注到,也没有具体落地的产品功能来支持。

根据行业统计,企业客服运营资源的分布也是遵循 2/8原则,既常规的客户服务与运营只占用了运营团队的20%的资源;而安抚不满意的客户和异常处理所消耗的资源,占到了80%。控制异常,维持稳定运营节奏是关键的业务目标。

为了从更全面的角度来监督和管控服务工单的优先级,预防运营风险,和提供更优质的服务,业务部门需要引入产品功能来更好的了解和评估工单的“感性”状态,做出对应的优先处理动作,例如,预先给客户电话做服务关怀,催促服务人员快速反应,调整工单优先级等等。

引入“感性”维度的产品,从而立体而全面的服务客户,提高用户满意度,维持高效运营,这样的业务痛点和诉求就放在了产品团队面前。

2. 产品方案

产品方案的设计思路是来自于产品经理常用的设计工具,用户旅程地图。

在服务工单的整个生命周期里,客户会在不同阶段,使用不同的沟通工具来对服务工单的进行跟进。通过监控对应的文字输入渠道和行为数据(例如,App里的报单信息录入,电话询问频次,系统留言等),汇总后提交给ChatGPT进行语义与情绪数据分析,当ChatGPT返回了对应的情绪结果后,运营系统接收相关结果,以情绪标签的方式展示在对应的工单上。

落实到具体产品实现效果,效果图所示。在现有的单个工单管理界面上,添加了新的情绪标识,实时的反馈该工单所关联的用户情绪和紧迫程度。当用户在被监控的沟通渠道上提供了的反馈,例如,留言和邮件等,后端的情绪分析机制会被触发,用户信息被发送给ChatGPT,做语义情绪解析。通过不同的表情符号,和字体颜色组合,可以给客服人员最直观的信息传达。

另外,在实时的各个情绪信息之上,匹配时间轴,还搭建了对应的情绪旅程图,全面的展示工单相关情绪的变化,让CSR做出更好的从“感性”角度的评估。

除了实时的情绪展示在工单管理界面上,当鼠标悬浮在对应的图标上时,按时间顺序排列用户情绪图标变化被串联起来,形成了用户情绪旅程图。运营人员可以通过观察整体的情绪历史,从“感性”角度采取服务措施。

众所周知,产品经理最重要的能力就是实现业务价值,持续交付。验证业务价值的基础就是产品数据的收集与分析。通过用户产品使用数据的分析,我们可以迭代优化产品,提升产品的业务价值。

3. 数据分析与洞察

用户情绪旅程图在去年12月分上线。同时我们使用数据埋点和分析工具为此产品搭建了匹配的数据收集和分析方案。在产品上线一个月后,我们把抓取的数据经行了清洗,在随后的数据分析里,得到与预期相差甚远的结果。

从这张数据图表可以看出,产品在上线初期出现过短暂的使用高峰后,客服人员的使用频次呈现断崖式的降低。到后期基本没有什么使用的数据。通过不同的数据组可以看出,用户数和点击数并不重合,因此表示,有用户多次点击使用产品的情况。

从整体上来说,产品的使用率非常低。并没有达到业务预期的效果。但是,关注个体数据的时候,我们又有不一样的发现。

我们单独提取出情绪标识被点击的工单做个案分析。通过阅读客户留言和听取谈话录音发现,这些被点击的工单确实是比较符合当初产品设想。既,工单本身被系统逻辑判定的处理优先级比较低,可以按标准SLA处理。但是情绪图标提示了客服人员需要关注实际的客户情绪,采取对应措施。

以下是一些个案留言:

“你们为什么总是不和我沟通就派人上门?我不要上班啊,没有自己的生活安排啊。不知道你们是怎么做决定的” – 客户A

“为什么安排的人没有出现?不是说好今天上门维修的么?我今天还特意请假在家等着。结果被你们放鸽子!我的浪费的假怎么算?!” – 客户B

这样产品整体的使用失败和个案的成功,说明了产品所针对的业务痛点问题是存在的,但是体量和效果不足以说明本产品对业务整体的价值。

4. 总结

用户情绪旅程图产品的立意和设计都有涉及到用户的痛点和目标价值。我们借助GPT对语义里的情绪识别,试图使用这个信息来构建立体的客服运营流程,提高用户满意度和运营效率。但是在实际的使用过程当中发现对应的产品使用率并不明显,并没有达到预期的效果。对于运营来说更多是一种锦上添花,而非雪中送炭的结果。

从投入和产出比的角度来看,此产品只达到了工程的成功,而未到达业务的成功。为业务提供的价值不显著。所以说,结合AI技术落地的企业产品并不会是一番风顺的。企业业务活动和运营行为很多时候是隐性的,现在的AI技术还无法有效嵌入活动中,直接起到效果。

本文由 @豆子面包 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 实际上2B的产品功能不能单纯的从功能的便利性来考虑,产品功能往往是企业管理诉求的体现,文中的客户情绪功能只看到了功能的设计和实现,实际上是缺少企业管理要求和制度的,这也是在功能上线一段时间后,使用频率断崖式下跌的原因,这个功能是没有或者说缺少生命力的。一个好的2B产品,背后都是有管理要求和制度的体现的,而产品功能只是实现管理目标的方式方法。一套管理制度的考核目标和关键数据,这些通过产品功能的方式进行记录和汇总,至少在企业内部来说,有从上到下的生命力,对于我们产品经理来说,功能设计和上线也会有多个切入点和抓手。

    来自河南 回复
    1. 完全同意了👍。所以这也是关于AI技术(大语言模型)是否能落地影响企业运营思考之一。网络上宣传都是很乐观的AI可以改变企业运营活动,提升业务表现。但是实际在落地具体2B产品的时候,技术成功只是最终产品成功的第一步。

      来自湖南 回复
  2. 写得不错 快更新!!
    关于情绪旅程图我的看法是直接展示的情绪标记就已经是足够且高价值的,因为能直观看到用户迫切程度来决定处理优先级,感觉对客服是很实用的。
    但是旅程图我并不认为对客服工作有什么作用,看见反馈者从好心情到坏心情和直接看到坏心情对客服来说有啥区别呢?特别是反馈很多的情况下更不可能一个个点击去看了。可能后面复盘客服处理质量,统计坏心情到好心情的工单数量对管理者来说还有点用,但是实际来看,能够产生有价值的旅程图的数量感觉也不多,实际有查看价值的其实也就是用户问题还没解决那一阶段的情绪。

    来自广东 回复
    1. 收到,最近在做一些能成功的产品,希望是未来的《AI产品对题本》的素材😀。
      你说的很对。这个状况是个痛点,但是解决痛点怎么传递为整个运营服务部门的效益上,还是效果不明显。只有出了重大事故了,才会回过头来看,当时为什么没有从与客户交流的渠道里识别出风险。

      来自湖南 回复
  3. 单纯从产品层面,能相对准确的反应客户的真实情绪,我认为就已经很成功了。至于要让客服更多的使用起来,这需要结合管理制度的考量。如果客服不看客户情绪,对公司有什么的影响?对客服个人又有什么影响?如果客服关注客户情绪,他又能有什么改进工作?对公司有什么影响?对个人有什么影响?很多时候组织体系的问题在于没有实现激励相容,这是意愿问题;另一方面就是能力问题,知道了也没招。

    来自北京 回复
    1. 有道理是👍,所以To-B的产品的业务成功与否牵制的因素太多,产品本身搭建完成只是一小部分,怎样能让使用者受益,让业务收益,并有如何固化这个行为是产品搭建之外的功夫了。

      来自湖南 回复
    2. 给意见点赞。好的功能需要搭配好的制度,如果新制度增加了极端案例的处理要求,也就是考核方向同时兼顾缓和用户情绪,从上至下,兴许就能用起来了。之后再对价值进行复盘,后续逐渐可能站得住脚了。
      睡白了,没有解决客服为什么要用的问题

      来自中国 回复
  4. 文章内容很好,可惜没有对客服人员使用频次断崖降低的原因做进一步的分析

    来自广东 回复
    1. 好问题,这个当时是有和运营部门有过沟通。主要原因是2点
      1. 运营人员需要改变常规的运营操作习惯。需要在之前的操作流程之外,需要记得查看情绪信息做为参考
      2. 文中也提到,实际日常运营里,这种情绪会影响具体业务的案例,占比不高。客服人员没有固化这个行为。
      所以,从功能和工程上来说,是个成功的交付。但是从商业和业务来说,并没有达到预期效果

      来自湖南 回复
  5. 虽然第一反应是用户情绪地图这个是伪需求,或者说没有对需求做考证就下手了,但是还是未事后有数据分析复盘功能点赞。

    来自广东 回复
    1. 嗯,感谢评论。

      这是一个B端产品开发一个容易出现的问题。就是业务部门负责给产品提需求或者业务痛点的人,是有自己信息茧房的。他/她做为领导,平时收集运营问题的时候,是聚集了整个部门的客服人员反馈,总量很多,所以感觉整个问题的密度很高。但是实际平均到每个客服人员,这类问题又占比不高。

      所以这样的,2层次对业务现状的理解,就会造成产品落地时候的脱节。因此,数据埋点来测量实际使用者的结果,是校验产品成功与否的重要手段。

      来自湖南 回复