运维的兄弟不得不看的客户满意度构成元素 客户满意度是考核服务绩效的关键指标之一，这一点是毋须质疑的，但在具体考核的执行过程中，我们有没有质疑过"满意度"的合理性和可执行性呢？当我们遭遇投诉或者获得低满意度评分时，有没有一起深入讨论"投诉和低评分"的深层诉求呢？满意度渗透在工作过程的每个细节，应用范围广泛至极，无所不含，我想用自己熟悉的IT运维为例，和大家分享一下客户满意度的组成元素。为了不混淆概念，在分享之前，我们先界定一下这篇小文所言客户的范围专指内部客户即企业内部员工。
百度百科对客户满意度的解释是这样的：满意是一种心理状态。是客户的需求被满足后的愉悦感，是客户对产品或服务的事前期望与实际使用产品或服务后所得到实际感受的相对关系。从释义上我们可以抽离出客户满意度的组成元素：心理状态、愉悦感、事前期望、实际感受，还有客户满意度的中介载体：产品或服务。
客户满意度一定是基于彼此认可的一种契约，绝不是一厢情愿的单相思，从供方的视角我们要在事前确定"你（需求方）需要什么"，"做到什么程度"，"我们怎么做"，这就是目标-标准-方法，从价值实现角度讲，我们(供方)的满意度一定是来自客户（需方），而不是来自我们内部，彼此之间是依靠"产品或服务"维系的，所以不管是供方还是需方都需要反馈机制。常用的反馈机制就是满意度调查，方式多种多样，问卷、邮件、座谈等等，健全有效的反馈机制是检查所输出的"产品或服务"质量的体温表，不可不慎查之，更不可流于形式。
既然是满意度是彼此约定的契约，或者说是彼此已经互相认可的结果，但在具体执行过程中，我们的目标当然是百分百交付，但也不得不考虑到执行的偏差，所以在拟定满意度标准的时候还要约定一个偏移范围，从站在现在看未来的视角上看，毕竟拟定满意度是一个未来还没有发生的事情，干扰因素是必须考虑进去的，如果不考虑干扰因素，就百分百完成就近乎苛刻了，但这个偏移范围必须是在"客户"可接受的范围，拿网络专线运维的考核标准之7*24小时不间断运转为例，不间断运转当然是诸人说望，但我们不能左右外网主干线的线路施工故障、机房维护、主干设备故障等突发事件，所以我们就要约定故障发生时能在3小时或者5小时内恢复，当然，这里的3或5个小时也不能我们随意写就，要看关键业务系统对网络的依赖程度，比如说如果网络中断10个小时，业务系统依旧正常运转而不受任何影响，那就可以适当的调整，但如果说ERP或OA系统故障中断的忍受极限是2个小时，超过2个小时将影响到订单的执行或审批，那我们就要必须把网络恢复的时间限定在1.5小时。话说回来，在生产环境中我们还是要做双线负载的嘛。
在影响满意度的因素中，事件冲突的问题也不得不考虑，做helpdesk的兄弟们都深有体会，同时提出服务要求有5个申请，那么如何平衡这5个申请呢？很多人都会说这是你沟通能力和时间规划的问题，首先我不否认在处理这种多申请问题时确确实实能够锻炼和考验一个人的沟通能力和时间规划能力，但这就把球踢给了helpdesk，而没有从管理的视角、从问题根源的视角去分析或者提出可以执行的解决方案，做为一个岗位角色，人会流动的，但事情不会变，那么如何保证任何人在这个岗位上都能按照既定的流程解决这类多发事件呢？我们与其拷问人的能力，不如让解决问题的方法固化，话题有点抽象，还是分享一下处理同时多方申请服务的问题吧。
首先要制定一个服务优先级，如：局域网故障问题>MIS系统故障问题>PC硬件故障问题>办公软件应用问题，当然我们也可以按照业务系统划分优先级，例如：BOSS>财务系统>生产系统>销售系统>职能系统，我的划分只是给大家提供一个参考，每个企业可以按照自己本身的业务供应链划分优先级。如果再继续细化下去，在判断PC硬件故障时还可以继续细化分级。划分优先级既为helpdesk提供了划分服务请求轻重主次的依据，也为快速处理问题提供的参考数值，既可以迅速处理多发事件，也能提高工作效率，而不至于手忙脚乱，疲于应对，结果却是丢了西瓜捡芝麻，落得抱怨声声难平人愿。
把构成满意度的几个元素用公式表达如下，我不是做科研的，
没有办法用更科学的表达公式说明这件事，只是从工作实践中提炼些经验与大家分享，姑且看之。
本文出自 "小孙村长" 博客，请务必保留此出处http://xiaosuncunzhang.blog.51cto.com/317407/1321200
没有评论:
发表评论