編輯導讀：用戶體驗好是用戶無阻礙、高效率、超出主觀預期地完成目標。本文作者從業務場景相對復雜的滴滴切入，從用戶可感知的產品設計來簡單分析滴滴服務管控的策略，借鑒其提升用戶體驗的方法，希望對你有幫助。

在「做用戶體驗的這一年」一文中，曾提及我認為“用戶體驗好是用戶無阻礙、高效率、超出主觀預期地完成目標”。

其實，不論是普通人的直覺還是實際情況，用戶認為體驗不好的主要場景常發生在各類異常場景中。這里說的異常場景如“用戶想查詢公積金，但是無法打開頁面、可以打開頁面但是點擊查詢報錯、可以點擊查詢但是未查詢”等等情況。

也是基于這樣的前提，當我們去提升用戶體驗時，會優先從用戶投訴、用戶低評分等負向反饋切入，并優先解決此類問題；當然，采用此方案會導致對問題了解不夠全面，更加全面的體驗評估體系如NPS、CSAT、HEART等，如有機會將在以后的文章中詳細介紹。

本文試圖從業務場景相對復雜的滴滴切入，從用戶可感知的產品設計來簡單分析滴滴服務管控的策略，借鑒其提升用戶體驗的方法。

一、滴滴服務管控是什么

用戶在打車時購買的是出行服務，是非標品。以上下班通勤為例，用戶購買的打車服務雖然價格相差不大，但是車況好壞、車內環境、司機服務會存在很大差距。也因此，為了盡量保持服務水準，滴滴會對用戶關心的核心體驗問題進行管控。

這里需要強調一點的是，不同業務、不同場景的服務管控水平會存在差異。

不同的業務，如定位高端出行的“滴滴專車”，不僅限定準入車型、要求車內環境保持干凈整潔、車內配備紙巾和瓶裝水，也對司機服務進行嚴格規定，普通用戶最有體感的是專車司機六句標準話術（您好滴滴專車為您服務、請問車內的溫度合適嗎、請問是否按照導航行駛、請您系好安全帶現在開始出發、請您帶好隨身物品并從右側下車、感謝您使用滴滴專車服務）；與專車形成鮮明對比的是快車，基本可以理解為負責“安全”“準時”送達，其他服務均為做規范。

不同的場景，如預約，在預約接送機場景下，在乘客預付費的前提下，司機可無責取消的條件更為苛刻。

二、打車核心體驗和服務管控范圍

如上所述，為了保持服務水準，滴滴會對用戶關心的核心體驗問題進行管控。

以用戶最常體驗的快車為例，排除派單相關場景后，結合用戶經常投訴的場景，當前滴滴主要的服務管控場景如下

• 費用相關：主要是多收費，具體又可以分為為繞路、提前計費、延遲結束計費、（一口價下）更改目的地等場景
• 服務相關：主要是取消，具體又可分為乘客取消（接單前取消、司機接單后取消、司機到達后取消）和司機取消（司機接單后取消、司機到達上車點后取消、行程開始后取消）等場景

三、解決問題第一步是拆解問題

解決問題首先需要基于問題進行詳細拆解，明確場景和具體原因，這是第一步也是最關鍵的一步。

其實，在2中，多收費這個問題已經根據邏輯和用戶反饋進行了一次拆分，拆分完后粗略分為繞路、提前計費、延遲計費、更改目的地等子問題。

針對子問題，還需要基于case和用戶反饋，拆分出具體原因有哪些。以繞路為例

• 用戶反饋繞路，實際并未繞路，價格差異是因為路況變化新增擁堵導致的
• 用戶反饋繞路，實際路線繞路，根據司乘軌跡和其他信息可推測/判定是司機原因（如，司機在五環上錯過路口，只能在下一個路口掉頭）
• 用戶反饋繞路，實際路線繞路，根據司乘軌跡和導航路線可推測/判定是平臺原因（如，平臺導航路況更新不及時，原規劃路線司機無法行駛）
• 用戶反饋繞路，實際路線繞路，根據司乘軌跡和其他信息可推測/判定是乘客原因（如，一口價場景下乘客接送朋友）

