AI 客服落地要把渠道身份、知识版本、人工接待、工单状态和质检记录接成一条服务链。客服负责人先明确入口与值班岗位，知识负责人确认有效资料，IT 人员接通身份、订单和工单接口。每一步都应能沿会话编号查到依据和结果：回答用了哪版资料、现在由谁接待、工单是否真实受理、后续问题交给谁处理。聊天记录不能代替业务回执。
先画清渠道身份与可服务范围
官网匿名访客、登录会员、企业微信客户和内部员工不能共用一套数据权限。开工材料应列出渠道标识如何映射到客户或会员标识，身份由哪个系统验证，失效和退出登录后怎样回收访问。模型只接收业务所需的身份范围，不保存明文密码、验证码或访问凭证。
匿名入口可回答公开说明；涉及个人订单、地址或售后进度时，应走业务系统的核验入口。用户在聊天里提供姓名和订单号，不等于已证明订单归属。跨渠道继续咨询时，先由系统确认是否属于同一客户；无法确认就保留独立会话，不让模型凭相似对话合并身份。
- 入口台账（建议字段）：渠道、身份来源、可读字段、允许动作、人工组、服务时间和责任人。
- 单期范围：先选一种咨询链路，例如公开售后说明、登录后进度查询和人工接待；其他渠道按自身身份条件接入。
能力与范围可在AI 客服系统中确认，避免把“支持聊天”直接当作“已接通业务”。
把知识发布与会话引用绑在一起
知识负责人应确认公开答复、内部操作步骤和敏感资料的分界，并给资料登记稳定编号、版本、生效时间、适用对象和替代关系。价格、活动、售后条件变化时，先完成审核和待发布索引检查，再切换生效版本；文件上传成功不等于所有渠道已经使用新口径。
每次回答关联知识版本和引用来源。进行中的会话遇到规则变更时，应重新检索有效资料，并提示适用条件；不能把历史对话里的旧承诺继续当作当前制度。订单状态等动态事实通过授权接口查询，回答中区分查询时间与知识规则。更完整的资料治理由企业知识库 RAG承接。
部署时要同时确认原文、索引、会话日志及模型请求的位置。云模型调用、混合私有化和全本地推理的数据流不同；即使部署在企业内网，仍要保留身份校验、有效版本与日志访问边界。
用状态和回执约束转人工与工单
触发投诉、资料冲突、授权之外的动作或用户主动要求人工时，系统应按规则停止自动对外回答。会话状态与工单状态分别保存：人工已接手不等于问题已解决，工单已创建也不等于退款、改价或其他业务动作已完成。详细移交字段见AI 客服转人工设计，本阶段重点是各系统能否接续同一事件。
| 链路节点（示例） | 成立依据 | 未取得依据时 |
|---|---|---|
| 请求人工 | 转接请求已登记 | 提示登记失败及可用联系路径 |
| 进入队列 | 队列编号与受理回执 | 显示待确认，不声称已有人接待 |
| 人工接手 | 接待人和接手时间 | 保持排队或升级至值班负责人 |
| 业务处理 | 工单编号、状态及更新时间 | 查询真实结果或进入人工核对 |
| 结束服务 | 处理结论、待办与后续归属 | 保留待跟进，不自动标成解决 |
人工接手后，AI 可继续提供内部草稿，但对客户的自动发送权限应关闭。接口超时后按已有业务编号核对状态，不直接重建工单。渠道会话和业务工单通过关联编号连接，避免跨渠道重复咨询被当成多次独立申请。接口字段与幂等细节可参考订单和工单接口清单。
让质检结果回到具体处理人
质检不是只给回答打分。客服主管应抽查会话是否引用有效规则、是否在无权限时拒绝、该转人工时是否转接，以及工单和对客话术是否一致。原始客户内容按必要范围保存和脱敏，质检人员按岗位读取，不能为了复盘扩大资料权限。
建议把异常标为知识缺失、旧版引用、身份失败、交接中断、接口结果未知或处理结论不一致，并分别派给知识、客服或IT负责人。处理单记录原事件、修改对象、负责人、复核结果；人工备注经审核后才考虑进入知识库，不把一例特殊处理自动推广为通用政策。
用一条会话贯穿交付，缺关键条件先缩小范围
交付材料应包括入口台账、身份映射、知识发布记录、会话与工单状态对应表、值班安排和异常归属。联调时走一条正常咨询至受理回执的完整链路，再走一条无权限或转接失败链路，沿同一会话编号核对资料、接待人和业务结果。完整上线放行检查见AI 客服上线测试清单，这份流程材料本身不替代测试。
身份无法核验、工单状态不可查询、队列无人值守或知识没有责任人时，先保留公开问答和只读辅助。聚匠科技可围绕客服售后 AI梳理系统连接与责任交接，自动写入范围应等业务规则、回执和人工兜底明确后再决定。
说明：状态名称与字段为实施示例，需映射到企业现有系统；本文不替代具体渠道接入规则、数据处理要求或合同验收标准。
