卓越运营 - 客服人员模式

了解有关架构良好的卓越运营的更多信息 → Agent Enterprise Operations Excellence

客服人员可观察性

模式

何处查看	好样的
Agentforce \| 会话跟踪	✅ 使用本地会话跟踪数据模型 (STDM) 捕获 Data 360 上统一数据模型中的客服人员交互，而不是构建并行遥测系统 — 将每个对话记录为会话、交互（轮次）和步骤的跟踪层次结构 (UserInputStep、LLMExecutionStep、FunctionStep)
Agentforce \| 会话跟踪	✅ 依赖于标准 STDM 对象（AIAgentSession、AIAgentSessionParticipant、AIAgentInteraction、AIAgentInteractionStep、AIAgentInteractionMessage），这些对象将操作作为交互步骤本地捕获，而不是需要单独的操作日志
Agentforce \| 会话跟踪	✅ 通过将交互步骤加入 LLM 呼叫记录（通过 GenerationId 和 GenAiGatewayRequest/Response 引用）而不是将它们存储为自定义会话字段来检索令牌使用情况、模型和提示详细信息
Agentforce \| 会话跟踪	✅ 从 Atlas 推理引擎捕获推理跟踪 — 会话跟踪将计划员的步骤记录为每次交互的一部分 — 以揭示客服人员的决策过程并提高可调试性
Agentforce \| 客服人员配置	✅ 记录轮次级别的详细信息，包括用户输入、客服人员响应、推理解释、置信度分数、检索的上下文、尝试的操作和遇到的错误
Einstein \| Trust 层	✅ 打开流到 Data 360 的 Einstein Trust 层生成式 AI 审计跟踪（提示和响应文本、PII 屏蔽版本、基础数据、安全和毒性分数、模型详细信息），以及 Einstein 生成式 AI 和反馈数据收集和存储，以便长期保留
平台 \| 自定义对象	✅ 保留自定义日志记录对象，以防蓄意例外，例如将客服人员行为与业务结果关联的轻量级对象，而不是将它们作为主要日志记录基底
平台 \| 仪表板	✅ 将客服人员行为与业务结果相关联，通过模式分析确定改进机会，并通过质量标签示例提供持续学习漏斗

反模式

何处查看	什么不好的样子
平台 \| 自定义对象	手动构建自定义事务对象作为主要对话记录基底，而不是本地会话跟踪数据模型，在存储多轮对话、大型 JSON 负载和快速数据增长时会遇到规模问题
Agentforce \| 会话跟踪	当 Agentforce 会话跟踪已经在 Data 360 上捕获统一数据模型中的交互时，构建并行遥测系统
Agentforce \| 客服人员配置	仅记录客服人员响应，不捕获输入、推理跟踪、检索的上下文和采取的操作
Einstein \| Trust 层	在生产中禁用 Einstein Trust 层审计跟踪，或未打开反馈数据收集和存储以在 Data 360 中长期保留
平台 \| 监控	仅依赖于对话成功/失败，而不通过 STDM LLM 调用连接捕获令牌使用、模型和提示详细信息

性能监控

模式

何处查看	好样的
平台 \| 监控	✅ 以百分位数测量响应延迟（p50、p95、p99），揭示典型性能和最糟糕的情况
平台 \| 监控	✅ 单独检测每个延迟阶段（模型推理、上下文检索、操作执行、网络），实现有针对性的优化
平台 \| 监控	✅ 当 p95 延迟超过阈值表示性能下降时发出警报
平台 \| 监控	✅ 跟踪每个对话、每个客服人员和每个用例的令牌分配（提示令牌、完成令牌、令牌总数）
平台 \| 监控	✅ 检测消耗过多令牌的异常对话，提示提示问题或滥用
平台 \| 监控	✅ 将当前吞吐量与接近阈值时提醒的已知速率限制或容量基线进行比较
平台 \| 监控	✅ 计算错误率占请求总数的百分比，以便跨客服人员和时间段进行比较
平台 \| 监控	✅ 区分需要不同响应的错误类别（模型错误、权限错误、集成错误）
平台 \| 监控	✅ 计算可用性作为客服人员成功响应请求的百分比，并根据 SLO 进行跟踪
平台 \| Proactive Monitoring	✅ 根据基准客服人员行为模式配置 Proactive Monitoring 阈值，而不是接受默认值
平台 \| 比例中心	✅ 在部署新客服人员或进行重大提示更改后，查看规模中心数据，验证资源消耗是否与预期相符

