如何設(shè)計出一款靈活的工單系統(tǒng)?
圍繞工單系統(tǒng),本文將介紹它的價值、業(yè)務(wù)背景、用戶場景、產(chǎn)品流程、產(chǎn)品設(shè)計,向大家分享如何設(shè)計一個靈活的工單系統(tǒng)。
Part1 核心價值
工單系統(tǒng)的核心價值是什么?
通過上圖我們發(fā)現(xiàn),當(dāng)發(fā)現(xiàn)問題和解決問題不是同一人的時候,這里面就會涉及到信息傳遞的效率問題。
Part2 業(yè)務(wù)背景
如果你是發(fā)現(xiàn)問題的人,可以試著問自己以下幾個問題:
- 我應(yīng)該如何描述我的問題?
- 我的問題應(yīng)該找誰處理?
- 我希望這個問題盡快解決嗎?
如果你是解決問題的人,可以試著問自己以下幾個問題:
- 這個問題的描述清晰嗎?
- 如果不清晰我該如何讓這個問題變得清晰?
- 我應(yīng)該在什么時間前解決這個問題?
- 這個問題我解決不了怎么辦?
- 現(xiàn)在有100個問題要解決,我應(yīng)該先解決哪個?
等等。
可以看到,發(fā)現(xiàn)問題和解答問題之間有一個巨大的信息鴻溝需要解決。而解決的辦法就是工單系統(tǒng)。
Part3 用戶場景
我們首先梳理一下工單系統(tǒng)的典型用戶:
- 工單提交者簡稱Q:客服、消費者
- 工單解決者簡稱S:運維、業(yè)務(wù)部門
- 工單監(jiān)控者簡稱M:客服管理者、業(yè)務(wù)管理者
再來看一下他們的用戶故事:
- 作為Q,我想要將消費者提出的問題記錄下來,以便于查詢或者轉(zhuǎn)交給S解決
- 作為Q,我想要知道問題應(yīng)該找誰解決,以便于問題可以快速定位并解決
- 作為Q, 我想要將問題轉(zhuǎn)交給到相應(yīng)的S,以便于S可以根據(jù)我記錄的信息解決問題
- 作為Q,我想要根據(jù)S的要求提供更多信息,以便于S解決問題
- 作為S,我想要知道問題的詳細(xì)信息包括問題描述、優(yōu)先級、解決時間要求等結(jié)構(gòu)化信息,以便于快速定位、解決問題
- 作為S,我想要在缺少部分信息的情況下詢問Q獲得更全面的信息,以便于解決問題
- 作為S,我想要在我解決不了這個問題的時候?qū)栴}交給其他S,以便于解決問題
- 作為M,我想要知道整體的問題處理情況,以便于了解服務(wù)質(zhì)量
- 作為M,我想要知道Q和S的工作量情況,以便于及時發(fā)現(xiàn)工作量的問題并做調(diào)整
Part4 產(chǎn)品流程
根據(jù)以上用戶故事,畫出工單系統(tǒng)的核心流程:
Part5 產(chǎn)品設(shè)計
根據(jù)系統(tǒng)流程,我們可以總結(jié)出工單系統(tǒng)需要具有以下核心功能:
- 工單類型
- 表單模板
工單系統(tǒng)的高度靈活,也就是組成工單系統(tǒng)的功能模塊的高度靈活,那上述核心模塊如何做到高度靈活呢?
1. 工單類型
在設(shè)計工單類型的時候,我們可能會依據(jù)產(chǎn)品線、問題發(fā)生階段、后果等維度來細(xì)分工單類型,為了實現(xiàn)高度靈活,我們就需要將工單類型的設(shè)置工作完全交給用戶。
從數(shù)據(jù)存儲的角度講,每一個工單類型都是一條記錄,在這條記錄中,需要設(shè)計以下字段信息:
- 名稱
- 層級
- 父類型
- 順序
在表現(xiàn)形式上,可以使用多級菜單的模式:
需要注意的是層級、類型數(shù)量的邊界設(shè)定,同時對于新增類型、層級內(nèi)展示順序、刪除高層及類型的操作要想好產(chǎn)品邏輯。
2. 表單模板
工單表單是問題的結(jié)構(gòu)化表達(dá),我們在設(shè)計工單表單的時候應(yīng)該盡量將問題的信息結(jié)構(gòu)化,便于S獲得全面信息及數(shù)據(jù)分析。而模板是為了應(yīng)對不同的業(yè)務(wù)場景需要,不同的場景對應(yīng)不同的模板。
為了達(dá)到結(jié)構(gòu)化和高度靈活這兩個目的,表單模板需要具有以下特性:
- 模板與表單一一對應(yīng)
- 模板依據(jù)工單類型劃分
- 字段可以增減(必填字段除外)
- 可以增加自定義字段
- 字段順序可以調(diào)整
表單模板原型圖如下:
在設(shè)計模板字段的時候,我們可以默認(rèn)添加工單中可能用到的字段,但為了覆蓋盡可能多的場景,還需要設(shè)計添加自定義字段的功能,包括字段名稱、字段類型等。
除了工單類型和表單模板,工單的流轉(zhuǎn)、消息通知、回復(fù)、操作記錄等并沒有提及,我認(rèn)為這些是標(biāo)準(zhǔn)功能,并無設(shè)計高度靈活的必要性,暫不列出。
Part6 總結(jié)
由于B端業(yè)務(wù)的多樣性,我認(rèn)為SaaS產(chǎn)品設(shè)計需要將靈活性放在足夠重要的位置,因為靈活性決定場景覆蓋范圍。在產(chǎn)品設(shè)計時,產(chǎn)品經(jīng)理應(yīng)該根據(jù)現(xiàn)狀和未來發(fā)展將需求、場景盡量抽象,設(shè)計出靈活的產(chǎn)品方案。
靈活性必然帶來開發(fā)工作量的增加,二者如何取舍?我們可以聊一聊。
本文由 @萬旗 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自 unsplash,基于CC0協(xié)議
我是本文作者,歡迎關(guān)注我的公眾號“凌云青年旅館”
你好,同為工單PM,可以一起交流經(jīng)驗心得嗎,我微信rowena422
我沒做過工單產(chǎn)品。。這只是我自己的一些構(gòu)思和設(shè)計哈哈哈
流程圖都錯了,:-(
解決工單問題——是否需要更多信息,這步需要在工單系統(tǒng)溝通嗎?為什么不能用釘釘/溝通軟件溝通,在工單系統(tǒng)溝通的目的是什么?留痕跡嗎
嗯嗯,漏掉了一條“否”的分支。溝通的場景是問題解決人需要獲得更多關(guān)于問題的信息才可以解決問題,所以需要基于工單進(jìn)行“跟帖回復(fù)”。而IM是脫離了工單這個流程場景的,無法將工單信息與回復(fù)信息關(guān)聯(lián)。
我作為一個企業(yè)員工,不可能常常登陸工單系統(tǒng)看是不是我的工單有人回復(fù)我了。
做了這個功能,是不是實際場景會是:it小王看到A工單,描述不清楚,回復(fù)了工單,A工單的發(fā)起人小張5天后想著去看看工單被解決了沒有,才看到了這條回復(fù)信息。
整個流程變的很復(fù)雜,如果上述場景時長發(fā)生,可能功能會廢掉(it人員根本不用,直接在釘釘詢問下,立刻就能得到問題的答案,立刻就可以解決這個問題)
嗯,明白你的意思。所以這種通知至少需要兩種渠道:產(chǎn)品內(nèi),產(chǎn)品外。產(chǎn)品外可以是短信、郵件等。
手機號更直接,處理人電話打過去咨詢也能給提交人一個好的印象,同時起到一個回訪作用。
其實現(xiàn)在做法是將工單系統(tǒng)賬號和釘釘賬號打通,將web頁面嵌入釘釘直接回復(fù),通過接入釘釘通知消息來解決及時性。工單對于問題的記錄、跟蹤、統(tǒng)計、歸納、抽象可以提升人員處理效率(不是每個人都很自覺,哈哈)
產(chǎn)品流程圖畫錯了把,是否需要更多信息的否那條線呢?