在数字化转型的浪潮中，智能客服已成为企业提升服务效率和客户满意度的关键工具。然而，许多企业在搭建智能客服系统时，往往忽视了运营分析这一重要环节。本文将从实战经验出发，深入探讨智能客服搭建的第一步——运营分析，供大家参考。

从业务上看，对于大多数企业来说，原来都设置了客服部门，所以企业构建智能客服，并不是完全“从0到1”的过程。并且在短期内AI智能客服并不能100%替代人工客服，很长一段时间可能是AI智能客服和人工客服交互协作，来支持企业与客户/经销商/相关合作方的沟通。

从技术趋势上看，在人工智能时代，由于智能客服能在一定程度上降本增效，且不受时间限制提供服务，对客服部门的工作方式产生了冲击，现阶段的主流是人工智能客服+人工客服协作为客户提供服务的模式，即一种“锦上添花“的模式。

那么基于这种条件假设，如何更加有效的搭建智能客服，我想不能仅仅从设计一款AI智能客服产品来思考，第一步甚至应该从AI智能客服运营出发来思考。运用好企业过往历史的人工客服阶段的运营数据，以此来定位客服业务的核心场景痛点，并识别出哪些场景适合人工客服，哪些场景适合AI智能客服，原来的人工客服的问题解决率、平均通话/回复时长等核心数据是多少，在同类场景下AI智能客服的指标KPI需要是多少，能否达到，并根据运营数据，不断调整人工客服和AI智能客服的场景分工和KPI目标。

主流的ai客服产品好比菜谱，菜谱大同小异，但是结合行业和公司特点的ai智能客服和运营好比炒菜的火候。

01 智能客服上线前的核心工作内容

下面推测一下，智能客服运营相关的重要工作，可能包括但不限于场景识别、考核指标设计、投资回报复盘、持续参与会话、FQA、TASK、知识库语料等相关工作，下面选取部分内容进行详细方向说明。

1.1 定位现状+场景识别

定位现状：我们可以采用定量和定性结合的方式来确定，对于大部分企业来说，以往会有一定的人工客服的管理统计数据，那么我们可以根据过往的管理数据进行分析，并从外部市场进行对比分析，以明确客服管理的总体现状。例如：

场景识别：进行场景识别，厘清业务痛点，根据过往客服运营数据识别适用的场景。接下来，我们可以根据更详细的客服运营数据，拟定我们的业务运营指标，这里的出发点，就是厘清在业务场景中，哪些场景是可以使用智能客服的，这些适合智能客服场景中，适用人工客服和智能客户的目标比例分别是多少，考核指标分别是多少。我们可以结合自己的客服运营管理方式进行痛点分析、场景识别数据分析。这里我们以呼入/呼出场景举例（以下仅提供分析思路，需结合各自行业和业务进行分析，切勿盲目套用）。

什么是B端产品经理？和C端产品经理有什么区别？

B端产品经理中的B是Business，商业的意思，B端产品经理首先就要理解这个职位的重要性，要设计出更适合这个项目需求的产品方案，B最终产品经理在日常工作中...

查看详情 >

呼入/在线：

呼出：

1.2 考核指标设计

基于前文的分析，我们已经事厘清了不同场景下，适用人工客服和智能客服的业务场景范围，那么接下来，我们可以思考以下增加智能客服后，在客户交互场景模式变化下，如何设计考核指标。

假设条件，我们设置了大部分场景优先AI智能客服解决，那么先接入AI智能客服，当AI智能客服无法解决问题的时候，转人工处理。这里以转人工处理为分水岭。即所有场景中，可能出现这3种模式。A类，全程由AI智能客服处理。B类，原先设定AI智能客服处理，但是AI智能客服无法满足客户的需求，客户选择转人工，由AI智能客服和人工客服配合完成处理。C类，重大紧急的事故，重要VIP客户，设置了专属人工客服处理。

那么针对A类场景的指标数据，我们可以将原有的未采用AI智能客服处理的运营数据，和采用AI智能客服的运营数据做对比。并制定AI智能客服的运营考核指标。

