編輯導語：什麼是異常流程？它會導緻哪些後果？産生的原因是什麼？作為産品經理，我們該如何處理異常流程呢？本文将圍繞這些問題展開，從異常流程發生以及解決方式進行分析，希望對你有所幫助。

對産品經理來說，正常流程，我們大家都很熟悉，就是我們産品設計的所有策略、流程、頁面、文案的元素組合體。

但是說到異常流程，我想可能很多人了解程度就可能沒有那麼高了。

今天，我們就圍繞互聯網産品設計中的異常流程，展開聊聊。

一、什麼是異常流程

先聲明下我對異常的定義：

異常就是用戶在使用産品的過程中，遇到阻斷流程、選擇障礙、目标不明确、操作麻煩等所有不符合用戶預期的情況。

接下裡我用一些工作中發生的真實case，來帶大家感受下什麼是異常。

案例1（信息流）：“11.11購買券活動用戶的差評”

在前段時間公司舉行的11.11活動中，業務上有一個購買券的活動，讓用戶可以以支付較少的金額購得一張面額較大的優惠券。

但是，在活動開始沒多久，就發生了一件不那麼美好的事情。購買券的用戶鬧着要退款，而平台的政策說明是不支持退款的，于是用戶在評論裡面就炸鍋了。

緊接着，平台第一時間修改政策，同意對購買券但未使用的用戶進行退款，用戶的憤怒才得以平複。

然後呢，在活動結束後的24小時，平台針對對應的用戶進行批量退款，但是中途由于操作失誤，其中一小部分用戶直到之後的第三天才收到了退款。

事情的經過大概就是這樣的。是不是感覺不複雜，并且好像整體上也沒有啥太大的“問題”。

接下來，我以用戶的視角和産品邏輯（含内部人工操作），按照時間線梳理了全程，讓大家再感受下異常：

經過這個事情，我們跟業務複盤的結果，後續需要對“購買券”當做一個整體的産品，在用戶感知層面多打磨，一些重要的規則需要更加強調。在後端，把支持退款作為一個開關，滿足業務需求，當退款時能無成本操作，并且也避免人為原因出現錯誤。

案例2（資金流）：“用戶微信問題導緻收不到錢”

公司做C2C業務起家，是典型的擔保交易形态。那麼對賣家一方，就會涉及到結算打款問題。

而平台最早時候，依托于微信登陸體系使用的是打款到賣家微信零錢的方式，賣家相對一般電商商戶的入駐，會簡單很多。

但微信支付（支付寶也存在）有個問題，就是可能會根據用戶的情況（例如賬号異常、風控、限額等）攔截掉打款。而無語的是，這個攔截的原因，有非常多，我們在接口層面并不能提前知道所有的狀态碼值（第三方的接口還動不動就更新）。

所以，我們隻能定向解析出我們已知的攔截原因，停止重試打款，轉到用戶自助流程，引導用戶更換打款方式/賬号來提現。

但是，對我們無法理解的新的狀态碼值，固定邏輯是會繼續重試的。而這時候，用戶感知就會有個時間差，就是錢款還在處理中。隻有我們定向将新的狀态碼值加到白名單才會停止重試再轉由用戶自助取回。

針對以上的規則邏輯。如果是在線的C2C還好，對于打款不及時的感知會被交易線上的引導文案所緩沖，感受并不會有那麼強烈。

但是，我們有一個業務是上門C2B回收，這個場景下跟線上不一樣，在線下，幾乎就是一手交錢一手交貨。

如果打款遇到微信攔截問題，并且剛好還是我們沒有識别過的攔截碼值，那用戶就會很崩潰，覺得我們是騙子，很可能會終止線下的回收交易。

而現場回收的工作人員也會很焦急，覺得我們産研一個簡單的打款問題都搞不定，不僅丢單還丢人。這時候，就會打電話給業務運營人員或是産研，到最後其實就隻能研發排查具體情況然後停止重試才能轉自助取回。

可能有人會問，為啥不對重試無法成功的直接都轉用戶自助取回，其實這是一個取舍的問題，因為失敗重試的情況發生的概率更大，影響面也更大，如果都擅自轉用戶取回，那整體這些用戶操作取回的總成本也會更高。

目前這類case，已經時間的累積，已經解決了絕大部分，但是仍然會有零星的情況會發生。

後續，我們能做的，就是考慮能否将解決這些零星問題的過程工具化，并且培訓給一線人員可以更加及時的解決用戶問題。

