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