为什么呼叫中心AI应用，光靠知识库部门搞不定？

文/田志刚 vx:511956894

不少呼叫中心做AI，最先动起来的是知识库和技术团队：

知识库团队整理制度、流程和话术，技术团队接入模型，做出一个能查资料、能回答问题的工具。

演示时，问“理赔要交哪些材料”，AI答得挺好。可一进入真实通话，客户问的是“我的材料已经交了，为什么还没赔？”项目就容易卡住。

要回答这句话AI需要能查到这笔理赔的状态，还得知道客户说的“已经交了”该怎么核实。

如果是人类客服没有问题，资深坐席知道先问什么、去哪里查，但这些经验可能就是她的下意识动作，并没写下来存到库里。

当碰上客户说已经提交、系统却查不到记录的时候，还要由业务部门明确下一步查什么、现在该怎么回答、由谁继续处理。

知识库团队往往就在这时陷入被动：错答案可以派给它整改，它也能追查原因、整理依据、推动各方确认。

但哪条记录可以作为收件依据，哪种情况可以向客户作出承诺，要由有相应权限的业务部门决定。

工单派给了知识库团队，解决问题所需的决定权却在别处。

呼叫中心AI应用要跨部门做，有两层原因。

第一，AI处理具体业务所需的数据、信息和知识分散在各处，有些还需要共同产出。

第二，知识的确认、使用和更新，也分别掌握在不同部门手里。 

前一层是从客服任务倒推AI需要什么上下文，后一层是知识治理。

一、AI需要知道什么，得从客服任务倒推

听到客户说“材料早就交了”，资深坐席通常会先确认是哪笔申请，再问材料从哪个渠道提交，然后查系统记录。

客户说的“交了”，可能是自己完成了上传，也可能是保险公司已经确认收件。

即使已经收件，也可能还有材料要补。还有一种情况，理赔已经有了处理结果，客户真正想问的是款项什么时候到账。

人类坐席能把几种情况分开，是因为他知道该追问什么、该查哪条记录、查到什么才能下判断。

这是让AI实现人类能力的基础条件，这里面是如何分析出相应的信息和知识需求。

具体该如何分析，可以用KMCenter的任务知识体系的方法，就是先看一项任务做得好是什么样，再倒推其中的关键判断，以及每个判断需要的数据、信息和知识。

要解决的问题	需要什么依据	依据在哪里
客户问的是哪笔理赔，真正想知道什么？	当前对话、案件标识、历史工单	坐席工作台、工单系统
客户说“交了”，该追问什么、先查哪里？	核实顺序、判断线索、常见例外	资深坐席的经验、质检案例
材料是否收到，案件到了哪一步？	收件记录、待补事项、案件状态	理赔及材料接收系统
查到结果后怎么答，记录冲突由谁接手？	答复口径、授权范围、交接规则	运营、理赔业务及相关专业部门

注意：“什么证据足以确认收件”是可复用的知识，“这笔案件有没有收件记录”是当次服务的信息。

再加上客户此刻说了什么、AI有什么权限，才构成它处理这通电话所需的上下文。

银行客户问“钱扣了，为什么还没到账”，道理一样。要先核实具体交易的状态，再用相应的业务规则判断如何解释和处理。

明确需求后，才能盘点企业已经有什么、谁手里有、还缺什么：

已有的规则要找到并确认，资深坐席脑中的经验要显性化并验证，企业尚未掌握的知识要通过分析和实践形成。 

一通电话可以揭示一个判断点，把多通客户说法相似、实际状态不同的电话放在一起，才能看清经验适用于哪些情况。

比如运营发现某类理赔咨询的重复来电偏多，这是一个值得追查的现象。回看通话后，可能发现有些客户把“材料已收件”理解成“材料已经齐全”，项目组可以试着在说明收件状态时，一并讲清还缺什么、从哪里补交，再用后续工单验证效果。

验证有效后，这套答复方式就成为企业可以复用的新知识。

这个时候，坐席代表既是知识提供者，也是知识需求方。 

资深坐席能讲清自己是怎么判断的，一线坐席则知道通话进行到哪一步时，需要一句追问提示，还是需要系统直接调出一条记录。

