客户投诉升级流程图
客户投诉升级流程图，一棵决策树：围绕风险、重复投诉、客户价值与付款权限的九道判断，通向六个明确的结果，并写明每一步由谁作决定。
运作方式
把泳道按决策权命名
把一线客服、团队主管、质量与合规和管理层，换成你们组织中真正握有权限的角色。泳道保持在三到四条。这不是一张部门图，因此只有当某条泳道里的人要回答下面的人无权回答的问题时，这条泳道才应该存在。
把四项条件写在首次接触判断上
“能否在首次接触时解决？”承载着整张图的绝大部分流量，因为大多数投诉都应该在这里止步。写明客服已公布的权限、他们无需请示即可提供的标准补救，以及两项排除条件：涉及风险，以及属于重复。如果处理人不问主管就没法作出这个判断，说明这道判断写得还不够严密。
设定并公布补偿上限
为“是否超出主管的金额上限？”给出每宗个案的一个具体金额，并为同一客户的重复善意补偿给出一个更低的金额。战略客户是像本图的“高价值”分支那样压过金额上限，还是仅仅知会一声，要单独作出决定。没有写明的上限，每通电话都会被重新谈一次。
定义重复与系统性的触发条件
确定什么会让“同一问题此前是否提出过？”成立：是同一根本原因而不是同样的措辞，是跨所有客户而不只是这一位，并且落在规定的回顾周期之内。然后约定这条分支触发后质量部门接手什么，包括他们是否也负责这位客户的补救，而不只是根本原因回顾。
按你们所处的行业确定外部转介路径
把“转介至独立申诉机构”换成适用于你们的机制，并附上必须先满足的条件。许多机制只有在机构已经发出最终答复、或者某个期限已过之后才受理个案。例如在英国金融服务业，FCA 的投诉规则要求在规定期限内作出最终答复——多数投诉为八周——客户之后才可以向金融申诉专员服务机构（Financial Ombudsman Service）提出。
拿已结案的个案检验这棵树
抽取一批已经处理完毕的投诉，把每一宗沿着图走一遍，比较树把它送到哪里、它当初实际去了哪里。每一处不一致，要么是缺了一条分支，要么是有一条标准大家并没有在用，这两者的价值都胜过再改一版图。
常见问题
投诉升级流程图与投诉处理流程图有什么区别？
它们回答不同的问题。投诉处理流程图是一个顺序：登记投诉、确认收到、调查、补救、提出纠正措施、结案。它告诉你接下来会发生什么、每一步由谁执行。升级流程图是一棵决策树：它告诉你该选哪个选项、谁有权作这个选择，而且它的分支通向不同的结果，而不是汇合到同一条路上。用流程图来设计程序，用本图来定下程序内部那些需要判断的地方。端到端的版本见 /zh/templates/客户投诉处理流程。
什么时候应该把投诉升级给主管？
只要首次接触的四项条件中有任何一项不成立。在本图中，这意味着补救措施超出客服已公布的权限、需要在标准补救之外额外付款、涉及安全、监管或法律因素，或者客户此前已就同一问题投诉过。把它写成四项排除条件而不是一次主观判断，正是让不同处理人之间的升级保持一致的原因，同时也让升级变得可度量——毕竟只有在背后的判断固定下来之后，首次接触解决率才有意义。
善意补偿或赔偿应该由谁批准？
按金额和客户地位分开处理，这也是本图有两条通向管理层的路径的原因。在主管已公布上限之内的付款由主管批准，个案在主管层级结束。超出上限的付款送到“管理层审阅该个案”，然后进入明确的批准或拒绝。另外，战略客户或高价值客户不论金额一律送交管理层，因为商业风险在于这段关系本身，而不在于这笔金额。两个阈值都应该写下来，因为一个没有记录的上限，在压力之下往往会一路上移。
投诉在什么情况下会走到申诉机构或监管机构？
当客户对结果提出异议，而机构自身的申诉途径已经用尽时，也就是图底部的“内部申诉途径是否已用尽？”这道判断。答“否”会把个案退回管理层再看一次，因此外部途径绝不会成为面对分歧时的第一反应。具体条件因行业而异：许多机制要求先有一封最终答复函，或者某个期限届满，才会受理转介，而且客户通常只有一段有限的时间可以提出。要把转介登记在这宗投诉上，而不是直接结案，因为这些正是监管机构日后会追问的个案。
重复投诉是否应该与首次投诉区别对待？
应该，这也是重复判断在本图中排在商业问题之上而不是之下的原因。就同一根本原因提出的第二次投诉，本身就是证据：第一次的补救解决的是个案，而不是原因。把它送往“已作为系统性问题升级至质量部门”会转移归属，让根本原因回顾与给客户的答复留在同一条记录上，而不是变成两件互不相干的工作。这个触发条件需要写明定义，通常是在规定的回顾周期内出现同一根本原因，否则它要么对什么都触发，要么对什么都不触发。