基于前文對工單的功能架構的重點功能的了解，本文將從【用戶管理】、【工單查詢】、【工單質檢】三個功能模塊進行闡述，對工單系統的功能架構做一些補充，希望對你有所幫助。

前言

工單的功能架構的重點功能前兩篇已經闡述完了，本篇我們主要在于查漏補缺，闡述清楚前兩篇沒有講到的【用戶管理】、【工單查詢】、【工單質檢】三個功能模塊，給工單系統的功能架構結個尾。

同時我們也將前文遺留下來沒有解釋的【渠道接入】、【配置組件】、【流轉流程】三個問題解釋清楚。

一、用戶管理

1. 賬號管理

工單系統的賬號體系要與設計規劃相呼應。如果只是面對后臺服務部門的賬號體系，那僅僅與服務部門的業務系統中的賬號體系做好對接，直接復用業務系統的賬號體系就夠用了。

如果在設計階段就期望能夠通過工單系統貫穿全公司業務范圍，那么工單系統的賬號體系最好和公司內部內網、移動辦公等系統的用戶中心打通，直接和公司級的賬號體對接。

這樣不僅在賬號體系上不需要重新設計，并且能夠與業務系統或用戶中心的用戶賬號同步進行增刪改的操作，后續對接各系統時也不用考慮賬號、登陸等問題。

2. 權限管理

在權限控制上和其他所有B端系統一樣，工單也需要根據權限管理的方法對用戶的權限進行控制。權限設計主要有3個原因：

（1）高效分工

權限設計并不僅僅只是為了系統的安全和保密，也在一定程度上有利于提升專業化分工。各部門的業務人員能夠專注于各自的業務范疇，從而提升工作效率。

畢竟工單系統又對接合作方、又關聯客服、還有商務、維修各個部門，針對不同的部門需求還有不同的處理邏輯，通過對創建環節的工單分類進行控制，可以大大提升業務人員對自己負責業務方面的關注度。

（2）數據安全

如果我們設計的是一個能夠打通全公司上下游協作的通用工單系統，那么系統中存儲的用戶、交易、業務問題等信息在成為公司寶貴的過程資產的同時，也會成為外部重點攻擊的對象，系統自身的數據安全性也將是非常重要的一個方面。通過權限管控也能在一定程度上減輕人員問題導致的數據泄露。

（3）權責分明

清晰的權限設計也有利于減少操作風險，保證權責分明。權利義務是相等的，權限不僅僅是代表你擁有了訪問、查看、操作某些頁面的權利，同時也代表了你將需要承擔這些頁面訪問、查看、操作的過程中的風險控制責任，在出現問題時也能更容易通過權限進行責任認定。

（4）小結一下

因此，對于權限的設計也是需要考慮的問題。在權限設計上，我們建議使用最通用的RBAC模型設計方法，權限–>角色–>用戶的方式進行訪問控制，能夠在滿足最小權限原則的同時比較好的兼容更靈活的權限配置。同時根據不同的處理組，我們也可以在處理組上對權限范圍的限定進行補充。

二、工單查詢

工單系統除了能夠提高各部門之間的協同效率之外，做到業務處理的數據留存也非常重要，這些一條條的工單數據也是組織業務發展過程中的數據資產。并且在工單日常運營和管理過程中，運營人員也需要掌握工單的處理情況，對工單數據進行查看并作出簡單分析。因此對于工單明細記錄的查詢也是輔助性的功能之一。

在工單較多的情況下，工單系統還需要考慮工單查詢的范圍和內容，一般情況下我們的設計方案是一年之內的工單查詢可以連接一年內的數據庫查詢，當查詢超過一年需要連接歷史數據庫，進行歷史所有工單數據查詢。

三、工單質檢

當工單成為重要工具之后，對于工單的質檢也會成為運營人員的一個重要工作，工單質檢主要是在業務部門，關注業務部門是否按照要求創建工單、處理工單、關閉工單。

1. 作業流程

我們建議在工單場景創建的時候，盡量和業務溝通好，從業務層面必須規定好工單的標準作業流程（SOP），這里的標準作業流程需要滿足SMART原則。

包括在什么場景下可以創建工單，什么場景下用什么方式處理工單，以及什么場景下允許以什么類型關閉工單。

這里的流程越標準、越具體，工單質檢的時候就越能減輕人工、系統在質檢場景下的處理和設計壓力。

2. 質檢方案

我們建議之間使用人機協同的機制進行，單個的人工質檢人工成本太高，單個的系統質檢錯誤率太高。

（1）人機協同

Step1：通過系統將必須檢查、并且規則清晰的質檢點進行第一輪次全量檢查，通過80分【這里質檢績效應該不加不減，也可以設計為100分】，不通過0分【這里應該需要和績效掛鉤，0分失去質檢績效】；

Step2：根據人工的工作量，隨機抽取對應的工單量，對必須由人工質檢的點，進行第二輪次隨機抽查，通過100【這里需要增加績效】，不通過根據質檢情況人工打分；

Step3：設計質檢申訴功能， 當質檢有誤時，支持由被質檢人員直接上級發起申訴，由質檢人員再次復審；

（2）質檢目標

工單質檢有利于促進各部門之間的協同體驗，同時SOP的建立也更能夠提升工單協同的規范程度，從而提升整體的協同效率。

因此在提升效率上，運營、系統需要兩手抓，才能夠達到1+1>2的效果，否則一定是1+1<2，人機協同的關系下，要么大于2要么小于2，沒有中間的狀態。