反模式

何处查看	什么不好的样子
平台 \| 监控	⚠ 仅测量平均延迟，而不是百分比，屏蔽最糟糕的用户体验
平台 \| 监控	无需检测单个阶段（推理、检索、操作执行）即可跟踪总延迟
平台 \| 监控	对所有错误一视同仁，而不是按类型（模型、权限、集成）分类，以获取适当的响应
平台 \| Proactive Monitoring	接受默认的 Proactive Monitoring 阈值，而不调整到基准客服人员行为模式
平台 \| 比例中心	部署新客服人员或进行即时更改，无需查看规模中心数据来验证资源消耗
平台 \| 监控	忽略令牌消耗模式，无法检测消耗 10 倍典型令牌的异常对话

质量度量和评估

模式

何处查看	好样的
Agentforce \| 测试中心	✅ 从本地测试和评估工具开始：在 Agentforce 测试中心维护可重用的测试用例集，并针对它们批量运行客服人员，检查客服人员是否选择了预期的主题和操作，并产生了可接受的响应
Agentforce \| 测试中心	✅ 使用本机评估器 — 现成的质量维度和 LLM 作为判断者的方法来对对话质量进行评分，并使用代表对话编写特定于组织的标准的自定义评估器，以便评估反映真实使用情况
Agentforce \| 测试中心	✅ 对于包含已知答案的事实问题，在测试中心将已知答案声明维护为可重复测试用例；对于开放式问题，添加对抽样对话的人工审核
Data 360 \| 检索质量	✅ 对于基于 Knowledge 库的客服人员，使用本地检索质量分析来评估回复的上下文相关性、答案相关性和忠实度（基于）
Einstein \| Trust 层	✅ 将 Einstein Trust 层运行时毒性检测作为第一道防护线,然后通过内容筛选、手动审查抽样、用户报告和跨人口统计组的公平性审计来改进安全监控
Data 360 \| GenAIFeedback	✅ 通过流向 Data 360 中 GenAIFeedback/GenAIFeedbackDetail DMO 的 Agentforce 反馈（拇指向上/向下、接受/拒绝、编辑、逐字评论）以及网关请求和生成数据，获取用户满意度
平台 \| Analytics	✅ 将显式反馈（升级前、对话后、跟进调查）与隐式信号（完成率、升级、放弃、重试）相结合，与对话特征相关联，以指导改进优先级

反模式

何处查看	什么不好的样子
Agentforce \| 测试中心	构建和运行自定义测试工具，而不是从 Agentforce 测试中心的可重用测试集和本机评估器开始
Agentforce \| 测试中心	⚠ 完全依赖自动评估，无需人工审核，即可对开放式回复进行质量评估
平台 \| 监控	仅监控准确性，不跟踪相关性、安全性和用户满意度维度
Data 360 \| GenAIFeedback	当 Agentforce 反馈已经流入 GenAIFeedback DMO 时，无法收集关于客服人员响应质量的任何用户反馈（显式或隐式）
Agentforce \| 客服人员配置	跳过公平性审计，评估人口统计组之间的结果分布

模型漂移检测

模式

何处查看	好样的
Agentforce \| 客服人员配置	✅ 在客服人员部署后立即建立基准性能，衡量代表性测试用例的准确性、相关性、安全性和满意度
Agentforce \| 客服人员配置	✅ 根据相同的测试用例定期重新评估，揭示与使用模式变化无关的性能变化
平台 \| 监控	✅ 当质量度量下降超过业务影响容限定义的可接受阈值时发出警报
平台 \| Analytics	✅ 监控输入特征（问题长度、主题分布、语言复杂性、领域术语），检测显著的分布变化
平台 \| 监控	✅ 监控响应特征（平均响应长度、操作调用率、升级频率、错误模式），建立行为基线
平台 \| 监控	✅ 配置当漂移度量超过阈值时触发调查和补救的自动警报

