工單系統——深度解析高效的功能架構(中)

zxx
2 評論 10548 瀏覽 78 收藏 24 分鐘

工單系統要如何搭建設計策略,才可以使系統更好地落地,并給到使用者足夠好的系統使用體驗?也許你需要在功能架構維度上多下功夫。本篇文章里,作者便針對工單系統功能架構中的幾個支撐性模塊,做了設計理念、設計策略上的拆解,一起來看。

前言

本文繼續闡述工單系統-高效的功能架構,中篇的5個支撐性的模塊分別為:工單管理、工單工作臺、工單時效、工單通知、工單監控,主要解決的是工單系統的使用體驗是否足夠好的問題。工單系統在體驗上的優化大部分優化以及小部分在效率上的優化會通過這五個功能模塊來完成。

同時這五個功能模塊的設計理念也緊密圍繞高效協同和靈活適配,在這五個模塊中仍然能夠看到大量為了更高效、更靈活做出的功能架構設計。

一、工單管理

工單管理主要聚焦“一個工單,創建—>處理—>關單的流程”中都需的要素,以及每個角色能夠在對應的環節中做些什么。主要分為工單創建配置、工單處理配置、工單關單配置三個部分來闡述。

1. 工單創建配置

首先我們來說工單創建的部分,工單創建配置主要是兩部分,工單渠道配置和工單建單信息。

1)工單渠道配置

工單可以來自于多個渠道,越優秀的工單系統的渠道也會越多;例如:

  • 將創建工單的入口嵌入在APP中,鼓勵用戶自助建單;
  • 在智能客服中嵌入工單模塊,幫助用戶智能建單;
  • 給供應商提供系統接口,幫助供應商建單;
  • 客服系統、售后維修系統、門店系統等自身業務系統中的建單渠道等等。

越多的渠道和入口也就代表了工單體系的生態就越好,有更多的參與方能夠一起參與進來,也有更多的場景能夠被覆蓋;這里要注意不同的渠道能夠創建的工單是有差別的,因此需要根據渠道配置不同的工單分類。

2)工單建單信息

其次是工單的建單信息,工單建單信息一般包括兩類:

  • 一是能夠被標準化的用戶信息例如身份證號、手機號、用戶姓名等、及能夠被標準化的商品SKU、商品名稱、所屬供應商等商品或訂單編號、下單時間等訂單這些業務信息和工單本身的一些信息。
  • 二是無法被標準化的配置類信息,這種信息一般都具有很強的業務屬性,會根據業務的發展階段,不斷變化。因此我們會提供標準模版,并且支持業務人員加入自定義配置的業務所需要的信息和字段。

通常在功能架構的設計中第一類信息會被設計成系統可以幫助用戶自動抓取的形式,來減少工單創建的工作量,提高用戶體驗和建單效率。

2. 工單處理配置

工單處理主要聚焦用戶如何處理和協助處理工單,其中包含“當前處理人”和“第三方協助人”兩個部分。

1)當前處理人

工單的當前處理人在處理工單過程中可以進行的操作主要有:處理記錄、發起任務(前文中子流程的概念)、流轉、上傳附件、關單。在設計理念中,工單處理人對工單有完全控制權限,因此工單當前處理人擁有這個工單的最高權限。這里我們重點闡述一下處理記錄和發起任務兩個功能:

  • 處理記錄:工單會在處理人手中進行綜合處理,在這個過程中,工單需要記錄下來處理人的每一步動作,因此我們會給處理人一個處理記錄的功能,以時間線為主維度將處理人的每一步處理都記錄下來,來保證工單進行回溯或者數據分析時的數據完整。
  • 發起任務:在前文中我們給工單設計了子流程的邏輯,這里的發起任務主要用于當處理人判斷該工單需要其他的第三方進行協助時,可以通過發起任務功能,選擇發起一個或多個子流程,尋求其他的協同方一同處理當前工單。

2)第三方協助人

第三方的協同人可以對工單進行的操作一般包括評論、備注、加急、回復任務等功能。

這里重點關注下備注,我們為第三方設計的無論是評論還是備注或者是加急,其實本質上都是在工單本身信息之外的其他補充性的信息預留的功能設計。將工單主動性交給處理人。