尤其是競爭壓力日漸增高的今天，1+1到底等于幾，已經成為一個公司的護城河級別的問題。因此尤其是B端產品經理一定要明白，系統設計一定需要和業務做好緊密的協同溝通，適配業務發展的階段現狀，這樣才有機會設計出來1+1>2的產品。

四、補充和總結

1. 對于【多渠道接入】的補充

工單系統的接入方式主要就是3種、全系統嵌入、H5接入、接口對接。

（1）全系統嵌入

主要是面向工單系統的重度使用業務部門；例如客服、維修、商城、倉庫等業務部門，它們從工單創建、工單處理到工單關單都有深度的使用場景，并且也貫穿自己業務的全流程，這種部門幾乎可以使用到工單系統任意一個頁面。對于這種業務部門我們提供的方式就是可以直接基于工單系統進行全系統的嵌入。

（2）H5接入

H5接入主要面向移動端的用戶；例如短信、郵件的通知接收人，可以讓用戶直接在短信、郵件中打開H5頁面直接回復；或者以H5的形式嵌入在移動辦公app中，滿足業務人員移動辦公的要求。

（3）接口對接

接口對接主要面向合作方以及一些對工單系統輕度使用的業務系統，提供接口對接的方式更加有利于保護數據安全，并且根據合作方的要求個性化的定義需要的數據字段、傳輸方式等內容，更加能夠滿足各方的要求。

2. 對于【組件化配置】的補充

工單系統是一個較為小眾的產品，在通用設計層面不會有非常多復雜的處理邏輯。工單系統中沉淀的非常多能夠和業務關聯的處理邏輯，這些邏輯是工單系統邏輯復雜的原因，因此我們希望工單系統的設計和開發需要將工作聚焦在不斷的提升工單處理效率和使用體驗。

現在去看很多企業的OA系統，仍然由開發人員進行維護，每新增一個OA流程都需要開發人員開發表單樣式、開發接口、對接聯調。

這樣的上線流程和很多大家在用的工單系統一樣，有3個非常嚴重的弊端：

1. 投入產出比差：把原本可以用來提升業務處理效率的時間和精力都消耗價值產出較低的重復性工作上，完全不符合效率提升的邏輯；
2. 業務適配性差：如果換成工單系統，在業務發展迅速，流程調整頻繁的情況下，這樣的效率根本跟不上業務的發展速度，不僅不能幫助業務提升效率，反而會成為制約業務發展的瓶頸；
3. 人員成長性差：長時間負責維護和處理這種系統，開發或者產品基本上接觸不到其他新方向的技術開發工作，也就談不上自身工作能力的提升了；

因此我們在設計上把工單分類完全做成組件化的配置項，業務運營人員可以直接組裝出來一個個的新分類，流程變更也可以業務調整后由運營或業務人員直接調整。

大大節省了開發上線的時間，也讓工單設計開發人員有足夠的時間能夠研究和開發與業務關聯性更強的擴展功能，讓系統更加適配業務。

3. 對于【雙流轉流程】的補充

在業務場景中，流程上增加一個處理人，實際工作上就會增加一個處理工序，例如：客服需要回訪用戶、維修師傅需要實際去線下維修、倉庫需要將貨物寄出。

這些處理工序短則1個工作日，長則3-5個工作日，如果一個工單將每個處理流程串聯起來，那么工單的處理時效就只能是正比增長：流程越多，時效越長。

這里我們仍然用第一篇中的投訴案例來簡單分析一下工單流程的設計：

客戶小美找315投訴你們公司的維修員大壯，在修理空調的時候把家里的空調遙控器按壞了。

315將這個投訴單轉給你們公司，你們需要復盤當時的維修工單，并且要求維修部門給出回復。

你們發現維修工單是兩個月前，記錄客戶追評認為大壯修得很好；

你們拿到了維修部門的回復，大壯解釋當時他發現了遙控器有點接觸不良，但是沒有在意；

最終經過向上級請示，你們給商城及倉庫發了工單，要求給客戶寄出一個新的遙控器。

（1）設計為單個主流程的串聯流程

工單創建–>投訴處理–>維修部門–>投訴處理–>上級審批–>投訴處理–>倉庫發貨->投訴處理–>關單；這樣從創建到關單總共9個流程節點。

在實際的業務場景中，業務人員在處理業務的過程中并不能及時的關注到每一個業務的情況，因此一般一個流程節點的處理時長大約為24小時。

我們即使按照0.5天的工作量來計算，9個節點最起碼也需要4.5個工作日。

同時由于工單再給到倉庫或者維修后，投訴人員失去了處理、關單等權利，導致及時工單再維修部門超出了回復時間，投訴人員也不能采取最終方案關單，這不僅僅影響了用戶體驗，也大大增加了工單的處理效率。

（2）設計為主流程和子流程的并聯流程

工單創建–>投訴支持–>關單；

如果投訴團隊需要維修、上級、倉庫的協助，可以以任務的形式發送給對方，在不影響投訴處理的情況下共同處理該問題。

這樣流程節點就能夠減少至3個，關單時長起碼能縮短至2個工作日；

同時投訴人員也有更多的自主性，在各方超過處理時間未回復的情況下，投訴人員就可以根據規定自己做出最終的處理決定，并關閉工單。

本例能夠明顯看到“主流程”和“子流程”這套雙流轉邏輯的設計能夠提高任務的并發量，減少串聯的等待時長，提高工單處理的自主性。

從而極大的提升多部門協同的效率，從系統設計的角度建立高效的協同機制。