反模式

何处查看	什么不好的样子
Agentforce \| 客服人员配置	⚠ 初始客服人员部署后无法建立基准性能，导致无法检测偏差
平台 \| 监控	在用户输入模式与客服人员设计处理的模式发生显著变化时，忽略分布漂移
平台 \| 监控	未根据既定基准监控行为变化（响应长度、操作率、升级频率）
平台 \| 监控	没有漂移度量的自动警报，仅依靠手动观察来检测退化

异常检测和警报

模式

何处查看	好样的
平台 \| 监控	✅ 监控令牌消耗分布，检测异常对话，并调查消耗 10 倍典型令牌的对话
平台 \| 监控	✅ 检测故障率的突然增加、基线之外的新错误类型或影响特定用户或客服人员的局部错误集中
平台 \| Analytics	✅ 按对话阶段跟踪对话放弃，确定用户是在初始交互、对话中还是在任务完成后放弃
平台 \| 监控	✅ 将关键客服人员故障立即路由到随叫随到的工程师，在工作时间将质量降级路由到产品团队，并将小异常路由到每日摘要

反模式

何处查看	什么不好的样子
平台 \| 监控	⚠ 同等紧急地处理所有警报，导致警报疲劳和错过关键故障
平台 \| 监控	忽略成本异常，例如令牌消耗峰值，这可能表示提示问题、滥用或基础设施问题
平台 \| Analytics	未跟踪对话放弃率，或无法按阶段分析放弃情况
平台 \| 监控	等待用户报表，而不是通过自动监控主动检测错误率峰值

提示版本控制

模式

何处查看	好样的
平台 \| 源控制	✅ 将提示模板与应用程序代码一起存储在 Git 中，将提示视为值得代码审查、测试和受控部署的关键应用程序逻辑
Einstein \| 提示生成器	✅ 使用提示生成器进行具有版本历史和测试功能的迭代提示开发，然后导出到部署漏斗的版本控制
平台 \| 源控制	✅ 将配置（模型选择、温度、令牌限制、检索配置、操作权限、功能标记）存储为代码，支持特定于环境的值和漂移检测
平台 \| 源控制	✅ 将语义版本应用于客服人员组件：主要（破坏性更改）、次要（功能）、补丁（错误修复），版本号显示在日志中
平台 \| 文档	✅ 记录更改内容、更改原因、验证更改的测试，以及每个提示和配置更改的回滚程序

反模式

何处查看	什么不好的样子
Einstein \| 提示生成器	无需代码审查、测试或受控部署流程即可进行即时更改
平台 \| 配置	存储源控制之外的客服人员配置，其中无法检测到偏差，部署也无法自动化
平台 \| 文档	无需记录原理、测试结果或回滚程序即可进行即时更改
平台 \| 源控制	无法应用语义版本，因此无法将事件与特定部署关联

模型注册表和部署跟踪

模式

何处查看	好样的
平台 \| 文档	✅ 维护模型注册表，记录部署的模型版本，包括模型系列、特定版本、微调状态、环境、部署日期和负责团队
平台 \| 文档	✅ 记录每个客服人员部署，包括版本、环境、时间戳、部署用户、获得的批准和部署结果
平台 \| 文档	✅ 明确映射客服人员、提示、Knowledge 库、操作和集成之间的依赖性，而不是在事件期间发现它们
业务 \| 流程	✅ 建立弃用计划，并充分提前传达策略支持的最小通知期，允许计划的迁移，而不是对强制弃用做出应急响应
平台 \| 文档	✅ 每个客服人员的文档回滚程序，包括目标版本、执行步骤、验证测试和通知要求
平台 \| 暂存	✅ 在非生产环境中测试回滚程序，在生产事故期间验证它们是否正常工作

