做專案不一定需要專案管理經驗
學長開始帶著我一起做專案，可是我沒有專案的經驗阿，之前畢業還海投 PM 職缺，通通石沉大海。
意識到這件事情之後馬上 Google 查了一個晚上什麼事專案管理，甘特圖，定義，Scope，一堆專有名詞看都看不懂。
隔天我很誠實的告訴學長我真的太廢了完全不知道專案要怎麼做。
學長笑我神經病，你搞得那麼複雜幹嘛，我們就只是把自己處理事情的方式歸檔，寫成 SOP 而已呀。
估計就只是把知識轉換成幾十頁的檔案而已，根本不用想那麼多好嗎？
恍然大悟！原來做這個專案不需要專案管理的技巧嗎？(筆記)
學長才跟我解釋什麼叫做 Knowledge base，是外包商常常用來查找解決辦法的檔案。
怎麼格式都不太一樣？有最好的呈現方式嗎？
剛開始歸檔的時候其實小組長都已經安排好大的工作項目了，基本上就是把常見的問題列出種類，然後分出大項目。
在每個大項目底下再一一去檢視客訴情境的細節，舉例來說如果帳戶無法登入的話，子項目包含什麼？有可能是忘記密碼，也有可能是重複登入，也有可能是根本還沒註冊成功。
我被分配到了一些子項目然後開始著手撰寫 SOP，可是我沒看過格式，不知道則麼寫。
我打開學長寫的幾個範本發現格式怎麼都好像不太一樣，有些有 index，有些沒有。
有些有解決步驟，知識之間有關聯性，有些的解決步驟沒有。
在研究了幾個版本之後，發現有一些準則是有跡可循的。最常看到的兩種版本是，
1）線性式的 SOP，這類的 SOP 會有審視的步驟，而因為每個審視的步驟中間都有相關性，所以要逐一設計哪個流程先哪個流程後。
舉例來說，帳戶不能登入要先看這人有沒有帳號，沒有帳號就可以直接 case close 了，但是如果他有帳號你才前往下一個步驟他有沒有忘記密碼之類的。
2）一目了然的 SOP，這類的 SOP 每個步驟之間沒有相關性，所以在歸檔的時候比較像是使用手冊，如果你可以直接判定客訴的種類，就可以直接對症下藥。
舉例來說，去逛 Ikea 的時候你很自然的就會知道要到退換貨櫃檯，或是運送櫃檯，每個櫃檯的服務項目是不重複的。
寫了幾個版本之後我就交給學長看。
學長還笑我說我是控制狂喔？為什麼每個格子的大小都拉的整整齊齊的。
但是他覺得我的格式很不錯，所以最後被抄來用。
當下覺得很有成就感，第一次自己能夠把過往的經驗轉換成幫助公司的附加價值，雖然說知道這個 SOP 的設計後可能會害自己失業，但是覺得對團隊有貢獻的感覺真好！
原來我們制定的 SOP 叫做 Knowledge base
Knowledge base 是客服中的一個專有名詞，意思是那些歸納成檔案的知識。
有些時候這個 Knowledge base 不僅限於內部使用，對外的使用者也可以把他輕易地轉換成常見問題的方式來讓客人自己吸收知識找答案。
如果你的 Knowledge base 設計的很完整又很直覺的話其實是可以有效的降低客訴的。
我常常在靈感枯竭的時候都會去參觀其它公司的 Knowledge base 介面來偷偷觀察他們怎麼設計的，像是 hubspot 的幫助介面就設計得非常好，如果你想問社群就去 community，想閱讀常見問題就點選 Knowledge base。
或是你可以根據產品的方式來安排你的資訊，像是 Google 的幫助介面就是依照產品線來區隔。
而 Amazon 就比較直觀，上面找不到答案就直接滑到最下面點選聯絡他們。
太不公平了吧，為什麼正職才有尾牙
做完專案後接近過年，那時候聽說公司有辦尾牙，但是好像約聘不能參加。
是說我自己也沒有多期待吃尾牙，但是這種感覺真的不太舒服，同樣都是公司的員工為什麼我們就是矮人一截。
我才知道原來外商裡頭約聘和正職是有很大的落差的，不管薪資、福利、甚至工作的心情。
後來我們幾個約聘想說不如自己來辦個尾牙，寒酸一點也沒關係。
可能因為我們是公司第一批的客服人員，所以建立起了革命情感，尾牙當晚雖然沒有大獎，沒有紅包，但是大家都吃得很盡興。
算一算也已經進入新產業也快三個月了，不知道自己還能撐多久。
馬上就要過年了，不曉得今年有沒有辦法擺脫服務業過年值班的魔咒呢？
更苦惱的是，我好像沒有什麼錢可以包紅包給自己的小孩，想想覺得有點哀傷。
Comments