---
schema_version: "1"
id: 4bfb7528f0bd874c84e206a7dfdb6424c804a3d240eca0dd70eb318b5de523c0
title: 资源和成本优化 - 客服人员模式
collection: architect
version: current
locale: zh-cn
portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/resource-and-cost-optimization-agentic-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/resource-and-cost-optimization-agentic-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 4463f9266ee606f2ca41eae38969104733fc33712158c0b60cac08aedaee2abe
products:
  - 架构良好的框架
  - Architect Site Content Repo
---
# 资源和成本优化 - 客服人员模式

了解有关架构良好的[资源和成本优化](/docs/architect/zh-cn/well-architected/guide/resource-and-cost-optimization.html)的更多信息 → [代理企业资源和成本](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-resource-and-cost-optimization.html)优化

## 客服人员工作量调控器限制

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 操作 | ✅ 接受集合的设计操作。客服人员处理 50 个个案更新会调用个案 ID 集合的单个操作，而不是 50 个单独的调用 |
| Agentforce \| 操作 | ✅ 使用关系查询检索单个 SOQL 语句中的父级和子级数据，以跨操作链管理 SOQL 预算 |
| 平台 \| 平台缓存 | ✅ 在平台缓存中缓存参考数据，消除同一对话中操作之间的重复查询 |
| 平台 \| Apex | ✅ 将超出同步限制的客服人员操作移到可排队或批量 Apex。 |
| 平台 \| Apex | ✅ 使用 Apex 执行日志加载的简档操作。在接近同步限制时，将计算繁重的处理移到异步上下文 |
| Agentforce \| 操作 | ✅ 针对数据偏差场景，设计具有硬子记录限制和分页的操作 |
| Agentforce \| 操作 | ✅ 当数量超过客服人员的阈值时实施抽样，客服人员可能会不可预测的请求“所有历史” |
| 平台 \| 比例中心 | ✅ 使用规模中心事务跟踪来确定哪些操作消耗了过多的查询 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 操作 | ⚠ 为每个记录调用单独的操作（例如，50 个单独的调用，用于 50 个个案更新），而不是接受集合 |
| 平台 \| Apex | ⚠ 在 10-15 个操作的复杂工作流中，每个操作运行 5-10 个 SOQL 查询，接近 100 个同步 SOQL 限制 |
| 平台 \| Apex | 在操作中同步运行大型处理，而不是在异步上下文中（例如，在同步 Apex 中评分 1,000 多个潜在客户） |
| Agentforce \| 操作 | 允许客服人员从拥有 15000 个业务机会的客户或拥有 5000 个活动的个案中检索无限的子记录，而无需防御性编码 |

## API 消耗

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| Event Monitoring | ✅ 在试点阶段监控 Event Monitoring 中的 API 消耗，以在全面推出前了解实际使用情况 |
| Data 360 \| 配置 | ✅ 设置向量搜索的前 K 个限制，以仅检索实际使用的结果数量 |
| Data 360 \| Analytics | ✅ 在 Data 360 Analytics 中监控矢量搜索结果利用率，以调整前 K 个参数 |
| 平台 \| 平台事件 | ✅ 在条件需要客服人员干预时发布平台事件，而不是无论工作存在与否都计划轮询消耗 API 调用 |
| 集成 \| 操作 | ✅ 使用复合模式：创建单个 MuleSoft 体验 API，以并行聚合多个系统检查（库存、定价、信用），客服人员调用 1 个外部操作，消耗 1 个标注 |
| 集成 \| 操作 | ✅ 设计执行所有下游更新的单个 MuleSoft 流，而不是每个客服人员交互的多个顺序流 |
| Agentforce \| 客服人员配置 | ✅ 使用标准组件将客服人员嵌入 Lightning 页面，避免每次交互时消耗 API 调用 |
| 业务 \| 计划 | ✅ 根据预计的客服人员交易量评估 MuleSoft 许可模型（基于交易与平台许可），以确定最佳经济效益 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Data 360 \| 配置 | 仅使用前 5 个矢量搜索结果时检索前 50 个矢量搜索结果，浪费 90% 的计算和上下文预算 |
| 平台 \| 计划作业 | 无论工作是否存在，计划轮讯消耗 API 调用（例如，每 5 分钟检查一次，发现 80% 的时间没有工作） |
| 集成 \| 命名凭据 | 使用 3 个消耗 3 个标注的单独操作，而不是聚合多个系统调用的单个复合 API |
| 平台 \| Apex | 当标准 Lightning 组件可以避免这种情况时，自定义 LWC 发出明确的 API 请求会消耗 API 调用 |
| 集成 \| 外部系统 | 外部系统轮询 Salesforce 的状态更改，消耗数百次每日 API 调用，而不是订阅 CDC 事件 |
| 集成 \| 操作 | 对于每个步骤（查询客户、查询产品、检查库存、创建订单、更新库存、通知发货），进行顺序 API 调用会消耗每个事务 12 次以上的调用，而复合模式会降低消耗 75% |
| 集成 \| 客服人员配置 | 跨多个系统编排客服人员操作，而不评估每个系统交互是否必要，将 API 消耗与每个添加的系统相乘 |

