30. 企业智能客服：售前售后服务进阶

在上一篇中，我们探讨了如何优化企业智能客服系统，特别是在售前和售后服务方面。我们主要关注了两个核心功能的实现：

1. 基于知识库的问答系统：我们创建了一个汽车故障处理的知识库，使智能客服能够根据用户的问题提供准确的故障处理方法和建议。

2. 用户预约功能：我们设计了一个完整的工作流，允许用户通过智能客服系统预约汽车保养、试驾等服务，并能够查询自己的预约信息。

这些功能的实现涉及了知识库的创建和导入、工作流的设计、数据库的使用，以及如何将这些元素整合到一个统一的智能客服系统中。

在本节中，我们将在此基础上进一步深入，探讨如何通过具体业务划分，将智能客服系统进一步优化。

需求分析

这次的优化，我们会将功能划分为三大类，每一类分别都会有相应的功能进行处理和实现，具体如下：

1. 销售顾问：

   • 新增给客户推荐汽车的功能，当用户咨询汽车时，智能客服能够根据用户的需求，推荐合适的汽车。
   • 复用之前的客户预约试驾功能，当用户咨询试驾时，智能客服能够根据用户的需求，满足试驾预约的需求。

2. 售后服务：

   • 复用之前的客户预约保养功能，当用户咨询保养时，智能客服能够根据用户的需求，满足保养预约的需求。

3. 技术支持和维修：

   • 复用之前的汽车故障处理回答，当用户询问汽车相关的故障问题时，智能客服可以快速响应用户咨询，提供准确的信息，并引导用户进行下一步操作。

可能你会发现，这里我们并没有新增很多新的功能，而是将之前已经实现的功能进行复用，但是这次功能优化的核心是，让大家可以有一个更好的结构化设计思维，让大家以后可以基于这个设计模式来进行更简单的功能扩展和维护。

基于我们这次分成三大类的业务功能，我们首先要记住一个重点：每个业务类别之间的需求设计一定不要有交集！ 就好像假设你是一个人力资源专员，在公司里你应该是做好自己人力资源的职责，比如招聘、培训、绩效、员工关系等，而不是越俎代庖去干销售、市场、财务等部门的事情，这样会导致你的工作内容变得非常混乱。设计 AI Bot 的功能实现也是类似的道理。

操作步骤

我们先来看看这次优化的最终版是怎样的：

从图中的功能分类可以看出，每个类别的业务功能都是各自为政，互不干扰的，这样设计的好处在于，当某个业务类别的需求发生变化时，我们只需要修改对应类别的功能实现，而不会影响到其他类别的功能实现。接下来我们一个个来说说。

销售顾问功能拆解

这次我专门独立出来了一个工作流car_pre_sale_service_handler来应对所有的销售顾问功能，我们来继续讲解里面的核心功能（工作流分享链接等待审核通过后会放在下方）：

工作流 car_pre_sale_service_handler 详情

用户咨询汽车推荐时，大模型就会调用这个工作流，然后工作流就会在开头检索用户有没有填写身份证 ID，如果没有填写，就会引导用户填写，然后根据用户填写的信息，使用下方的意图识别节点来识别用户具体要想咨询的事项：

新功能：客户购车意向

意图识别节点识别到要推荐汽车后，就会调用推荐汽车的子工作流get_customer_car_intent：

工作流 get_customer_car_intent 详情

为了这个功能，我也创建了一个新的数据库表，表名为 customer_purchase_intent，表结构如下：

1. 了解购车动机：purchase_motive 字段记录客户的购车动机。

2. 判断购车经验：is_first_purchase 字段用于区分是否为首次购车。

3. 了解预算情况：

   • budget_range 记录客户的预算范围
   • loan_or_full_payment 表明客户是倾向于全款还是贷款购车
   • extra_cost_budget 记录客户对附加费用的预算

4. 分析客户偏好：

   • type_preference 记录客户对车型的偏好
   • brand_preference 记录客户对品牌的偏好
   • specific_function 记录客户对特定功能的需求