例如原本和維修師傅定的是早上10點去維修,但客戶突然聯系客服說晚上6點才有時間,這時候我們可以在備注中對維修工單進備注?;蛘咴就对V部門準備下午3點回訪用戶,但是用戶找客服要求現在就要回復,客服可以對工單進行加急。

第三方主要做的是協助處理的工作,將需要告知處理人的信息告知處理人即可,并不能對工單做進度調整、內容修改等其他操作。當然系統可以針對一些動作做處理,例如客服加急之后,可以提高這個工單的優先級,工單被評論后,會在待辦列表中置頂展示等等。

3. 工單關單配置

工單的關單配置主要包含兩個部分:關單權限配置和關單信息。

1)關單權限配置

工單在流程中會配置某一個流程節點的處理人是不是可以作廢、關閉當前的工單。

例如一個升級邏輯的流程,客服-客服組長-部門經理。如果客服組長已經解決了用戶的問題,那么其實無需到經理節點,組長就可以直接關單了。這些在主流程中的邏輯配置是工單處理層也需要關注的。

2)關單信息

關單信息的重點一般在關單類型,常見的關單類型有客戶滿意關單、未達成一致關單、聯系不上關單這三種類型,這三種類型分別對應最常見的三種處理結果:

  1. 客戶滿意關單:工單處理完成后處理結果客戶很滿意,沒有其他問題,關單結束;
  2. 未達成一致關單:和客戶根本達不成一致,訴求滿足不了,多次溝通未果,關單結束;
  3. 聯系不上關單:壓根沒聯系上客戶,關單結束。

其他需要關注的還有需要配置在關單流程中需要客服補充填寫的關單信息,因此也需要在關單環節對關單填充信息進行配置。

4. 小結一下

工單管理模塊中的功能主要關注在工單本身的功能上,包括需要在哪個流程為哪些角色提供哪些具體的功能。這些具體到工單的功能設計對用戶體驗的影響是非常重要的,大多數用戶感知比較強的功能優化也集中在這個模塊,因此要警惕不要因為這個模塊做起來很有成就感就顧此失彼,忘記對核心模塊的改造才是提升效率的重點。

二、工單工作臺

業務工作臺是業務人員的主要工作臺。在這里需要的就是把業務人員手中的工單,幫助他們進行分類整理,便于業務人查找和處理,減輕業務人員在處理工單之外的工作任務。主要包含以下三個模塊:

1. 已處理工單

用來存放業務人員已經處理過的工單,一般存個7天內就夠用了,比如業務人員創建的工單,可能會擔心工單是否創建錯誤了,或者擔心剛剛需要創建的工單是不是已經創建過了,也可以用來在工作即將結束的時候對自己這一天的工作進行復盤,工單是否都正確創建和處理,有沒有漏單的情況等。

2. 待處理工單

用來存放當前并不需要處理的工單,例如維修時間不是今天的工單、回訪時間不是今天的工單、已經發了任務,要等子流程回復的工單等等,暫時不需要處理的工單。這個模塊的工單是可以在觸發一定條件后轉移到處理中的工單列表中,例如被加急、任務被回復、被評論等情況。

3. 處理中工單

用來存放當前需要處理的工單,一般會按照處理時間排序,因此這個列表需要進行優先級的設計。把處理時間、緊急程度、工單類型進行綜合評估,給出合適的優先排序,工作人員只需要關注工單本身,根據優先級挨個處理工單即可。

4. 小結一下

工單工作臺是工單業務人員主要的工作臺,尤其是作為B端工具,用完即走真的是它的核心邏輯,不要讓業務浪費太多時間在工單的處理等等其他事務性的工作上。因此工作臺要做的就是幫助業務人員集中精力在工單本身的處理上,將排序、思考、復盤等能幫助業務人員解決的問題都一一解決,這對于用戶體驗的提升是非常大的。

三、工單時效

在講工單通知和工單監控模塊之前需要先將工單時效配置的功能模塊穿插進來,它是通知和監控的基準。

通知和監控都需要有一個比較合理的標準,而對于工單系統來說,也需要這樣一個標準來不斷推動和指引工單系統的不斷進步。

工單時效配置就是這樣一個功能,它是工單監控模塊的基礎功能,也是整體工單系統設計中的畫龍點睛之筆,它將藏在工單系統深處的設計目標以最直接最明確的數據形式展示在業務人員、運營人員和管理層面前。

