一个常见的客户支持问题听起来很简单：谁来处理这张工单？在较小的团队里，答案是”谁有空谁处理”。在较大的团队里，这个答案就行不通了：重置密码和数据库迁移不可能由同一个人高效处理。
支持层级就是结构性的答案。它们按复杂程度把涌入的问题分成三层，让合适的技能水平处理合适的问题。本指南介绍每个层级实际做什么、工单如何在层级之间升级，以及团队在划分时容易出错的地方。
主要优势
- 技能与问题匹配： 简单问题由 Tier 1 直接解决，无需等待专家；复杂问题能得到妥善处理，而不必由通才去猜测。
- 平均解决速度更快： 由于 60-80% 的工单在 Tier 1 关闭，Tier 2 和 Tier 3 的专家不会成为瓶颈。
- 职业发展路径更清晰： 客服坐席从 Tier 1 成长为 Tier 2、Tier 3，每次晋升都有明确的技能标准。
- 人员配置可预测： 每个层级的业务量可以独立预测，使容量规划变得可行。
每个层级实际处理什么
具体的划分因行业而异，但原则是一致的。
Tier 1 一线客服坐席
Tier 1 是第一接触点。所有涌入的工单都从这里开始（除非路由规则明确将高优先级账户发送到其他地方）。
Tier 1 处理的内容： 账户问题、密码重置、订单状态、标准产品信息、初次投诉受理、基础故障排查，以及知识库中已有解决方案的所有问题。
所需技能： 沟通能力、用户层面的产品熟悉度、对常见问题按标准话术回复的执行力，以及判断何时应升级的判断力。
典型解决率： 在设计良好的结构中，全部涌入工单的 60-80% 应在 Tier 1 关闭。如果 Tier 1 的关闭率低于这一水平，要么是知识库不够完善，要么是升级触发条件过于宽松。
Tier 2 产品专家
Tier 2 承接 Tier 1 无法解决的问题：需要更深入的产品知识、对工作流的理解，或有权批准政策例外的问题。
Tier 2 处理的内容： 复杂的配置问题、特定工作流的问题、退款例外、已升级的投诉、需要产品深度的技术问题，以及涉及多个系统的案例。
所需技能： 深入的产品知识、复现客户所报问题的能力、熟悉后端工具和管理界面，以及在规定范围内对政策例外作出判断的能力。
典型解决率： Tier 2 应关闭升级到它这里的 70-85%。其余部分要么升级到 Tier 3，要么需要产品或工程方面的变更。
Tier 3 工程或产品团队
Tier 3 是需要代码变更、基础设施工作或尚未解决的缺陷的问题最终落到的层级。在大多数公司里，Tier 3 并不由专职支持坐席组成，而是由工程或产品团队轮流承担支持职责。
Tier 3 处理的内容： 已确认的缺陷、需要代码修复的集成故障、数据损坏、安全事件、触发产品根本性限制的边缘情况，以及任何需要改动底层系统的问题。
所需技能： 工程知识、直接访问系统的权限、编写补丁或热修复的能力，以及事件响应经验。
典型业务量： 应低于全部涌入工单的 5%。如果 Tier 3 被大量工单淹没，说明 Tier 2 的升级标准有误，或者产品存在系统性问题。
升级实际如何运作
升级是大多数层级结构出问题的地方。有两种模式会导致失败。
升级过于积极。 如果 Tier 1 把任何超过三分钟的工单都升级，Tier 2 就会成为瓶颈，Tier 1 也会失去意义。正确的升级触发条件很具体：无法复现、需要政策例外、客户明确要求主管介入，或问题属于已知的高难度类别。
升级过于迟缓。 如果 Tier 1 在超出自身能力的问题上坚持处理，解决时间就会膨胀，CSAT 也会崩塌。基于时间的升级：在 N 分钟内未解决就自动提升到 Tier 2，可以防止这种情况。
健康的模式是：明确的升级标准加上硬性的时间上限。两者必须同时具备，而不是只取其一。
团队在划分上容易出错的地方
在早期团队中合并 Tier 1 和 Tier 2。 小团队常常完全跳过划分，这在业务量增长之前是可行的。引入 Tier 2 的正确时机，是当同一位专家不断被从其他工作中拉走时；这就是需要设立专职层级的市场信号。
让 Tier 3 做 Tier 2 的工作。 把数小时花在本应在 Tier 2 解决的问题上的工程师，就是没有在开发产品的工程师。这通常是因为 Tier 2 缺少工具访问权限，而不是因为 Tier 2 缺少知识。
没有交接协议。 一张没有背景信息、没有复现步骤、没有客户历史的升级工单，会让 Tier 2 从零开始。交接协议（尝试过什么、客户说了什么、Tier 1 得出了什么结论）不是额外负担，而是升级正在正常运作的体现。
工具在其中扮演的角色
分层结构需要支持升级流程的工具。将新工单默认路由到 Tier 1 的路由规则、能传递完整上下文的升级按钮，以及让 Tier 2 和 Tier 3 查看 Tier 1 对话历史的可见性。
像 Cekat 这样的平台在单一工作区内处理路由和交接机制，因此升级时客户记录、对话历史以及所有尝试过的解决方案都会随工单一起传递。这消除了工单向上层移动时的”从零开始”问题。
从哪里开始
如果你的团队规模较小（少于五人），正式的分层结构可能为时过早。相反，找出两三种持续超出平均处理时间的工单类型：这些就是正在形成的 Tier 2 类别，它们标志着何时应当正式化。
如果你的团队规模较大且业务量在上升，请衡量当前的划分情况：如今每个层级各自解决了多少工单。如果超过 40% 的工单越过了第一位客服坐席，Tier 1 就需要更好的工具或更好的培训。如果升级比例低于 10%，Tier 1 很可能在吸收本应由专家处理的工作。
关于客户服务、客户关怀和客户支持如何在统一团队中划分职责的相关观点，请参阅客户服务 vs 客户关怀 vs 客户支持。
支持层级不是官僚化的层级。它是对增长问题的结构性答案：如何在不论复杂程度、对每个问题都投入同样多注意力的情况下，处理更大的业务量。
发表回复