## 客服人员响应延迟

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 提示模板 | ✅ 最小化提示长度：删除繁琐的说明、冗余的示例、不必要的上下文。选择性上下文会改善延迟和质量 |
| 平台 \| Apex | ✅ 将选择性 SOQL 与索引筛选器一起使用。利用查询计划工具识别导致全表扫描的缺失索引 |
| Agentforce \| 客服人员配置 | ✅ 在不存在依赖性时使用并行操作执行。同时检索客户详细信息和业务机会会使延迟比顺序检索减少一半 |
| 平台 \| 平台缓存 | ✅ 缓存频繁访问的参考数据（产品目录、区域映射、定价规则），消除重复的 SOQL |
| 平台 \| 平台缓存 | ✅ 实施语义缓存匹配类似的查询，为重复的请求提供服务，而无需新的推理 |
| 平台 \| Apex | ✅ 使用丰富的异步调控器限制异步处理非紧急请求（状态更新、批处理、报表生成） |
| 平台 \| Apex | ✅ 现实数据量下的简档操作。无论 LLM 推理是否快速，采取 3 的操作都会成为瓶颈 |
| Agentforce \| 操作 | ✅ 在操作中实施批量化，以最小化每个操作的执行时间 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 提示模板 | 包含添加噪音的穷举上下文，而不是改善延迟和质量的选择性上下文 |
| Agentforce \| 客服人员配置 | 在不存在依赖性时按顺序执行操作（例如，客户查询 2s + 业务机会查询 2s = 4s 按顺序执行，而不是 2s 并行） |
| 平台 \| Apex | ⚠ 运行全表扫描，因为缺少索引，而不是使用带有索引筛选器的选择性 SOQL |
| 平台 \| 平台缓存 | ⚠ 重复查询 Data 360（每次调用 1.5 次），以了解可以缓存的常见数据（距离平台缓存 50 毫秒） |
| Agentforce \| 客服人员配置 | ⚠ 需要同步完成非紧急操作（状态更新、批处理、报表生成） |