1. 工單時效設計

工單時效的設計會貫穿整個工單的處理流程,最重要的四個時效有:回復時效、處理時效、流轉時效、關單時效,這四個時效是涵蓋一個工單整體生命周期的基礎時效。

  1. 回復時效:指的是創建工單后第一次回訪用戶的時效;
  2. 處理時效:指的是業務人員每一次處理工單的間隔時效;
  3. 流轉時效:指的是工單工單每個節點的處理時長;
  4. 關單時效:指的是工單整體的關單時長。

2. 工單時效配置

同時,不同的業務部門、不同的業務場景、不同的工單流程,處理時效也是需要根據具體的工單分類設計情況進行設計。因此設計該功能的作用是針對不同的工單配置不同的回復效率、處理時效等等,為后續的工單監控和工單提醒提供標準支撐。

因此對于工單來說時效的配置必須是畫龍點睛的功能點,能夠和敢于把工單時效概念提出來,正視工單處理時效的業務部門,才會真正花費力氣再不斷地提升工單的處理時效上,不斷地提高工單處理效率。

3. 小結一下

工單時效的關鍵在于業務部門,這里需要和業務部門進行充分溝通和論證,在業務部門的支持下進行工單時效的設計。主要原因在于時效設計不能單單只是一個時效設計,設計本身并不困難,但是這個時效的作用是給到業務部門的運營和管理人員關注,通過持續不斷的優化,提升工單的各個時效,從而提高工單的處理效率。

如果做的好,工單系統的效率能提升一倍,如果做不好工單系統也只成功了一半,所以它是畫龍點睛的一筆。

四、工單通知

工單系統涉及的業務部門和協作方非常多,專注于協作的工單系統,必然需要為使用系統的人員提供更及時的系統通知,因此工單的通知模塊就顯得尤為重要。

1. 通知觸發配置

工單觸發主要通過時效部分配置,以及一些監控設置,在到底一定閾值的情況下,會觸發通知提醒,提醒的設計會在工單監控模塊重點闡述,這里主要是說明一個工單的提醒其實是兩個模塊共同作用的結果,需要做好聯動設計,防止后續返工在產品設計和開發上面增加不必要的工作量。

2. 通知渠道配置

在上文中用戶能夠從哪個渠道發起工單,理論上通知的渠道就要能夠觸達到哪里。甚至在實際的工作場景中,我們通知的設計會更加的深入。這個設計主要是方便將工單的處理狀態及時的同步到關注工單的各個部分,當然最重要的通知是當前處理人。

例如有其他協助方回復工單的時候,如果處理人沒有關注工單系統,我們可以通過企業內部的IM系統(例如飛書或者釘釘等)通知用戶,這樣用戶才可以第一時間收到通知去處理工單,對于更高級別的例如投訴工單下發的任務到達協助方之后,我們甚至會下發短信或智能外呼去及時通知用戶,以提高工單的處理速度,快速解決問題,防止工單事態的進一步升級。

3. 小結一下

工單的通知模塊可以理解為工單的消息中心,和所有業務系統的消息中心一樣,它是工單系統的傳聲器。這一個部分的關鍵在于消息分級;不同等級的消息提醒,觸達渠道不一樣、觸達方式也不一樣。例如最高級的投訴通知,可能就需要通過短信直接發送到業務人員的手機上;而最低級的新工單提醒,只需要在工單系統彈出提醒一下,看不看都不會影響業務人員的處理。

五、工單監控

監控模塊主要是協助業務管理者以及工單系統的運營人員能夠及時關注工單整體的處理情況,及時發現工單積壓、工單超時等問題,通過人員調度、資源協調、智能調整等手段對進行調控。保證工單整體,及時有序的處理完成。并且工單監控也能夠提供工單處理人某些工單需要及時處理,某些工單已經超時需要盡快處理等。工單監控部分分為三個部分,工單監控看板、工單監控提醒、工單預警監控。

1. 工單監控看板

工單監控看板的主要作用是通過一系列的工單數據看板,展示工單整體的運營情況。它就是管理者和運營人員的眼睛,輔助他們了解工單整體的狀況,對工單處理、人員情況、運作狀態做到心中有數。工單看板重點關注兩個部分:

1)工單處理情況

以不同工單分類為維度展示的工單創建量、工單處理量、工單回復效率、工單關單時長,工單超時任務量等指標,對每個場景下的工單處理情況進行監控,確保能夠及時發現工單處理中的問題;

2)人員處理情況

包括處理組的在崗人數、正在崗時長、工單未處理量、待處理量、已處理量、工單回復效率、工單回復時長等看板等數據,以及處理人今日已處理、當前未處理、平均關單時長、即將超時工單量等等;

因此工單監控看板對實時性的要求非常高,要的就是實時數據,數據刷新要求一般在2s以內。當然不同公司、不同管理者之間也有誤差,有些不那么關注的10s他也能接受,那就沒有必要設計的那么實時,這些需要產品經理現場把握了。

只要能夠從各場景工單處理情況、各處理組處理情況、各處理人處理情況三個大的維度整體考慮,對工單系統的生態運營情況進行監控,保證工單體系的運營流暢即可。

2. 工單監控提醒

這個模塊的主要目的在于提醒, 設定一定閾值對工單運行情況進行監控,并及時通知業務人員、管理者以及運營人員。提醒的重點在于督促被提醒人馬上做出改變。

例如工單即將超時提醒,這個監控的被提醒人就是工單處理人,提醒的目的就是讓業務人員盡快去處理這個工單,不然這個工單馬上就要超時了。而例如工單超時未處理提醒,就是讓處理人立刻、馬上去處理該工單。

這個模塊會和工單通知模塊進行聯動,對工單監控中的提醒確認好提醒的等級,并且配置不同的觸達渠道和觸達方式,來達到提醒的作用和目的。

這里也能看出監控看板和監控提醒兩個功能的側重點不同、面向角色不同、想要達到的效果也不相同。

3. 工單監控預警

預警的重點在于對即將發生的風險進行提前干預,防止沒有及時干預導致的投訴等其他風險,因此預警的重點在于提前發現問題。

例如關鍵詞預警,配置某些工單關鍵詞例如提及投訴、報警、詐騙等敏感詞,在命中規則后會自動將工單升級到投訴部門進行及時回訪,避免可能引起的投訴、詐騙問題。當然在實際的業務場景中,一般工單監控預警是多命中規則合并的更加復雜的處理邏輯,僅憑借單一邏輯判斷,無效命中或者誤命中的概率很高。

根據真實的實踐經驗工單監控預警這一部分設計起來的復雜度和難度簡直趕得上工單系統的設計難度。

但一定要相信這條路一定是能走的通,如果不順暢可能只是需要換個現實一點的目標或者熬過這段痛苦的過程。

也可以考慮加入更加強大的人工智能工具,例如GPT,加入進去說不定能找到更快、更準、更好的實現方案。

4. 小結一下

工單監控模塊對于提高工單處理效率的重要性,是這五個支撐模塊中最直接、最重要的。但是這一塊也是最不好做、最容易出現問題的地方,當然也就代表了做好是最出彩的。

我們在實際處理中需要關注以下兩個點,就能大大提高成功的可能:

  • 第一點在于監控的準確性,最好是我們能夠說服業務部門在工單時效模塊投入精力,這樣有準繩的監控才能做的更準確。
  • 第二個問題這些都是數據性的工作,想要真正提效需要業務部門有對應的運營手段,例如大部分被提醒的場景都是業務人員已經在努力做了,但是仍然不能做完,這時候你提醒再多也沒有作用,最需要做的其實是和運營人員聯合做一些功能優化或者加入一些智能手段去調控工單。

六、總結

從工單管理到工單監控,從用戶體驗到工單效率,其實這五個支撐性的模塊作用一點也不弱于上一篇的核心模塊,支撐性的模塊是功能架構的基礎,沒有基礎核心設計的再好也沒有用武之地。無論是基礎還是核心,都是工單系統需要關注的重點,他們是相輔相成的關系。下一篇我們會對工單架構篇做個總結,中篇的五個模塊到這里就先結束。

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

題圖來自Unsplash,基于CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 受益匪淺,給作者點贊

    來自廣東 回復
  2. 每一篇都拜讀了,受益頗多,感謝~

    來自上海 回復