用戶管理支援 (Managing user support)

現在你已經建立了一個服務台 ，可以用來善用使用者回饋意見以改進你的服務與使用者經驗。

規劃查詢數據的子項目

有效且快速地回應使用者回饋意見的能力端視你如何規劃分析這些查詢數據。

如何將查詢數據規劃到適當的類別取決於：

• 查詢的複雜程度
• 用來處理查詢數據的系統之複雜程度

這些因素將決定分類調查數據的過程是由人工進行（人員建立元數據(metadata)來處理他們握有的查詢數據)或是機器自動進行(用來處理查詢數據的軟體會自動加入大多數的元數據(metadata))。

最基本安排的查詢方式有：

• 管道（電話，電子郵件，交談，社交媒體，普通郵件等）
• 目標族群可以作為意見反饋

可能的子項目類別

除了上述的基本管道語目標規劃，以下的類別也是可能的適合選項。

查詢類別

這個詢問是：

• 一個議題(question)
• 一個問題(problem)
• 一個投訴
• 一個有關資訊自由(Freedom of Information, FOI)的要求
• 一個無法採取任何作為(non-actionable)的叫罵

查詢者細節

基於使用者隱私考量，應該思考你將如何蒐集使用者數據。
最基本的要求是向尋求協助的查詢者取得最少的資訊。

回復類別

這個回復是必要的/預期中的或是不需回復嗎？

查詢狀態

這個查詢的狀態是開放、待解決或是已解決等

查詢類別

舉個具體的例子來說，在一個大型網站上，你可以根據想要如何分類不同的URL和各章節去規劃內部的章節或功能類別。

服務類別

依據不同的處理過程環節來擷取資訊。
你會想擁有的資訊包括：

• 協助等級
• 優先順序
• 內部解決小組
• 解決人員
• 受理時間/日期/星期
• 解決時間/日期/星期

根源類別

尋求服務台協助的根本原因，例如：

• 無法下載網頁
• 資料庫無回應
• 忘記密碼
• 使用者錯誤
• 軟體程式錯誤

大致根據以上幾點，規劃出適合你的產品或支援模式的根源類別。

寄送數據到對應類別

收集到數據以後，你需要決定如何分享它。如果你的機關能夠直接處理與使用這些數據，那麼數據分享就會顯得容易許多。但是比較可能的情形是不同類型的問題由不同的人員處理，而且很可能在你的部門之外。

如果可能的話，讓你的系統自動分享數據。

查詢視為服務缺陷

將每一個來自使用者的查詢視為服務中的一個缺陷是一種非常積極的改進方式。這樣一來，每個查詢就會是你的服務支援模式中的不足之處，或是你用來處理這些查詢的管道之一。

雖然可能誇張解釋了其他前來查詢的原因（例如使用者來信感謝或致意的電子郵件會是一個缺點嗎？）但是這的確是一個直接且挑剔的方式去思考該如何提供服務。

改善工程

在查詢等級改進數據被分配到正確的組別後，就可以開始進行改進程序分析。將你的查詢等級數據結合成本數據以協助排出哪些區域為優先處理。但你也可以單純使用受影響的用戶數量（或比例）作為排序優先順序的工具。

無論如何，請確認你能夠聯繫具有流程分析與改進經驗的人員，最好是有相關的聯絡中心或是技術經驗。
能夠直接詢問處理查詢與建置改進項目服務的人員將會得到更快更好的結果。

譯者：劉盈秀
校稿者：
原始出處：https://www.gov.uk/service-manual/operations/managing-user-support/