案例3（實物流）：“用戶拒簽導緻售後慢”

再說一個售後的案例。

電商流程中一般都有售後，支持退換修的服務。那麼，如果用戶遇到售後，就會存在一個逆向物流的環節，即用戶需要把貨物返回商家售後站點，然後商家進行判責然後給用戶進行售後服務履約。

正常情況下，沒什麼問題，但是如果是用戶選擇拒簽退貨時，就會有個“異常”的發生。

背後發生這個“異常”的原因是：物流拒簽會原路打回發貨地，而發貨地和售後站點如果分屬于2個物理站點和2個團隊，那就會多很多中間的轉移環節。

具體我們看下圖：

大家可以看到，“拒簽到貨”會到發貨倉，而“正常售後到貨”會到售後站點。所以，拒簽到貨進入發貨倉時候，質檢環節無法識别為自己需要作業的件兒，會當做異常進行處理。

後續，隻能等周期性的售後部門前來尋找異常件，那麼這中間就會存在信息時間差，以及物理位置轉移的時間差。

所以，給購買用戶的感受，就會覺得他的售後處理起來特别慢，覺得平台是不是沒有人在處理他的售後，對平台失去信任，也可能會發展為輿情投訴。

以上這種拒簽的問題無法避免，那麼我們能做些什麼呢？我們需要針對異常件進行定向設計，包括産品層面和線下團隊進行流程重塑，确定執行規範和時效标準。

二、異常流程有哪些後果

以上3個案例講完了，按照同理心，我嘗試推演了下用戶側和我們内部工作人員的一些感受。

顯而易見，異常流程會發生“溢出”效應，并對所有受影響的用戶，造成心理上、精力上的影響和損耗。

以下，我們按照溢出的類型，把對象分成2類：外部終端用戶（C/B用戶）、内部系統用戶（客服、售後、運營、線下作業人員等），來分别看下影響鍊。

先總結下：

拿上面案例1（11.11購買券活動）為說，我們是可以看到外部終端用戶一步步的心理變化。

而實際上，真正評論、投訴的人占比肯定還是少的，背後那些沒有發聲的用戶，其實内心活動應該也是如上圖差不多。根據最終退款的人數，可能好幾千的用戶數，他們每一個都是有自己主見的個體，也都有信任體系和自己的口碑傳播通道。

再來說說，對内部系統用戶的影響吧。

首先，明面上，業務童鞋和客服童鞋投入到這個事情中處理的時間和精力是最長線的，整體時間有至少一周左右。

其次，處理一些看不到的東西，其實花的成本一點也不低，隻是更多時候大家看不到而已。

我們事後統計了一下，隻是産研在這個事情中投入的精力至少有40個工時以上。

另外，這個過程也間接産生出了一個事故，造成了數萬經濟損失，對參與童鞋的情緒影響也是很負面的。

總之，異常産生的後果，雖然更多時候，不可直接量化，不容易被看得到，但是産生的影響确是不小的。

三、異常流程産生的原因

異常發生的背景多有以下特點：多角色共同協作、流程長、邏輯複雜。例如，上邊舉的3個案例，其實分别就是電商系統的信息流異常、資金流異常、實物流異常，這3個流向都符合以上3個特點。

異常産生的原因，從表面上來看，是系統的邏輯分支多與流程設計覆蓋度不全之間的矛盾。

但從根本上來看，我認為主要集中在以下幾個原因：

• 沒有以用戶視角來設計産品；
• 沒有基于全局視角做設計；
• 唯一責任人制缺失；

其中，1和2看起來是産品設計的問題，但是真正細究起來，發現第3點更加重要，即唯一責任人制。

因為，每個人在日常工作中都會有自己“重要”的事情，這個可能跟公司的kpi/okr有關，也就是績效導向。而這些所謂的“異常”，平時可能并不會像業務目标一樣被更多人關注到，自然也不會有人對這個角度提出更高的要求。

四、怎麼處理異常流程

1. 産品設計層面

正向的邏輯，一般是被大家熟知的，也是最容易被設計的；而看不見的邏輯，也更應該被設計。

接下來，分别從事前、事後、還有重構這3個方面聊下異常如何被設計。

（1）事前預防：降低異常出現概率

① 策略完整性：産品設計對流程盡可能窮舉；

這個其實沒有更好的辦法，跟産品經理的功力有關系，經驗豐富優秀的産品一定會比其他人做得更完善。

在關鍵産品上，公司的項目流程盡可能在需求評審環節多進行一些check和打磨，降低後續出現異常的概率。

