為什么數字化項目的甲方總對交付質量不滿？

靈魂拷問：做數字化的甲方朋友，遇到過超出預期的乙方嗎？

至少小蔣聽到的，更多的都是對交付服務質量的吐槽和抱怨：顧問水平不行、項目計劃延期、交付物質量稀爛、屎山運維優化難度大……

這也是為什么在BEST選型法中會提到：既要選產品（T），更要選服務(S)。

當然，評價服務質量要比評價產品質量更復雜。縱使有關鍵節點的交付物，也可能有過程的服務標準，服務更多時候依然是無形的，客戶對服務的評價也更多是基于主觀的。

為什么客戶會對服務質量不滿？

80年代初，Gronroos等學者就提出了感知服務質量（Perceived Service Quality）的想法，即：

客戶眼中的服務質量 = 客戶感受到的服務 - 客戶期望的服務

當感受低于預期，就會覺得質量差、就會對服務不滿。

感知到的服務與預期中的服務，差異來自哪里？

80年代末，美國市場營銷專家Valarie Zeithaml, A. Parasuraman, and Leonard Berry提出了SERVQUAL服務質量，并對兩者的差異來源進行解釋：

我針對數字化系統實施交付服務，對這個模型略做調整：

圖中的差異5，即是前面所說的客戶感知到的服務質量。

在圖中上半部分——甲方企業側，對于數字化實施交付服務的預期來源于：

• 業務需求：企業對數字化的愿景、業務目標、對項目的規劃、對功能的設想等
• 與供應商的溝通：系統廠商、實施咨詢公司給出的方案、承諾，產品的市場宣傳等
• 市場調研：了解市場上供應商的背景、了解同業標桿、真實客戶的實施效果和服務口碑等
• 過往經驗：過往項目經驗和服務體驗（包括好的體驗和不好的體驗）

• 在需求管理方面，搞清楚自己的業務需求及緊迫性、重要性
• 在項目管理方面，要清楚項目范圍、項目計劃對于數字化成功落地的重要性
• 在產品選型中，將場景驗證做扎實，而不是未經深入交流就輕信廠商的肯定答復
• 在供應商選擇中，首先要知道完美的供應商/顧問是不存在的，好的顧問是非常稀ang缺gui的；要清楚自身當前更需要的是哪些方面的支持和建議，以及最大的阻力來源是什么？是組織變革、人力業務、功能應用、開發技術還是數據治理？或者其他。但這些問題，基本是不可能能靠單一顧問甚至單一供應商搞定。
• 在人員投入上，要對本方的人員投入提前做好溝通和準備，最好盡早配備具備數字化落地項目經驗、有乙方背景或者有與乙方合作經歷的人員。

• 沉淀經驗，深入理解客戶預期，制定完善、可執行、同時有一定靈活度的服務質量標準
• 讓聽得到炮火的人確定服務質量標準，減少信息傳達需要經過的層級，在內部梳理并分享客戶預期的數據、案例等信息
• 交付項目遵照服務質量標準來交付，保證服務水準
• 用科技創新、流程優化、交付物標準化等手段，實現服務質量標準執行的降本增效
• 招募、培養、保留具備較高能力、素質的服務交付人員
• 激勵交付團隊提供更好的服務，加強內部溝通分享
• 懲罰過度承諾，加強對市場、營銷團隊與交付團隊的溝通、加強對實際產品能力和服務體驗的了解。
• 保證及時的客戶溝通和暢通的客戶投訴渠道
• 在服務中，強調容易被客戶忽視的投入
• 通過營銷活動增加客戶可感知的價值，比如客戶社群、交流活動等等。

1. 有形設施 Tangibles，服務供應商的資質強、硬件好。對于系統實施服務，主要包括使用的軟件工具，顧問的硬件設備和精神面貌等。官網做得好、辦公室風景好當然也能加印象分。
2. 可靠性Reliability，能夠履約，靠譜、可信賴，言必行、行必果，能夠長期提供服務，不用擔心跑路、倒閉。
3. 響應性 Responsiveness，對于服務及時性和耗時，能讓客戶心理有預期；能夠按標準和溝通情況，及時響應客戶的需求。
4. 保障性Assurance，員工和顧問值得客戶信賴，展現出足夠的專業水準，包括行業知識、專業技能、溝通能力、經驗和信心，讓客戶放心托付、推心置腹。
5. 同理心Empathy，能夠從客戶的角度換位思考，理解提出需求的原因，考慮客戶的利益、主動關心客戶，并能夠根據客戶的情況提供部分個性化的服務。

• 更容易理解當初的設計、回想到當時設計背后的業務需求和業務背景
• 知道哪些設置的調整要慎重，會有什么風險、有哪些要注意的步驟和要點
• 形成規范、嚴謹的需求管理、測試管理、問題管理、變更管理、知識管理、數據管理方法和習慣
• 培養內部人員的系統專業知識和能力
• 留下系統培訓推廣的基礎材料
• 提升對企業內對于數字化價值、規劃思路和落地方法的認識