运维的兄弟不得不看的客户满意度构成元素

客户满意度是考核服务绩效的关键指标之一，这一点是毋须质疑的，但在具体考核的执行过程当中，咱们有没有质疑过“满意度”的合理性和可执行性呢？当咱们遭遇投诉或者得到低满意度评分时，有没有一块儿深刻讨论“投诉和低评分”的深层诉求呢？满意度***在工做过程的每一个细节，应用范围普遍至极，无所不含，我想用本身熟悉的IT运维为例，和你们分享一下客户满意度的组成元素。为了避免混淆概念，在分享以前，咱们先界定一下这篇小文所言客户的范围专指内部客户即企业内部员工。

百度百科对客户满意度的解释是这样的：满意是一种心理状态。是客户的需求被知足后的愉悦感，是客户对产品或服务的事前指望与实际使用产品或服务后所获得实际感觉的相对关系。从释义上咱们能够抽离出客户满意度的组成元素：心理状态、愉悦感、事前指望、实际感觉，还有客户满意度的中介载体：产品或服务。

客户满意度必定是基于彼此承认的一种契约，毫不是一厢情愿的单相思，从供方的视角咱们要在事前肯定“你（需求方）须要什么”，“作到什么程度”，“咱们怎么作”，这就是目标-标准-方法，从价值实现角度讲，咱们(供方)的满意度必定是来自客户（需方），而不是来自咱们内部，彼此之间是依靠“产品或服务”维系的，因此不论是供方仍是需方都须要反馈机制。经常使用的反馈机制就是满意度调查，方式多种多样，问卷、邮件、座谈等等，健全有效的反馈机制是检查所输出的“产品或服务”质量的体温表，不可不慎查之，更不可流于形式。

既然是满意度是彼此约定的契约，或者说是彼此已经互相承认的结果，但在具体执行过程当中，咱们的目标固然是百分百交付，但也不得不考虑到执行的误差，因此在拟定满意度标准的时候还要约定一个偏移范围，从站在如今看将来的视角上看，毕竟拟定满意度是一个将来尚未发生的事情，干扰因素是必须考虑进去的，若是不考虑干扰因素，就百分百完成就近乎苛刻了，但这个偏移范围必须是在“客户”可接受的范围，拿网络专线运维的考核标准之7*24小时不间断运转为例，不间断运转固然是诸人说望，但咱们不能左右外网主干线的线路施工故障、机房维护、主干设备故障等突发事件，因此咱们就要约定故障发生时能在3小时或者5小时内恢复，固然，这里的3或5个小时也不能咱们随意写就，要看关键业务系统对网络的依赖程度，好比说若是网络中断10个小时，业务系统依旧正常运转而不受任何影响，那就能够适当的调整，但若是说ERP或OA系统故障中断的忍受极限是2个小时，超过2个小时将影响到订单的执行或审批，那咱们就要必须把网络恢复的时间限定在1.5小时。话说回来，在生产环境中咱们仍是要作双线负载的嘛。

在影响满意度的因素中，事件冲突的问题也不得不考虑，作helpdesk的兄弟们都深有体会，同时提出服务要求有5个申请，那么如何平衡这5个申请呢？不少人都会说这是你沟通能力和时间规划的问题，首先我不否定在处理这种多申请问题时确确实实可以锻炼和考验一我的的沟通能力和时间规划能力，但这就把球踢给了helpdesk，而没有从管理的视角、从问题根源的视角去分析或者提出能够执行的解决方案，作为一个岗位角色，人会流动的，但事情不会变，那么如何保证任何人在这个岗位上都能按照既定的流程解决这类多发事件呢？咱们与其拷问人的能力，不如让解决问题的方法固化，话题有点抽象，仍是分享一下处理同时多方申请服务的问题吧。

首先要制定一个服务优先级，如：局域网故障问题>MIS系统故障问题>PC硬件故障问题>办公软件应用问题，固然咱们也能够按照业务系统划分优先级，例如：BOSS>财务系统>生产系统>销售系统>职能系统，个人划分只是给你们提供一个参考，每一个企业能够按照本身自己的业务供应链划分优先级。若是再继续细化下去，在判断PC硬件故障时还能够继续细化分级。划分优先级既为helpdesk提供了划分服务请求轻重主次的依据，也为快速处理问题提供的参考数值，既能够迅速处理多发事件，也能提升工做效率，而不至于手忙脚乱，疲于应对，结果倒是丢了西瓜捡芝麻，落得抱怨声声难平人愿。

把构成满意度的几个元素用公式表达以下，我不是作科研的，

没有办法用更科学的表达公式说明这件事，只是从工做实践中提炼些经验与你们分享，姑且看之。