需要強調的是，在做子問題歸因的時候，不要停留在邏輯層面進行枚舉，一定要去看具體的用戶投訴case（一天100個不再話下，至少看1000條）。

通過用戶反饋原文/錄音、規劃路線、司機實際軌跡、乘客實際軌跡、司機被投訴次數等嘗試還原當時場景。在這個過程中，總是可以發現很多意想之外的場景，這既是線下服務的服務管控的挑戰，也是它的魅力之處。

四、事前、事中、事后三管齊下保效果

滴滴的服務管控采取了事前、事中、事后三管齊下的解題思路。為了方便大家更好地理解，下文采取用戶端來進行舉例。

想特別說明的一點是在解決用戶體驗問題時，除了真正去解決問題、降低發生率外，如何管理用戶預期提升用戶感知也是重要的一部分。

1. 事前教育

如3中所述，“用戶反饋繞路，實際并未繞路，價格差異是因為路況變化新增擁堵導致的”，此種場景大多是因為用戶不了解計費規則。

當前國內快車的計價模式多為實時計價，即根據時長和里程進行計算-在用戶輸入起終點后根據當時的時長和里程進行預估。然而路況是瞬息萬變的，快車實際價格會與預估價產生差異，當價格超出一定范圍時（如，預估29元實際31元這種典型場景，用戶記憶中的是二十多變成三十多了），用戶就會感到多收費從而投訴繞路。

在解決問題的時候，除了通過預測路況等方式來提高預估價的準確率外，對用戶的教育是很重要的一部分。

如下圖，在打車確認呼叫前、等待應答時均在做用戶教育

除此之外，在新功能上線或用戶第一次使用時也要對用戶進行教育，尤其是費用相關功能，必要時可以采用彈窗等強提醒的交互方式。

如下圖，成都打車時收取超時等待費

很多產品經理會誤以為用戶對業務很了解，然而，事實是大部分用戶沒有我們想的對業務這么了解。即使用戶很了解很聰明，告知義務也是人之常情，在這一點上切忌用中國家長式思維的“你怎么連這個都不知道？”來思考問題。

2. 事中干預

與線下揚招出租車相比，網約車受益于更多的數據，可以在部分場景下根據數據直接進行干預和判責。

滴滴當前可以獲得的數據包括但不限于預估路線（時長和里程）、司機定位畫成的行車軌跡、乘客定位畫成的行車軌跡、行程結束后的提問式評價、車內的錄像錄音等。

舉一個事中干預的典型案例，司機手機沒電后導致當前乘客計費異常，在此情況下可以主動詢問司機是否需要更改價格。下文再舉兩個乘客端案例，方便大家感知。

Case 1 司機在未按照規定路線行駛（高速上錯過了路口），到達終點后支付時，系統自動改價后直接按照預估價進行支付

Case 2 杭州蕭山機場司機添加過路費，系統提示用戶確認費用是否合理

3. 事后反饋

經過這么多年這么多App的教育（尤其要感謝淘寶），普通用戶已經知道了遇到問題可以找客服。然而，不可否認的一個事實是，客服是一個成本部門，這也是為什么現在很多公司都在做智能客服、語音客服，同時還會把客服入口藏的很深以減少人工客訴。

我一直堅持的觀點是，把客服入口藏的深并不能解決客服投訴量這個問題，用戶是帶著極大的情緒才想要投訴，藏的深只會讓用戶付更多的努力找客服入口，而付出的額外努力會更加加劇用戶的情緒，最終反而要付出更多的成本來解決用戶問題。

一個正確的思路是，當用戶遇到問題時能夠讓用戶便捷的找到客服，同時可以根據場景推薦猜測用戶遇到的問題，引導用戶自助解決，最終可以實現人工客訴量的減少。

仍以滴滴為例，用戶集中投訴的場景集中在行程結束后（主要因為牽涉到費用）。滴滴的做法是，在行程結束頁面，客服卡片高優并采用大卡片進行展示，并根據用戶場景推薦常見問答（如，根據策略識別可能存在司機延遲結束計費問題，則優先展示“司機延遲結束計費”）。

實在找不到滴滴國內的截圖，只能用一下DiDiglobal的圖示意

以上。

希望對你有啟發。

本文由 @Estela 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。