A类 KPI（可考虑按呼入/呼出到场景细分的统计，按需）

针对B类场景，重点分析客户为什么转人工，进行问题分析。有针对性的提升ai智能客服。可采用两种方式，一种的主动问询客户满意度数据，另外一种是通过监测后台指标数据的方式。

第一种是主动问询客户获取满意度数据，快速评估客户对服务的感知。包括满意度评分（csat）、净推荐值（NPS）等，这里尤其我们要关注满意和不满意的部分，加强优势，并且分析不满意的具体原因，并制定针对性的解决方案。

第二种是后台监测指标数据，这里又可以分为两类：第一类是可以直接反映AI智能客服的指标，例如，首次解决率（FCR）、平均响应时长（ART）、转人工率、情感分析。另外一类是不能直接反映AI智能客服，但可以间接推测AI智能客服运营质量的指标，例如增益类指标：消费者满意度、用户增长率、用户流失率、用户留存率、营销推广触达率、获客成本、客户终身价值提升率。约束类指标：消费者投诉率、消费者问题一次性解决率、消费者问题解决时长、客服响应时长等。

针对C类场景则是一些极其特殊的场景和重点关注的场景，这里我们不做过多的赘述。

1.3 知识库搭建

对于大多数行业来说，知识库是智能客户运营的重要工作事项，当然部分行业由于行业属性较为特殊，例如法律等行业，可能偏向采用微调的模式，也有部分行业采用微调+RAG结合的模式。但对于需要快速适应市场、产品和营销有一定的更新迭代速度，RAG模型显然是目前较为主流且合适的模式，在RAG模式下知识库的搭建和运营，是智能客服运营的重要工作内容之一，包括可能会参与知识库的期初调研和设计，以及后续知识库的管理运营。

同时对于知识库场景是设计，我们需要明确一个整体的场景，以及一期重点搭建的场景、二期重点搭建的场景…，这里重点搭建的场景可以结合我们前面识别的重点场景，并明确不同场景下所需的知识库素材是什么，制定相对统一的底层数据标准，避免出现由于数据标准不一致的原有，造成的召回捞起识别错误。

由于时间精力等原因，本次暂不给出具体示例，但对于知识库的期初设计我们可以考虑以下内容

• 明确知识库使用的场景：根据前文的呼入、呼出场景，明确不同场景下需要的知识库，进行映射关系说明
• 明确知识库的信息来源：第一是内部数据，公司内部不同的部门，销售政策、相关规则、产品手册等等，第二是外部数据外部的数据来源
• 明确知识库分类体系：按照内容形式，分为图片、文字、音频、视频；按业务类型、产品类别、问题类型等设置相关分类
• 明确知识库关联设置：第一是建立知识之间的关联关系，如相似问题关联、相关产品知识关联、业务流程前后环节关联等。第二是知识库嵌入agent工作流中不同知识库之间配合的关联，对话管理的task
• 明确知识库的权限：设置不同的访问权限，限制不同人员对知识库的查看、编辑和使用权限；例如，客服人员可以查看和使用所有知识，而普通员工可能只能查看部分公开知识
• 设计知识库的评估和指标：如知识检索准确率、问题解决率、客户满意度等，定期对知识库的使用效果进行评估

02 智能客服上线后的核心工作内容

2.1 业务运营数据分析与策略迭代

从AI智能客服的工作原理探究，发生BUG的原因：以最常见的客诉呼入场景为例，假设人工客服的操作SOP是根据用户输入问题，进行问题理解，包括但不限于定位订单、定位业务场景、定位客户需求等，并针对用户输入问题进行澄清回复。这一步人工客服已经明白了场景和客户诉求。接下来，人工客服会根据场景和客户诉求，根据过往的经验、公司政策、查询相关信息，给出一个方案，如可以直接判断，则给出解决方案给客户，如不能直接判断，人工客服会要求转接其他同事/稍后回电。之后人工客服可能会持续询问客户是否满意此方案，满意即结束此客户服务，不满意则询问客户不满意的点在哪，并让客户给出她希望的方案，根据过往的经验、公司政策、查询相关信息看能否满足客户诉求，直至在公司条件规则下与客户诉求达成一致。

