運維的兄弟不得不看的客戶滿意度構成元素

客戶滿意度是考覈服務績效的關鍵指標之一，這一點是毋須質疑的，但在具體考覈的執行過程當中，咱們有沒有質疑過「滿意度」的合理性和可執行性呢？當咱們遭遇投訴或者得到低滿意度評分時，有沒有一塊兒深刻討論「投訴和低評分」的深層訴求呢？滿意度***在工做過程的每一個細節，應用範圍普遍至極，無所不含，我想用本身熟悉的IT運維爲例，和你們分享一下客戶滿意度的組成元素。爲了避免混淆概念，在分享以前，咱們先界定一下這篇小文所言客戶的範圍專指內部客戶即企業內部員工。

百度百科對客戶滿意度的解釋是這樣的：滿意是一種心理狀態。是客戶的需求被知足後的愉悅感，是客戶對產品或服務的事前指望與實際使用產品或服務後所獲得實際感覺的相對關係。從釋義上咱們能夠抽離出客戶滿意度的組成元素：心理狀態、愉悅感、事前指望、實際感覺，還有客戶滿意度的中介載體：產品或服務。

客戶滿意度必定是基於彼此承認的一種契約，毫不是一廂情願的單相思，從供方的視角咱們要在事前肯定「你（需求方）須要什麼」，「作到什麼程度」，「咱們怎麼作」，這就是目標-標準-方法，從價值實現角度講，咱們(供方)的滿意度必定是來自客戶（需方），而不是來自咱們內部，彼此之間是依靠「產品或服務」維繫的，因此不論是供方仍是需方都須要反饋機制。經常使用的反饋機制就是滿意度調查，方式多種多樣，問卷、郵件、座談等等，健全有效的反饋機制是檢查所輸出的「產品或服務」質量的體溫表，不可不慎查之，更不可流於形式。

既然是滿意度是彼此約定的契約，或者說是彼此已經互相承認的結果，但在具體執行過程當中，咱們的目標固然是百分百交付，但也不得不考慮到執行的誤差，因此在擬定滿意度標準的時候還要約定一個偏移範圍，從站在如今看將來的視角上看，畢竟擬定滿意度是一個將來尚未發生的事情，干擾因素是必須考慮進去的，若是不考慮干擾因素，就百分百完成就近乎苛刻了，但這個偏移範圍必須是在「客戶」可接受的範圍，拿網絡專線運維的考覈標準之7*24小時不間斷運轉爲例，不間斷運轉固然是諸人說望，但咱們不能左右外網主幹線的線路施工故障、機房維護、主幹設備故障等突發事件，因此咱們就要約定故障發生時能在3小時或者5小時內恢復，固然，這裏的3或5個小時也不能咱們隨意寫就，要看關鍵業務系統對網絡的依賴程度，好比說若是網絡中斷10個小時，業務系統依舊正常運轉而不受任何影響，那就能夠適當的調整，但若是說ERP或OA系統故障中斷的忍受極限是2個小時，超過2個小時將影響到訂單的執行或審批，那咱們就要必須把網絡恢復的時間限定在1.5小時。話說回來，在生產環境中咱們仍是要作雙線負載的嘛。

在影響滿意度的因素中，事件衝突的問題也不得不考慮，作helpdesk的兄弟們都深有體會，同時提出服務要求有5個申請，那麼如何平衡這5個申請呢？不少人都會說這是你溝通能力和時間規劃的問題，首先我不否定在處理這種多申請問題時確確實實可以鍛鍊和考驗一我的的溝通能力和時間規劃能力，但這就把球踢給了helpdesk，而沒有從管理的視角、從問題根源的視角去分析或者提出能夠執行的解決方案，作爲一個崗位角色，人會流動的，但事情不會變，那麼如何保證任何人在這個崗位上都能按照既定的流程解決這類多發事件呢？咱們與其拷問人的能力，不如讓解決問題的方法固化，話題有點抽象，仍是分享一下處理同時多方申請服務的問題吧。

首先要制定一個服務優先級，如：局域網故障問題>MIS系統故障問題>PC硬件故障問題>辦公軟件應用問題，固然咱們也能夠按照業務系統劃分優先級，例如：BOSS>財務系統>生產系統>銷售系統>職能系統，個人劃分只是給你們提供一個參考，每一個企業能夠按照本身自己的業務供應鏈劃分優先級。若是再繼續細化下去，在判斷PC硬件故障時還能夠繼續細化分級。劃分優先級既爲helpdesk提供了劃分服務請求輕重主次的依據，也爲快速處理問題提供的參考數值，既能夠迅速處理多發事件，也能提升工做效率，而不至於手忙腳亂，疲於應對，結果倒是丟了西瓜撿芝麻，落得抱怨聲聲難平人願。

把構成滿意度的幾個元素用公式表達以下，我不是作科研的，

沒有辦法用更科學的表達公式說明這件事，只是從工做實踐中提煉些經驗與你們分享，姑且看之。