客户支持升级流程图（一线到二线）
泳道式客户支持升级流程图：一线解决尝试、有记录的二线交接、严重程度与 SLA 复评、升级至研发。
什么是客户支持升级流程图（一线到二线）流程
升级是客户支持中大多数团队凭直觉运行的那一部分。客服做到了自己能力的边界，个案于是横向转给更懂行的人，或者纵向转给权限更大的人。ITIL 把这两种移动分别称为职能式升级和层级式升级，而它们并不能互相替代：把个案交给专家，并不会告诉客户负责人任何事情；而告诉经理，也不会让故障得到诊断。本图把两者画成两条独立的分支，好让团队就“谁在什么时候被告知什么”达成一致。
有必要把这个流程不是什么讲清楚。它不是完整的工单生命周期：首次接触即解决的个案根本不会进入这里，本图会把它们直接引向客户确认。它不是事件管理——当同一个故障同时影响许多客户、目标从关闭一个个案转向恢复一项服务时，事件管理才接手。它也不是缺陷分级：一旦研发接受了一个可复现的缺陷，这个缺陷就按自己的节奏进入分级与发布流程，而支持个案则继续对客户保持开启。它同样不是投诉处理——如果客户不满的是自己被如何对待，而不是某个技术故障，那就应该走投诉流程。
下面绘制的版本横跨五条泳道：客户、一线支持、二线/专家、支持经理和研发。两条分支承担了大部分重量。“一线是否已解决？”是决定究竟会不会发生升级的那道关口，也是团队最常留给个人判断的一步——正因如此，同一个个案在一位客服手里十分钟就升级，在另一位手里却压了三天。“是否关键个案或重点客户？”决定支持经理和客户负责人是在个案仍然开启时听说它，还是在客户已经找上他们之后才听说。所有离开一线的个案，包括被重新打开的个案，都要经过同一份有记录的交接，好让接手的专家看到已经尝试过什么、已经排除了什么。
本流程图涵盖的内容
本模板包含
- 五条泳道，每一步都有指定负责人：客户、一线支持、二线/专家、支持经理和研发，分布在从受理与分流到解决与复盘的五个阶段。
- 在考虑任何升级之前的一线工作：“登记个案并记录影响”“对照已知问题分流”和“尝试一线解决”，使升级决策是针对一次有记录的尝试作出的，而不是凭感觉。
- 升级关口本身：“一线是否已解决？”要么把个案送往客户确认，要么送入“记录升级交接说明”——这是每一个升级个案和每一个重新打开的个案都必须经过的唯一交接记录。
- 交接时的重新评估：二线执行“评估严重程度与 SLA 影响”，随后由“是否关键个案或重点客户？”分支在调查继续进行的同时通知支持经理与客户负责人，而不是等客户自己升级之后才通知。
- 研发路径：“是否确认为产品缺陷？”把配置问题与真正的缺陷区分开，把缺陷交给研发去复现并登记，再由“本次发布是否已有修复？”分出“已应用修复”与“与客户约定的临时变通方案”两条路。
- 确认与复盘：“客户是否确认已解决？”会把仍未解决的个案退回交接步骤，而不是直接结案；已确认的个案则经过升级后复盘和一篇已知问题文章，然后才结案。
何时使用本模板
- 升级靠私聊消息或走到别人工位旁边完成，个案一旦离开一线，谁也说不清由谁负责。
- 你们正在设定或重设分级定义，希望把一线与二线之间的边界写成一个带判定条件的决策，而不是两份岗位说明。
- 客户比你们的支持经理或客户负责人更早知道严重个案。
- 你们正在工单系统里配置升级规则、队列、严重程度字段和 SLA 计时器，希望在工具无意中固化一套流程之前先把流程谈定。
- 被升级的个案比同类在一线解决的个案耗时长得多，你们需要看清多出来的时间究竟卡在哪一次交接上。
运作方式
把泳道改成你们真实的角色
把客户、一线支持、二线/专家、支持经理和研发换成你们实际拥有的职能。小团队通常把二线并入研发；设有专属客户经理的团队常常把支持经理泳道拆成值班经理和客户负责人。即使客户泳道只有两个节点，也要保留它，因为那正是由客户、而不是由你们控制流程走向的两个点。
界定一线被允许做什么
“一线是否已解决？”需要同时挂上范围和时限：客服可以访问哪些系统、可以执行哪些操作，以及一次一线尝试进行多久之后个案就必须往下走。两者缺一，升级量就会随当班的人而波动。请明确写出：在时限内升级是正确的结果，而不是一次失败，否则客服会为了保住自己的数字而压着个案不放。
固定交接记录的内容
决定“记录升级交接说明”必须包含什么，并把它做成工单系统里的模板：受影响的客户与环境、复现步骤、已经尝试过并排除了什么、对客户的影响，以及已经向客户说过什么。从聊天记录里粘贴出来的交接，是专家把第一个小时的工作重做一遍的最常见原因。
为关键分支写出客观触发条件
“是否关键个案或重点客户？”不应该取决于客户写得多大声。使用可以核查的条件：业务关键流程被阻断、被指名的战略客户、合同响应目标面临风险，或者个案已经被重新打开过一次。写明每个触发条件通知谁，并声明通知本身不会重新排定队列优先级，否则每一个个案都会变成关键个案。
决定研发暂时无法修复时该怎么办
缺陷一旦被接受，就进入研发的发布节奏，而它比支持的节奏慢。请约定在此期间由谁负责维护客户关系、即使没有新消息也要多久更新一次，以及你们承诺的是一个目标版本还是一个具体日期。“尚未”这条分支存在的意义，就是让变通方案成为与客户明确达成的约定，而不是一段沉默。
约定重新打开的规则，然后发布一个有版本的副本
本模板把确认失败的个案退回交接步骤，因此重新打开的个案会被重新记录、重新评估，而不是被丢进某个队列。如果你们希望重新打开的个案直接回到上一位负责人手上，就改掉它。然后与每一条泳道一起走一遍这张图，修正大家实际执行的步骤，并把它作为当前版本发布并签署确认，好让日后阅读的人知道适用的是哪一版。
常见问题
什么是客户支持升级流程？
它是一个支持个案在一线无法解决之后所遵循的、有记录的路径。它涵盖的不是完整的工单生命周期，而是从一线能力边界开始的那一段：升级的决定、向专家的交接、在个案注定要花更长时间之后对严重程度与 SLA 影响的重新评估、调查本身，以及使个案结束的确认与复盘。它的价值不在于各个步骤本身——大多数团队本来就在做——而在于就每一个节点由谁负责、以及个案易手之前必须写下什么达成一致。
支持个案什么时候应该从一线升级到二线？
使用客服可以核查的条件，而不是主观判断。覆盖大多数情形的三条是：客服缺少诊断所需的权限或工具；症状超出已记录的一线职责范围；或者一线尝试的时限已过而仍未解决。第四条被刻意单列：个案需要一个只有他人才能作出的决定，例如一笔信用额度或一项合同让步。唯独不应当单独作为触发条件的，是客户要求升级，因为那会把分级变成一场谈判。这类要求应当走通知分支来处理。
职能式升级和层级式升级有什么区别？
职能式升级把个案横向转给更懂行的人，例如一线交给专家。层级式升级把它纵向转给权限更大或需要知情的人，例如通知支持经理和客户负责人。它们解决的是不同的问题，在本图中也表现为两条独立的分支：“一线是否已解决？”的升级分支是职能式，“是否关键个案或重点客户？”的关键分支是层级式。常见的失败是做了其中一个，就以为覆盖了另一个，于是专家在默默处理一个个案，而客户负责人却是从客户那里第一次听说它。
这与事件管理有什么不同？
升级是把一位客户的个案转给更有条件解决它的人。事件管理是为所有受同一个故障影响的人恢复服务。触发条件、时间尺度和成功标准都不一样：一个被升级的个案，衡量标准是这位客户是否已解决并确认；一个事件，衡量标准是服务多快恢复。当多个被升级的个案指向同一个故障时，就由事件流程接手，这些个案被关联到该事件，并在服务恢复且每位客户确认之后结案。把两者分开，正是防止服务台把一次故障当作五十条并行调查来跑的关键。
升级之后由谁负责这个个案，交接记录应该包含什么？
调查的所有权转给专家，但客户关系的所有权通常仍留在最初那位客服手里——本图通过回到一线执行“与客户确认解决结果”体现了这一点。请明确设定这条分工，因为双方都以为对方在更新客户，是沉默最常见的来源。交接记录应当载明受影响的客户与环境、复现步骤、已经尝试过并排除了什么、对客户的影响，以及已经向客户说过什么。把它保持为一条记录而不是一个消息串，这样重新打开的个案再次经过同一步骤时，会累加进同一份历史。