2021-5-8 濤濤
在新業務啟航準備出海乘風破浪時，業務方和產研同學就開始思考一個問題：產品體驗做得足夠好嗎？
為了回答這個問題，用研同學在研發階段就開始進行 demo 測試，試點運營時期進行反饋追蹤，上線初期進行可用性測試……可以說，不是在驗證體驗，就是在準備驗證的路上。但這些回答都是片段性的，只能發現散落的關鍵點。
等到業務成熟運轉且穩定后，各方負責人可能會發出靈魂一問：如何全面評價業務體驗？此時，用研工程師意識到：建立長效全面的體驗監測系統非常重要和必要。
麥肯錫給出的定義是：一個持續運轉的觀察系統。①能發現足夠詳細的旅程、觸點、渠道方面的客戶體驗信息 ②能長期追蹤客戶體驗變化和衡量改善措施的效果 ③能夠為企業帶來統一的審視客戶體驗的視角 ④能提供完整準確的體驗數據，讓組織基于數據而非主觀直覺做出決策。通過這份定義，可以得出體驗監測系統的幾個特征：
1. 認可度高的體驗監測模型
定義和特征有了，那么成型的體驗監測系統是什么樣的？我們整理了目前認可度較高的體驗模型：
谷歌 HEART 模型（C 端體驗模型）。該模型由 5 個指標構成，分別是：
阿里 PTECH 模型（B 端模型），由 5 個指標構成：
LIFT 模型（C 端模型），由 widerfunnel 公司開發，旨在提升轉化率，主要有六大法則：
2. 模型應用問題
這些模型有衡量 C 端體驗的，有針對 B 端產品的，在度量線上系統的用戶體驗方面表現優異，但存在 3 個問題導致他們并不適合貝殼這種極端復雜、線上線下交融的業務場景：
因此，我們在貝殼探索了一條差異化的建立 B 端體驗監測體系之路。
監測系統的三大核心——測量指標、測量范圍、測量用戶，在搭建前需要按順序逐一確定。
1. 確定測量指標
測量指標，指用于評價系統好壞的量化數據。在 B 端，可分為五類指標：
由于不同 B 端系統的功能、應用場景、用戶等差異很大，因此可根據實際情況組合上述指標，形成更貼合業務的測量體系。
2. 確定測量范圍
B 端業務一般有較長的使用鏈路和較復雜的功能，在搭建系統前，需要確定：
測量范圍越大，越能發現“隱匿的冰山”，觸達業務核心問題。但隨之帶來的問題是：①測量成本增大 ②發現的問題類別復雜，權責難以落實到部門，落地困難。
3. 確定測量用戶
B 端業務的用戶角色一般多于 C 端，以新房系統為例，按使用頻率可分為主使用者、次使用者等，按參與角色又可分為信息錄入角色、審核角色、維護角色等。在確定測量指標和測量范圍后，根據不同用戶角色對業務的貢獻度、參與度，考慮將哪些角色納入監測系統。
指標、范圍、用戶都確定后，B 端監測體系也就自然的建立起來。
接下來，我們簡單介紹下貝殼的 B 端體驗監測系統的構建思路。
在貝殼，B 端體驗監測系統經歷了三個重要階段：
第一階段
從功能點出發建立產品滿意度系統，如下圖所示（部分業務流程由于保密原因，做了修改或隱匿）。
△ 圖 1 早期二手滿意度架構（僅包含部分內容）
特點是：①架構清晰，基本按照功能架構 ②次序明確，一級影響因素（大產品功能）與二級影響因素（大功能下的小功能、細節設計等）層層遞進。
之所以采用這樣的架構和內容，是因為：①早期建立監測體系時，產品同學往往參與意愿更強烈，提供的資料和需求更多 ②只有產品問題能確定落地，其他問題總會被推諉 ③產品槽點多，只專注這個區域就挖不完寶。
這樣的體系好處是：①問題明確，低滿意度產品模塊可快速找到對接人，容易落地 ②結構簡單，背景知識少，設計滿意度系統認知和時間成本低，可以先跑起來 ③合作部門少，只需要和重點模塊產品打交道，項目推動更省力 ④可計算出每個模塊對整體產品滿意度的貢獻值，幫助產品同學發現優先改進點。
劣勢是：①只能發現單個模塊的問題，陷入谷倉效應 ②以產品功能為骨架，可能漏掉其他用戶關注的業務、運營問題 ③產品框架不符合用戶關注習慣，部分打分可能與實際情況有出入 ④題量較大，完成難度大。
第二階段
考慮到產品滿意度系統的問題，我們在此基礎上進行了監測系統的優化：從服務設計理論出發，建立場景式滿意度系統，如下圖所示（部分業務流程由于保密原因，做了修改或隱匿）。
△ 圖 2 早期新房滿意度架構（僅包含部分內容）
這樣的監測系統特點是：
這樣的體系好處是：①可以發現整個業務流程的單點問題與銜接問題 ②從用戶角度出發設計問題，用戶回答順暢準確 ③指標更符合業務需求 ④能發現不同角色的分工問題，是否存在某個角色工作負荷過高。
劣勢是：①結構復雜，需要對業務非常熟悉，前期準備工作非常耗費人力與時間成本 ②發現的問題難以歸類，解法需多方協同（如運管人員審核壓力過大，需要同時優化產品邏輯和增加數據對接準確性）③合作部門多，項目推動難度大 ④調研對象多、覆蓋范圍廣，后期數據分析、結論產出耗費精力多。
第三階段
由于二代系統耗費精力過多，貝殼 er 們在此基礎上又進行了改良，建立自動化觸點式體驗監測系統，以數據看板+人工分析形式運轉。
這樣的監測系統特點是：
貝殼 B 端體驗監測系統的這三個階段，代表了三種思想的轉變：從先跑起來，到精細測量，再到自動化分發，越來越全面，越來越省力。
1. 新房 B 端滿意度系統
新房是一個多角色參與的復雜系統，參與的角色包括：購房客戶、新房經紀人、客發經理（負責宣傳樓盤、與開發商談判拿盤、系統內錄入樓盤資料等）、駐場（在樓盤現場處理經紀人帶看事宜、錄入各項數據、同步銷控信息等）、運管（負責審核成交數據、解決流程問題等）、財務（負責回款跟蹤等）、法務（負責確認合同條款、合作歸檔等）……
整體流程也非常復雜，從接待客戶到完成回款，一共有 20 多個環節，每個環節都要耗費 1~3 個角色的大量精力。如何測量這個系統的用戶體驗，就是個非常頭痛的問題。
面對這個硬核滿意度任務，我們給出的解決方案是：
最終產出了一個包含 4 種最重要角色（經紀人、案場等）、22 個流程節點、3 類指標（滿意度、NPS、費力度）的新房體驗監測系統，如下圖所示（部分業務流程與業務數據由于保密原因，作了修改或隱匿）。
△ 圖 3 新房體驗監測系統示意
其中 NPS 與全體滿意度作為整體指標，描述新房系統各角色的總體感知和體驗情況；費力度與流程滿意度作為單節點指標，描述不同節點的業務感知和體驗情況。未來，在業務持續發展過程中、業務方遇到整合問題以及項目有了全局落地的能力后，我們也會增加針對整體業務和針對單個節點的業務指標（如回款安全性、流程可跟蹤性），將體驗監測與商業價值掛鉤，進一步提升 B 端體驗的勢能。
通過貝殼的例子，可以發現 B 端體驗監測系統往往比 C 端更復雜，對創建者的業務理解程度有更苛刻的要求。無論搭建還是落地，都需要較高人力和時間成本，因此建議大家在設計 B 端體驗監測系統前做到：
B 端監測體驗系統的建立與運行，是復雜的長期性工作，也是對用研團隊專業性和業務理解程度的挑戰，愿大家勉力前行。
文章來源：優設 作者：貝殼KEDC
藍藍設計( www.skdbbs.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務