5. 了解使用场景：usage_scenario 字段记录客户的用车场景。

这个表的设计可以帮助销售顾问更好地了解客户需求，从而提供更精准的车型推荐。通过分析这些数据，智能客服系统可以根据客户的具体情况和偏好，推荐最适合的汽车，提高客户满意度和成交率。

而且有一个重点时，我设计的所有数据库全部都是多用户模式，这个核心目的在于，我们之后可以扩展功能，设计一些管理数据的功能把这些用户数据导出，然后给到销售顾问进行客户跟进甚至是后续的二次营销。

好，我们接着来看这个子工作流，基于已有的用户身份证 ID，我们先去这个数据库查询一下是否已经有用户填过这个表了，如果有的话，我们就会显示给用户之前的推荐意向记录并询问用户是否继续沿用，如果用户选择继续沿用，我们就会使用之前填写的数据，如果用户选择重新填写，我们就会引导用户重新填写这些信息：

如果用户确定了要重新填写的话，这里和用户没有先前推荐意向记录是一样的后续步骤，就是要开始填写自己专属的推荐意向：

1. 购车动机： 工作流首先询问用户的购车动机。这可能包括是否为首次购车、是否是为了升级现有车辆、家庭需求等。了解用户的购车动机有助于销售顾问更好地理解用户的需求背景。

2. 购车经验： 接下来，工作流会询问用户是否为首次购车。这个信息对于后续的推荐和沟通策略非常重要，因为首次购车者和有经验的车主可能需要不同的指导和建议。

3. 预算情况： 工作流会详细询问用户的预算情况，包括：

   • 预算范围
   • 是否倾向于贷款或全款购车
   • 对额外费用（如保险、税费等）的预算考虑 这些信息有助于推荐符合用户经济能力的车型。

4. 车型偏好： 用户会被询问对车型的偏好，如轿车、SUV、MPV 等。这有助于缩小推荐范围。

5. 品牌偏好： 工作流会询问用户是否有特定的品牌偏好。这可以帮助销售顾问了解用户的品牌忠诚度或兴趣。

6. 特定功能需求： 用户可以表达对特定功能的需求，如自动驾驶、高性能音响系统等。这有助于推荐具有这些特性的车型。

7. 使用场景： 最后，工作流会询问用户的主要用车场景，如城市通勤、长途旅行、越野等。这有助于推荐最适合用户日常使用的车型。

这里每个步骤都使用了单独的对话节点来获取信息，可以确保每个问题都得到清晰的回答。

获取到对应的回答后，就是展示给用户看收录到的整体内容结果了，并且基于此来写入到数据库中：

下一步就是通过一个文本处理节点将这个最终的推荐意图结果整理起来输出到结束节点，好让后续的父工作流去使用了：

当然，如果前面的步骤在意图识别节点时就识别不到这个子工作流支持的功能的话，就会统一返回一句客户给到的购车需求为空，用作后续的父工作流处理：

好了，这就是整个子工作流get_customer_car_intent的具体流程了，我们继续拿着它最终的结果走父工作流后续的过程。

后面的流程其实不难，就是使用了一个插件WebPilot来基于这个推荐意向网络搜索结果来返回合适的答案了：

最后就把得出的结果转发给结束节点返回给用户了，这就是新功能客户购车意向的全部内容了。

功能：客户试驾预约

基于上一篇的内容，客户试驾预约功能是通过复用之前实现的工作流来完成的。这个功能的主要流程如下:

1. 身份验证:

   • 检查是否已有用户 ID(身份证号)
   • 如果没有，引导用户输入身份证号并保存

2. 意图识别:

   • 使用意图识别节点确定用户是否想预约试驾

3. 收集预约信息:

   • 使用一系列问答节点收集必要信息:
     • 车型
     • 预约日期
     • 联系电话
     • 其他备注

4. 数据库操作:

   • 将收集到的预约信息写入数据库，包括:
     • 预约类型(试驾)
     • 用户 ID
     • 车型
     • 日期
     • 联系方式
     • 备注等

