- 只会回答重复问题的聊天机器人，能减轻的工作量很有限，因为客户真正打电话来问的事，通常都要调出他本人的资料才能处理。
- 新一代服务系统能查看客户的历史记录，知道这个问题以前有没有出现过，简单的事情当场就能办完。
- 要做好，得先划清界限：哪些事系统可以自己处理，哪些必须转交给人，而且转交时不能让客户从头再讲一遍。
传统网站和应用做不到的地方
老式聊天机器人就像第一天上班的实习生，标准答案背得出来，可客户一问“我昨天下的单到哪儿了”，它就只能请客户等人工客服接听。所以真正繁重的工作一点也没少。
机器人反复发送同一条常见问题（FAQ），或者员工一再要客户重复提供信息，都会让客户恼火。新一代 AI 应该减少这些摩擦，但在有风险的个案中，不能把联系真人的渠道藏起来。
很多服务门户（Service Portal）只负责创建工单（Ticket），然后让客户干等。其实产品型号、故障照片、维修记录和服务权益这些重要信息，一开始就可以收集起来并做初步核查。结果客服人员不得不重复提问，工单派错团队，客户也不知道问题处理到了哪一步。
因此，好的 AI 服务门户要做成个案工作区（Case Workspace），光把 FAQ 的回答写长是不够的。它帮助收集证据，在允许的范围内诊断，建议安全的操作步骤，预约服务并跟进结果。系统必须记住每个个案的进展，从自助服务（Self-service）转到人工时，信息不能丢。
| 传统模式 | 新一代 AI 产品模式 |
|---|---|
| 识别关键词，按话术回复，创建一张空白工单 | 读取历史记录、照片和语音，区分故障症状，核查权益，建议排障步骤，调用经过批准的工具，并连同时间线（Timeline）一起转交给专家 |
服务场景中的 AI 必须连接个案历史、服务权益和经过批准的流程，才能协助诊断、推进工作。每次调用工具都应关联个案编号（Case ID）并记录证据，这样建议才不会脱离历史记录，同一个操作也不会重复执行。
企业可以用上的新能力
区别在于：系统真的能打开这位客户的资料，知道他以前有没有反映过这个问题，也有权限自己办完简单的事，比如修改收货地址或重开收据。复杂的问题，或者出错代价高的问题，仍然转给人处理，并附上完整信息。
项目形态
用户先用文字、语音、照片或文件描述问题。系统给个案分类，并根据客户的产品和权益生成检查清单。界面应显示当前状态、正在检查什么、还需要补充什么，以及预计时间，让客户明白自己提供的每一项信息有什么用。
解决问题的功能
核心功能可以包括多模态接收（Multimodal Intake）、引导式诊断、知识解答、安全操作、预约、个案时间线、通知和专家交接。如果客户按步骤操作后问题仍未解决，系统应记录结果并换一条路径，不能反复推送同一个答案，也不能因为已经发过一篇文章就关闭个案。
背后的技术
系统通过 API 连接客户身份、产品/资产记录、服务权益（Entitlement）、工单系统和知识库，用检索（Retrieval）引用经过批准的操作步骤，也可以用视觉或语音技术读取图片和声音，但每次都要记录置信度。每个操作都有审计追踪（Audit Trail）；在动到客户的设置或权益之前，还要经过安全停止（Safety Stop）规则。
对用户的好处
客户更快得到答复和进度，换了渠道也不用重讲一遍。客服人员拿到的个案简报（Case Brief）已经附有证据，可以把时间花在解决问题上，不用再四处收集信息。企业还能看出客户反复来联系的原因，回头去改进产品、说明书或上游的工作流。
- 多模态接收文字、图片、文件或语音
- 诊断流程根据症状和产品调整提问
- 操作工具，例如查询状态、重置、预约技师或生成个案编号
- 主动回访，处理后询问结果，问题没解决就重新打开个案
模拟案例
实际使用场景
客户拍下家电上显示的错误信息，应用读取错误代码，核对型号和保修，推荐安全的处理步骤；如果这些步骤不奏效，就预约技师，并把照片、历史记录和已经尝试过的操作一起发过去。
在这个模拟案例中，一位客户反映设备在更新后停止工作。他拍下屏幕，系统读取型号和错误代码，核查服务权益，然后给出技术部门事先批准的检查步骤。一旦发现风险信号，系统就停止自助服务，立即为客户预约专家。
专家收到一条时间线，上面写明系统问了什么、客户确认了什么、已经试过哪些步骤，以及哪些信息只是推测。问题解决后，处理结果会回写到系统，用来评估这条诊断路径是真的帮上了忙，还是拖慢了个案。
先取证，后操作
系统在执行任何会产生实际影响的操作前，必须先掌握最低限度的证据，并把即将发生的事展示给用户确认。
不能为了速度，在错误的账户或设备上执行操作。
范围、风险与效果评估
必须把“已发送答复”和“问题已解决”分开。衡量指标应包括首次联系解决率（First-contact Resolution）、重开率（Reopen Rate）、转到专家所需的时间（Time-to-Expert）、安全停止次数，以及客户需要完成的步骤数。如果分流率（Deflection）上升了，重开的个案或造成的损失却也在增加，说明系统只是把工作藏了起来，并没有减少工作。
涉及安全、钱或客户权益的工作，必须有清楚的边界，记录用户的同意（Consent），并且始终留出让人接手的通道。
写给开发团队 · 技术指标
应跟踪的指标：First-contact Resolution、Repeat Contact、Escalation Quality、Unsafe Suggestion 和 Customer Effort
- Discover：跟进实际工作，收集常规情况和例外情况的样本
- Assist：让 AI 起草或给出建议，由人保持控制
- Act：测试集通过后，一次只开放一个工具
- Scale：监控、后备方案（Fallback）、成本和负责人都到位后，再扩大范围
一旦出现风险信号、身份信息对不上，或者人工经常推翻系统的建议，就应立即停止自助服务。在合适的个案中尽早转给专家，本身就是服务质量的一部分，并不代表 AI 失败。
BUSINESS & PRODUCT READINESS
划清自助服务、AI 辅助和专家之间的界线
好的服务不需要让 AI 关闭每一个个案。可以设计一个分级解决阶梯（Resolution Ladder）：一般信息立即答复；标准检查步骤由 AI 附上证据给出建议；可以撤销的操作由用户确认；有风险的个案转给专家。分流率目标定得太高，往往让客户很难找到真人，反而增加重复联系。
写给开发团队 · 技术细节
把 Case Taxonomy、Required Evidence、Safety Stop、Entitlement 和 Outcome Code 准备齐全，让系统知道“已解决”和“已发送答复”有什么区别。人工改写过（Override）的答复和重开的个案，要作为改进 Knowledge 和 Workflow 的数据保存下来，不能只看满意度评分。
客户企业的服务团队和专家应共同制定每种故障的个案分类（Case Taxonomy）、必需证据（Required Evidence）和解决标准（Resolution Definition），并明确哪些步骤普通用户可以自己做，哪些需要先验证身份，哪些只能由技师或有权限的人执行。这些边界属于领域知识，不应让软件去猜。
试点可以从步骤清晰、风险低的重复个案开始，先让 AI 在人工审核下收集信息、起草建议。等到有证据表明个案分类正确、交接信息完整、重开率没有上升，再一次开放一类自助服务或操作。
哪些个案不用动客户权益就能解决？
每种故障至少需要哪些证据？
转交给人时需要附上哪些上下文？
什么时候才算真正结案？
设计一套记得来龙去脉、能把个案一直处理到底的服务
DNA Maker 与客户企业的服务团队和产品专家一起制作服务蓝图（Service Blueprint），覆盖接收、诊断、操作、跟进，直到升级处理（Escalation）。技术和安全方面的排障步骤由客户自己制定，我们负责把这些步骤整理成决策流程（Decision Flow），让它展示证据，并在超出范围时停下来。
UX 团队设计文字、图片、文件和语音的接收方式，既能收集到足够的信息，又不用问一长串问题；同时设计让客户看到系统正在做什么、在哪里可以呼叫真人的界面。AI 智能体（AI Agent）的原型会用常规个案、信息不全的个案，以及禁止给出建议的个案来测试。
DNA Maker 设计个案数据模型（Case Data Model），以及面向客户、客服人员和知识库维护人员的界面，让所有人看到同一个状态。我们按角色分配权限，对接工单/CRM、资产、预约和通知系统，并设计后备方案，应对系统集成响应慢、数据缺失或模型置信度低的情况。
开发过程中，我们用真实个案做原型，建立常规、例外和危险三类测试集，并搭建以解决率为衡量重点的仪表盘，回复数量只作参考。如果有一类工单每周都占用团队大量时间，可以拿出隐去个人数据的样本，和我们一起评估哪些适合做引导式流程（Guided Flow），哪些适合 AI 辅助，哪些只能交给专家处理。
DNA Maker 可以开发客户门户或移动应用、AI 诊断智能体、工单/CRM、预约、通知和实时语音功能，并内置同意管理、审计、评测和智能体转人工的交接。上线后，仪表盘会指出系统答不了的个案，以及需要补充的知识。
如果团队有一类重复出现的工单，排障步骤也比较明确，我们可以协助开展有员工审核的辅助试点（Assisted Pilot），先证明首次联系解决率，再开放更多操作。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
这份术语表帮助区分客户发送的媒体、个案的上下文、同意和转交给人这几件事，可以用来检查门户收集的信息是否足够解决问题，同时没有收集超出需要的数据。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| Multimodal | 接收并理解多种形式的信息。每种媒体各有长处：照片可以作为证据，语音适合腾不出手的时候。系统应按任务选择合适的形式，不必因为技术上做得到就把每种媒体都加上。 | 读取错误画面的照片，配合语音描述 | 哪种形式的质量足以实际使用？ |
| Session Context | 系统在一个个案内记住的信息。上下文应把用户确认过的内容与 AI 总结或推测的内容分开，并设定符合隐私要求的保存期限。 | 记住型号和客户已经试过的步骤 | 保存多久？谁能看到？ |
| Escalation | 超出范围时把个案转给人。转交应由可以核查的规则触发，比如风险、置信度低或超出权限，并规定接手的团队和服务水平协议（SLA）。 | 电气问题立即转给技师 | 风险条件是否已经覆盖全面？ |
| Consent | 用户的同意。同意必须写明目的、使用的数据和撤回方式，进入服务前一个笼统的“我接受”勾选框是不够的。 | 允许使用照片来检查个案 | 用户如何撤回同意？ |
| Realtime API | 低延迟的语音或数据连接，适合语音交互或需要即时响应的场景，但要规划好延迟（Latency）、打断、成本，以及网络不可用时的备用方案。 | 语音对话中同时调出个案状态 | 语音中断时，转回哪个渠道？ |
延伸阅读（原始文档）：https://platform.openai.com/docs/api-reference/realtime