## Data 360 集成效率

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Data 360 \| 配置 | ✅ 将 Knowledge 文章、产品文档、个案历史分解为具有语义意义的 250-750 个单词段 |
| Data 360 \| 配置 | ✅ 根据客服人员查询模式验证块大小。平衡精度（较小的块）与上下文完整性（较大的块） |
| Data 360 \| 配置 | ✅ 使用匹配客服人员查询模式的嵌入。根据衡量检索精度和召回的代表性查询验证选择 |
| Data 360 \| 配置 | ✅ 通过元数据筛选器增强向量相似性，确保业务约束（例如，筛选到活动产品，排除停用的项目，而不管语义相似性如何） |
| Data 360 \| 配置 | ✅ 使用统一简档将来自多个来源的客户数据聚合到单个视图中。在单个查询中访问完整的上下文（属性、见解、参与、预测） |
| Data 360 \| 配置 | ✅ 启用身份解析，提供准确的跨系统客户匹配 |
| Data 360 \| 配置 | ✅ 在匹配数据驻留合规性监管要求的区域配置 Data 360 实例 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Data 360 \| 配置 | 使用过大的块，其中包含不相关的信息，稀释了向量搜索结果的相关性 |
| Data 360 \| 配置 | 仅依赖语义相似性，没有元数据筛选器，返回中断或低质量的结果 |
| Data 360 \| 配置 | 编排多个单独的源查询，而不是使用 Data 360 统一简档来获取完整的客户上下文 |
| Data 360 \| 配置 | 使用不匹配客服人员查询模式的嵌入模型（例如，用于问答相似性的文档分类嵌入） |
| Data 360 \| 配置 | 在非 European Data 360 实例上处理欧洲客户数据，违反数据驻留要求 |

## 上下文窗口管理

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 客服人员配置 | ✅ 明确确定上下文的优先级：最近对话历史（最高）、关键业务数据/记录状态/权限（第二）、历史上下文（最低，仅在空间允许时） |
| Agentforce \| 客服人员配置 | ✅ 在 10 到 15 个回合后，将早期对话总结为简洁的概述，在没有完整逐字记录的情况下维护关键事实 |
| Data 360 \| 配置 | ✅ 在 Data 360 或自定义对象中存储扩展上下文，而不是在每次 LLM 调用中存储完整历史记录。按需查询使提示关注当前需求 |
| Agentforce \| 操作 | ✅ 仅返回操作响应中的基本字段。客户检索返回与当前任务相关的字段，而不是所有 50 个字段 |
| Agentforce \| 客服人员配置 | ✅ 为上下文窗口分配设计明确的优先级逻辑与任意截断 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 客服人员配置 | 在没有显式优先级逻辑的情况下任意截断上下文 |
| Agentforce \| 客服人员配置 | ⚠ 将完整的逐字记录对话历史记录保持在 10 到 15 轮之外，耗尽上下文预算 |
| Agentforce \| 客服人员配置 | 在每个 LLM 调用中包含完整历史记录，而不是在外部存储扩展上下文并按需查询 |
| Agentforce \| 操作 | 当只有子集与当前任务相关时，返回客户检索中的所有 50 个字段，消耗上下文预算 |
| Agentforce \| 客服人员配置 | 分配上下文预算，而不保留足够的空间来生成响应 |

## 可组合客服人员设计

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| 操作 | ✅ 开发涵盖记录 CRUD、批准、通知、报告、验证的集中操作库。平台团队保持行为、安全性和性能的一致性 |
| Agentforce \| 客服人员配置 | ✅ 创建具有深厚领域专业知识的专注专家客服人员（个案管理服务代理、业务机会指导销售代理） |
| Agentforce \| 客服人员配置 | ✅ 使用客服人员生成器编排，协调跨域需求的专家客服人员 |
| Agentforce \| 提示模板 | ✅ 在提示生成器中维护验证的提示模式。模板捕获经过验证的 RAG 查询形成、多步骤推理、响应格式化方法 |
| Agentforce \| 提示模板 | ✅ 版本提示模板支持 A/B 测试改进 |
| Data 360 \| 配置 | ✅ 在 Data 360 中维护共享 Knowledge 库，为多个客服人员提供服务。单一产品 Knowledge 库为销售、服务和合作伙伴入口网站客服人员提供基础服务 |
| Agentforce \| 客服人员配置 | ✅ 从经过验证的构建块中撰写新客服人员：定义目的、选择操作、配置提示（自定义构建的天数与周数） |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 提示模板 | 为每个客服人员创建临时提示，而不是重复使用经过验证的提示模板库 |
| Agentforce \| 操作 | 为每个客服人员重新实施操作，而不是使用集中的可重用操作库 |
| Agentforce \| 客服人员配置 | 构建尝试所有场景的通用客服人员，而不是拥有深厚领域专业知识的专注专家客服人员 |
| Data 360 \| 配置 | 为每个客服人员重复 Knowledge 库，而不是共享一个让多个客服人员成为基础的 Knowledge 库 |

