ADZ 學習筆記

Ruby/Rails, Startup, Life

晚鳥票經驗 - 縮小解決問題的範圍

| Comments

雖然我是創業幼幼班新手,不過經看過幾間公司的產品失敗,多少也知道一些問題點,即使目前晚鳥票還沒找到一個可行的商業模式,但我對晚鳥票的想法就是「我一定要從中得到以前沒經歷過的體驗」,既然是一種學習,我就慣例的採用常用「遮蓋式」的學習方式。

縮小解決問題的範圍

我們發現高鐵團購是一個吃力不討好的工作,經營的前三個月,我們預估我們能夠消化的極限是一個月 8 - 10 團的量 (240 - 300張票),而且每天面對的是雪片般飛來的信,光是處理票務、回客服信、接電話就消耗掉我們大部份的時間,好幾次看不到前景、沒有正營收、又把自己惹得一身腥,讓我們打算把服務關掉。

但是我認為這是我們管理上的問題,即使這個服務真的無法發展,我們也不能用「沒有前景」的理由,當作我們無法「建立健全機制」的藉口,這是完全兩件事情,即使最後沒辦法找到商業模式,我們至少會學到「如何 tune 每個流程、管理上的細節」。

於是我開始親自回每封客服信,參與處理票務,結果發現:我們的票務處理後台有夠難用、無法即時掌握目前處理狀況、與客戶的互動分散在 Facebook / Email / 電話上,我們不僅無法掌握團購班次、也無法掌握跟客戶間的所有互動。

於是我們導入 UserVoice 這個 CRM,把所有公司電話從網站中拿掉、設定 Email forward 到 UserVoice,批次處理這些客服信,避免電話打斷工作的情況。

並把所有客戶常問的問題建立 FAQ、一開始使用者還是習慣在 Facebook 上問問題,但我們就是不斷丟 Link,讓使用者習慣去網站自己找資料。

最後我們一直調整網站的出貨流程、處理團購流程,調整使用者參加團購流程,調整 Mobile 用戶看到的每一個畫面、避免每個使用者看到的文字有誤解、避免寫讓使用者失去興趣的冗長的文字敘述 ..... etc

我們先把商業模式遮起來,直到今天,在團購這個服務上我們現在一個人可以應付一個月 1000+ 的票量,還有所有客服信即時回應,這過程其實跟 tune server 很像,但更好玩。

總結

以前寫 ACM 的時候,很多問題無法被人腦運算 (同時思考 3+ 維度的問題),把部分問題遮起來並不是逃避,而是釐清的過程,好處是可以避免情緒影響決策。畢竟這世界上很多事情都無法被一次解決,尤其面對複雜的情況,把週邊的小問題解決、就定位,有助於面對最後的考驗。

系列文章

  1. 晚鳥票經驗 - 縮小解決問題的範圍
  2. 晚鳥票經驗 - 勇敢跟使用者收費
  3. 晚鳥票經驗 - 解決使用者的真實問題
  4. 晚鳥票經驗 - 避免導因為果邏輯

Comments

comments powered by Disqus