[原创]用户满意度的一次改进

周五参加了一个部门的例会。会上听了新上任部门主管有关部门管理的改进计划。其中谈到工程师管理并从中引发出对一个问题的思考：未完成的任务是否需要做回访？

中心规定：凡外出维护单必须在完成之后，工程师向服务台座席员反馈并由座席员回访用户，询问用户是否对此次的维护满意。这个规定对未完成的任务只要求工程师反馈，不安排座席员回访。

这是一个很有意思的规定。直接的效果就是用户满意度基本上维持在100%。用户的特点是即使报修时喊的震天响，但工程师上门并解决了问题，用户一般还是和颜悦色地签上字并表示对工程师的满意。用户满意了，委托我们为这些用户提供IT服务的客户也就满意了。用户满意度是客户考核我们的一个指标。100%的数字完成了一个考核指标，美化了我们的服务报表。

也许从满足客户IT服务考核看，以这种方式进行满意度统计无可厚非。但从提升自身IT服务管理的角度来讲，这样的做法其实是在回避矛盾，错过发现问题，改进工作的机会。我曾经提过是否对未完成任务也进行类似的回访，但几次都被否决，因为用户满意度也是考核直接领导的指标。如果加进未完成的回访，那么很有可能带来用户满意度在短期内出现突然下降的问题。于是，几次碰壁之后我也没有再提的兴致。

有些事情峰回路转的会让你想象不到。这次例会上我也就顺口提了这个问题。没想到被重视了起来。问题提出时，领导正巧不在，回来的时候我们已经在讨论这个问题。领导听到这个问题首先表示了认可，然后询问与会人员是否有相反意见。希望看到赞成和反对的两种意见。在众人一致赞同的情况下领导要求服务台主管和实施部主管尽快讨论此事。

接下来，两位主管开始挠头。因为难题出现了。未完成满意度如何回访才能做到既能在提交给客户的报表上看到的依然是完美的服务，又能发现问题便于改进；既不能得罪领导，也不能到头来未完成回访只是做了个表面文章。

其实这个做法并不难。我们在考虑这个未完成任务的回访时，不要把目光局限在用户满意这个层面上。既然未完成在回访时会遇到一些麻烦，那么我们可以不可以换一个回访形式。不要直接询问用户：您对此次的服务满意吗？对我们的工程师满意吗？有用户一听可能会心想：没完成你还来问我这个，我能满意吗？这不是找抽的嘛！有这个担心很正常。你没有提供用户满意的IT服务，用户当然有权否定你的成绩。究竟这种担心带来的应该是因噎废食，还是亡羊补牢？

未完成任务的回访应该不以用户是否满意为询问主要目的。这个首先要明确。否则即使领导赞成回访，执行的人也找不到合适的回访方式。我的看法是未完成回访目的有两个：一是以服务补救的方式及时地安抚用户；一是为跟踪未完成任务而作记录以便做到尽快解决（这个问题是和信息系统支持不到位有关）。

完成的任务，我们可以询问您对服务态度、服务技能、响应时间等等是否满意。对未完成的任务，我们可以对用户说：对您这里的问题，我们会帮您继续跟踪。由此给您带来的诸多不便我们表示歉意，我们会尽快在下一个工作日内帮您解决这个问题。如果您还有什么意见可以向我反映等等，最后一句：谢谢您的配合。

这时候，我们对未完成任务的回访主要起到一个服务补救的作用。用户的怨气和不满我们需要在第一时间尽可能地去平息。而且这时我们回访可能会听到一些平时我们无法得知的问题。这些问题可能是工程师忽略的，也可能是对工程师不利的而隐瞒不报的。最后，每个月统计有多少家未完成，在未完成的统计中有多少家提出过意见，这些意见中是否有对工程师的各方面评价。而这种评价往往比在满意时提供的信息更有价值。

这就是未完成任务回访和完成任务回访之间的差别。完成的回访强调客户的服务体验是否得到满足，是否身心愉悦，而未完成的回访强调是客户的服务体验在得不到满足，甚至得到伤害的情况下，我们如何来抚慰。我一直强调技术的失误可以用服务来弥补，而服务的伤害无法用技术来平复。

未完成的任务，我们可以另外记录在册。规避正规的用户满意度记录。这样，我们既保证了原有报表的考核数字，又能找到一个改进自身服务的机会。

 

 

 

 

推荐到鲜果： 查阅更多相关主题的帖子: IT服务管理 用户满意度 IT服务台管理