## 客服人员版本和测试

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| 自定义元数据类型 | 使用自定义元数据类型和提示生成器控制行为，无需更改代码。管理员修改提示模板和推理参数，无需开发周期 |
| Agentforce \| 客服人员配置 | ✅ 将子集路由到实验版本，比较质量度量、满意度、完全推出前的任务完成情况（例如，10% 到 v2，90% 到 v1） |
| Agentforce \| 客服人员配置 | ✅ 在 A/B 测试中发现问题时，监控验证期并保持回滚能力 |
| Agentforce \| 操作 | ✅ 定义组件之间的明确接口合同：操作指定输入、输出、错误、性能预期 |
| Agentforce \| 客服人员配置 | ✅ 在多周推出期间逐步扩展成功版本（10% 到 25% 到 50% 到 100%） |
| Agentforce \| 操作 | ✅ 在保留界面合同时，无需客服人员修改即可替换操作实施 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| Apex | 需要更改代码来修改客服人员行为，而不是使用配置驱动的方法（自定义元数据类型、提示生成器） |
| Agentforce \| 客服人员配置 | ⚠ 完全推出新的客服人员版本，无需对比较质量度量和满意度的子集进行 A/B 测试 |
| Agentforce \| 操作 | 客服人员取决于操作实施详细信息，而不是界面合同，在实施更改时中断 |
| Agentforce \| 客服人员配置 | 立即为 100% 的用户部署新版本，无需逐步推出 |
| Agentforce \| 客服人员配置 | 在实验版本测试期间，在没有回滚功能的情况下运行 |

## 灵活信用消耗

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 客服人员配置          | ✅ 以尽可能少的客服人员操作解决每个请求 — 每个操作消耗 Flex Credit，因此将多步骤逻辑整合到一个操作中会直接降低成本 |
| Agentforce \| 客服人员配置          | ✅ 根据文档化的灵活信用消耗率和预期交互量，对每月成本预测进行建模，从而支持预算规划 |
| Einstein \| 监控                     | ✅ 按客服人员、用例和用户群体监控 Flex Credit 消耗，以确定需要优化的高消耗模式 |
| Einstein \| 监控                     | ✅ 将实际消耗与预测进行比较，为未来规划提供信息，并确定优化机会 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 客服人员配置          | 将许多小操作链接在一起，其中一个合并操作可以解决请求，使每次交互的灵活信用消耗成倍增加 |
| 业务 \| 计划                       | 发现 Flex 信用消耗仅在生产部署后超过预测，因为没有执行每个交互成本建模 |

## 对话优化

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 客服人员配置          | ✅ 设计会话边界和超时，以便对话适当持续，而不会过早终止并强制进行新的可计费对话 |
| Agentforce \| 客服人员配置          | ✅ 将客服人员的能力集中在首次对话的解决上，以便在初始对话中完成任务，而不是需要可计费的跟进 |
| Einstein \| 监控                     | ✅ 跟踪首次对话解决率，作为每次对话定价下的成本效益度量 |
| Agentforce \| 客服人员配置          | ✅ 在现有对话上下文中处理相关问题，而不是打开单独的对话，每个对话产生固定的费用 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 客服人员配置          | 通过短会话超时提前终止对话，迫使用户开始新的可计费对话以完成单个任务 |
| Einstein \| 监控                     | ⚠ 仅监控总对话量，不跟踪首次对话解决率，缺少每次对话定价下的主要成本杆 |