反模式

何处查看	什么不好的样子
平台 \| 文档	仅在事件期间发现客服人员、提示和 Knowledge 库之间的依赖性，而不是维护显式依赖性映射
业务 \| 流程	⚠ 提供的弃用通知不足，迫使紧急迁移，而不是计划的迁移
平台 \| 文档	⚠ 具有未经测试的回滚程序，在生产事件期间最需要时失败
平台 \| 部署	部署客服人员时不记录版本、环境、批准或结果，失去将事件与部署进行关联的能力

持续训练和域适应

模式

何处查看	好样的
平台 \| UI	✅ 系统地收集显式反馈（拇指向上/向下、质量分数、评论）和隐式反馈（完成率、升级频率、重试模式）
Data 360 \| 数据策划	✅ 通过筛选质量、删除有问题的例子、确保代表性和重复数据消除，将对话日志纳入训练数据集
Data 360 \| 基础训练	✅ 主要通过基于 Data 360 的 RAG 和提示调整 — Salesforce 本地适应路径，使客服人员适应域词汇、业务流程和组织特定的 Knowledge
Einstein \| BYOLLM	✅ 当基础和提示调整不足时，从外部微调模型并通过 BYOLLM 连接它，而不是期待平台内的生成式微调
Einstein \| 提示生成器	✅ 建立定期的提示审核节奏，检查最近的对话、质量度量和用户反馈，以确定改进机会
Einstein \| 提示生成器	✅ 通过 A/B 测试在全面推出前验证改进，逐步实施提示更改
Agentforce \| 客服人员配置	✅ 维护涵盖幸福之路、边缘个案、对抗输入和历史问题场景的测试集，并随着新边缘个案的发现而不断扩展

反模式

何处查看	什么不好的样子
平台 \| 数据	在没有系统反馈收集的情况下尝试改进，使改进成为猜测而不是数据驱动
Data 360 \| 数据策划	使用未经策划的对话日志进行培训，包括违反安全规定、错误和非代表性示例
Data 360 \| 基础训练	⚠ 在用尽 RAG 基准和提示调整之前，需要外部微调，这是无需自定义模型即可解决大部分域适应需求的本地路径
Einstein \| 提示生成器	将即时工程视为一次性实践，而不是随着使用模式的发展而调整的连续实践
Agentforce \| 客服人员配置	⚠ 拥有从不扩展的静态测试集，以涵盖生产中发现的新边缘个案

逐步推出和 A/B 测试

模式

何处查看	好样的
平台 \| 自定义元数据类型	✅ 使用自定义元数据类型或自定义设置实施功能标记，以将部署与发布分离，从而进行高风险客服人员更改
平台 \| 权限集	✅ 实施金丝雀部署，首先使用控制客服人员访问权限的权限集将客服人员更改发布到小用户子集
Agentforce \| 客服人员配置	✅ 监控金丝雀队列，以密集测量成功率、质量、错误率、延迟、令牌消耗和满意度，并仅在金丝雀匹配或改进了运行上一个客服人员版本的对照组时扩大推出
平台 \| Analytics	✅ 在开始 A/B 测试前定义成功标准，防止结果不明确，与业务目标保持一致
Agentforce \| 客服人员配置	✅ 部署冠军挑战者测试，将经过验证的版本作为后备版本，同时与改进的挑战者版本进行比较
业务 \| 流程	✅ 在促销决策前，建立客观的促销标准，包括最小样本量、质量阈值和评估持续时间

反模式

何处查看	什么不好的样子
Agentforce \| 客服人员配置	⚏ 在不进行金丝雀测试的情况下，同时向所有用户推出客服人员更改，从而最大化问题的爆发半径
平台 \| 部署	部署没有功能标记的高风险客服人员更改，无需重新部署即可实现即时回滚
平台 \| Analytics	在没有预定义成功标准的情况下运行 A/B 测试，导致结果不明确和决策不当
平台 \| Analytics	运行样本大小不足的实验会产生噪声结果，导致错误的结论
Agentforce \| 客服人员配置	⚠ 为每个微小的提示更改使用功能标记，而不是将它们保留给业务关键客服人员进行高风险更改

