记得很久之前，听朋友说过一次出差“奇”旅：他当时在北京出差，需要从地铁站中转一下再去机场。
在转站的过程中，就跑呀跑，一边跑一边想：北京的地铁，怎么台阶这么高、这么长。最重要的是，完全没有扶梯！
他后来转念一想，这么大的地铁站，不装扶梯完全不合理，于是开始给12345打电话，反映这个情况。
惊喜的是，在1个小时内，12345那边就找到了北京地铁的相关方给出了回复。
地铁方的回复内容大意是：地铁内其实是有直梯的，可能路标引导稍弱，导致大家无法第一时间找到直梯，接下来，他们会在地铁站内的各个位置摆放一些比较显眼的引导，减少这类问题的发生。
晚些时候，12345也对他进行了一次回访，主要目的是咨询这单反馈的处理流程，反馈人是否满意等等。
不管是朋友还是听了这个故事的我，都有一个很清晰的共识：地铁方可能不会因为某个人的几句反馈或抱怨就立马进行大幅改造，毕竟地铁会有自己的既定规划。但他们能及时给到反馈，且态度认真诚恳，这一点其实是最打动人的。
对朋友来说，虽然他不常在北京，但这种处理方式让他对北京这座城市又增添了一些好感度。
说到这了，就不得不提前段时间他身上发生的一件糟心事：趁着母亲节活动，朋友网购了一件东西，不幸的是，收到货后发现这件商品已经坏了。于是便开启了漫长而艰难的投诉之旅——快递方说是发货的问题，商家说是运输的问题。双方互相推诿，只苦了消费者这个皮球在中间被踢来踢去。最终的处理办法是，让平台客服介入，而的朋友态度则是不关注过程，只要一个处理结果。
两种情况、两种问题，得到的却是两种截然不同的处理态度。很明显，前者的问题解决机制更为有效，也更让人舒服。
事实上，不论是产品使用，还是一次出行，或是一次温馨的聚餐，当过程中出现各种无法预料的意外或失误时，高效的问题解决机制尤为重要。
在这篇文章中，我们要深入了解的是ITR（Issue to Resolution）流程，一个由华为提出的客户服务体系构建方法和管理流程。
一、问题发生到解决
ITR（Issue to Resolution）流程，也叫问题到解决流程，是华为三大业务流程（IPD-产品集成开发、LTC-线索到回款、ITR-问题到解决）体系之一。这一流程旨在以客户为中心，打通从问题发现、反馈到问题解决的完整服务过程，以端到端的方式打造服务闭环。
它涉及反馈的提交、评审、分发、跟踪和验证，直至最终关闭反馈等各个阶段。流程的目的是快速响应并解决客户或运维人员提出的问题，从而提高客户满意度和运维效率。
二、ITR流程的提出
在发展初期，华为面临着很多已经非常成熟强大的对手，如诺基亚、爱立信、摩托罗拉等。这些西方的巨头，他们的产品、技术等各方面都很完善。对初建的华为来说，要怎样才能从他们手里争下一份蛋糕呢？
事情的转机出现了。有一个客户以前和爱立信合作，现在开始寻求新的合作商。由于爱立信是一家瑞典公司，周六周天不上班，因此当产品出现一些问题时，客户这边无法得到及时的服务响应。在这个背景下，华为凭借24小时的问题响应服务，成功地让该客户由爱立信转向华为。
对客户来说，一个高效、及时的问题响应与解决流程，也许就是影响决策的关键因素。
三、ITR流程的挑战与解决
搭建公司自己的ITR流程时，一般会有以下几个步骤：
用户、运维、市场等人员提出问题后，及时创建反馈；
专人进行评审反馈是否合理、有效；
评审通过的反馈进行分发，需要有指定人员进行解决、处理；
及时跟进反馈状态与阶段；
验证反馈是否得到解决、解决方案是否满意；
关闭反馈。
虽然看似简单，但在实际应用中，ITR流程往往也面临着很多挑战，比如：反馈跟踪困难、处理流程长、等待时间长和反馈分发等问题。
接下来，想跟大家分享一下禅道团队的ITR流程是怎样的。
首先，无论是客户还是运维人员发现问题后，客户侧同事会判断问题是否之前出现过。若是已知问题，会直接回复客户答案或解决方案。若问题是新发生的，则会在禅道中记录，由产品经理评审反馈的合理性与描述的清晰度。合理且清晰的反馈，会进入处理流程，产品经理接下来会考虑该反馈的考虑解决方案，并可能将反馈转换为工单、Bug、用户需求或研发任务。
具体处理方式取决于反馈的类型和紧急程度：
若反馈为紧急需求或紧急Bug，但影响的是某一个或某几个特定客户，通常会转换为工单，以便快速解决影响客户流程的问题；若反馈的是较为通用的紧急需求或Bug，一般转换为任务或Bug。
在考虑需求紧急程度的维度中，一般紧急的需求会转为工单，普通需求转化为研发需求或用户需求。
同样，需求的清晰度也会影响处理方式，因为客户提出的可能仅是初步想法，需产品经理细化、拆分后才能进入研发阶段。
在做完反馈的流转后，接下来，又将由哪些人员负责跟进处理呢？在禅道团队中，具体划分为以下四个小组：
第一个是通用产品研发小组，主要负责通用产品的需求实现以及Bug解决。通用产品研发小组采用敏捷开发的方式，且周期也较为固定，一般按照两周一个迭代的节奏交付，最终交付物是通用产品的版本。
除通用产品需求外，还会有一些比较小众的研发需求。这里会有一个小众需求开发小组，同样采用敏捷开发的方式。由于小众需求量较少，处理周期也较短，迭代节奏是一周一迭代，最终交付物为插件或功能包。
对不同的客户来说，通用版本可能无法满足各种特定需求。因此，禅道成立了定制开发小组，主要负责定制需求的实现和Bug解决。定制开发小组的开发模式一般是融合瀑布模型，最终交付物是定制版本。
最后，禅道也成立了应急响应小组，主要负责处理非常紧急，需要立刻响应客户、给出解决方案的问题。应急响应小组的处理方案一般为工单，采用看板的开发方式。在应急响应小组中，没有固定的周期开发，通常是以小时为单位做估算，最终交付物为补丁或插件等。
这便是禅道的反馈跟踪矩阵。
四、具体的ITR流程在禅道中应如何落地？
在禅道中，有一个反馈模块，客户可以通过反馈模块来条目化地管理问题和反馈，还可以通过工作流功能自定义公司实际的反馈流程。
在跟踪、监控反馈的过程中，也可以通过禅道的BI模块，了解现阶段的反馈响应速度等情况。
五、应急响应小组的工程实践
在之前的反馈处理流程中，获取到一个反馈后，产品经理会依据反馈的紧急程度和适用群体，转为工单，并指派给应急响应小组。此时，应急响应小组会根据工单的基本信息，进行相应的环境搭建，进行问题修复，再以补丁或插件的形式交付给客户。
整个修复过程会耗时1~2小时，这种时长对紧急程度高的工单而言，效率较低。因此，应急响应小组编写了两个脚本来自动化流程：
一是环境配置，只需输入版本号，脚本便能自动完成版本信息的提供、下载、替换加密文件、获取授权文件以及环境搭建，整个过程仅需约15秒；
二是自动打包，研发人员在编码完成后只需提供版本信息和反馈ID，脚本便能自动完成打包、编写描述文件、压缩和加密，整个过程约需40秒。
这些脚本的应用显著提高了应急响应小组的工单处理速度，原本需耗时一小时的流程现在不到一分钟就能完成。处理完毕后，程序还会自动将打包文件推送到通讯工具中，供相关人员下载。这一自动化工程实践不仅提高了问题解决的效率，还减少了重复性工作，极大地缩短了问题响应解决时间。
由此出发，客户满意度的提高也不是什么稀罕事了。
对每一个公司来说，在如今的经济下行期，也许ITR（从问题到解决）流程会变得至关重要。华为打造的ITR流程，或许就是复制华为成功经验的绝佳路径。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
