環球快看：工單系統——深度解析高效的功能架構（上）

工單系統的架構核心圍繞著高效協同、靈活適配兩個核心理念展開，本文就工單分類模塊、工單流轉模塊、工單分派模塊三個核心模塊展開分析，并對工單系統功能架構進行一些補充和總結。

前言

工單系統系列共分為四個篇章，本文是工單系統的第三篇-功能架構，開始對工單系統本身的功能結構進行解析。由于整體文章較長，計劃分為上中下三篇來闡述，上篇主要闡述工單系統3個最核心的模塊，中篇主要闡述工單系統的五個支撐性的模塊，下篇主要闡述工單系統3個較為外圍的模塊以及對工單系統功能架構的補充和總結。

【資料圖】

一、理念和綜述 1. 核心理念

工單的系統架構核心圍繞前文我們講的兩個核心理念：高效協同、靈活適配展開。

承載核心理念的3個核心模塊分別為：工單分類模塊、工單流轉模塊、工單分派模塊。

下面將從上述理念出發，詳細闡述工單系統3個核心模塊如何設計能夠保證工單系統的高效協同以及靈活適配。

二、3個核心模塊 1. 工單分類

工單分類是工單系統核心模塊中的基礎模塊。它提高不了一個工單系統的上限，但它直接決定工單系統的下限。包括3個重要的配置功能：

（1）工單分類的配置

給不同的業務場景定義不同的工單分類，比如售后處理單、客服咨詢單、投訴處理單。當然在實際的案例中，大部分工單體系的分類多為三級分類，例如【售前咨詢-大家電-參數配置】、【售后處理-退貨-圖文描述不符】、【外部投訴-行業協會投訴-退款問題】等等。

（2）工單信息的配置

除了通用的用戶信息以及業務信息外，不同的業務場景可能需要按照場景定制化一些對場景有用的信息。這時候就需要根據業務要求在分類中進行配置。

例如售前咨詢可能需要用戶咨詢時使用的渠道、用戶產生疑問的售貨渠道等信息；售后處理時可能需要外包裝是否完好、是否7天無理由、是否滿足自主退貨要求等信息；投訴處理時可能需要用戶投訴渠道、用戶投訴時間、歷史是否有投訴記錄等信息。這些按場景需要的個性化信息就需要配置到工單分類中。

（3）工單流轉的配置

不同的工單分類后續的處理邏輯也不一樣，比如售前咨詢的工單，基本上客服回答完工單就結束了。比如售后處理的工單，可能客服是需要與銷售團隊溝通，是否存在這個問題，以及是否允許退貨，并且需要同步倉庫進行售后收貨防止因為外包裝不完好拒收。

這些流轉邏輯是工單系統的協同引擎-非常重要，因此對于流轉邏輯的設計是一個單獨的核心模塊。而分類這里的配置，是將已經設計好的流轉邏輯，配置到分類上，以便分類知道自己應該如何流轉。

（4）小結一下

專業化的分工是提高生產效率最基礎也是最有效的手段，而工單分類則是工單系統的核心模塊之一，也是其最重要的基礎建設。涵蓋更多的業務場景對于工單系統來說非常重要，但是不同業務場景會帶來不同的需求，包括合作的團隊、所需的信息以及處理邏輯等。因此，按照不同的業務場景進行細分，提供各自場景需要的信息、處理團隊以及處理邏輯，不僅可以提高工單處理效率，也能保證工單處理的質量。

2. 工單流轉

工單流轉引擎，是工單系統的核心模塊中真正核心的模塊，它真正能直接決定一個工單系統是否高效。流轉引擎主要包括3個重點功能：

（1）工單處理組配置

在工單系統中，我們一般定義處理組是流程的最小節點，每一個處理組就是一個處理團隊，不同的處理團隊串聯或者并聯起來，就形成了一個工單分類的流轉邏輯。

例如客服團隊是一個處理組、維修團隊定義為一個處理組、銷售團隊定義為一個處理組、投訴團隊也是一個處理組。這樣一個“用戶咨詢客服–>客服反饋維修–>維修人員處理”的維修單流程表現形式，可能就是：【客服團隊處理組】–>【維修團隊處理組】–>【結束】。

（2）工單主流程配置

現代工單系統一般都區分兩個流程：主流程和子流程。主流程是真正流程式的節點配置，里面的每一個節點都不能缺少；在工單處理過程中必須要經過主流程中的處理組，表現形式為串聯式。同一時間工單只能被其中一個節點的處理人進行處理，他可以關閉工單、可以向后流轉。主流層的表現形式為：必須從A到B，經過B之后再到C，每一個節點的處理人都需要進行流程節點的確認。