## 利用率优化

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 业务 \| 文档                  | ✅ 推动采用，以便获得许可的用户积极参与客服人员，因为未计量的每用户定价价值来自使用情况，而不是最小化每次交互 |
| Einstein \| 监控                     | ✅ 跟踪利用率，以确定低使用率的许可用户，以便进行有针对性的培训或许可证重新分配 |
| 业务 \| 文档                  | ✅ 按用户群体将客服人员交互与业务结果联系起来，以便高价值用例证明每个座位的投资是合理的 |
| 业务 \| 计划                       | ✅ 节奏审查用户群体，以便许可证与实际使用保持一致，而不是过度许可 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 业务 \| 计划                       | ⚠ 配置没有采用计划的每用户许可证，为很少与客服人员接触的用户支付固定的每座席成本 |
| Einstein \| 监控                     | ⚠ 从不按用户群体审查利用率，让许可证流向浪费传统席位的过度许可 |

## 混合架构

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 客服人员配置          | ✅ 实施分类客服人员，使用简单逻辑处理初始路由，仅在复杂性要求时将用户定向到专用客服人员 |
| 平台 \| 流                           | ✅ 对于基于规则的逻辑足够的确定性场景，回归流自动化，为真正需要的不明确场景保留客服人员推理 |
| Data 360 \| 客服人员配置          | ✅ 有选择地检索基础数据，仅在客服人员的推理需要时调用向量搜索和文档检索，而不是每次交互时 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 客服人员配置          | 将每个请求直接路由到专门的客服人员，对简单分类逻辑可以处理的请求进行昂贵的复杂调用 |
| 平台 \| 流                           | 将客服人员推理用于基于规则的确定性工作流，流将以更低的成本执行，而不会消耗变量 |
| Data 360 \| 客服人员配置          | 检索每个交互的基础数据，无论推理是否需要，都会增加不跟踪真实需求的 Data 360 消耗 |

## Data 360 消耗

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Data 360 \| 客服人员配置          | ✅ 使用定义的刷新节奏（例如 24 小时）缓存产品目录嵌入，从缓存中检索常规问题，并仅查询 Data 360 以获取新的或特定于客户的数据 |
| Data 360 \| 客服人员配置          | ✅ 实施缓存策略，减少常见请求的重复查询，平衡成本优化和数据新鲜度要求 |
| Data 360 \| 组织                          | ✅ 将前期数据接收和处理成本（协调、身份解析、嵌入生成）与增量增长成本分开建模 |
| Data 360 \| 客服人员配置          | ✅ 在添加检索扩充生成之前，评估 RAG 开销是否有理由对特定用例进行质量改进 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Data 360 \| 客服人员配置          | 尽管大多数查询是相同的常见问题，但没有实施缓存，为重复相同的响应消耗 Flex Credit |
| Data 360 \| 组织                          | 实施激进缓存，不考虑数据新鲜度要求，为用户提供过时信息 |

## Sandbox 和开发成本

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| 组织                            | ✅ 将部分复制 Sandbox 和目标客户数据示例用于客服人员开发，并将完全复制 Sandbox 专用于生产前验证 |
| 平台 \| 组织                            | ✅ 预先计划开发基础设施成本，包括 Data 360 容量、用于快速测试的灵活信用和集成连接 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| 组织                            | ⚏ 每个开发人员为客服人员开发配置完全复制 Sandbox，Sandbox 成本增加 5 倍 |
| 平台 \| 组织                            | 依赖临时手动测试提供的覆盖范围不足，仅在生产中发现质量问题 |
| 业务 \| 计划                       | 使开发基础设施成本在规划期间不可见，在实施期间导致重大意外成本 |

