01项目目标
让客服电话在无人值守时段也能被接起并给出有数据依据的答复，让报修从 Excel 变成可追踪、可统计的工单。
| 指标 | 现状 | 一期目标 |
|---|---|---|
| 7×24 电话接通率 | 夜间依赖手机转接，存在漏接 | 100%（AI 秒级接起） |
| AI 独立解决率 | 无 | ≥ 40% |
| 报修工单留痕率 | 依赖 Excel，大量散落在微信与口头 | 100% 系统留痕 |
02现状诊断
方案的每一项取舍都建立在现状之上。以下六条事实决定了技术路线，其中第五条是整个方案成立的关键条件。
| 现状 | 带来的问题 | 对方案的约束 |
|---|---|---|
| 对外有 400 总机和客服手机，无专门后台 | 通话无录音、无记录、无法质检、无法统计话务分布 | 一期必须先建通话通道，否则后续所有优化都没有数据基础 |
| 月通话量不足 100 次 日均约 3 通 |
重资产语音机器人单通成本过百元，投入产出不成立 | 走云服务按量付费，不做私有化，不做重定制 |
| 报修主要靠 Excel | 问题分散在微信群、销售转达、现场口头，无法追踪闭环 | 工单系统优先级高于电话功能本身 |
| 知识资产需从零建设 | AI 无内容可说，直接上电话会答非所问 | 知识库冷启动必须先于电话全量上线 |
| 充电运营平台自研，可提供 API | —— | 本方案最有价值的条件，决定 AI 能查数据而非念话术 |
| 需 7×24 服务 | 夜间人力成本高、响应慢 | AI 定位为补夜班，不是替代白天坐席 |
03核心判断
判断一：AI 的定位是补夜班，不是替代坐席
月通话不足 100 通，日均约 3 通，夜间通常 0–2 通。但充电行业夜间谷电时段充电集中，晚上充不上电车又停在桩边，是客户焦虑度最高的场景。当前靠手机转接、值班人员待命，响应慢、体验差、且无法保证不漏接。AI 在这个时段的价值远高于白天：秒级接起、不厌其烦、能查数据。白天人工坐席仍应保留，AI 做前置筛选。
判断二：电话不是主战场，Excel 报修才是
奥特迅有 150 座以上自营站和大量已售设备，真实故障量远超日均 3 通电话。其余问题走的是微信群、销售转达、现场口头。当前的主要矛盾不是「接不过来」，而是问题根本没有被收拢——没有记录、无法追踪、不能统计、不能沉淀。工单系统是本项目最有长期价值的产出，电话只是其中一个入口。
判断三：投入重点在知识库与 API 集成，不在语音基础设施
按本案话务量测算，云上语音识别、语音合成、大模型调用、呼叫中心坐席的年费合计在万元量级，可以忽略。真正的成本是知识库整理和接口对接的人力。因此不建议采购私有化部署的语音机器人：建设费高、维护成本高，且无法随产品线快速更新。
04系统架构
系统分四层。第一、二层为成熟标准件，可直接采购云服务；第四层企业已有；第三层是工程量所在，需要把平台数据与对话能力对接起来，这部分决定系统是否真正好用。
关键设计：带数据的客服
C 端车主来电时，系统应通过来电号码自动关联该号码最近的充电订单，在 AI 开口前就已知晓上下文：
「您好，奥特迅充电服务。看到您刚才在月亮湾大道站充电，是遇到什么问题了吗？」
这一句话的体验差距，远大于任何话术优化。前提是运营平台提供按手机号查订单的接口。
同理，车主描述「充不上电」时，AI 必须先查该桩的实时状态与故障码，再作判断。查不到就转人工，不允许推测。
05一期功能范围
纳入一期
- 400 电话 AI 接听与意图分流
- 夜间（22:00–08:00）全时段 AI 值守 + 留电回呼机制
- 通话中实时查询设备状态、充电订单、场站信息
- 工单创建、指派、进度回填，替代 Excel
- 知识库首版（200–300 条，覆盖 Top 20 高频问题）
- 通话录音与基础话务统计
一期不做
| 不做 | 理由 |
|---|---|
| 海外多语种 | 一期只做中文，海外先用英文邮件兜底 |
| 微信 / APP / 官网全渠道 | 渠道越多运营成本线性上升，一期做不完也养不起 |
| 私有化部署 | 话务量不支持重资产投入 |
| 语音情绪识别、声纹、智能质检 | 进阶功能，等基础数据积累后再评估 |
| 与电网客户工单系统对接 | 涉及合规加严，需单独立项评估 |
06通话流程设计
场景 A：C 端车主充电故障（占比最高）
场景 B：B 端客户（运营商、公交、物流、经销商）
意图通常为设备报修、备件申请、调试验收、技术咨询。AI 需收集：客户名称、站点名或合同号、设备型号、故障现象，生成工单后指派至对应售后负责人或销售。
此类通话单次价值高，建议 AI 只做信息采集，处理环节仍走人工。不要让 AI 对 B 端客户做技术判断。
场景 C：安全类事件（最高优先级）
触发词：冒烟、起火、着火、漏电、触电、爆炸、焦味、冒火花、烧了。
命中即执行：① 立即中断 AI 对话，转接值班手机；② 同时向值班负责人推送告警；③ 通话结束前播放安全提示，请客户远离设备、不要触碰枪线、必要时拨打 119。
此类事件事关人身安全，任何情况下不得由 AI 自行解释或安抚了事。这条不做成规则，早晚出事。
07转人工规则
| 触发条件 | 处理动作 |
|---|---|
| 客户明确要求转人工 | 立即转 |
| 连续 2 轮未识别意图 | 转人工 |
| 涉及退款、索赔、投诉、法律纠纷 | 转人工 |
| 命中安全类关键词 | 立即转人工 + 同步告警 |
| 设备状态或订单数据查询失败 | 转人工，禁止推测性回答 |
| 通话超过 3 分钟仍未解决 | 转人工或留电回呼 |
| 夜间无人值守时段 | 留电回呼 + 短信确认 + 次日优先处理 |
夜间留电回呼机制
夜间（22:00–08:00）无人工坐席时，AI 无法解决的问题按以下流程处理：
客户听到「没人接」和听到「已记录、明早 10 点前回复您」，感受完全不同。但如果售后部门接不住这个承诺，比不承诺更伤客户。上线前必须与售后确认可行性。
08接口需求
以下五个接口是 AI 具备「查数据」能力的前提。研发资源有限时，优先做第 1、2 个，这两项已能覆盖大部分 C 端场景。
| # | 接口 | 用途 | 关键字段 | 时效 |
|---|---|---|---|---|
| 1 | 按手机号查最近订单 | 来电自动关联上下文 | 手机号 → 订单号、桩编号、站点名、充电起止时间、电量、金额、结束原因、失败码 | < 500ms |
| 2 | 按桩编号查实时状态 | 判断是否为设备故障 | 桩编号 → 在线状态、当前功率、当前故障码、最近告警时间、所属站点 | < 500ms |
| 3 | 按站点查信息 | 位置、价格、空闲枪数咨询 | 站点名 → 地址、收费标准、空闲枪数、营业时间、停车费 | < 1s |
| 4 | 创建设备工单 | 替代 Excel | 客户信息、桩编号、故障现象、录音 ID、来源渠道 → 工单号 | < 2s |
| 5 | 查设备告警历史 | 排查间歇性故障 | 桩编号 + 时间范围 → 告警码、告警时间、恢复时间 | < 1s |
接口 1、2 是在通话过程中同步调用的，超过 1 秒客户就会感到明显停顿。建议为此单独提供轻量查询接口，不要复用后台管理页面的重查询。
09知识库建设
素材来源（按价值排序）
| 序 | 来源 | 价值说明 |
|---|---|---|
| 1 | Excel 历史报修记录 | 真实的客户问法与真实的处理结论，可直接转成问答对。比从产品手册抄 FAQ 有效得多 |
| 2 | 故障代码表 | 充电桩模块级告警码及释义，是「充不上电」类问题的判断依据 |
| 3 | 产品与安装调试手册 | 用于产品参数、安装规范、操作说明类咨询 |
| 4 | 资深工程师访谈 | 整理 2–3 位一线工程师的经验，尤其是手册里没写的现场处置技巧 |
每条知识的结构
建议四段，缺一不可。第四段最容易被忽略，但恰恰是防止 AI 乱答的关键。
| 字段 | 内容要求 |
|---|---|
| 客户原话 | 客户实际怎么说，保留口语、方言表达、错别字 |
| 判断条件 | 什么情况下适用，需要哪些数据佐证 |
| 处理动作 | 标准处置步骤 |
| 边界 | 什么情况下不能这样答，必须转人工 |
首批目标
200–300 条，覆盖 Top 20 高频问题。一期不追求全覆盖，先覆盖 80% 的常见来电，剩余靠转人工兜底，上线后按实际话务持续补充。
10实施计划
按 4 周推进，灰度策略是先切夜间、后切白天。
接口开发启动 + 知识库冷启动
Excel 历史记录结构化；故障代码表整理；接口 1、2 开发启动。产出：接口文档 + 首批 80 条知识。
语音链路搭建
云呼叫中心开通；语音链路搭建；知识库扩至 150 条；安全词规则配置。产出：可拨测的 AI 号码。
夜间时段灰度运行
联调；22:00–08:00 切换至 AI；每日复盘录音。产出：夜间灰度运行报告。
全时段 AI 前置
白天也改为 AI 前置；工单系统上线；坐席培训；验收。
夜间是当前体验最差的时段，改进空间最大，且出问题影响面最小。夜间数据验证识别率达标后，第 4 周再切白天。全程保留原 400 号码，「无应答呼叫转移」关闭即恢复现状，不影响业务。
11成本估算
| 项目 | 计费方式 | 年成本量级 |
|---|---|---|
| 云呼叫中心（号码、录音、转接） | 按坐席 / 月 | 数千元 |
| 语音识别 + 语音合成 | 按分钟 | 千元以内 |
| 大模型调用 | 按 token | 千元以内 |
| 知识库与工单系统 | 按账号 / 月 | 数千元 |
| 实施与知识库建设 | 一次性人力 | 取决于内部投入或外部服务 |
按当前话务量测算，软件与云资源年成本在万元量级。主要投入是知识库整理和接口开发的人力，不是软件采购费。这也是不建议采购私有化语音机器人方案的原因——钱会花错地方。
12风险与对策
| 风险 | 影响 | 对策 |
|---|---|---|
| 粤语及方言识别不准 | 深圳场站车主大量讲粤语，识别错误会导致体验劣化 | 语音识别需支持粤语；桩编号、金额等关键信息逐位复述确认 |
| 知识库不足导致答错 | 损害品牌信誉，引发投诉 | 严格执行「查不到就转人工」，宁转不猜；上线首月每日复盘录音 |
| AI 误判桩故障为车辆问题 | 实际是桩故障，误判会直接引发投诉 | 涉及充电失败的判断必须先查设备状态与故障码，禁止凭话术推断 |
| 400 转移链路不稳定 | 电话打不进来 | 保留原号码可随时回退；启用转移失败自动回落原线路 |
| 安全事件被 AI 淡化处理 | 人身安全风险 | 安全关键词硬编码，命中即转人工并告警，不经模型判断 |
| 场站标识牌号码不一致 | 客户拨错号 | 采用不换号方案，仅做呼叫转移，标识牌无需更改 |
| 数据合规 | 客户隐私与录音安全 | 一期仅服务国内客户，录音与数据全部存储于境内 |
13待确认事项
以下事项需在方案评审前明确，否则会影响实施排期。
| # | 事项 | 影响 |
|---|---|---|
| 1 | 预算区间 | 决定是纯云服务拼装，还是加入定制开发 |
| 2 | 项目牵头人 | 客服部、IT 部或市场部，影响需求决策效率 |
| 3 | 400 号码管理权限 | 呼叫转移设置需要运营商后台权限，需确认由谁操作、走什么审批 |
| 4 | 夜间回呼承诺时效 | 建议次日上午 10:00 前，需与售后部门确认可行性 |
| 5 | 值班手机归属 | 安全类事件转接的目标号码，需明确责任人 |
| 6 | 坐席人数与班次 | 影响转人工的排队策略与工作台配置 |
| 7 | 工单流转规则 | 工单指派给谁、超时如何升级、闭环标准是什么 |