起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識業務還是功能？2B產品的用戶角色問題
如何構建一個能夠“容納”不同角色的用戶體系并行處理業務，實現跨流程的協作？
我們之前談到了基于用戶洞察設計產品的業務架構 ，其目的是：實現業務的解耦，以便構建一個“輕型”的2B業務系統，實現可擴容的架構，使得整個系統能夠跟上業務快速發展的步伐，而不必為了新業務的增長而重構系統。
我們也花了幾個篇幅來介紹“產品架構”的概念、思路和設計的方法，并復盤了一個 2B產品的多租戶架構設計 案例。
如果你稍微細心，就能發現其中還缺少了一個關鍵的環節。
是的，這個環節就是 “用戶對象”的問題，就是整套業務系統里面，到底應該如何構建一個能夠“容納”不同角色的用戶體系并行處理業務，如何實現跨流程的協作。
事實上，這個問題對系統的影響還包括如何構建角色和權限模型，這一點在后續將繼續展開。
作為整個系列的第12篇文章，本文仍然以“O2O平臺”作為案例展開。
01 基于工作流梳理用戶對象
2B的產品，簡單的來說，就是解決很多的用戶（發布在很多業務部門，涉及各種交叉并行的業務流程）如何高效率的協同工作的問題。不管是我們常見的OA系統，還是各種復雜的ERP、CRM系統，還是前些年火熱的O2O平臺。
對任何面向企業的產品來說，都是一頭挑起各種不同的用戶角色，另一頭挑起協作效率的重任。
對普通的使用者來說，這套系統的價值在于節省時間和工作量，通過使用這套系統來實現自身（個人或部門）“業績”和能力提升。
對企業的管理、決策者來說，這套系統的最多價值在于如何有效的提升整個企業的業務能力。
換一種說法就是：2B的產品，本身指是一個實現企業業務運作協作的工具。它的難點在于：如何更有效率的容納N中角色和N多并行業務的處理能力，并通過這一產品，實現企業業務流程的優化創新？
2B產品的設計實踐，也就是思考如何基于企業客戶的業務場景，實現個人 vs 組織的“矛盾性”需求的過程。
不管各種新奇的理論如何，我們首先做的第一件事情始終都是在圍繞用戶展開，通過實地的業務模擬，考察和分析推演，結合具體的業務流程和工作流程，拆分各個“群體”——系統的服務實體對象。
1. 業務還原
在構建整個 O2O平臺的過程，我們大致梳理的業務過程，包括用戶發起服務請求、后臺處理服務請求、前端完成服務請求三個過程。
簡單描述如如下圖所示：
業務閉環示意圖
服務請求：
用戶（不管是2B的客戶，還是2C的終端用戶）可以通過多種方式發起客服服務請求，在這個過程中，坐席端的首要任務就是如何及時響應用戶端的請求，完整的記錄用戶的問題，并快速解決用戶的問題。
從這個過程中，可以拆分的產品價值包括用戶端的體驗問題以及坐席端的效率問題。
也就是，在這個過程中，需要拆分和解決的問題包括：
- 如何建立完整的用戶請求的通道（全覆蓋的通道能夠提升用戶的整體體驗）？
- 如何解決坐席的快速解決用戶的問題（任何一個服務平臺都希望盡可能的提高一次服務過程解決用戶問題的比例，這需要一個足夠高效的知識庫）？
- 如何幫助坐席快速，完整的記錄用戶請求的內容，也涉及到當服務請求過大時如何分配合理的坐席資源？
這些問題不但涉及到產品的架構設計，也是產品的交互和視覺設計的重要參考依據，必須充分結合實際工作場景，方式和流程，來考慮在交互上的便捷性，甚至視覺上減輕使用者的疲勞感。
實際上，這也是技術選型的重要指標性因素。所以通常來說，產品的需求文檔必須要有明確的技術性指標，包括響應時間，并發數等。
ps：在前文 淺析產品的信息架構、產品架構與業務架構談到的“產品的抽象能力”，指的是這種從上往下的業務分析能力，而不是指能從下往上看各個細節。
對產品經理來說，面向任何一個業務需求，都首先要從大方面思考，再深入到細節性流程，一旦反過來，則整個產品只有功能，而沒有業務。
服務調度：
調度，指的是針對某類型用戶/客戶，發起服務請求的響應和處理。
也就是基于“效率至上”的原則，如何調配最合適的工程師解決用戶的問題是最經濟、最高效？在這個過程，涉及到很多種場景的優先考慮，比如：有些問題只是一般性的咨詢，有的問題則嚴重的質量問題，還有的問題可能已經引發了群體性和輿論性問題。
這不但需要建立一種完備的處理機制和流程，首先則是需要賦予一線“接線員”相應的權限和能力，能夠第一時間識別到風險，也能快速調動相關的資源，及時處理用戶問題。
在產品和技術上的處理細節，還需要考慮到資源的瓶頸性，系統必須要能人工干預的調度資源，還要能建立一個“眾包”的通道，打通更多的社會性資源加入“平臺”。同時，也在一定程度上激發工程師的積極性，來提高服務的處理效率。
服務履約：
這個環節，也是最終如何處理用戶服務請求的過程，也是一個對服務質量考核的關鍵節點，包括服務響應時間、服務質量、用戶評價等過程。
業務上，這個環節在某些場景還可能存在服務和產品的二次銷售行為。
綜上所述，我們就能夠把整個復雜的業務過程，抽象成三大“業務動作”，也就是支撐整個系統能夠正常運轉的基本節點。想象一下房子的支柱，即可理解這種思路設計的系統有那些優勢。
換言之，我們在第一階段設計產品的架構時，根本無需過多的考慮分支流程和細節性邏輯，只需要構建一個支撐平臺即可完整的還原整個業務流程。
也就是，我們可以想象自己在打造一個桌面，只需要考慮桌子的四個角之間的構造合理性、穩定性和承重能力，就可以保障未來的業務擴展。
在架構設計的階段，我們可以把上述的業務流程進一步抽象，整個的業務模型可以表達如下：
O2O平臺業務模型
從整個模型上，我們既能看到要服務的用戶對象，也能看到各個服務的實體，以及在整個過程中關鍵業務動作。圍繞這些動作，即可完成各種不同場景下的業務訂單。
這個平臺是一個高度解耦的系統，能夠兼容不同的業務和不同的單據格式和內容，對整個系統而言，表現層的內容對業務本身不構成影響因子，整個平臺僅依賴“業務動作”的高效運轉。
2. 實體拆分
從整個業務模型中，我們梳理出了一個業務全貌，可以清晰的識別到各個服務層所承載的服務能力，即可根據各自的能力進一步的拆分出實體的“業務范圍”。
我們也就能基于對整個業務場景的透徹理解，從實際業務的角度逐級分解整個用戶角色的邊界和在流程中的承接和交互關系。
這種從邏輯層的分解，在系統的設計中，就直接演變對應到實際中的“業務實體”，也就是不同的業務應用對象，他們直接承載著整個平臺的業務運作。
(ps：在實際的產品設計中，只需要依據業務場景的展開，即可完整的勾繪出整個平臺的業務關系。本文為方便描述，本文示例進行了大量的簡化工作。)
角色示例
從上圖可以清晰的看到不同的實體，他們的業務邊界非常的清晰。在這個邏輯下，我們可以清晰的設計各自的工作流，也就能清晰的界定不同的用戶角色權限。
以“門店”為例：TA在這個角色關系中，實際上處于一種“上下承接”的關系。
向上對接訂單的調度，負責總部的調度機制和工單協調機制；向下，對接其旗下的服務工程師，負責工程師的調度和工單的協調。
按照這種思路，我們在設計“門店”這個角色和工單的流轉業務中，就能很明確的限定它在這個平臺中的地位。換句話說，也就能界定它的權限范圍和需求范圍。也就不會再出現隨意性的變更，因為它受制于整個平臺的管理規范。
基于這種思路，我們就能夠有效的拆分復雜的應用，解耦整個系統的框架設計，也就能清晰的描述各個用戶角色在平臺上的職責、權限和價值體現。
整個平臺是基于角色的工作流作為出發點，而不是賬戶，兩者可實現柔性的關聯關系，而不是強制性的管理關系。
任何用戶，只需要符合某種角色身份就可以在平臺中自由完整的執行業務動作。這也是整個平臺賬戶體系設計的基本思路。
越是大型的系統，越是要能界定邊界，瀝青責權。
02 專注于動機設計用戶標簽
“標簽”的目的，除了簡化系統設計以后，還有一個重要屬性就是構建柔性的網絡管理規則，可以根據不同的業務需求，直接配置不同對象。
標簽系統可以根據角色的類別、屬性、業務動作等進行分解，如下圖所示：
這個圖，有出現“類別”、“屬性”、“可視范圍”、“業務動作”這些名詞。實際上這四個名詞并非通用性術語，而是在構建這個平臺以及制定整個平臺的SOP采用的一種項目化語言。
根據我的經驗，采用這一約束性的項目化語言，有助于團隊快速的理解需求，并在規范的范圍內加速產品的應用落地。
這里還引入了一個重要的屬性：可視范圍。
簡單的說，就是一個坐席、或者門店，工程師可以根據他們的實際情況，配置他們所能履約完成的業務范圍，比如：A門店具備上門服務的能力等。
對于一個產品 / 系統來說，決定業務的是每一個獨特的實體對象，也就是在整個工作流過程中的角色，只需要緊扣角色對象，就能夠清晰的界定整個平臺的邊界范圍——直接給業務實體打標簽。但我們卻容易停留在表面，而沒有能夠深入業務，更談不上對用戶動機的深刻洞察。
換句話說，我們在用戶調研過程中，過于傾向于關注用戶的行為動作，而不是動機——用戶畫像過多的停留在個人信息和人口學屬性的集合，而沒有能夠深入到實際業務中。（我們最容易犯的錯誤就是過于停留在產品的功能上，而不是業務場景中。）
比如：調研發現用戶需要頻繁的打印那些有規劃地點、線路的訂單，如果只是去設計一個高效的打印、排版的訂單處理和調研界面，顯然不是更好的解決方案。
對產品而言，不能提供關于“用戶態度和行為特性”的人物角色只是一個“雞肋”般的存在。因為無法真正理解用戶的痛點，無法真正解決用戶的“績效問題”，也就根本不能設計一款真正符合用戶預期的產品。
“當用戶使用某個產品的時候，他們是為了完成某個特定的工作(到達某種結果)”，這是一句產品名言。
在設計產品時，真正值得高度關注的是用戶的目標、產品的使用場景以及用戶與產品的關鍵交互階段，而不是把焦點集中在用戶的任務是什么以及如何完成任務。
所以，在設計用戶角色模型時，應該分成兩個步驟來完成：
- 建立對人物角色的同理心，包括用戶的履歷和年齡、收入等人口學屬性。
- 關注人物角色的動機，包括用戶的態度和行為，使用產品的目的和動機，以及在使用產品時的行為細節、偏向和心理感受。
<本文完>
#專欄作家#
杜松，公眾號：產品微言，人人都是產品經理專欄作家。專注于人工智能方向，擅長產品規劃和架構設計。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash ，基于 CC0 協議。
企業的良莠不齊，部分2b的產品更多像是在教育用戶，如何使流程更規范效率更高…