## TCO 建模

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 业务 \| 文档                  | ✅ 构建涵盖所有六个成本类别的综合 TCO 模型：开发、推理 (Flex Credits)、基础设施 (Data 360 + MuleSoft)、运营、治理和变更管理 |
| 业务 \| 文档                  | ✅ 创建电子表格 TCO 模型，预测 3-5 年的成本，并记录互动量、信用消耗率和增长轨迹的假设 |
| 业务 \| 文档                  | ✅ 执行敏感性分析，揭示哪些假设对投资总额影响最大，从而保证验证工作的针对性 |
| 业务 \| 文档                  | ✅ 将持续运营成本建模为成熟客服人员每年开发成本中有意义的经常性部分，它来自通用 AI 客服人员行业基准，而不是固定的 Salesforce 数字 |
| 业务 \| 计划                       | ✅ 包括经常被低估的变更管理成本（用户培训、业务流程调整、组织变革） |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 业务 \| 计划                       | ⚠ 仅包括客服人员业务个案中的开发成本，而不对持续消耗进行建模（Flex Credits、Data 360、运营），在部署后发现大量计划外的年度成本 |
| 业务 \| 计划                       | 忽略治理开销（安全审查、人员监督基础设施、审计日志、合规验证），这些开销会随着客服人员的自主权和风险级别而增加 |
| 业务 \| 计划                       | 低估变更成本，尤其是对于创建大量工作流轮班的客服人员，导致预算短缺 |

## 构建与购买

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 业务 \| 文档                  | ✅ 通过全面的 3 年 TCO 比较（包括维护成本）评估预构建 Agentforce 客服人员与自定义开发 |
| 业务 \| 文档                  | ✅ 架构决策记录中的文档构建与购买决策，支持未来在成本和功能变化时重新评估 |
| Agentforce \| 客服人员配置          | ✅ 考虑通过提示生成器和操作配置自定义预构建客服人员，作为现成和完全自定义之间的中间环节 |
| 业务 \| 计划                       | ✅ 成本之外的因素决策标准：实现价值的时间、组织发展能力、战略差异化价值和供应商依赖性容忍度 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 业务 \| 计划                       | 构建自定义客服人员，因为“我们想要控制”而没有建模 3 年 TCO，显示预构建选项可能便宜得多 |
| 业务 \| 计划                       | ⚠ 仅根据第一年成本选择构建或购买，而不预测多年持续维护、信用消耗和供应商更新的好处 |

## 比较分析

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 业务 \| 文档                  | ✅ 在部署前将客服人员 TCO 与传统自动化替代方案（流、Apex、手动流程）进行比较，验证投资合理性 |
| 业务 \| 文档                  | ✅ 建立手动流程基准，包括满负荷员工成本、错误率、处理时间和吞吐量能力，以揭示潜在的节省 |
| Agentforce \| 客服人员配置          | ✅ 部署客服人员，以处理需要自然语言理解、自适应推理或传统自动化无法匹配的高场景变化的任务 |
| 平台 \| 流                           | ✅ 将流自动化用于具有明确规则的确定性工作流，以更低的成本提供等效结果，而无需变量推理消耗 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 客服人员配置          | 部署客服人员执行简单的确定性路由任务，当 Flow 在不增加成本的情况下提供同等功能时，每年消耗 1500 美元信用 |
| 业务 \| 计划                       | 对于所有自动化，默认使用客服人员方法，而不评估传统自动化是否以较低的总成本提供同等结果 |

