客户支持升级流程图(决策树) — Excel

客户支持升级流程图是一棵决策树:它就一线职责范围、SLA 风险、客户保护和缺陷状态对个案逐项判定,然后指名由谁接手——一线、二线、研发、客户负责人还是值班经理。

在 Excel 中每行记录一个步骤,并填写唯一编号、说明、下一步和负责人。 客户支持升级流程图是一棵决策树:它就一线职责范围、SLA 风险、客户保护和缺陷状态对个案逐项判定,然后指名由谁接手——一线、二线、研发、客户负责人还是值班经理。

简而言之

  • 在考虑任何升级之前的一道一线关口:是否在一线职责范围内?和已记录的解决方案能否解决?必须都回答是,才能到达一线解决这一结果。任一项回答否,个案都会进入由组长进行升级复核。
  • 风险敞口是最先判定的,而不是最后。是否存在声誉或法律风险?回答是,直接进入值班经理泳道的是否涉及关键客户?,其是终止于值班经理接管指挥,其否终止于客户负责人接手。
  • SLA 目标是否有风险?把有风险与仍在目标内分开:有风险的个案在任何技术分派之前先绕经客户判定,仍在目标内的个案则直接进入缺陷问题。

源数据表: 客户支持升级流程图(决策树)

在 Excel 中每行记录一个步骤,并填写唯一编号、说明、下一步和负责人。 本页是一棵决策树,不是流程图。流程图回答的是接下来会发生什么、由谁去做,从登记工单一直到结案。决策树回答的则是藏在其中的一个更窄、也争议大得多的问题:面对眼前这个个案,它是否留在一线?如果不留,由谁接手?要看包括登记、定级、重大事件处理和结案在内的端到端流程,请用事件管理流程图。要处理客户对服务本身的不满而非产品故障,请用客户投诉流程图。当争论的焦点正是路径本身时,就用这张图。

将说明映射到 Box text,将目标映射到 Line to,将分支名称映射到 Line text,将负责人映射到 Vertical lane。 升级会朝两个相反的方向出错,而两种代价都很高。升级过于随意,二线就会变成一线本可以自己关掉的个案的第二条队列,这会推高单工单成本,也会让真正需要专家的个案等得更久。升级过于罕见,一个受合同保护的客户就会从自己的用户口中得知一项被错过的承诺。这两种失败都不是靠加强监督解决的,而是靠写下来的判定条件解决——本图中共有八项,每一项都能从工单和客户档案中得到答案,而不是凭对话给人的感觉。 对照数据表检查图中的所有分支和责任人。 另请参阅 /zh/guides/如何整理-excel-流程图数据.

运作方式

  1. 指名这四位决策者

    在 Excel 中每行记录一个步骤,并填写唯一编号、说明、下一步和负责人。 把一线客服、支持组长、客户负责人和值班经理换成你们组织里真实存在的角色。小团队常常把客户负责人并入组长;有非工作时间值班安排的组织通常保留独立的值班经理,因为这个角色随排班轮换。每一条泳道都必须是一个联系得上、并且有权作出判断的人,而不是一个部门名称。

  2. 把一线职责范围写下来

    将说明映射到 Box text,将目标映射到 Line to,将分支名称映射到 Line text,将负责人映射到 Vertical lane。 是否在一线职责范围内?这项判定决定了你们有多大比例的工单永远不会升级,因此它值得一份成文定义。按能力而不是按投入程度来界定范围:一篇已发布的知识库文章、一项已记录的配置调整或一次标准的账户操作属于范围内;任何需要改代码、访问生产数据或作出合同让步的事项,按定义就属于范围外——无论客服多愿意试一试。

  3. 把 SLA 风险触发点设在期限之前

    分享前,沿着正常路径、拒绝路径和回环逐一检查图表。 决定剩余响应或解决时间达到多大比例才触发SLA 目标是否有风险?,并提前约定好,让工具可以自动触发。这条分支的全部价值在于:它要在目标仍然可以达成的时候运行。把触发点设在期限本身,只是在告诉你承诺已经错过了。

应避免的错误

  • 缺少连接

    只有明确每一步的目标,并为每个决策结果命名,任务清单才会成为流程图。 在你们团队里,是否升级取决于个人性情,同一个个案两位客服的处理方式并不相同。

常见问题

可以使用自己的 Excel 文件吗?

可以。将列映射到 QueryChart 工作表编辑器,调整行后再次核对目标位置。 流程图是一条序列:登记工单、分流、处理、解决、结案,并用泳道标明每一步由谁执行。本图是一棵决策树,它的主干是一连串问题而不是一连串任务,它的分支通向五个不同的具名结果,而不是汇聚到同一个结案步骤。用流程图去看一个个案的完整生命周期,用这棵树去处理生命周期中必须选择路径的那一个点。两者是互补的:事件管理流程图显示升级决策位于何处,而本图说明这个决策该怎么做。

什么时候应该升级一个支持个案?

当一小组写下来的判定条件中有一项回答是的时候,而不是当个案已经开了很久的时候。本图八项判定中有五项决定是否升级:个案超出一线能力、没有已记录的解决方案能够解决、SLA 目标有风险、客户属于战略或受合同保护,或者存在声誉或法律风险。其余三项决定它去哪里。已耗时长是复核个案的有用触发条件,但单独作为升级触发条件就很差,因为它只是搬动了工作,并没有增加这个个案真正需要的能力。

升级到二线和升级到管理层有什么区别?

它们解决的是不同的问题,ITIL 把它们分为职能式升级和层级式升级。职能式升级把个案交给技能更专、系统权限更深的人,也就是这里的升级至二线支持和作为缺陷升级至研发。层级式升级引入权限更高的人,用于重设客户预期、批准例外或调配资源,也就是这里的客户负责人和值班经理两个结果。一个个案可能两者都需要。当个案真正需要的是专家时却把它送上管理链,既浪费了经理的时间,也没有推动工单前进。

流程图指南中的更多内容