圍繞工單系統，本文將介紹它的價值、業務背景、用戶場景、產品流程、產品設計，向大家分享如何設計一個靈活的工單系統。
Part1 核心價值
工單系統的核心價值是什么？
通過上圖我們發現，當發現問題和解決問題不是同一人的時候，這里面就會涉及到信息傳遞的效率問題。
Part2 業務背景
如果你是發現問題的人，可以試著問自己以下幾個問題：
- 我應該如何描述我的問題？
- 我的問題應該找誰處理？
- 我希望這個問題盡快解決嗎？
如果你是解決問題的人，可以試著問自己以下幾個問題：
- 這個問題的描述清晰嗎？
- 如果不清晰我該如何讓這個問題變得清晰？
- 我應該在什么時間前解決這個問題？
- 這個問題我解決不了怎么辦？
- 現在有100個問題要解決，我應該先解決哪個？
等等。
可以看到，發現問題和解答問題之間有一個巨大的信息鴻溝需要解決。而解決的辦法就是工單系統。
Part3 用戶場景
我們首先梳理一下工單系統的典型用戶：
- 工單提交者簡稱Q：客服、消費者
- 工單解決者簡稱S：運維、業務部門
- 工單監控者簡稱M：客服管理者、業務管理者
再來看一下他們的用戶故事：
- 作為Q，我想要將消費者提出的問題記錄下來，以便于查詢或者轉交給S解決
- 作為Q，我想要知道問題應該找誰解決，以便于問題可以快速定位并解決
- 作為Q， 我想要將問題轉交給到相應的S，以便于S可以根據我記錄的信息解決問題
- 作為Q，我想要根據S的要求提供更多信息，以便于S解決問題
- 作為S，我想要知道問題的詳細信息包括問題描述、優先級、解決時間要求等結構化信息，以便于快速定位、解決問題
- 作為S，我想要在缺少部分信息的情況下詢問Q獲得更全面的信息，以便于解決問題
- 作為S，我想要在我解決不了這個問題的時候將問題交給其他S，以便于解決問題
- 作為M，我想要知道整體的問題處理情況，以便于了解服務質量
- 作為M，我想要知道Q和S的工作量情況，以便于及時發現工作量的問題并做調整
Part4 產品流程
根據以上用戶故事，畫出工單系統的核心流程：
Part5 產品設計
根據系統流程，我們可以總結出工單系統需要具有以下核心功能：
- 工單類型
- 表單模板
工單系統的高度靈活，也就是組成工單系統的功能模塊的高度靈活，那上述核心模塊如何做到高度靈活呢？
1. 工單類型
在設計工單類型的時候，我們可能會依據產品線、問題發生階段、后果等維度來細分工單類型，為了實現高度靈活，我們就需要將工單類型的設置工作完全交給用戶。
從數據存儲的角度講，每一個工單類型都是一條記錄，在這條記錄中，需要設計以下字段信息：
- 名稱
- 層級
- 父類型
- 順序
在表現形式上，可以使用多級菜單的模式：
需要注意的是層級、類型數量的邊界設定，同時對于新增類型、層級內展示順序、刪除高層及類型的操作要想好產品邏輯。
2. 表單模板
工單表單是問題的結構化表達，我們在設計工單表單的時候應該盡量將問題的信息結構化，便于S獲得全面信息及數據分析。而模板是為了應對不同的業務場景需要，不同的場景對應不同的模板。
為了達到結構化和高度靈活這兩個目的，表單模板需要具有以下特性：
- 模板與表單一一對應
- 模板依據工單類型劃分
- 字段可以增減（必填字段除外）
- 可以增加自定義字段
- 字段順序可以調整
表單模板原型圖如下：
在設計模板字段的時候，我們可以默認添加工單中可能用到的字段，但為了覆蓋盡可能多的場景，還需要設計添加自定義字段的功能，包括字段名稱、字段類型等。
除了工單類型和表單模板，工單的流轉、消息通知、回復、操作記錄等并沒有提及，我認為這些是標準功能，并無設計高度靈活的必要性，暫不列出。
Part6 總結
由于B端業務的多樣性，我認為SaaS產品設計需要將靈活性放在足夠重要的位置，因為靈活性決定場景覆蓋范圍。在產品設計時，產品經理應該根據現狀和未來發展將需求、場景盡量抽象，設計出靈活的產品方案。
靈活性必然帶來開發工作量的增加，二者如何取舍？我們可以聊一聊。
本文由 @萬旗 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自 unsplash，基于CC0協議
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。