事件检测和分类

模式

何处查看	好样的
平台 \| 监控	✅ 通过对错误率、质量度量下降、成本异常、延迟增加和用户升级的自动监控提醒来检测客服人员故障
平台 \| 监控	✅ 使用用户报告机制补充自动检测，支持问题升级
业务 \| 流程	✅ 根据用户影响、爆炸半径、数据完整性风险和恢复紧迫性，客观定义严重性标准
平台 \| 文档	✅ 将初始响应程序记录为没有深厚客服人员专业知识的随叫随到工程师可执行的 Runbook
Agentforce \| 客服人员配置	✅ 包括在初始响应中：禁用故障客服人员（断路器）、路由后备、收集诊断、通知利益相关者、启动事件通信

反模式

何处查看	什么不好的样子
平台 \| 监控	依赖用户报表作为主要检测机制，而不是自动监控客服人员故障
业务 \| 流程	⚠ 使用主观严重性分类，导致实际问题上报不足或小问题上报过多
平台 \| 文档	⚠ 没有 Runbook，在每个事件期间需要具有深厚客服人员专业知识的工程师进行特定于事件的调查
业务 \| 流程	⚠ 将客服人员故障视为与传统应用程序故障相同的故障，无需考虑幻觉、主题外响应或安全违规

断路器和后备

模式

何处查看	好样的
平台 \| Apex	✅ 实施具有可配置错误阈值（例如 50% 错误率）、持续时间窗口（例如 5 分钟滚动窗口）和恢复测试（定期试用请求）的断路器
Agentforce \| 客服人员配置	✅ 设计后备层次结构：主要复杂客服人员 → 更简单的备份客服人员 → 静态常见问题解答 → 人工切换
平台 \| 编排	✅ 在编排层而不是单个客服人员中实施后备逻辑，实现客服人员生态系统之间的一致行为
Agentforce \| 客服人员配置	✅ 设计人工切换工作流，保留对话上下文，传达切换原因，并路由到具有相关专业知识的适当人工客服人员
平台 \| 监控	✅ 按主题、客服人员和失败原因监控切换率，以确定客服人员的能力差距
Agentforce \| 客服人员配置	✅ 当复杂的推理失败时，回退到更简单的逻辑；当实时数据不可用时，对缓存的数据进行操作；当集成失败时，以只读模式操作
平台 \| 编排	✅ 测试后备路径，在需要时定期验证它们是否正常工作

反模式

何处查看	什么不好的样子
Agentforce \| 客服人员配置	没有断路器，允许故障客服人员在解决问题时反复影响用户
平台 \| 编排	在单个客服人员中实施后备逻辑，而不是在编排层，从而产生不一致的行为
Agentforce \| 客服人员配置	⚠ 设计完美或完全失败的二进制通过/失败代理，没有优雅的降级选项
平台 \| 编排	从不测试后备路径，发现它们仅在实际事件中不起作用
Agentforce \| 客服人员配置	⚏ 丢失对话上下文的人工切换，迫使用户重复信息

事件后分析

模式

何处查看	好样的
业务 \| 流程	✅ 进行无可指责的事件后审查，重点关注系统改进，而不是个人错误创造心理安全
业务 \| 流程	✅ 通过带有时间戳的检测、调查、响应、恢复和验证，从初始条件创建详细的时间线
业务 \| 流程	✅ 使用“五个为什么”技术从症状到根本原因进行钻取，而不是简单地得出结论
业务 \| 流程	✅ 分析影响因素，包括监控差距、测试差距、文档差距、自动化差距和架构差距
业务 \| 流程	评估检测：什么信号应该更早检测到问题，什么监控支持更快的检测
业务 \| 流程	✅ 指定具体的、已分配的、有时限的操作项目，以防止重复发生（例如，“添加超过 10 分钟的错误率 5% 的警报 - 已分配：Alex - 到期：2 周)
业务 \| 流程	✅ 在后续审核中跟踪操作项目的完成情况，确保持续改进实际发生
平台 \| 文档	✅ 在共享 Knowledge 库中记录事件后审查，并标记启用跨多个事件的模式分析
业务 \| 流程	✅ 通过团队会议或午餐学习会议，广泛分享事件后审查，而不仅仅是直接的事件响应者

