線上客服工具：打造智能與真人的即時對話功能
此專案目標是打造一個整合的線上客服前台工具，並導入智能技術降低真人服務量。在專案過程中，設計師發揮了主導性和影響力，並得到了合作夥伴的肯定。最終，上線成果顯示實體進線和 LINE 詢問數減少了 30%，線上客服整體解決率提升到 80%。
專案背景
有很多原因驅動了此專案：
- Business：目前客服提供實體進線電話服務，而線上是採用外部工具 LINE bot 及 Zendesk，兩者皆要付費，希望能精簡化線上客戶服務的工具，降低成本。
- Technology：因應市場趨勢導入智能技術。
- User’s pain points:
- 內部使用者 (CS Team)：因提供多種客服渠道，讓回覆的後台分散，切換使用不便。
- 外部使用者：在非客服上班時段，遇到問題無法獲得即時解答，只能留言等待回覆。
專案目標
「創造一個線上客服前台工具，並導入智能技術降低真人服務量。」
在官網提供統一的線上客服前台工具，讓客服人員可以直接在官網後台統一管理回覆，並透過智能技術降低常見問題的服務量，同時預留未來更多服務的擴展彈性。
專案挑戰
此專案成員組成特別，需求來自內部的 CS Team，而開發的人力資源是直接從每個 Team 派一位設計師、前端工程師、後端工程師組成臨時小組，讓執行端與需求端直接對接合作。
最大的考驗便是「如何在沒有 PM 統籌的情況下進行協作？」、「如何讓 CS Team 融入開發團隊的工作流程？」，並確保能在ㄧ個半月內先推出ㄧ版 MVP。
設計過程
1. Discover 探索工具
先著手調查外部工具服務，分為：
— 付費工具
Zendesk、IntercomOmniChatFreshchat 等，研究方案內容與可供客戶客製、串接的彈性。
在維持購買 Zendesk 的前提下，經工程師研究，Zendesk 沒有提供完整的訊息往來串接，故不考慮。
— 自架工具
市場上蠻多間銀行都有線上客服功能，這些自架工具的介面佈局與元件呈現更多元，可以作為設計案例參考，並透過實際的展示與 CS Team 對齊操作體驗的期待。
![[fig1] 自架工具案例收集](https://ruuuchen.github.io/portfolio/img/onlinecs/fig_自架工具案例收集.png)
2. Define 需求釐清
決定自架工具後，在 Kick-off 會議時 CS Team 提供了 Wireframe 與期望上線日，我們深入討論了很多執行上的細節，以及在 Web 第一版本上線後該如何推出更多功能，並提及 App 未來有應用的可能。
Zendesk 上班時段進行真人服務，下班時段切換智能服務，提供 FAQ 常見問題的即時回覆，若問題沒有獲得幫助，可以留下訊息給真人客服。
![[fig2] Wireframe-Phase 1](https://images.spr.so/cdn-cgi/imagedelivery/j42No7y-dcokJuNgXeA0ig/c0e39ad1-4e3b-4bb7-abe4-eaeb67dddb6b/fig_Wireframe-Phase1/w=2048,quality=90,fit=scale-down)
全面移除 Zendesk ，自架工具可切換真人服務，且可填寫滿意度、傳輸資料，並依據使用記錄，整理相似問題與推薦解答，提高解決率。
![[fig3] Wireframe-Phase2](https://images.spr.so/cdn-cgi/imagedelivery/j42No7y-dcokJuNgXeA0ig/c46fc120-7905-4e05-9c8f-aae97179020f/fig_Wireframe-Phase2/w=2048,quality=90,fit=scale-down)
3. Develop 構思方案
把簡單的 Wireframe 往下設計，是設計師很熟悉的事情，但這次起頭有一點卡關，因為這個工具還需先探討：「技術端會如何開發？將觀乎到需設計的畫面尺寸。」
方案ㄧ、建置獨立頁面，並使用 <iframe> 內嵌到全站。 方案二、使用彈窗模組。
![[fig4] 開發技術討論筆記](https://ruuuchen.github.io/portfolio/img/onlinecs/fig_開發技術討論筆記.png)
最終考量開發的可行性與未來擴充性，Web 先選用彈窗模組開發，若後續要將 Web 嵌入到 Andriod、iOS 系統時，再改寫成獨立網址頁讓各裝置使用。
4. Design 視覺化方案
— 繪製 UI Flow
已知會有兩個 Phase 的情況下，我先透過視覺化的 UI Flow 流程圖展開情境狀態，確認每一個操作任務都有端到端的回應，並將稿件釋出後讓專案成員清楚了解每個 Phase 要完成的功能畫面，預留開發彈性。
![[fig5] UI Flow-主要對話流程](https://ruuuchen.github.io/portfolio/img/onlinecs/fig_UI Flow-主要對話流程.png)
— 定義訊息元件
由於訊息有多種情境，我逐一將其定義並建立出九種 Type 的訊息元件，元件之間可進階依使用情境排列組合，方便後續的維護與擴充使用。
![[fig6] Component-訊息元件總表](https://ruuuchen.github.io/portfolio/img/onlinecs/fig_Component-訊息元件總表.png)
設計展示
![[fig7] 介面設計展示](https://ruuuchen.github.io/portfolio/img/onlinecs/fig_介面設計展示.png)
關鍵成果
反思與學習
當時被分派為此專案的負責設計師時，接收到的訊息為：目前遇到什麼問題，想請設計跟工程先研究一下可以怎麼處理，當時聽到時我和工程師一頭霧水，期間又去處理其他專案，直到有天 CS Team 啟動了 Kick-off 會議，才安心許多。
在這個特別組成的專案小組中，因為需求方提供的內容還沒有完全定案，我有了空間與機會發揮多一點的設計主導性與影響力，在承接 CS Team 的需求時挖掘背後的目的性，協助補齊缺少的規格與操作流程，提出更好的設計體驗建議，並於專案如期上線後收穫跨部門的肯定，令人開心！
收獲專案合作夥伴的反饋：
Enther Wu, Design team Eason Lin, Daniel Sung, Engineering team Dolly Lin, Ada Hsu, PM team Jian-Hua Chen, Jhu-Sin Fang, CS team