5. 确认预约:

   • 向用户确认预约信息已保存

这个功能与保养预约的流程类似，只是在预约类型和可能的一些具体问题上有所不同，比如这里的流程就没有了判断汽车保养的功能了，因为这个功能被挪到了售后服务功能范畴里面了。通过复用这个结构，可以快速实现试驾预约功能，同时保持系统的一致性和可维护性。

售后服务功能拆解

售后服务就单独使用了以下的工作流来应对：

工作流 car_service_advisor_handler 详情

功能：客户保养预约

这里的功能和上述的客户试驾预约的流程是类似的，毕竟也是复用的功能，只是当前这个功能被挪到了工作流car_service_advisor_handler里面而已，这里就不多赘述了。

技术支持/维修功能拆解

基于上一篇的内容，技术支持和维修功能主要是复用了之前创建的汽车故障处理知识库。这个功能的主要流程如下:

1. 知识库创建:

   • 创建了一个名为汽车故障处理方法合集的知识库
   • 导入了包含故障现象和处理方法的问答集(约 200 条)
   • 选择故障现象作为知识库的索引

2. 知识库集成:

   • 将创建的知识库添加到 AI Bot 中

3. 用户查询处理:

   • 当用户询问有关汽车故障的问题时，AI Bot 会自动从这个知识库中检索相关信息
   • 根据用户描述的故障现象，匹配最相关的处理方法
   • 向用户提供准确的故障处理建议

4. 响应生成:

   • AI Bot 使用自然友好的语言，将从知识库中检索到的信息转化为易于理解的回答
   • 提供专业的故障处理建议，帮助用户解决车辆问题

最终版功能演示

这里我继续直接给一个长对话的演示，让大家感受下整个流程的完整性：

这个截图展示了一个智能客服系统的完整功能演示，涵盖了文章中提到的多个核心功能。让我们逐一分析：

1. 身份验证： 对话开始时，AI Bot 首先要求用户提供身份证号码，这是进行身份验证的关键步骤。

2. 销售顾问功能：

   • 购车意向调查：AI Bot 引导用户完成了一系列关于购车意向的问题，包括购车动机、预算、车型偏好等。这些信息被用来为用户推荐合适的车型。
   • 车型推荐：基于用户提供的信息，AI Bot 给出了详细的车型推荐，包括具体型号、价格和特点。

3. 试驾预约： 用户表达了试驾意愿后，AI Bot 立即引导用户完成试驾预约流程，收集了必要信息如试驾车型、日期和联系方式。

4. 售后服务：

   • 保养预约：AI Bot 展示了如何帮助用户预约汽车保养服务，同样收集了必要的信息。
   • 预约查询：用户能够查询自己的预约记录，AI Bot 准确地从数据库中检索并展示了用户的所有预约详情。

5. 技术支持和维修： 当用户询问关于汽车故障的问题时，AI Bot 能够从知识库中检索相关信息，提供专业的故障处理建议。

总结

这次本文详细介绍了一个高度优化的企业智能客服系统，专门针对汽车行业设计。这个系统成功地将销售顾问、售后服务以及技术支持/维修功能进行了清晰的划分和整合，展现了以下几个关键特点：

1. 结构化设计：通过将功能分为三大类（销售顾问、售后服务、技术支持），实现了清晰的业务划分，便于后续的扩展和维护。

2. 功能复用与创新：在已有功能的基础上，新增了客户购车意向分析等创新功能，同时合理复用了试驾预约、保养预约等现有功能。

3. 数据驱动：引入了新的数据库表（如 customer_purchase_intent），用于存储和分析用户的购车意向，为个性化推荐提供数据支持。

4. 工作流优化：通过精心设计的工作流（如 car_pre_sale_service_handler），实现了从用户意图识别到具体服务提供的全流程自动化。

5. 知识库应用：利用已建立的汽车故障处理知识库，为用户提供准确的技术支持和维修建议。

6. 用户体验优化：通过自然语言交互和多步骤引导，提供了流畅、友好的用户体验。