在我们工作中，能用AI协助做不少事，比如说产品重构。这篇文章，我们从一个案例说起，看看如何用AI重做一款B端产品，帮助大家提高生产力。
关于【如何用AI重做现有产品】这个话题，之前以分享了两篇：
第一篇 如何用AI重做B端产品（附3个案例与3个方法论）？，从方法论与案例进行全面的分享（当时没想到（短期内）这个主题的后续分享）；
第二篇 如何用AI重做B端产品2:从微软与天猫学习，从成熟产品的案例中，明确了两种AI产品架构与产品形态，同时，定义清楚了产品定位与落地场景。
如果回到【以终为始，全面梳理；以始至终，最小闭环】与【小切口，大纵深】的方法论，则它们只完成了【以终为始，全面梳理】部分，而未完成【最小闭环】的【小切口】。
这就是今天分享的主题。
01 如何找到一个应用AI的“小切口”，完成最小闭环？
前文我们分享过【用AI重做智能客服系统】，但没有具体与深入讨论。
基于【需求是1，方案是0】方法论，则需自问：为什么要用AI重做客服系统呢？难道为了AI而用AI？
我们每年需1.2个全职研发员工（且必须对业务、系统非常熟悉之人），才能解决所有客诉问题。其中：
- 65%的客诉问题，均集中在加班、假期、报表与打卡四个模块；
- 70%的客诉问题，均是两大类问题：客户操作与客户信息查询。
如果把上述四大模块的两大类客诉问题全部解决，则至少可解决47.08%的客诉问题，每年节约581工时（大概76/人日，约3.3个月）
笔者是经历了3轮的解决方案与不断调试，最终才真正找到了一个AI应用的小切口。
第一轮：只聚焦加班与假期类问题，通过构建知识库+AI的方式有效解决客诉问题
从上述分析可知加班（18.35%）、假期（18.26%）占比最高，所以把它们当做切口，而其中最核心的就是【知识库】的建设。
第一，建设知识库。所以把这两个模块近2年的所有客诉问题，进行抽象与提取，加上之前客服所累积的内容，最终形成了一个【知识库】（共4万+知识点问题，其中加班与假期相关超过300+）
第二，应用知识库。基于AI+知识库，我们把它分别应用于内部跟外部：
- 内部：面向实施、客成、客服、研发、测试等角色，把它应用在【客诉问题】平台上。即当他们提客诉问题时，AI自动根据问题给出【AI解答】，最终由研发人员确认后给出最终答案（如下图）。
- 外部：面向的是用户、客户，与一般客服助手无异，不再赘述。
最终结果：运行近2个月的效果来看，对客诉问题，几乎没有明显的帮助。但过程中，又发现了另一个值得优化的问题点。
第二轮：聚焦加班的最高频问题，构建对应全面的案例与解决方案加班相关问题中，有近30%是一类问题：员工加班后，却没有生成加班记录？
如果只聚焦这一个问题，至少可解决5.4%的客诉问题（加班占总比的18.25% x 此问题占加班类30%≈5.4%）
所以制作了一个关于此问题的全面解析，包含加班规则、记录丢失原因以及对应的案例、解析、如何确认、如何解决，期望至少内部员工（客成、客服、实施等），可借此解决此类问题。
最终结果：在试运行了1周后，发现效果依然不佳。原因是：无法精准有效定位问题，可能性较多，每次发生情况有差异，这么一个“全面”的文档，几乎无意义。
第三轮：构建企业的AI Copilot，不仅仅解决客诉问题第一轮跟第二轮效果不佳的原因，是均只是在产品规则、逻辑等层面，不断增加知识库的广度与深度，但都是是静态数据，无法有效解决动态的客诉问题，而如果要解决动态问题，只能选择AI Copilot的方式。
它可以识别任务、分解任务、执行任务，最终解决用户问题。它必须具备与业务数据和场景的（多轮指令）交互能力。
比如类似ChatGpt的官方案例
同理，作为一款SaaS产品的Copilot，它的定位是AI Copilot = 客服助手 + 业务助手+ 数据助手+政策专家。它是基于自然语言交互的生成式AI，而不是决策型AI。
- 客服助手（现有能力P0）：可以查询产品手册、产品规则、产品逻辑等，解决用户对复杂系统的学习成本；
- 业务助手（新能力P1）：可以查询系统的操作记录、业务数据，定位用户问题（即分析任务）、分解用户问题（即分解任务），最终可通过多轮指令完成解决问题（即执行任务），并自动完成学习反馈；
- 数据助手（新能力P2）：可以查询、展示、分析业务数据，并给出决策建议以及行动；
- 政策专家（新能力P3）：可以查询相关的各类政策，用户还可订阅最新消息。
02 小切口的最小闭环：如何解决占比5.4%的“员工加班后，却没有生成加班记录”的问题？
日拱一卒，功不唐捐，每天向前30公里。
所以，我们的最小可行性版本是：
它聚焦解决一个“小问题”：客诉问题中占比5.4%的【加班后，为什么不生成加班记录】
- 它的目标是：用最小投入解决【加班记录不生成】的客诉问题；
- 它的价值是：用最小成本提升对应问题的人效，释放产研资源。同时，用最小成本跑通AI Copilot的模式，验证可行性与价值。
- 它的能力是：清晰定位限定问题的原因，并给出解决方案。
- 它的产品形态是：结合现有的客诉平台，完成最小成本的闭环（如下图）
03 总结
1、需求是1。笔者的需求是：如何用AI解决47.08%的客诉问题，提升产研效率？
2、方案是0。笔者的方案经历了三个阶段：
- 第一阶段：聚焦客诉问题占比最高的两个模块:加班（18.35%）、假期（18.26%），专注于构建知识库的丰富性与落地验证，结果失败；
- 第二阶段：聚焦一个加班的高频问题（即占比5.4%的加班后，无加班记录问题），采取全面场景与案例结合方式，结果依然失败；
- 第三阶段：依然聚焦占比5.4%的加班后，无加班记录问题，但重新设计新的MVP解决方案（即AI Copilot），结果待验证（思路没问题，效果不佳则一定是执行环节的问题）；
3、以终为始，全面梳理。
- AI Copilot的产品定位与终局：客服助手 + 业务助手+ 数据助手+政策专家；
- AI Copilot的产品形态：基于【全功能集合中心式】的产品架构（类似Microsoft Copilot或有赞智能运营助手）；
4、以始至终，最小闭环。通过三个阶段的摸索，最终确认Copilot的MVP方案，专注于一个最高频的问题（即加班后，无加班记录问题）。
5、关键认知：To B/SaaS等企业服务类产品落地AI，目的是交付用户一个正确结果，而不是创意。所以一定要控制大模型含量，保证它输出的结果，要么正确，要么不知道，不能模棱两可，也不能随意发挥。
专栏作家
邢小作，微信公众号：邢小作之家，人人都是产品经理专栏作家。一枚在线教育的产品，关注互联网教育，喜欢研究用户心理。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
友情提示
本站部分转载文章，皆来自互联网，仅供参考及分享，并不用于任何商业用途；版权归原作者所有，如涉及作品内容、版权和其他问题，请与本网联系，我们将在第一时间删除内容！
联系邮箱：1042463605@qq.com