反模式

何处查看	什么不好的样子
业务 \| 流程	⚠ ⸏ 专注于指责的尸体会降低心理安全并阻止诚实评估失败
业务 \| 流程	⚠ 简单的根本原因结论（“客服人员有缺陷”）而不是支持有效补救的特定结论
业务 \| 流程	模糊操作项目，例如“改进监控”，而不是特定的、已分配的、有时限的任务
业务 \| 流程	操作项目完成率低，表明持续改进过程失败
业务 \| 流程	将事件后的学习单独保留给直接响应者，而不是为了组织学习而广泛共享

部署批准

模式

何处查看	好样的
业务 \| 流程	✅ 验证部署前核对清单，包括测试、安全审查、合规性验证、文档、监控配置和相关方批准
业务 \| 流程	✅ 根据爆炸半径、数据灵敏性、操作权限、集成依赖性、恢复复杂性和合规性影响评估风险
业务 \| 流程	✅ 基于风险的规模批准要求：高风险需要主管批准、安全审查和逐步推出；低风险需要同行审查和标准测试
平台 \| 审批流程	✅ 使用 Salesforce 审批流程或外部部署工具实施自动化、跟踪和可审计的批准工作流
业务 \| 流程	✅ 定义紧急绕过程序，需要主管批准、理由文档和快速部署后审查
平台 \| 监控	✅ 单独跟踪紧急部署;紧急部署频率高表示流程问题需要调查

反模式

何处查看	什么不好的样子
业务 \| 流程	⚠ 无论客服人员风险状况如何，应用统一的审批深度，将精力浪费在低风险客服人员或审核不足的高风险客服人员上
业务 \| 流程	部署生产客服人员，无需部署前核对清单验证测试、安全性、合规性和监控
平台 \| 部署	⚠ 没有紧急旁路程序，导致生产事故期间的关键修复延迟
业务 \| 流程	⚠ 经常需要紧急部署，表明标准流程已中断，而非特殊情况

质量门和测试

模式

何处查看	好样的
Agentforce \| 客服人员配置	✅ 测试输出特征（包含所需信息、保持适当语气、包含引用），而不是非确定性客服人员输出的精确文本
Agentforce \| 客服人员配置	✅ 建立最低质量阈值（例如“坚持测试集的准确率为 95%，安全违规为零，公平性审核显示人口统计差异不超过 5%”）
Agentforce \| 客服人员配置	✅ 使用对抗性输入执行安全测试，包括提示注入、越狱尝试、请求升级和范围外请求
Agentforce \| 客服人员配置	✅ 让未参与客服人员开发的团队成员执行安全测试，为漏洞提供新的视角
平台 \| 性能测试	✅ 在实际负载下测试，包括并发对话、典型对话长度和预计使用量
平台 \| 安全性	✅ 验证客服人员无法访问未经授权的数据，无法执行未经授权的操作，以及提示注入无法升级权限
平台 \| CI/CD	✅ 使用 Salesforce 代码分析器和专用 AI 安全工具，在部署漏斗中集成安全扫描

反模式

何处查看	什么不好的样子
Agentforce \| 客服人员配置	测试客服人员在非确定性输出上精确匹配文本，而不是测试输出特征
平台 \| 性能测试	仅针对单用户场景、缺失调控器限制问题、资源限制和可扩展性瓶颈进行测试
Agentforce \| 客服人员配置	跳过安全测试或让开发人员测试自己的客服人员，而没有新的漏洞视角
平台 \| 安全性	⚠ 不测试提示注入是否可以升级客服人员权限或访问未经授权的数据
Agentforce \| 客服人员配置	静态测试集不代表真正的使用多样性，包括不同的用户类型和对话复杂性

