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