客服工作区导航：我与 Service Console 设计的旅程

二月 06, 2026

我记得很清楚，当我们团队开始着手优化客服代理的工作效率时，Salesforce Service Console 自然成了我们的核心关注点。一开始，我们都很兴奋，觉得这个平台功能强大，能把所有东西都集中到一个地方。但很快，我们发现了一个实际问题：如果设计不当，这种“集中”反而会变成“混乱”。

初见“混乱”：信息过载与上下文切换

我们遇到的第一个挑战是：信息过载和频繁的上下文切换。代理们抱怨说，每当他们打开一个 Case，或者从 Case 导航到关联的 Account、Contact 时，往往会自动弹出多个新标签页。有时是 Case 本身，有时是其关联的 Contact，甚至还有历史工单列表。屏幕上很快就堆满了各种标签页，导致他们难以分辨当前最重要的数据，也增加了寻找特定信息的认知负担。

问题表现：
打开一个 Case，同时弹出 Contact 详情和相关的活动列表，每个都占一个新标签。
从 Case 上的相关列表点击一个 Opportunity，又是一个新标签。
结果就是，代理需要手动关闭大量无关或已处理的标签页，或者频繁地在多个标签之间切换，大大降低了响应速度。

摸索与判断：Console Navigation 的取舍

这个问题让我深入研究了 Service Console 的导航设置，特别是 App Manager 中针对具体 Console App 的 Navigation Items 和 Workspace Settings。我们最初的设想是“把所有相关信息都展现出来”，但实践证明，这和“高效工作”是两码事。

决策一：Tab vs. Subtab 的哲学

这里最关键的配置是 Workspace Settings 下的 Open records as。它有两个主要选项：

New primary tabs (打开为新的主标签页)
Subtabs of the current record (作为当前记录的子标签页)

我的判断是，并非所有关联记录都需要同等重要的“主标签页”地位。例如，当代理查看一个 Case 时，他们通常需要深入了解该 Case 的详细评论、附加文件、或相关的活动记录。这些内容与 Case 紧密相关，如果每次都打开一个新主标签页，就破坏了 Case 的上下文。

因此，我们决定：

主标签页 (Primary Tabs)：只用于核心业务对象，例如 Case、Account、Contact。当代理明确需要“切换到”一个新主题时，才应该打开主标签页。
子标签页 (Subtabs)：用于与当前主记录紧密关联、需要快速切换查看的信息，例如 Case Comments (案例评论)、Files (文件)、Activities (活动) 等。当代理在查看一个 Case 时，点击这些相关列表的记录，应该作为 Case 的子标签页打开。

这个调整极大地改善了导航体验。代理可以专注于一个 Case，而其相关的详细信息则以子标签页的形式呈现，保持了上下文的连贯性。

// 概念性配置描述，实际在 Salesforce UI 中进行
Service Console App -> App Settings -> Workspace Settings

Primary Tab Behavior:
  - Account: Open as new primary tab
  - Contact: Open as new primary tab
  - Case: Open as new primary tab

Subtab Behavior (for records opened from a Primary Tab):
  - Case Comments (from a Case): Open as subtab of the current record
  - Files (from a Case): Open as subtab of the current record
  - Activities (from a Case): Open as subtab of the current record
  - Other related lists (e.g., related Opportunities from an Account): Open as subtab of the current record

当然，这需要细致的权衡。如果子标签页太多，也可能导致单个主标签页下的信息密度过高，需要频繁横向滚动。我们的经验是，每个主标签页下最多保持 3-5 个活跃的子标签页是比较理想的范围。

决策二：Utility Bar 的精简与提效

Utility Bar 是 Console 的另一个强大功能，它允许代理快速访问常用工具，而无需离开当前工作区。我们最初也犯了“什么都往里放”的错误，导致 Utility Bar 变得很长，一些不常用的工具也占据了空间。

我们的判断标准是：Utility Bar 应该只包含那些代理在几乎任何上下文中都可能需要即时访问的工具。

我们放入的：

Omni-Channel：这是核心的路由工具，必须随时可用。
Scripts：我们的自定义脚本工具，用于引导代理完成特定流程。
Knowledge Search：快速搜索知识库文章，不需切换上下文。
一个自定义的 Quick Create 组件：用于快速创建任务或其他小对象，减少点击。

我们没放入的（或后来移除的）：

History：虽然有用，但大部分时间代理都在当前 Case 上，不常回顾历史。如果需要，也可以通过其他方式查看。
特定的报表/仪表板：这些通常是辅助性的，不需要即时访问。
与当前上下文强关联的组件：这些更适合直接放在记录页面布局上。

通过精简 Utility Bar，我们确保了其真正作为“工具箱”的价值，而不是一个杂物间。

更深层次的优化：Embedded Components

在解决了导航混乱之后，我们开始思考如何更进一步地提升信息的可视性，而不是仅仅依赖点击和切换。这时候，嵌入式的 Lightning Web Components (LWC) 就发挥了巨大作用。

我们发现，代理在处理 Case 时，往往需要预先知道客户的某些关键信息，例如：

客户最近开过的其他 Case。
客户拥有的产品或服务合同信息。
来自外部系统的客户信用评级。

如果这些信息都藏在相关列表里，代理需要点击、等待加载、再点击，这个过程效率很低。我们的解决方案是，在 Case 记录页面布局的右侧或底部，嵌入定制的 LWC 组件。

// 示例：一个嵌入式 LWC 的概念
// myRecentCustomerCases.js
import { LightningElement, api, wire } from 'lwc';
import getRecentCases from '@salesforce/apex/CaseService.getRecentCases';

export default class MyRecentCustomerCases extends LightningElement {
    @api recordId; // 当前Case的ID
    customerRecentCases;

    @wire(getRecentCases, { caseId: '$recordId' })
    wiredCases({ error, data }) {
        if (data) {
            this.customerRecentCases = data;
        } else if (error) {
            console.error('Error fetching recent cases', error);
        }
    }
}

// myRecentCustomerCases.html

通过这种方式，当代理打开一个 Case 时，无需任何点击，就能在页面右侧或底部直接看到一个简洁的卡片，上面展示了客户最近的 3-5 个工单，或者客户的核心产品信息。这大大减少了代理的探索时间，让他们能更快地进入问题解决的核心。

当然，嵌入组件的权衡在于性能。过多的复杂 LWC 会增加页面加载时间。我们的经验是，每个页面布局上嵌入的自定义组件不宜超过 3-4 个，且每个组件的数据加载逻辑应该尽量优化，避免不必要的查询。

总结与未尽之思

回顾我们对 Service Console 的优化过程，我最大的感悟是：Service Console 的强大不在于它能做什么，而在于你如何通过精心的配置和设计，让它“少做”或“做对”事情，从而赋能代理。

它不是一个开箱即用的完美解决方案，而是一个高度可配置的平台。理解代理的实际工作流，然后围绕这些流去配置导航、信息展现和工具集，才是关键。我们在过程中不断尝试、收集反馈、调整，逐渐摸索出了一套适合我们团队的 Console 配置。

目前，我们仍在探索如何更好地集成第三方系统数据到 Console，以及如何利用 AI 驱动的建议进一步优化代理的决策过程。这些都是在现有 Console 框架下，需要持续思考和实践的课题。

Salesforce中文网