那么AI智能客服，实际上是在模仿人工客服的场景，根据上文的例子，我们可以简要的总结AI智能客服必然有几个重要的模块节点。即对于AI智能客服发生“bug“的原因，我们大致可以从以下的维度思考：

• 输入处理层：存在多模态输入解析问题（语音识别歧义、图像识别错误、上下文丢失）及语义理解偏差（场景混淆、意图误判、信息遗漏）；
• 知识处理层：知识库存在数据更新滞后、长尾问题覆盖不全、标签分类错误等缺陷，同时检索匹配算法存在向量空间偏差、业务优先级忽略及上下文融合不足；
• 对话管理层：任务调度可能出现 API 调用异常、流程误触发或上下文丢失，交互策略存在澄清引导模糊、情绪安抚缺失及超时处理不当；
• 输出生成层：响应生成可能出现模板匹配错误、逻辑漏洞或合规性疏漏，表达方式存在口语化不足、多语言支持弱及格式异常；
• 模型局限性：生成式幻觉导致编造答案或逻辑矛盾，小样本场景泛化能力不足；
• 外部依赖层：调用的第三方服务异常或网络问题引发连锁错误。

如何改进，从运营角度，非整体角度：

1. 高频场景定制化模板：例如将物流派件投诉，拆解成派件时效延迟、未放指定地点、派件未电联、派件服务态度问题、未经允许放自提柜等，根据不同场景设置相应的定制化对话模板和提示词
2. 智能分流A/B测试：识别适用AI客服的场景，复杂的交给人工处理。定期测试高频场景
3. 人工接管触发规则：业务关键词、情绪关键词，触发人工接管，例如，十分生气、外部投诉
4. AI质检：检验抽查，运用模型对响应内容进行检查，拦截风险应答
5. 数据监控看板：针对核心指标，例如首答解决率、平均响应时长、人工转接率等设置看板，进行红黄绿灯预警
6. 人性化提示词设置：提示词设置人性化的性格描述，让客服说话更“像人”。少说术语：例如，把“请在APP端提交SN码”改成 → “您打开手机APP，点订单详情，找到页面最下面那串20位的黑色数字，填进去就行”。同时，避免连环问，错误示范：“请问是订单号问题？物流问题？还是售后问题？”（一次问3个选项用户容易懵）。正确操作：先问*“您是遇到订单问题了吗？”* → 用户说是 → 再问*“具体是物流没到？还是商品有问题？”*
7. 专属特权配置：例如，coze上可以针对具体的某个用户回复个性化设置，适用于高价值客户，记录用户偏好，实现千人千面的智能客服

2.2 知识库更新的规则和政策

• 更新频次： 明确产品和营销活动更新上传的频次，如每周或每月。
• 内容管理： 规定知识库内容的增删改流程，确保信息的准确性和时效性。
• 审核标准： 制定知识库内容审核的标准要求，确保内容质量。

知识库数据质检：

• 日常质检： 定期质检一定数量的会话记录，确认机器人回答的准确性，补充知识库中不存在的内容。
• 模型升级质检： 在模型升级后进行线上质检，创建数据集，由知识库运营人员提供问题形成数据集，进行标注，测试新版本的准确性。

根据运营数据迭代知识库：

• 转人工问题分析： 分析转人工最多的问题，找出知识库的不足。
• 用户不满意场景分析： 从用户不满意的场景中分析知识库的缺陷。
• 精准度和召回率分析： 从精准度和召回率低的对话场景中分析问题。
• 客户反馈问题分析： 针对客户主动反馈的不满意问题，分析知识库中没有答案、答案不一致、算法提炼不准确或回复不符合预期等问题，并进行相应的迭代。

2.3成本收益核算

以下是简要的智能客服下面成本收益分析，该成本收益分析并不完善和专业，仅提供一些分析思路给大家。

分析的大类包括但不限于：