## 实时成本跟踪

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Einstein \| 监控                     | ✅ 构建灵活信用消耗仪表板，按客服人员、用户群体、时间段和交互类型显示消耗，以快速识别消耗峰值 |
| Einstein \| 监控                     | ✅ 实施将信用消耗与业务交易联系起来的每个交互成本归因（每个已解决个案的成本、每个合格的潜在客户的成本、每个已处理订单的成本） |
| Einstein \| 监控                     | ✅ 按客服人员和用例配置示例阈值的预算提醒，例如 70% 和 85%（不仅是组织范围），以便在超支之前进行主动干预 |
| Einstein \| 监控                     | ✅ 实施异常检测，识别异常消耗模式（突然峰值表示提示效率低下、意外使用模式或滥用） |
| 业务 \| 文档                  | ✅ 与业务利益相关者和技术团队共享成本仪表板，创造透明度，实现成本感知客服人员的使用 |
| 业务 \| 文档                  | ✅ 进行季度预算审查，将实际消耗与预测进行比较，评估业务结果，并根据展示的价值调整分配 |
| 业务 \| 计划                       | ✅ 为实验和意外消费增长预留 10%-15% 的信贷预算,防止创新瓶颈 |
| 业务 \| 计划                       | ✅ 根据客服人员采用趋势、新部署和扩大用例创建多年预测，支持容量规划和供应商谈判 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Einstein \| 监控                     | ⚠ 仅通过每月发票审核监控信用消耗，在续订前发现预算超支 6 周而没有时间进行优化 |
| Einstein \| 监控                     | 仅在组织级别配置预算警报，缺少指示优化业务机会的按客服人员和按用例消耗峰值 |
| 业务 \| 计划                       | 需要增加紧急预算，因为消费监控没有及早实施，无法主动识别和解决超支问题 |
| 业务 \| 计划                       | ⚠ 在会计年度开始时设置年度预算一次，无需审核，使高价值客服人员渴望获得信用，而低投资回报率客服人员消耗分配 |
| 业务 \| 计划                       | 为实验分配零预算储备，迫使团队在任何探索之前通过冗长的批准来证明每个新用例的合理性 |

## 客服人员成本分配

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Einstein \| 监控                     | ✅ 按客服人员实例跟踪消耗，支持跨客服人员类型和用例进行比较，揭示哪些客服人员提供最佳 ROI |
| 业务 \| 文档                  | ✅ 将消费与业务流程（潜在客户资格、个案解决、订单处理）联系起来，使业务领导能够评估战略调整 |
| Einstein \| 监控                     | ✅ 按部门、角色或用户细分跟踪消耗，揭示客服人员采用率最高和成本最集中的地方 |
| 业务 \| 计划                       | ✅ 使用季度成本审查来比较不同产品组合的客服人员投资回报率，并根据展示的价值将投资从低投资回报率重新分配到高投资回报率客服人员 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 业务 \| 计划                       | 将所有客服人员成本分配到 IT 预算，而不考虑业务部门属性，防止业务领导评估支出是否符合优先级 |
| 业务 \| 计划                       | 将客服人员消耗视为无差别成本，而不将消耗与业务结果联系起来，因此无法计算 ROI |

## 按存储容量使用计费模型

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 业务 \| 文档                  | ✅ 实施展示性报告，提供业务部门的消费可见性，培养成本意识，从而做出明智的使用决策，而不会引起有争议的退款争议 |
| 业务 \| 文档                  | ✅ 对高用量生产客服人员使用带按存储容量使用计费的混合分配，对实验性或低用量客服人员使用带展示的混合分配，平衡问责制与创新灵活性 |
| 业务 \| 文档                  | ✅ 进行季度审查，讨论消耗是否与交付的价值一致，从而做出优化承诺 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 业务 \| 计划                       | ⚠ 对实验代理实施完全计费，通过立即对新生用例强制实施预算问责来阻止创新和探索 |

## 提示优化

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 提示模板              | ✅ 消除系统提示中不必要的繁琐性 识别每个额外的令牌会增加所有交互的预填充计算和延迟 — 将系统提示调整为客服人员实际使用的内容 |
| Agentforce \| 提示模板              | ✅ 通过选择性上下文检索仅包含相关信息，相关性排名确保最高价值的信息适合上下文限制 |
| Agentforce \| 提示模板              | ✅ 为常规交互指定简洁的响应格式，通过避免请求复杂的格式或广泛的解释来最小化完成标记 |
| Agentforce \| 提示模板              | ✅ 在相似客服人员之间重复使用标准化提示模板，在创造一致性和效率的同时分摊提示优化投资 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 提示模板              | ⚏ 在未经优化的情况下以对话方式编写提示，每次交互消耗 2K 以上的令牌，包括客服人员很少引用的详细指令和大量示例 |
| Agentforce \| 提示模板              | 检索上下文的所有潜在相关数据，而不是有选择地仅包含相关信息，从而增加提示令牌消耗 |
| Agentforce \| 提示模板              | 为每个客服人员创建唯一的提示模板，而不是标准化模式，增加了提示工程的工作量，而没有成比例的质量优势 |

