家政O2O工單系統設計全流程復盤:從調研到功能設計
編輯導讀:工單系統,是用于客服-客服、客服-業務、業務-客服之間溝通工具系統,它的主體使用人員是客服工作者,同時也會包含其他需要聯系的業務人員,是個比較典型的To B產品。本文作者對工單系統從調研到功能設計的全過程進行了詳細的梳理分析,希望通過此文能夠加深你對B端產品的認識。
前些時間參與了一個面向家政公司的工單系統,現在系統研發接近尾聲,自己收獲很多。希望通過復盤的形式鞏固自己學到的知識,同時也能幫到在B端產品路上前進的小伙伴。
本文詳細記錄了工單系統從調研到功能設計的全過程,適合初級產品經理閱讀,有助于形成系統設計的基本方法論。由于隱私限制,部分關于公司內容已刪除,同時受篇幅限制,文章復盤內容只展開關鍵部分,小伙伴只要懂得大概方法論即可,無需過多關注細節。話不多說,開始閱讀吧。
一、確定調研目標
- 確定工單系統的定位,戰略目標,未來的發展規劃;
- 調研公司當前的組織架構,經營策略,管理模式;
- 調研當前的業務人員的工作流程,工作內容及工作細節;
- 梳理當前業務現狀和痛點,確定優先級;
二、梳理調研結論
通過訪問公司CEO和公司總經理,確定以下內容:
- 確定工單系統的定位是希望可以取代現有的手動派單的工作方式;
- 戰略目標是通過工單系統實現業務線上化,信息化,進而提高公司業務效率;
- 未來的發展規劃是把工單系統拓展為商城后臺,客戶可以在小程序上下單,后期拓展為公司內網系統,同時支持以家政為核心業務,以生鮮電商,房屋中介,相親交友,商家聯盟為輔助業務的公司戰略,推動公司信息化;
- 確定公司的組織架構圖,在管理模式上,公司采用統一管理模式,員工統一向對應負責人報告,負責人向總經理報告,總經理向CEO報告;
- 為了和市場上同類產品差異化,公司的家政產品大多采用年套餐形式,比如19999元保潔50次,6999煮飯20次,主要的目標客戶是有住家保姆的家庭。
- 近期內不考慮以低利潤率獲取市場的進擊的營銷行為,需要保持10%-20%的利潤率。營銷注重口碑,希望通過老客戶去獲取新客戶。在保住現有市場份額的情況下,在其他區域獲取更多客戶,達到擴大市場份額的目的。
組織結構圖
三、繪制系統運轉流程圖
通過親身體驗相關崗位以及訪問負責人,一線從業人員,繪制出了公司運轉流程流程圖,具體如下:
系統流轉圖
四、梳理關鍵業務問題
經過調研分析,總結了目前遇到的問題,具體如下:
- 客戶購買服務只能通過線下付款,下單效率低,同時也不方便傳播;
- 客戶可以通過多個渠道購買形成訂單,但是沒有統一的訂單中心,訂單整理容易出錯;
- 手動派單,不但容易出錯,而且會出現員工工單超出或者員工沒有工單的情況;
- 手動統計剩余工單數量,非常耗費精力;
- 上門服務員工只能通過企業微信等聊天工具通知,效率低;
- 服務種類多,價格也不同,工資結算非常復雜;
- 對員工的管控能力弱,容易出現員工虛假作業問題;
五、解決思路
- 實現訂單中心,訂單中心記錄著所有訂單,管理人員可以導入訂單(高優);
- 實現工單中心,通過訂單生成工單,同時完成派單(高優);
- 實現風控中心,保證員工不會約超(高優);
- 實現對賬報表,確保訂單,工單間的數據的準確性(中優);
- 實現員工端小程序,確保服務內容通知到位,杜絕虛假作業(高優);
- 實現客戶端小程序,確保客戶可以通過小程序快速下單(中優);
六、核心業務流程
設計業務系統,應該要從核心業務流程開始。以核心業務流程為中心,向外拓展其他業務流程,從而形成緊密配合又相互獨立的業務結構,這樣設計的系統不但滿足不斷增加的功能,同時也能支撐不斷增長的業務量。下面先來梳理業務系統的主要流程。
很明顯的,這套業務的系統的主要流程是派單流程,也就是由訂單中心-工單中心-派單形成業務流程,流程圖如下:
主要流程圖
產品定位
經過對公司高層訪談,我們知道公司目前要解決的問題是線上化派單,所以面向客戶的小程序暫時不做,但是需要預留好相應的功能接口?;谂蓡尉€上化,判斷公司需要一個控制臺。由于控制臺涉及對產品,訂單,工單,員工的增加,刪除,修改等復雜操作,所以只在PC端實現。同時上門服務員工需要收到工單消息,以及服務打卡等行為,所以還需要實現員工端。基于成本和便利性考慮,目前只做微信端的小程序。
基于以上分析,我們將工單系統拆分為三個獨立部分,分別如下:
- 商城前臺:通過小程序實現,面向客戶,主要功能是客戶下單,客戶預約工單;
- 運營管理后臺:pc端實現,統一管理整個系統所需要的訂單,工單,員工,產品等所有信息;
- 員工端前臺:小程序實現,面向上門服務員工使用,主要是通知員工工單信息和員工服務打卡等功能;
七、應用架構設計
該公司首次實現線上化,沒有任何代碼基礎,所以我們需要在設計每個模塊的時候,要以服務化為目的,以便后續與其他功能模塊相互合作,實現更復雜的功能。在后續會一一介紹每一個功能的設計要點。
系統架構圖
八、功能模塊設計
從調研中可以了解到,客戶端小程序的主要功能有客戶購買商品和預約上門服務。從用戶使用流程來說,購買商品包括商品分類,商品展示,商品詳情頁,生成訂單,付款等功能模塊;預約上門服務包括創建工單,選擇地址,展示可預約時間,查看工單詳情,查看服務人員詳情;
員工端小程序的主要功能是幫助員工更好地完成工單,功能模塊包括接單,查看工單詳情,導航,上門服務,打卡;
系統管理后臺的功能模塊可以分為管理模塊,查詢模塊,財務模塊,其中管理模塊細分為產品管理,訂單管理,工單管理,員工管理;查詢模塊細分為員工查詢,訂單查詢,工單查詢;財務模塊細分為結算模塊,對賬模塊,發票模塊;
演進藍圖設計
在功能模塊中,我們盡可能將所有能想到的功能模塊一一列出,這是一個做加法的過程,我們不可能一次性實現全部功能,這個時候需要根據業務優先級,將功能模塊拆分多期來完成,這是做減法的過程。確認產品功能規劃和實現節奏,這就是常說的演進藍圖。
如何確定優先級呢?大家可以根據以下原則去確定
- 優先解決頻次高,工作量大,機械程度高的業務;
- 其次是支持第一點業務的功能;
- 最后才是風控,運營等相關功能;
以下是具體的演進過程設計
一期(實現訂單-工單-派單主流程):
- 在對外系統中完成員工端小程序,系統管理后臺;
- 管理中后臺完成產品中心,訂單中心,工單中心,員工中心;
- 業務單元支持系統中完成風控驗證;
- 基礎架構支持系統中完成Passport(基于RBAC角色控制理論進行設計),Auth(微信小程序),Gis(騰訊地圖接口),Msg(派單信息傳遞);
- 數據底層和應用中完成MDM(客戶主數據系統);
二期(實現客戶端小程序并完善系統管理后臺功能):
- 對外系統中完成客戶端小程序;
- 管理中后臺中完成客戶中心;
- 業務單元支持系統中增加CallCenter,風控驗證中增加客戶端創建工單限制;
- 職能單元支持系統中增加Finance;
- 基礎架構支持系統中增加Pay(微信支付);
- 數據底層和應用不增加內容;
三期(增強系統能力,并為后續功能研發做好預留功能):
- 業務單元支持系統中增加CRM初步能力(可以適當采購),增加CallCenter,風控驗證增加訂單-工單不符校驗,員工調派校驗等;
- 數據底層和應用實現Data WareHouse,Data Mart,BI,Data Mining等底層模塊,為數據分析做好準備,同時為集團的業務拓展留下預留功能;
九、業務數據建模
經過業務調研,發現目前業務方有如下訴求:
- 要有產品中心,產品主要可以分為三種類型,一種是按上下午,晚上計時的服務商品,一種是按小時計時收費的服務商品,最后一種是以上兩種混合計時的服務商品;
- 要有訂單中心,訂單中心有客戶端小程序中的訂單,線下訂單,第三方平臺的訂單;
- 要有工單中心,管理員根據客戶的需求可以在后臺生成工單,客戶在小程序客戶端生成;
- 要有派單系統,工單要和對應的員工匹配,提高效率。匹配方式要自由多樣,方便安排派單。員工一天只能工作八小時,不能超單。為了能快速查詢到哪些員工可以派單,需要查詢員工派單記錄;
- 上門服務員工可以在員工端小程序接單,上門服務后可以完成打卡,拍照;
- 員工服務完成后,根據工單的具體情況結算工資;
E-R圖如下:
十、具體功能實現
1. 客戶端小程序
流程圖設計如下:
頁面流轉圖設計如下:
頁面設計如下:
2. 員工端設計
流程圖:
頁面流轉圖:
頁面設計
3. 后臺員工權限設計
經過調研,明確業務方有以下訴求:
- 管理人員可以控制員工可訪問的頁面及使用的按鈕權限;
- 管理人員可以控制員工的數據訪問范圍,包括哪些數據可以訪問,哪些數據可以可以編輯;
- 管理人員可以控制員工可以訪問哪些功能模塊;
- 管理人員可以控制員工可以控制哪些角色和職能;
設計思路:
- 管理人員可以管理員工訪問數據的范圍;
- 按鈕,頁面全部接口化;
- 根據RBAC原則設計角色;
- 數據對象可編輯,可設置;
- 管理人員可配置員工訪問的角色的范圍;
具體設計頁面如下:
4. 產品中心
經過調研,明確業務方有以下訴求:
- 依據服務時間的統計規則不同,產品可以分為保潔類產品和工程類產品。其中保潔類產品的服務時間為上午,下午和晚上三個時間塊,而工程類產品的服務時間是按小時進行統計。
- 不同產品對應著不同的工單,需要不同技能的員工服務;
- 產品根據地區進行劃分,由于服務員工不同,不同地區的產品可能不同;
設計思路:
- 在新建產品時,增加產品分類字段,用來區分產品是保潔產品還是工程產品;
- 在產品中增加表示服務時長,技能及對應員工數的字段,生成工單后自動抓取該信息形成派單信息;
- 新建產品時增加地區字段,保證產品按地區劃分;
頁面設計:
5. 訂單中心
經過調研,明確業務方有以下訴求:
- 訂單中心中包含三種類型訂單,分別是小程序訂單,線下訂單,第三方平臺訂單。
- 查看訂單的剩余服務情況,清晰客戶的到期情況,方便平臺客服提示客戶復購。
設計思路:
- 設計導入訂單功能模塊,可以導入線下訂單,第三方平臺訂單,后續可以嘗試接入第三方數據平臺,實現訂單自動導入;
- 設計客戶中心,通過客戶中心可以快速找到客戶對應的訂單,服務,工單和其他數據。
- 設計客戶到期管理中心,通過客戶到期管理中心,客服可以快速找到服務即將到期的客戶,后期可以拓展為線索池模塊。
頁面設計:
訂單中心
客戶到期查詢
6. 工單中心
經過調研,明確業務方有以下訴求:
- 創建工單時不能超單;
- 派單要靈活。比如:一個4小時的上門服務訂單,可以安排1個人服務4小時,2個人服務2小時,4個人服務1小時;
- 導入歷史工單后可以得到準確的客戶的可用服務情況。
- 在派單過程中,可以直接看到符合工單要求的員工,快捷派單。
設計思路:
- 設計創建工單驗證中心。后臺創建工單限制低:員工對應的剩余服務時間總和大于等于產品的服務時長,則可以創建成功。小程序創建工單限制高:員工需要滿足產品設定好的員工,技能,服務時間要求才能創建工單成功。
- 在編輯工單模塊中增加編輯工單類型,員工服務時長,技能和人數選項。
- 增加歷史工單導入功能;
- 增加工單與員工間的匹配功能;
頁面設計如下:
以上是對自己對這段時間完成的工單系統的復盤。
參考資料:
《決勝B端》楊堃
作者:寶寶心里苦啊;公眾號:寶寶心里苦啊
本文由 @寶寶心里苦啊 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
好奇想問問,能做出這一套,月薪能干到多少
感覺作者有一定的技術功底,整體思路還是挺清晰的,不過在工單執行的流程不是閉環,設計里少了客戶互動的環節,比如工單員工完成后,提供客戶確認完結的操作,使客戶能夠參與完工驗收,并且采集到相關數據用于后續迭代,不知是否有評價、分享、曬單之類的規劃,有興趣的話可以私聊細節
這個還是很簡單的工單系統的,后續評價是沒有的,分享有,在做
怎么聯系啊
加微信聊唄,Jcyy_1080p
非常完整的產品工作流程,和設計思路。適合初級產品經理學習,整理思考鏈路
大家能看清圖片么
看不清呀,怎么辦?
很多同學都有問到這個,可以在我的公眾號后臺發送:工單系統復盤 可以得到AXURE文檔鏈接
能看清的