② 降低影響面：小流量測試；

灰度小流量測試，就不說了，其實就是提前暴露風險的一種手段，既保證了影響面較小，又能在生産環境下複現異常，然後打補丁。

③ 降低影響時間：建立監控預警，提前發現風險；

産品上線後，必要的監控預警機制不能少，有時候你不能盯到所有環節的情況，但是一些關鍵環節和結果數據，是可以幫你發現一些異常的。這樣，問題就能第一時間被暴露出來，産研提前應對，降低線上異常對用戶的影響時長。

（2）事後補漏：快速解決異常并定向設計

相比事前預防，其實我更建議産品做的是事後補漏。

為什麼？因為事前預防說起來容易，其實做以上3個事情，都是需要花費額外的成本的，很多時候，大家不願意去做，或做得不那麼到位。

但事後不一樣，異常出現了，問題直接就被擺在明面上了，這時候你就會有非常明确的“需求”去解決，以及有“動力（壓力）”去解決。

補漏的過程，其實就是你積累經驗的過程，這次的疏忽，會變為下次你的事前預防産品設計。

說到這裡，我提一個現象，那就是很多産品，在對待用戶反饋問題時，總是覺得是打斷，是負擔，是用戶太笨，從而産生抵觸情緒。

但我說一個我自己的觀點：“補漏是一個很好提升産品設計能力的方法，你應該主動去挖掘一些要補漏的信息通道，然後把補漏當做你成長最好的食糧”。

用戶online反饋、客服進線咨詢問題、售後遇到的用戶問題，都是産品很好的食糧，有時候你越是關注末端的部門，那你就距離用戶越近。

在過去的一段時間内，我自己負責的業務中，也做了很多自主排查/解決問題的工具，還有一些像異常件、打款異常等項目也被列為了我們的重點項目去推動。

（3）做重構：敢于做破而再立的決策

有些系統設計由于曆史架構的原因，再加上逐步的打補丁，已經到了積重難返的地步。那如果此刻在老的基礎上疊代，用戶體驗和實現成本都已經非常糟糕，那麼就很有必要搞一次大的重構。

長痛不如短痛，破而再立才能為用戶負責。

2. 協作機制/責任人機制保障落地

異常更多時候是由用戶遇到并提交客服部門的，或者内部系統異常是由一線作業人員最先發現的。

但異常卻是由很多環節共同造就的，那這時候用戶是崩潰憤怒的，客服或一線也是焦急且無助的，那如何把用戶和客服/一線的聲音傳達到需要整改的人呢？

這時候，就一定需要機制的保障。這裡說2個機制，搭配起來用應該會很有效。

（1）信息傳輸機制：按燈機制

按燈機制，應用比較出名的應該是亞馬遜。所謂按燈，就是指一線員工在發現一個異常出現多次的時候，有權利停掉業務運營（如商品下架、商家處理等），進而倒推相關方第一時間盡快解決問題。

這個按燈機制，非常巧妙了改變了一線員工在遇到用戶問題焦急但無奈的現況，讓異常信息可以第一時間被相關方所感知到去解決，畢竟停掉業務運營上遊業務kpi都會受到影響的。

遇到異常—>用戶聲音—>一線員工信息傳輸—>上遊解決異常，整個過程非常高效，不僅當前用戶異常問題得到解決，并且一勞永逸解決了類型問題，防止損害到更多用戶的利益。

（2）責任人機制：确定主責任人并跟績效挂鈎

有時候，異常解決所需要協作的角色非常多，之間相互依賴，可能最後，有些問題就會因為各種“不可抗拒”的原因給拖延了。

追求責任的時候，就會變為了法不責衆，相互責任邊界也扯不清楚。

所以，确定主責任人或唯一責任人，就會變得很有必要。給予權責，并跟績效挂鈎，那麼這個責任人就會有“動力”持續牽引這個事情的解決。

以上内容，就是我對“異常”這個事情的觀點。

大家都能發現，“異常”相對“正常”大概率都是不好解決的，有時候甚至會伴随着非系統化流程、三方非強約束合作這些風險因素存在，異常根本上無法杜絕。

但是，面向用戶，我們沒有任何借口，唯有從用戶出發，做事情對用戶多一些同理心。隻有這樣，我們的産品能力才會提升、用戶體驗才會提升、企業口碑才會提升。

作者：減形簡遠，産品雜談（life_pm）

本文由@減形簡遠 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部