变更管理

模式

何处查看	好样的
平台 \| 文档	✅ 记录每个更改：更改内容、原因、测试验证，以及存在哪些回滚程序
业务 \| 通信	✅ 通知所有利益相关者（用户、运营团队、支持、业务），描述正在变化的内容、时间、好处、风险以及联系对象
业务 \| 通信	✅ 为不同变更类型建立通信模板，标准化消息并降低准备开销
平台 \| Event Monitoring	✅ 低用量期间的时间客服人员部署由 Event Monitoring 数据显示实际使用模式
业务 \| 流程	✅ 从周初到周中部署主要客服人员变更，避免周末事件响应能力下降
业务 \| 流程	✅ 在重大业务事件（会计年度末、产品发布会、重大市场营销活动）前建立变更冻结期
业务 \| 流程	✅ 文档变更冻结日历每年提前通知限制期间

反模式

何处查看	什么不好的样子
平台 \| 部署	⚏ 在使用高峰、月末结算、季度末结算或主要业务事件期间部署
平台 \| 部署	在事件响应能力有限时，在周一（增加）或周五（减少人员）部署
业务 \| 流程	变更冻结过多会降低改进速度，而不会按比例降低风险
业务 \| 通信	部署客服人员更改，而不通知受影响的用户、运营团队、支持团队或业务利益相关者
平台 \| 文档	⚠ 在不记录理由的情况下进行更改，创建重新发现经验教训而不是基于经验的组织

反馈循环架构

模式

何处查看	好样的
平台 \| UI	✅ 在对话 UI 中实施反馈收集，以便在交互新鲜时立即响应，而不是延迟收集
平台 \| Analytics	✅ 查询对话日志，按主题分析问题类型、对话长度、成功率，按对话特征分析用户满意度
平台 \| Analytics	✅ 按错误类型、受影响的用户、对话模式和时间分布分析错误日志分组，以揭示系统问题
平台 \| Analytics	✅ 按频率和影响确定错误补救的优先级：影响许多用户的高频错误需要立即关注
平台 \| 监控	✅ 在初始部署后建立质量基线，并根据基线监控持续质量，并在趋势下降时发出警报

反模式

何处查看	什么不好的样子
平台 \| UI	延迟反馈收集（例如，几天后的跟进电子邮件），降低回复率并引入召回偏见
平台 \| Analytics	⚠ 不分析使用模式，以确定客服人员是否有理由考虑操作复杂性，或功能是否未得到充分利用
平台 \| Analytics	平等对待所有错误，而不是按频率和业务影响确定优先级
平台 \| 监控	在没有数据、缺乏质量基准和趋势监控的情况下做出改进决策

实验跟踪

模式

何处查看	好样的
业务 \| 流程	✅ 提供一致的实验结构：假设、实验设计、度量、样本大小和成功标准
业务 \| 流程	✅ 执行前记录实验，防止结果解释不明确
平台 \| Analytics	✅ 跟踪对话元数据中的变量分配，启用按变量的结果相关性
平台 \| Analytics	✅ 根据预期效应大小、统计能力和可接受的错误率，在实验前计算所需的样本大小
平台 \| Analytics	✅ 使用多臂强盗优化，将更多流量动态分配到性能更好的变体，降低业务机会成本
平台 \| 文档	✅ 维护实验目录，其中包含测试的变体、测量的结果、实现的结果和做出的决策，以防止重新测试失败的方法

反模式

何处查看	什么不好的样子
业务 \| 流程	在没有预定义假设和成功标准的情况下运行实验，导致结果不明确
平台 \| Analytics	使用样本量不足会产生干扰结果，导致改善决策不佳
平台 \| 文档	没有实验目录，导致团队重新测试以前失败的方法，并丢失组织 Knowledge
平台 \| Analytics	⚠ 不跟踪哪些用户收到了哪些变体，使得结果相关性变得不可能