1. 初期搭建成本和年运维成本。
2. 年节省的人力成本。
3. 计算回本期，判断项目的经济可行性。
4. 综合评估其他潜在收益和风险因素，使用高级财务工具：使用净现值（NPV）、内部收益率（IRR）等方法，将未来收益折现到当前价值来评估项目的财务可行性。

那么按照成本和收益分析，则可以归纳为下述内容：

总成本=系统建设成本+运营维护成本+人力转移成本：

• 系统建设成本（NLP 引擎 / 知识库 / 算力资源）
• 运营维护成本（数据标注 / 模型迭代 / 系统监控）
• 人力转移成本（坐席再培训 / 管理重构）

总收益=直接收益+战略收益：（由于战略收益难以量化，本次暂只计算直接收益）

• 直接收益：人力成本节约 + 服务效率提升
• 战略收益：数据资产积累 + 服务品牌溢价

计算回本期：（示例计算）

假设：

初期搭建成本 (Cinitial) = 180万

年运维成本 (Coperation) = 45万/年

人力转移成本=10万/年（前2年）

每年节省的人力成本 (Slabor) = 100万/年

结论：当收益总计大于成本总计，即回本了，这里我们的收益不考虑难以量化的战略收益，进考虑人力成本节约。约3.6年可以回本。

番外篇：一个基于coze的智能客服实战示例

下面以一个企业数字化服务的咨询公司的智能客服为例，介绍To B智能客服如何搭建。

广义上来说，To C企业的智能客服应用更广，尤其是在售前咨询和售后争议解决方面，在数量级、AI场景丰富程度、SOP流程上都有更广的空间，但由于过往经验的限制（主要是知识库数据隐私限制），目前仅以To B企业数字化服务的咨询公司的智能客服来举例说明。

除了COZE外，Dify也是一个很好的低代码的智能客服搭建工具，‌另外，‌LangChain‌和Ollama也是非常主流的应用开发框架或本地化LLM部署工具，并且可以搭配使用，Dify和Ollama的集成可以实现本地化部署与隐私保护，本次不做过多的技术选型讨论，下面是基于COZE的搭建流程说明（由于本人最近有点忙，这个智能客服的工作流和知识库还在迭代中，虽然已经接入本微信公众号示例，但是精细化程度估计不足，大家图个乐子，别当真，本人也没有公司提供相关产品，哈哈哈）。

第一步：点击官网，并进行注册

第二步：选择模式（单/多agent）

第三步：配置对话流

这一步是智能客服智能体里面的重要设置环节，通俗的来说，你可以配置流程，设置提示词，配置角色名称、角色设置、开场白。也可以设置调用的组件，其中知识库中，除了可以根据行业、产品、用户、业务场景、客服场景设计相应的内容，也可以设置召回量，最小匹配度等。

对于目前agent模式尚未实现，更多是是LLM的工作流形式，主流的workflow有以下几种形式，供大家参考，根据需要选择。 个人觉得路由器在智能客服分流上可能较为匹配，有较强的适用性。

1、链式工作流（Chain Workflow）模式：

第一，每个大语言模型的调用顺序是固定的。

第二，链式工作流上一个步骤的输出结果，作为下一个步骤的输入。

2、并行化工作流（Parallelization Workflow）模式：

第一，同时调用多个大语言模型，并行处理，这些调用可以同时进行，无需等待其他大语言模型调用完成。

第二，输出结果前，采用聚合器，整合之前调用多个大语言模型。

3、路由工作流（Routing Workflow）模式：

第一，先由路由器判断任务分配给哪个大语言模型，路由器根据输入数据的特征、内容或其他相关因素，决定将数据发送到哪个大语言模型。

第二，大语言模型根据路由器分配，处理相关任务。

4、编排器-工作者（Orchestrator-Worker）模式：

并行化工作流和路由工作流的结合。

第一，编排器分配任务给不同的大语言模型。

第二，合成器将不同LLM调用的结果进行综合处理，生成输出。

5、评估器-优化器（Evaluator-Optimizer）模式：