质检从错例中发现容易漏掉的核实步骤，培训从练习中发现新人卡在哪里，运营从数据中找到值得追查的问题。

这些发现都会改变AI需要什么、应该怎样提供帮助，所以各方从任务分析时就要参与。

二、知识治理要明确谁确认、谁维护、谁验证

假设项目组已经分清了“客户已上传”“系统已收件”和“材料已齐全”，接下来还要回答几个问题。

哪个系统的记录可以作为收件依据？两个系统显示不一致怎么办？坐席工作台上能看到的信息，哪些可以由AI直接告诉客户？业务口径变了，谁来同步和验证？

知识库团队可以牵头制定术语、内容模板和版本规范，记录规则来源、适用条件、生效时间和维护责任。

理赔业务部门确认业务口径，技术核对系统字段并落实权限，涉及对外披露的边界由相应责任方确认。

培训负责把新做法教给坐席，质检负责用工单验证实际处理是否符合新口径。

比如，理赔部门调整了确认收件的条件。知识库当天改了条目，AI仍在引用旧规则，培训仍用旧案例，质检仍按旧标准评分，坐席就会面对几套口径。

一项规则变更是否完成，要看实际服务中的各个环节有没有同步：

知识库团队可以牵头协调和跟踪，业务确认、系统配置、培训传播和质量验证，各自都要有人负责。

三、参与客服AI，各部门都要懂一点知识库

过去业务部门提供一份制度，资深坐席读完，往往会用经验补上制度没有写明的细节。

要让AI参与客服工作，各部门就得把这些细节说到可以判断和执行的程度。

比如，“查询材料状态”只说了要做什么，要让AI在答复前用得上，项目组还得讲清楚：

在哪一步查、查哪笔案件、以什么记录为准、记录缺失或冲突时怎么办。 

同样，知识库里写着“材料已收件时告知客户”，也要说明这条知识适用于什么情形，什么时候还需要提醒客户补件。

因此，业务、运营、质检、培训、技术和坐席代表，都需要学习与自己工作有关的知识库基础。

一条知识应该细到什么程度，怎样写清适用条件和例外，为什么要标注来源和版本，哪些内容可以反复使用，哪些信息必须按当前案件实时查询。 

业务人员理解这些，才能把口径讲到可执行的程度。质检人员理解这些，才能区分一次错答究竟是规则缺失、数据没取到，还是引用了旧口径。坐席和培训人员理解这些，也更容易说清楚，一线在什么时候缺了什么帮助。

知识库团队可以牵头建立这套共同语言：各部门掌握了这些基础，才能把自己手里的规则、经验和信息，接到同一项客服任务上。

四、业务对服务结果负责，知识库牵头知识建设与治理

业务部门对认领AI场景有顾虑，也有实际原因。

过去由坐席当场核实的问题，一旦要让AI直接答复，就需要有人事先确认依据和授权边界。

规则变了要审，出了错要复盘，都需要投入人手。如果等工具做好了才请业务部门签字，它接到的就是一项额外的审批和维护工作。

所以，立项时就要明确分工。

管理层提供跨部门授权和资源，业务负责人对服务结果和上线范围负责，知识库团队牵头知识建模、维护和变更协调。 

运营、质检、培训、技术和坐席代表从试点设计开始参与，各自承担能决定、也能改进的环节。

应用可以先从辅助坐席做起：AI提示该查什么、调出相关记录，给出供坐席核对的答复建议。等一个环节的判断依据、数据和权限都经过验证，再逐步开放给客户自助。

例如，完成必要核验后，AI可以说明已经确认的案件状态。遇到记录冲突、理赔裁量或正式承诺，按事先划定的边界交给授权人员，并把已核实的信息一并交接。

回到开头那通电话。

客户想知道的是，材料到底收没收到，案件走到哪一步，自己接下来该做什么。

这通电话能不能处理好，才是客服AI项目要交付的结果。 

知识库团队能把判断依据组织起来，而要让这些依据真正用进服务，还需要业务确认规则、技术接通记录、坐席验证能否用起来、培训同步做法、质检检验实际效果。

这就是为什么，各部门要从项目一开始就参与。（本文作者为知名知识管理专家田志刚，您可以通过微信号511956894联系他。）