在ITR里可能产生一些新的需求，而实际上解决方案的推进还是在LTC流程里。

ITR重点的管理就是技术服务方面的一些问题故障，还有一些请求把这部分快速推进。要去解决一些问题或者一些请求，不一定是能够在一线或者服务体系里，能够在小团队里完成，可能还需要其他的团队协助。比如更换一些产品，可能就和LTC销售团队相关；比如一些功能性或质量的问题，可能和IPD的团队相关。

 

一、ITR服务流程体系的四大模块

 

ITR对于科技制造型企业来讲，通常分为以下四个模块：

第一个模块：管理技术服务请求。

通常是解决一些客户的产品使用问题，如产品质量或设备故障等问题。

 

第二个模块：管理备件服务交付。

备件是为了解决产品问题，如为一些硬件产品问题提供一些备件，由于这涉及到成本，因此需要进行一个规划，看要多少配件，以及配件怎么保存等等。

 

第三个模块：管理非技术服务请求。

可能是问价或问一些解决方案，通常不会在ITR某个具体环节里执行，会转到相应其他的一些流程，比如LTC流程或别的流程去处理，处理完了以后反馈信息在ITR里去关闭。

 

第四个模块：管理客户声音。

它不单是一个客户投诉的事情，还包括了前面技术服务请求也好，非技术服务请求也好，备件也好。这么多的工单在里面，我们在一个时间周期，比如一个月或者一个季度去进行工单统计，看有哪一些共性的问题，整合了以后把问题分发到相应的职能组织。

比如发货的问题，可能就会发到供应链里进行整改；产品质量，功能性的问题发到研发去整改；其他客户满意度的问题，就发到一些客户满意度做得不好的职能部门去整改。

要把ITR做成一个业务流程，而不是一个服务团队流程。

 

二、工单受理流程和知识库建设

 

ITR有很多需求可以录入进去。工单是ITR流程里的一个功能，即当客户打一个电话进来，或者是发一个邮件过来说有一个什么问题，受理的员工就要去创建一个工单。

创建工单的目的就是要把这个工单一直跟踪到结束能够关闭为止，这样就不会丢失。

 

1、工单受理流程

工单受理的流程通常把技术服务分成受理、处理和关闭三个小模块。

受理有两种方式，第一种是通过机器人进行回应，即客户输入关键字之后看是否找到相关的解决方案，同时会有一个满意度调查的框跳出来，最后就关闭问题了了；但在大部分To B业务的情况下，网上的机器人方式不太适用，比如可以通过微信或app的方式来让客户把问题输入，通过一些现成的工单模版输入以后登记问题。

看客户提的问题是不是在我的服务范围内，再去看它可能是哪一个产品的问题，可能是只卖盒子，也可能是卖一整套的解决方案，你不一定能够知道是哪一个部门，哪一个工种能够去解决这个问题，问清楚才会分发到下一个工序。这个过程中已经基本了解了一些状况，也可能解决了一些问题。这需要有一个基础的数据库，短时间内就能找到。

同时，要去判断他是不是我的客户，如果不是客户，可能只是过来问个价，问个解决方案，那么就把它进行信息录入；如果是客户的话，它就需要关闭流程，如果不可以，就进行派单，把它派到第三方流程去。处理流程大概就是这样的一个基本逻辑。

 

2、工单录入风险

如果大部分数据都是靠销售或服务代表来录入的话，刚开始可能没什么问题，时间久了以后，就会发现这其实存在着一个很大的风险：客户更加依赖于销售或服务代表，而不会直接去找到服务团队来解决问题了。

这就会导致两个问题：第一，服务效率没有那么高；第二，当销售或服务代表换人了以后，客户就找不到合适的人，就会认为企业服务上有问题。

很多企业在ITR流程建设的过程中，都会要求企业引导客户直接和服务热线打交道。如果有一些紧急的问题，正好有一个工程师在旁边，就直接让工程师去解决。

但是大部分情况下，尤其是中小企业也不太可能随时都会有一个工程师在身边，这个时候要有一个快捷的途径帮助客户去解决问题。

每个公司都有它的一些特点，要去分析到底哪一种可能会更有效率。

 

3、知识库建设

在知识库里，不是所有的问题都很复杂，大部分的问题其实很简单、常见。

知识库建设有很多的方法，需要有很多的案例来充实。如果案例库不行，使用的人就会更少，大家就会更加没有积极性，它是一个相互的过程。

首先要让大家踊跃去写案例来充实知识库，写了后能得到一定的好处，比如职级晋升等；其次看写的案例被引用或使用过多少次，他就会得到对应的一些奖励。

同时，知识库并不需要一个复杂的软件，做一个文件服务器就可以，它只需要满足一个“模糊查询”的功能即可，打其中一两个字就可以搜索得到。

在知识库里面，要把问题分成若干的大类，比如需要解决方案去负责的有哪些类？然后再进一步分成小类，比如有十种产品，那可能你分成三个小组，看由哪一种来解决。

 

三、ITR流程里的工单流转-问题单的管理逻辑

 

问题进来之后先选择产品，产品选完了之后具体分析可能出现的问题类型。根据这条产品线下所出现的问题类型，对应给团队里的具体人员。这时可能会有以下两种场景。

第一种场景：你卖若干个盒子，单单产品就比较容易去判别；

第二种场景：你可能卖了一个解决方案系统，比如某一个局域网有好几百个节点，若某一个点不通，很难判别是哪个产品的问题，这需要一定能力去初步判别，可能是路由器的问题，就把问题转到路由器相关的小组，经过排查发现不是，就把单转到另外一个小组去。

 

对于类似于产品组合或者解决方案的第一步也是初步排查，第二步是谁排查，它并不是说一开始大家就在一个问题下进行讨论，这在部门的责任人里是有优先级的。

这个需要去看问题的紧急程度，如果网络都已经瘫痪了，就没有那么多时间先去召开一个什么会去排查，只能先初步判断可能是某一个事情的问题，就先发到某一个地方去。

 

如果是一个非常紧急的问题，就要立刻形成一个小团队去做，牵头去形成一个快速排查的机制，进一步把问题分层分级去管理。不同等级问题的划分都需要有明确的定义。

比如去定义清楚什么是紧急问题，什么是重大问题，什么是一般问题等等。紧急问题的处理流程和一般问题的处理流程不一样，紧急问题需要更快，可能就要有一个小组去解决；如果只是一般问题，一个隐患什么的，慢慢排查也没问题。

ITR流程更倾向于是一种问题事件处理流程，类似于工单处理的思维。