客户支持升级流程图（决策树）
客户支持升级流程图：由八项判定组成的决策树，把个案分派给一线、二线、研发、客户负责人或值班经理。
什么是客户支持升级流程图（决策树）流程
本页是一棵决策树，不是流程图。流程图回答的是接下来会发生什么、由谁去做，从登记工单一直到结案。决策树回答的则是藏在其中的一个更窄、也争议大得多的问题：面对眼前这个个案，它是否留在一线？如果不留，由谁接手？要看包括登记、定级、重大事件处理和结案在内的端到端流程，请用事件管理流程图。要处理客户对服务本身的不满而非产品故障，请用客户投诉流程图。当争论的焦点正是路径本身时，就用这张图。
升级会朝两个相反的方向出错，而两种代价都很高。升级过于随意，二线就会变成一线本可以自己关掉的个案的第二条队列，这会推高单工单成本，也会让真正需要专家的个案等得更久。升级过于罕见，一个受合同保护的客户就会从自己的用户口中得知一项被错过的承诺。这两种失败都不是靠加强监督解决的，而是靠写下来的判定条件解决——本图中共有八项，每一项都能从工单和客户档案中得到答案，而不是凭对话给人的感觉。
泳道命名的是决策权，不是部门。一线客服决定职责范围，以及一个已记录的解决方案是否真的有效。支持组长负责风险敞口、SLA 和缺陷这三项判定。客户负责人回答该客户是否属于战略客户或受合同保护。值班经理只回答一个问题——是否涉及关键客户——而且只有在风险敞口已经确认之后才会被问到。按这个顺序执行判定，意味着权限最高的一方胜出：一个带有法律风险的个案，不可能悄无声息地把自己排进研发的待办队列。
本流程图涵盖的内容
本模板包含
- 在考虑任何升级之前的一道一线关口：“是否在一线职责范围内？”和“已记录的解决方案能否解决？”必须都回答“是”，才能到达“一线解决”这一结果。任一项回答“否”，个案都会进入“由组长进行升级复核”。
- 风险敞口是最先判定的，而不是最后。“是否存在声誉或法律风险？”回答“是”，直接进入值班经理泳道的“是否涉及关键客户？”，其“是”终止于“值班经理接管指挥”，其“否”终止于“客户负责人接手”。
- “SLA 目标是否有风险？”把“有风险”与“仍在目标内”分开：有风险的个案在任何技术分派之前先绕经客户判定，仍在目标内的个案则直接进入缺陷问题。
- “是否为战略客户或受保护客户？”位于客户负责人泳道。回答“是”终止于“客户负责人接手”；回答“否”则汇回技术分派路径，而不是另开一条并行队列。
- 经由“是否确认为产品缺陷？”进行的技术分派：“否”终止于“升级至二线支持”，“是”继续走向“是否有变通方案？”，其中“否”终止于“作为缺陷升级至研发”。
- 一个有意为之的“不升级”结果：当存在变通方案时，客服把方案提供给客户，个案终止于“登记为缺陷，不予升级”，于是这个缺陷进入常规的研发待办队列，而不是消耗一次升级。
何时使用本模板
- 在你们团队里，是否升级取决于个人性情，同一个个案两位客服的处理方式并不相同。
- 二线或研发正在就升级质量提出异议，你们需要的是双方认可的准入条件，而不是更严厉的语气。
- 客户经理总是先从客户口中、而不是先从内部听说严重个案。
- 你们正在编写或修订升级政策，希望在有人动笔写正文之前先把判定条件和决策权谈定。
- 你们正在培训新的支持人员，需要一页纸说明何时升级、升级给谁，与端到端流程图配套使用。
运作方式
指名这四位决策者
把一线客服、支持组长、客户负责人和值班经理换成你们组织里真实存在的角色。小团队常常把客户负责人并入组长；有非工作时间值班安排的组织通常保留独立的值班经理，因为这个角色随排班轮换。每一条泳道都必须是一个联系得上、并且有权作出判断的人，而不是一个部门名称。
把一线职责范围写下来
“是否在一线职责范围内？”这项判定决定了你们有多大比例的工单永远不会升级，因此它值得一份成文定义。按能力而不是按投入程度来界定范围：一篇已发布的知识库文章、一项已记录的配置调整或一次标准的账户操作属于范围内；任何需要改代码、访问生产数据或作出合同让步的事项，按定义就属于范围外——无论客服多愿意试一试。
把 SLA 风险触发点设在期限之前
决定剩余响应或解决时间达到多大比例才触发“SLA 目标是否有风险？”，并提前约定好，让工具可以自动触发。这条分支的全部价值在于：它要在目标仍然可以达成的时候运行。把触发点设在期限本身，只是在告诉你承诺已经错过了。
提前定义受保护客户名单
“是否为战略客户或受保护客户？”必须能在几秒内从 CRM 中得到答案。维护一份明确的名单，并记录一个客户凭什么被视为受保护：被指定的战略地位，或者写入协议的响应与解决承诺。逐案判断，正是让嗓门最大的客户、而不是最重要的客户获得优先处理的原因。
与法务一起确定风险触发条件
“是否存在声誉或法律风险？”是那条会压过其他所有判定的分支，因此它的判定标准应当在支持部门之外获得签署确认：个人数据外泄、涉及监管机构或审计方、存在安全风险、出现公开帖文或媒体查询，或者合同罚则被触发。清单要短到在压力下也记得住，并且任何单一条件成立即为充分。
约定什么算确认缺陷、什么算可接受的变通方案
为“是否确认为产品缺陷？”设定证据门槛，例如已在受支持版本上按另一位工程师可以照着走的步骤复现，这样未能复现的报告就会转给二线做诊断，而不是转给研发。然后决定由谁判断变通方案是否可接受。如果这个判断只由支持部门作出，“登记为缺陷，不予升级”这一结果就会遭到从未同意过它的客户质疑。
常见问题
这与客户支持升级流程图有什么不同？
流程图是一条序列：登记工单、分流、处理、解决、结案，并用泳道标明每一步由谁执行。本图是一棵决策树，它的主干是一连串问题而不是一连串任务，它的分支通向五个不同的具名结果，而不是汇聚到同一个结案步骤。用流程图去看一个个案的完整生命周期，用这棵树去处理生命周期中必须选择路径的那一个点。两者是互补的：事件管理流程图显示升级决策位于何处，而本图说明这个决策该怎么做。
什么时候应该升级一个支持个案？
当一小组写下来的判定条件中有一项回答“是”的时候，而不是当个案已经开了很久的时候。本图八项判定中有五项决定是否升级：个案超出一线能力、没有已记录的解决方案能够解决、SLA 目标有风险、客户属于战略或受合同保护，或者存在声誉或法律风险。其余三项决定它去哪里。已耗时长是复核个案的有用触发条件，但单独作为升级触发条件就很差，因为它只是搬动了工作，并没有增加这个个案真正需要的能力。
升级到二线和升级到管理层有什么区别？
它们解决的是不同的问题，ITIL 把它们分为职能式升级和层级式升级。职能式升级把个案交给技能更专、系统权限更深的人，也就是这里的“升级至二线支持”和“作为缺陷升级至研发”。层级式升级引入权限更高的人，用于重设客户预期、批准例外或调配资源，也就是这里的客户负责人和值班经理两个结果。一个个案可能两者都需要。当个案真正需要的是专家时却把它送上管理链，既浪费了经理的时间，也没有推动工单前进。
每一个确认的产品缺陷都需要升级给研发吗？
不需要，而且把每一个缺陷都当作升级，正是升级失去意义的原因。本图在“是否有变通方案？”处分叉。没有可接受的变通方案，客户就被卡住了，于是个案终止于“作为缺陷升级至研发”，并带有影响服务的优先级。有变通方案时，客服把方案提供给客户，个案终止于“登记为缺陷，不予升级”：这个缺陷仍会通过常规的缺陷接收与排期路径到达研发，只是不会打断任何人。第二个结果被特意画成一个“拒绝”型终止节点，因为决定不升级是评估的一项正当结果，就应当被这样记录下来。
谁有权拒绝一次升级？
谁负责那项未通过的判定，谁就有权拒绝——这也是本图泳道代表决策权而非部门的原因。组长可以拒绝一个在风险敞口、SLA 和缺陷三项判定上都未通过的个案，并把它退回一线。客户是否受保护由客户负责人决定，而不是由支持部门决定。值班经理决定客户是否属于关键客户，而且只有在风险敞口已经确认之后才会被问到，这让这个角色留给真正需要指挥的场合。没有记录理由就被拒绝的升级，正是会再回来的那些，因此请把是哪一项判定未通过记录在个案上。