企业电话接入AI前，如何整理AI客服知识库？

第一步：收集现有资料，明确负责人

先选一个来电较多、规则清楚的业务场景，例如售后流程咨询，收集当前有效的产品说明、客服培训文档、办理流程、常见问题和业务通知。给每份资料记录名称、原始位置、适用业务、负责人、版本和生效日期。

遇到同一问题有多个答案时，交给对应业务负责人确认统一口径；过期内容标记失效，尚未确认的内容暂不作为正式答案。保留原始资料，后续才能核对问答依据，而不是只留下改写后的文本。

第二步：整理有适用条件的标准问答

一条记录尽量回答一个具体问题，写清“客户怎样问、适用什么条件、按什么流程处理、哪些事情不能承诺”。把口语、简称和相近问法归到同一条记录，避免维护多份相同答案。

例如“我的订单到哪了”与“什么时候能收到货”，都可能涉及订单进度，但不一定需要同一类数据。应先明确客户要查发货、物流还是预计送达，再规定查询条件和回答依据。

知识记录样例：客户来电查询订单进度

以下是通用的记录写法，用于说明知识边界，不是已交付客户案例，也不表示现有产品已完成订单系统集成。

• 客户真实问法：可收集“我的订单发货了吗？”“包裹到哪里了？”“这两天能收到吗？”等常见口语；此处为模拟表达，上线前用本企业经适当处理的真实问法补充验证。
• 咨询意图：确认客户要查的是订单处理状态、物流进度还是送达预期，不能把三者当成同一个问题。
• 回答所需条件：按企业流程完成身份核验，取得必要的订单定位信息。若需要自动查询，还应有经过授权且可用的订单或物流接口，并能识别结果的查询时间和状态含义。
• 标准处理方式：知识库先提供查询流程和状态解释。有授权查询结果时，只按返回的状态及时间回答；没有接口、查询失败或结果不明确时，说明需要进一步核实，并按既定渠道转交人工查询。
• 禁止承诺或推断：不能根据一般发货规则推断本单已发货，不能凭空补写物流节点、订单异常原因或确定送达日期；超出查询结果的信息不作承诺。
• 转人工条件：身份核验未通过、订单无法匹配、查询不可用、数据冲突、客户提出投诉或主动要求人工时，进入对应处理流程。核验未通过时，不披露该订单的受限信息。
• 资料来源及更新责任：查询流程以企业确认的客服作业说明为依据，具体订单状态以获授权的业务系统查询结果为依据。由企业指定客服流程负责人维护问答口径，系统负责人维护接口及状态解释，记录版本、生效日期和复核时间。

第三步：区分公开知识与受限信息

服务时间、通用办理说明等可公开知识，与内部操作流程、客户身份资料、订单详情分别管理。知识整理表中标明“谁可以查看、在什么条件下可以回答、是否需要核验身份”，不要把客户信息或账号口令混进公共问答。

静态知识适合解释规则和流程；CRM、订单、工单等系统中的当前业务状态，应走授权查询。评估时分别确认核验方式、可读字段、访问权限和查询失败处理，不能用历史文档替代当前数据。

第四步：制定人工承接规则

为资料缺失、答案冲突、投诉和需要个案判断的问题指定接收团队，记录转人工触发条件、服务时间，以及忙线、无人接听或转接失败时的安排。还要确认人工能够接收哪些已核实的信息，减少客户重复说明。

把规则写成可测试的场景，例如“客户明确要求人工时如何处理”“夜间查询失败交给谁”。可对照AI客服遇到复杂问题时如何转人工检查遗漏项，再在实际电话系统中验证。

第五步：使用真实问法测试并持续维护

从本企业业务咨询中整理经过适当处理的测试样本，覆盖正常问题、不同说法、条件不全、无答案、动态数据查询和转人工情形。每个样本写明预期回答依据及预期处理方式，逐项检查答案、权限和流程是否符合要求。

发现错误后，区分是资料缺失、口径冲突还是系统流程问题，交由相应负责人处理。更新时记录版本、生效日期和修改原因，并复测受影响问答；先验证一个场景，再逐步扩大范围。

完成五步后，用下方“知识库上线前检查清单”逐项复核，再评估电话系统的接入条件。