< 前情提要>
我自己學 SQL 最大的收穫不是可以抓資料，而是和 data team 有共通的語言。就我的觀察，和 data team 最難溝通的是那個從 0 到 1 所需要的東西。
很多時候我們都會跟 data team 講說我想要一台摩托車，可是他們會想要知道你的摩托車是什麼種類的，是用來代步還是跑外送？
你如果沒有辦法描繪自己想要用來幹嘛，你就很有可能期望一台新勁戰但是最後卻拿到一台 Gogoro。
然後如果你連想要什麼輪胎尺寸，煞車系統，甚至汽缸都不懂那就別怪對方把你當盤子，跟你說抓這個資料要很久，你可能要等兩個禮拜。
< 正文開始 >
【嗨小帥，好久不見】
之前出差安排不同梯次的關係，我的出差時間和小帥幾乎是錯開，算一算我也差不多三個月沒有看到他本人了吧，只有在視訊會議的時候才會偶爾和他打哈哈。
小帥的工作內容其中一部份是管理 BPO 的表現，所以想要知道 BPO 表現好不好的話當然是去找他問最清楚了。我走到小帥的座位旁邊開門見山的問「欸小帥，好久不見啊，我還以為你和 BPO 相處的那麼融洽都不打算回台灣了。話說，我們之前一起訓練的那批 BPO 表現如何呀？」
小帥「馬馬虎虎吧，他們每天還是問我很多問題。我等等要和茉莉還有我們訓練的 BPO 一起開會，希望茉莉可以多幫忙處理一些 escalation，不然你一起參加那個會議好了。」
距離我下一個會還有一小時，不然來觀摩看看好了。
【Business Review】
客服營運因為要維持外包商的服務品質，所以常常會和外包商定期開會來確保我們掌握他們的營運細節，這種定期的會議我們稱之為 business review。通常就是觀察 KPI 的表現，討論 SOP，棘手 escalation 怎麼處理。
一開始報告的內容包含他們上禮拜處理了多少客訴，按照每個客服人員的表現排列出顧客滿意度，然後觀察他們處理客訴的速度快不快。小帥和茉莉也在會議中稍微瞭解一下哪些客服專員為什麼顧客滿意度特別低，是不是因為回覆出錯還是本身我們制定的 SOP 有問題導致客人不滿意。
我覺得這個會最棒的地方是這些客服人很多，處理的客訴量也大。我們之前訓練了 60 多個客服專員就代表有 60 雙眼睛每天在幫我們的服務品質把關，搜集洞見客人的不滿才能持續的讓我們優化客服經驗。
但是還是會有啼笑皆非的情況出現。像那個時候有一張客訴的駕駛超氣，說乘客在車上掉了東西（有附圖）然後問我們怎麼辦。結果 BPO 以為那是一張垃圾紙，所以建議駕駛把那張紙丟掉就好。結果駕駛超氣，然後給了滿意度一顆星被我們發現，看了前期後後的客訴內容才知道為什麼駕駛那麼生氣。原來那張紙長這樣...
【那些 BPO 不知道的事情】
因為不確定 BPO 給的回饋是不是正確的，所以帶著好奇心我馬上抓了一些數字把數字視覺化來看我們 BPO 的表現。常見的 KPI 包含客訴量，顧客滿意度，回覆速度和服務等級。而這四個 KPI 其實中間是多少有相關性的。
像底下這張圖就可以告訴我們在產品推出的第一個禮拜客訴量很高，而且顧客滿意度也因為對產品不了解，所以特別低。但是隨著使用者慢慢習慣產品，客訴量慢慢降下來，滿意度也逐漸回升。
（客訴量和顧客滿意度）
另外一個例子是我們團隊在尖峰時段的回覆速度雖然很快而且有在進步但是服務等級因為人員配置一直縮編導致沒有辦法滿足客訴的量能。所以就算報表顯示 AHT 不斷有在進步，但是其實還是有蠻多客人沒辦法即時得到回覆的（超過 25% 的客訴沒在服務等級內）。
（回覆速度和服務等級）
其實這些顧客體驗 BPO 是很難體會的，他們因為太聚焦在處理每一筆的客訴內容，以至於最後會見樹不見林。
在他們報告完之後我發現這些使用者一定有某些習慣，不禁讓我覺得，我們有沒有辦法操縱使用者的偏好和習慣呢？
以上內容純屬虛構，如有雷同純屬巧合
Comments