在我们工作中，能用AI协助做不少事，比如说产品重构。这篇文章，我们从一个案例说起，看看如何用AI重做一款B端产品，帮助大家提高生产力。

关于【如何用AI重做现有产品】这个话题，之前以分享了两篇：

第一篇 如何用AI重做B端产品（附3个案例与3个方法论）？，从方法论与案例进行全面的分享（当时没想到（短期内）这个主题的后续分享）；

第二篇 如何用AI重做B端产品2:从微软与天猫学习，从成熟产品的案例中，明确了两种AI产品架构与产品形态，同时，定义清楚了产品定位与落地场景。

如果回到【以终为始，全面梳理；以始至终，最小闭环】与【小切口，大纵深】的方法论，则它们只完成了【以终为始，全面梳理】部分，而未完成【最小闭环】的【小切口】。

这就是今天分享的主题。

01 如何找到一个应用AI的“小切口”，完成最小闭环？

前文我们分享过【用AI重做智能客服系统】，但没有具体与深入讨论。

基于【需求是1，方案是0】方法论，则需自问：为什么要用AI重做客服系统呢？难道为了AI而用AI？

如何定义B端产品及B端产品经理方法论

相较于C端产品，B端产品最大的特点是：面向特定领域用户，且数量少得多，但更注重对用户专业领域操作流程的深度挖掘——也就是专业性更强，与业务的结合更紧密。

查看详情 >

我们每年需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，目的是交付用户一个正确结果，而不是创意。所以一定要控制大模型含量，保证它输出的结果，要么正确，要么不知道，不能模棱两可，也不能随意发挥。