第一，生成器生成结果，评估器给出迭代优化策略。

第二，生成器和评估器互相配合，持续优化，输出最优结果。

提示词工程这里说人话就是帮助机器更好的理解你的问题你的情景你要解决的问题你要了解的信息，你可以通过提示词，决定你的客服是活泼的、理性的，回复是简洁高效还是全面严谨，设置她的回复偏好等等。下面是现在较为主流的提示词工程模型：

1. ICIO 框架

Intruction（任务）：明确指出希望 AI 执行的具体任务。

示例：

“分析某新能源汽车论坛的用户评论，提取关于电池续航的关键词。”

适用场景：市场调研、用户需求挖掘。

Context（背景）：提供任务的背景信息，帮助 AI 理解任务的上下文。

示例：

“公司计划推出长续航版电动车，需了解用户对现有车型的不满点。”

适用场景：产品迭代前的数据支持。

Input Data（输入数据）：指定 AI 需要处理的具体数据。

示例：

“附上 50,000 条论坛评论的 CSV 文件（字段：用户 ID、评论内容、发布时间）。”

适用场景：数据驱动的分析任务。

Output Indicator（输出格式）：设定期望的输出格式和风格。

示例：

“输出 Excel 表格，按关键词出现频率排序，并标注负面评论占比。”

适用场景：需标准化汇报的企业级需求。

2. BROKE 框架

Background（背景）：提供任务的背景信息，帮助 AI 理解任务的上下文。

示例：

“某国产美妆品牌计划进军东南亚市场，需制定 TikTok 推广策略。”

Role（角色）：指定 AI 作为，以便它能够以专业的角度回答问题。

示例：

“跨境营销专家，熟悉东南亚文化差异和社媒平台算法。”

Objectives（目标/任务）：给出任务描述。

示例：

“设计 3 套 TikTok 内容方案，突出产品成分天然性。”

Key Result（关键结果）：设定回答的关键结果。

示例：

“每套方案需包含：10 秒短视频脚本、话题标签、与本地 KOL 的合作建议。”

Evolve（改进）：在 AI 给出回答后，提供三种改进方法。

示例：

“增加穆斯林用户适配性” / “强化价格对比优势” / “添加用户证言剪辑模板”。

适用场景：跨境营销策划、动态优化方案。

3. CRISPE 框架

Capacity and Role（角色）：明确 AI 在交互中应扮演的角色。

示例：

“区块链技术律师，擅长智能合约合规审查。”

Insight（背景）：提供角色扮演的背景信息，帮助 AI 理解其在特定情境下的作用。

示例：

“某 DeFi 平台需确保新合约符合欧盟《数字资产法案》（MiCA）。”

Statement（任务）：直接说明 AI 需要执行的任务，确保其理解并执行用户的请求。

示例：

“审查以下智能合约代码，标注可能违反 MiCA 的条款（第 12-15 条）。”

Personality（格式）：设定 AI 回复的风格和格式，使其更符合用户的期望和场景需求。

示例：

“以法律意见书格式输出，用红黄绿三色标注风险等级，引用具体法条。”

Experiment（实验）：如果需要，可以要求 AI 提供多个示例，以供用户选择最佳回复。

示例：

“提供 3 种合规修改方案：激进型（完全重构）、平衡型（局部调整）、保守型（补充免责声明）。”

适用场景：法律合规、技术方案多路径验证。

另外，召回量和调用的模型组件也可以根据自己的需求设置，说人话就是在召回量设置上越大，客服回复的字数通常会更多。调用模型组件越多并不是最好的，可能出现精准度不足的问题，带来幻觉问题，并且影响检索效率，出现回复时效较慢的情况。这里值得注意且深度探索的还有业务逻辑、会话管理、知识库等设置和配置，即积木组件有了，搭成什么样的城堡，完全由我们自主决定。

第四步： 设置记忆 你可以设置变量，让回复基于用户特征，更加个性化；设置数据库；选择是否采用长期记忆

第五步：测试调优，与发布

第六步：和微信公众号等外部应用链接API（可选）