## 缓存策略

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 客服人员配置          | ✅ 缓存常见客服人员对常见问题的响应，直接从缓存为重复查询提供服务（缓存命中率超过 30% 表示存在重大优化机会） |
| Data 360 \| 客服人员配置          | ✅ 缓存稳定的 Knowledge 上下文（产品目录、策略文档、参考材料），减少引用常见信息的每次交互的检索开销 |
| Agentforce \| 客服人员配置          | ✅ 在用户会话中实施对话缓存，跨轮次维护上下文，无需重新发送完整历史记录，减少多轮次交互中的令牌消耗 |
| Agentforce \| 客服人员配置          | ✅ 根据内容波动性定义缓存无效策略（产品信息缓存小时/天，实时数据不应缓存） |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 客服人员配置          | 尽管 60% 的查询是相同的常见问题，但没有实施缓存，这不必要地消耗了重复相同响应的 Flex Credit |
| Agentforce \| 客服人员配置          | 缓存需要新鲜度的实时数据（库存水平、定价、可用性），提供导致客服人员响应不正确的过时信息 |
| Agentforce \| 客服人员配置          | 始终不会刷新缓存的响应，从而在产品、策略或流程更改时导致答案过时 |

## 投资审批框架

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 业务 \| 文档                  | ✅ 需要业务个案，包括预测的 3 年总拥有成本、带有测量方法的预期业务结果、与替代方案的比较和风险评估 |
| 业务 \| 文档                  | ✅ 定义批准阈值，将部门可以授权的投资与需要主管批准的投资分开，以便较高投资或较高风险的客服人员接受相称的主管审查 |
| 业务 \| 文档                  | ✅ 在全面生产投资前，要求试点部署验证假设（消耗、质量、采用） |
| 业务 \| 文档                  | ✅ 在客服人员建议书中包含 ROI 计算（例如，通过解决个案和手动处理成本节省显示 4:1 的退货率） |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 业务 \| 计划                       | 部署没有业务个案的客服人员，发现 3 倍的预测信用消耗，同时提供不明确的业务价值，在没有记录 ROI 的情况下创造计划外的年度消耗 |
| 业务 \| 计划                       | 跳过试点部署，直接进入全面生产，错过了在提交全面预算之前验证消耗假设的机会 |
| 业务 \| 计划                       | 批准客服人员投资，无需与可能以较低成本提供同等价值的替代方法（手动流程、传统自动化）进行比较 |

## 客服人员产品组合优化

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 业务 \| 文档                  | ✅ 进行年度产品组合审查，评估所有客服人员的成本、使用情况、业务价值和战略一致性，以揭示客服人员审查错过的优化机会 |
| 业务 \| 文档                  | ✅ 定义日落标准（采用率低、投资回报率低、功能过时、成本过高），防止低价值客服人员累积消耗预算 |
| 业务 \| 计划                       | ✅ 实践持续投资重新分配，将资源从低绩效客服人员转移到与不断变化的业务优先级一致的高价值业务机会 |
| 业务 \| 文档                  | ✅ 按 ROI 等级对客服人员进行分类（例如，前 2 名以 50% 的成本交付 70% 的价值 = 优秀；中间 4 名以 35% 的成本交付 25% 的价值 = 可接受；后 2 名以 15% 的成本交付 5% 的价值 = 日落候选人） |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 业务 \| 计划                       | ⚏ 部署的客服人员无限期地留在生产中，没有利用率或价值审查，累积了低价值的客服人员，消耗了本可用于资助高价值业务机会的预算 |
| 业务 \| 计划                       | ⚏ 仅单独评估客服人员，没有产品组合视角，缺少一些客服人员提供最大价值的见解，而许多客服人员消耗的资源不成比例 |