客戶滿意度是考覈服務績效的關鍵指標之一，這一點是毋須質疑的，但在具體考覈的執行過程中，我們有沒有質疑過“滿意度”的合理性和可執行性呢？當我們遭遇投訴或者獲得低滿意度評分時，有沒有一起深入討論“投訴和低評分”的深層訴求呢？滿意度***在工作過程的每個細節，應用範圍廣泛至極，無所不含，我想用自己熟悉的IT運維爲例，和大家分享一下客戶滿意度的組成元素。爲了不混淆概念，在分享之前，我們先界定一下這篇小文所言客戶的範圍專指內部客戶即企業內部員工。
百度百科對客戶滿意度的解釋是這樣的：滿意是一種心理狀態。是客戶的需求被滿足後的愉悅感，是客戶對產品或服務的事前期望與實際使用產品或服務後所得到實際感受的相對關係。從釋義上我們可以抽離出客戶滿意度的組成元素：心理狀態、愉悅感、事前期望、實際感受，還有客戶滿意度的中介載體：產品或服務。
客戶滿意度一定是基於彼此認可的一種契約，絕不是一廂情願的單相思，從供方的視角我們要在事前確定“你（需求方）需要什麼”，“做到什麼程度”，“我們怎麼做”，這就是目標-標準-方法，從價值實現角度講，我們(供方)的滿意度一定是來自客戶（需方），而不是來自我們內部，彼此之間是依靠“產品或服務”維繫的，所以不管是供方還是需方都需要反饋機制。常用的反饋機制就是滿意度調查，方式多種多樣，問卷、郵件、座談等等，健全有效的反饋機制是檢查所輸出的“產品或服務”質量的體溫表，不可不慎查之，更不可流於形式。
既然是滿意度是彼此約定的契約，或者說是彼此已經互相認可的結果，但在具體執行過程中，我們的目標當然是百分百交付，但也不得不考慮到執行的偏差，所以在擬定滿意度標準的時候還要約定一個偏移範圍，從站在現在看未來的視角上看，畢竟擬定滿意度是一個未來還沒有發生的事情，干擾因素是必須考慮進去的，如果不考慮干擾因素，就百分百完成就近乎苛刻了，但這個偏移範圍必須是在“客戶”可接受的範圍，拿網絡專線運維的考覈標準之7*24小時不間斷運轉爲例，不間斷運轉當然是諸人說望，但我們不能左右外網主幹線的線路施工故障、機房維護、主幹設備故障等突發事件，所以我們就要約定故障發生時能在3小時或者5小時內恢復，當然，這裏的3或5個小時也不能我們隨意寫就，要看關鍵業務系統對網絡的依賴程度，比如說如果網絡中斷10個小時，業務系統依舊正常運轉而不受任何影響，那就可以適當的調整，但如果說ERP或OA系統故障中斷的忍受極限是2個小時，超過2個小時將影響到訂單的執行或審批，那我們就要必須把網絡恢復的時間限定在1.5小時。話說回來，在生產環境中我們還是要做雙線負載的嘛。
在影響滿意度的因素中，事件衝突的問題也不得不考慮，做helpdesk的兄弟們都深有體會，同時提出服務要求有5個申請，那麼如何平衡這5個申請呢？很多人都會說這是你溝通能力和時間規劃的問題，首先我不否認在處理這種多申請問題時確確實實能夠鍛鍊和考驗一個人的溝通能力和時間規劃能力，但這就把球踢給了helpdesk，而沒有從管理的視角、從問題根源的視角去分析或者提出可以執行的解決方案，做爲一個崗位角色，人會流動的，但事情不會變，那麼如何保證任何人在這個崗位上都能按照既定的流程解決這類多發事件呢？我們與其拷問人的能力，不如讓解決問題的方法固化，話題有點抽象，還是分享一下處理同時多方申請服務的問題吧。
首先要制定一個服務優先級，如：局域網故障問題>MIS系統故障問題>PC硬件故障問題>辦公軟件應用問題，當然我們也可以按照業務系統劃分優先級，例如：BOSS>財務系統>生產系統>銷售系統>職能系統，我的劃分只是給大家提供一個參考，每個企業可以按照自己本身的業務供應鏈劃分優先級。如果再繼續細化下去，在判斷PC硬件故障時還可以繼續細化分級。劃分優先級既爲helpdesk提供了劃分服務請求輕重主次的依據，也爲快速處理問題提供的參考數值，既可以迅速處理多發事件，也能提高工作效率，而不至於手忙腳亂，疲於應對，結果卻是丟了西瓜撿芝麻，落得抱怨聲聲難平人願。
把構成滿意度的幾個元素用公式表達如下，我不是做科研的，
沒有辦法用更科學的表達公式說明這件事，只是從工作實踐中提煉些經驗與大家分享，姑且看之。