例如：【客服團隊處理組】–>【維修團隊處理組】–>【結束】就是一個主流程。這里的客服接到用戶反饋，經過判斷需要提供維修服務后，必然要流轉維修工單到維修團隊，維修團隊接到工單后也必然需要提供維修服務，服務完成后必須記錄關單。

（3）工單子流程配置

子流程的出現是工單系統升級的一大亮點，大大提高了工單系統的處理效率，其表現形式為并聯，你可以理解為主流程處理人可以同時向外發送的N條任務。子流程通過并聯的方式將工單中一些可以并行處理的任務進行整合發送，主流程處理節點中的處理人可以選擇是否需要等待并聯任務的回復。這樣大大提高了主流程節點處理人對工單的控制力，也提高了工單處理的效率。

例如一個投訴工單的主流程可能為：【客服團隊處理組】–>【投訴團隊處理組】–>【結束】，而子流程中有豐富的第三方可供選擇，例如【銷售團隊】、【維修團隊】、【電商團隊】等等處理組，讓投訴團隊可以根據不同的投訴內容，產生投訴的各個部門核實情況，也不會因為各個部門的核實進度影響自己的處理進度。

（4）小結一下

工單核心中的核心就是流轉邏輯，流轉邏輯直接決定了流轉速度，流轉速度直接決定了工單的處理時間，提高工單效率最直接的手段就是調整流轉邏輯（主流程中每多一個流程節點所耗費的時間都是24小時以上）。

因此通過工單流轉模塊的設計思路，也能夠直接看出一個工單系統產品經理的抽象和邏輯推理能力，它幾乎完全決定了一個工單系統是不是足夠高效。

在這里，我們為了降低工單流程邏輯的復雜度，工單流程的最小單位被整合抽象為處理組，而通過設計主流程和子流程，直接解決了傳統工單串聯流轉的效率及協同問題，使工單流程更加簡約，處理方式更加靈活，協同效果更加高效。（主流程和子流程這里可能不太容易理解，后續我們會在具體的功能設計篇詳細闡述）

3. 工單分派

工單分派引擎是工單系統核心模塊中最有潛力的模塊，它主要負責將處理組中的工單分派到具體的處理人手中，和工單流轉模塊的作用不分伯仲，分派引擎主要分為兩個功能：

（1）手動分派配置

許多中小企業仍然采用手動派單，而這種派單方式對于不同發展階段的企業，不同情況下的企業來說，有其存在的價值和必要性。因此：

一則需要設計一個手動派單操作臺，由某派單員可以在操作臺上，將流轉到某一處理組的工單進行手動分派。

二則這里需要在權限上做好管控，對派單員能夠進行分派的處理組進行配置和管控。

三則需要設計可以查看組中成員工單處理情況的看板，派單員可能需要根據不同成員處理的不同情況進行分派。

（2）自動分派配置

對于自動分派來說所需要的功能配置就非常齊全和重要，這里我們簡單闡述分派時間和分派方式的概念。

在分派時間上，例如客服團隊的上班時間一般是7*12、投訴團隊的上班時間一般是7*8。這樣在進行工單分派的時候，不在工作時間的處理組，即使有新的工單出現也暫時不進行分派，而是等到處理組上班之后再進行工單分派，防止由于請假等不在崗的情況下，工單仍然進行持續分派的情況。

而在分派方式上，例如投訴組的主要工作是進行投訴處理，那么對于投訴組來說工單只要能夠平均的分派到每個人手里就行，因此投訴組的工單可以通過設置自動分派的邏輯進行平均分派。對于運營團隊可能不同的商品負責的運營人員是不同的，那么需要將冰箱相關的問題分給冰箱條線的負責人，空調相關的問題分給空調條線的負責人，這些小功能都需要進行設計和配置。

（3）小結一下

在工單流轉模塊中，我們將工單流程的最小單位整合為處理組，因此工單根據流轉邏輯流轉到處理組后，工單分派就是解決如何將工單匹配到對應的處理人的問題。工單的分派大致可以分為三種形式，一是由專門的分派人員，分派到不同的處理人手中；二是工單流轉到處理組后，處理組中的用戶根據自己的情況主動領取工單；三是系統對分派邏輯進行設計，自動根據設置的邏輯分派工單。

大多數情況下我們鼓勵設計自動分派邏輯，但是根據不同處理組的實際情況，前兩種分派方式仍然有其存在的必要，產品經理需要根據實際的業務場景把握是否三種分派形式都需要，控制架構設計的合理性。

高效的工單系統架構-上篇，我們講到這里就先結束了，這一篇中已經將高效的工單系統高效在哪里基本上闡述的非常清楚了；

下期，我們再接著講工單系統架構中5個重要支撐的功能模塊，那些模塊主要面對和解決的是工單系統在使用體驗上的問題。

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

題圖來自Unsplash，基于CC0協議

責任編輯：Rex_03