业务场景与选型
AI客服怎样承接智能呼入？
智能呼入最容易出问题的地方，不是答不上来，而是同一个问题答出两种结果、客户却不知道为什么。所以要先画出客户进线后的四段路径，明确哪些信息来自业务系统、哪些来自知识资料、读不到时怎么回复。
先画出客户进线后的四段路径
智能呼入应从"客户为什么来电"设计：先识别可用身份信息和问题类型，再依据已确认知识或业务系统状态回复；能自助完成的给出明确结果，需要判断或资料不足的转入人工，并把已确认上下文一并交接。
按下面四段把路径画出来，每一段都要有可验收的结果——只画流程不写验收标准，上线后就没法判断这一段到底算不算走通：
| 环节 | 需要确认 | 可验收结果 |
|---|---|---|
| 身份与上下文 | 号码、客户记录及授权范围 | 识别成功或明确进入通用流程 |
| 问题理解 | 常见问法、组合问题和上下文 | 问题分类与待处理事项清楚 |
| 回答或办理 | 知识版本、接口和执行条件 | 回复有依据，动作结果可核对 |
| 人工接续 | 触发条件、队列和工作时段 | 坐席实际接听并获得必要上下文 |
差异化回复依赖哪些条件
同一问题可能因客户身份、订单状态或服务范围而得到不同答案。这不是"回答不稳定"，而是有依据才回答——前提是你能说清依据来自哪里。
要先分清哪些信息来自业务系统、哪些来自知识资料，以及读不到的时候怎么回复。这一点没定清楚，同一个问题答出两种结果时就无从解释。
身份识别失败时，只处理无需身份信息的公开问题；涉及个人业务记录则进入核验或人工路径。下面三类信息的来源，建议在上线前逐项写明：
| 信息来源 | 举例 | 读不到时怎么办 |
|---|---|---|
| 业务系统 | 订单状态、余额、资格 | 进入核验或转人工，不猜测 |
| 知识资料 | 产品说明、办理条件 | 说明限制，不自行补全 |
| 对话上下文 | 客户前面已说过的内容 | 沿用最新一次确认的信息 |
7×24 在线应该怎样表达
机器人可以持续接待，但能解决的问题仍受知识、接口、权限和流程限制。网站应分别说明在线接待、自动解决和人工服务时段——只写一句"7×24 在线"，客户会以为随时都有人，实际找不到人时落差更大。
另外建议把下面四种结果分开统计，不要只用进线数代替解决效果。进线量大不等于解决得多，这是呼入项目里最常见的误读：
| 结果分类 | 说明 |
|---|---|
| 已经解决 | 客户的问题当场办完 |
| 给出导航 | 提供了可用入口，客户自行继续 |
| 转交人工 | 需要判断或超出授权，已转出 |
| 仍待处理 | 本次未解决，需另行跟进 |
用哪些问题做上线验证？
样本应覆盖常见问题、组合提问、身份状态差异、知识缺失和系统不可用。每个样本都记录期待结果与实际处理，两边不一致的逐条追因——只看"整体回复流畅"是不够的，一问多答的场景尤其要拆开看。
| 验证项 | 要检查什么 |
|---|---|
| 上下文沿用 | 客户补充或修改信息后，系统是否沿用最新上下文 |
| 回答依据 | 回答是否来自当前有效知识或业务记录 |
| 入口可用 | 推荐入口是否确实可用并能继续办理 |
| 人工交接 | 转人工时，坐席是否获得已确认内容和未解决事项 |
一份呼入接待方案要写清的交接点
身份字段、读取权限、导航入口和人工路径，需要在项目中逐项确认。这些不是接入后自动就有的——写进方案，才能避免上线后两边对"这一步算不算完成"理解不一致。
交接点建议落到下面三类，每一类都要能追到具体记录：
| 检查项 | 填写或判断方法 | 验收依据 |
|---|---|---|
| 身份可用 | 识别结果及允许读取的业务状态 | 回答与客户当前状态对应 |
| 身份不可用 | 先提供通用信息或按规则核实 | 不猜测订单、余额或资格 |
| 无法完成 | 已回答内容、未解决问题、接收人员 | 人工能接续已经确认的上下文 |
常见问题
AI客服能读取所有客户资料吗？
不能预设。需要核对具体系统、接口、权限和必要范围：哪些字段能读、由谁授权、读不到时怎么回复。这几项建议在方案阶段逐项确认，不要默认接入后自动可用。
机器人在线是否等于人工也全天在线？
不等同。人工服务时段和非服务时段的处理方式应单独约定，并在网站上分别说明。机器人可以持续接待，但涉及人工判断的问题仍要看坐席排班。
一问多答怎样验收？
将每个子问题逐项核对，不能因为整体回复流畅就视为全部正确。客户一句话里问了三件事，答对两件、答错一件，整体看起来仍然很顺畅——分开验收才能发现问题。
身份识别失败时，还能回答问题吗？
可以回答无需身份信息的公开问题；涉及个人业务记录的，应进入核验或人工路径，不要猜测。这两类问题建议在话术设计阶段就明确分开。
呼入和外呼能共用一套知识吗？
不建议直接共用。呼入是客户带着问题来找你，外呼是你主动联系客户，两者的知识范围、可承诺内容和退出规则都不一样。可以共用底层资料，但服务边界要分别定义。