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