概念地圖・禮賓與綠野仙蹤光譜
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：創業
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
禮賓與綠野仙蹤光譜：先用人驗假設，再花錢自動化
新服務上線的第一天，客人在螢幕上點完、按下送出，畫面回一句「已收到」。那句話背後可能是一套系統，也可能是一個人坐在辦公室裡，把單子一張一張抄進廚房的舊機器。禮賓與綠野仙蹤光譜畫的就是這條路：從創辦人親手服務每一位客人，到前端看起來全自動、後台其實是人在補完，再到規則接手大部分、人只處理例外，最後才是真的系統。有人盯著它，是因為它把「什麼時候該花錢寫程式」這種模糊的判斷，換成一個可以按天算的量——後台那個人今天被吃掉幾分鐘。
光譜四站，後台的人做什麼
把四站攤成一張表，最後一欄才是該盯著看的地方——每一站替你問的問題都不一樣。
| 站別 | 後台是誰在做 | 每張單的人工 | 這一站在測的假設 |
|---|---|---|---|
| 全人工禮賓 | 創辦人自己接單、自己做完，客人知道對面是人 | 300 秒 | 有沒有人願意掏錢買這件事 |
| 綠野仙蹤 | 前端已經自動，輸入與判斷還是人在後面補 | 150 秒（單量一漲就吃滿整晚） | 客人會不會照著設計好的流程走完 |
| 半自動 | 規則跑掉大部分，人只接例外 | 40 秒 | 例外會不會愈跑愈少 |
| 真系統 | 系統自己跑，人退到維運 | 10 秒 | 量放大之後還撐不撐得住 |
秒數遞減只是表面。真正決定你該停在哪一站的，是最後那一欄還有沒有東西沒問完——假設還沒驗完就急著往右，你花的錢是在把一個還沒被證實的流程灌進水泥；假設早就驗完還賴在原地，你買的答案就開始重複計費。第二站那格警示不是隨手標的：它是四站裡唯一「兩邊都在改善、人卻沒有被放出來」的位置。
三個訊號告訴你該不該往右移
底下三個訊號都拿同一個示意場景來說：一家自助點餐機系統商，第一個客戶的單子每天晚上由工程師手動補完。
一、人力頂著的那一段，正在替你問什麼。那位工程師每天晚上手動輸單，表面上是「系統還沒寫好」。實際上他在替公司問一件事：一家店願不願意讓一台陌生的機器站在門口收單、廚房願不願意照著它出菜。這個問題寫程式回答不了，只有真的收到單、真的出了菜才知道。所以先分清楚，後台這雙手是在補技術債，還是在買一個買不到的答案。自問：我現在用人力頂著的那一段，測的是哪一個還沒被驗證的假設？
二、假設驗完了，會長出一個看得見的樣子。那家系統商的答案出現在第三週：店家自己把機器搬到更顯眼的位置，還問能不能加第二台。那是行為——比問卷上的任何分數都硬。行為一旦出現，工程師每晚做的事就變質了：同一個答案買了第二次、第三次，多出來的只有體力。假設驗完的訊號長在客戶身上，他開始把你的東西當成日常，用起來不再像在試用。自問：那個假設驗完了沒有，我怎麼知道？
三、把客戶數乘上去，先算那個人的工時。系統商簽第二家、第三家店之前，先拿計算機按一次：一家 30 張單、每張 4 分鐘，三家就是 6 小時，等於憑空多出一個全職晚班。這個數字要在簽約前按，等到人開始加班才按就晚了。工時算出來，還會順手指出下一段程式該寫哪裡——指到的多半是最重複的那一段，難度反而排在後面。自問：先算一次再多接十個客戶時，後台那個人的工時會變成多少？
一家自助點餐機系統商的第一個客戶，光譜上走一遍
底下這家台灣中部的自助點餐機系統商，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實公司。（招牌圖上那組秒數是光譜本身的示意刻度，底下這家算的是它自己的帳。）
- 第一站・全人工禮賓：第一個客戶是台中一家日式定食店，每天 30 張單。點餐機的畫面做好了，後面沒接上廚房系統，工程師每天晚上手動輸入，每張 4 分鐘——一天 120 分鐘，整整兩小時。兩小時換到一個答案：客人真的會站在機器前面點完餐
- 第二站・綠野仙蹤：又上了兩家店，每天 80 張單。前端自動送單、後台由人對帳補完，每張壓到 90 秒。單量長到兩倍多，每張快了一半以上。80 張 × 90 秒還是 120 分鐘，那個人的下班時間一分鐘都沒提早
- 第三站・半自動：規則引擎上線，對得上的單直接進廚房。每天 200 張，其中 25%（品項改名、備註加點、臨時退單）對不上，50 張要人看、每張 60 秒——剛好一天 50 分鐘。工時第一次真的掉下來，而且掉的是重複的那一半
- 第四站・真系統：例外類型收斂到 4%。每天 400 張、16 張要人看、每張 60 秒，一天 16 分鐘。16 分鐘不是零；那 4% 會一直在，只是換人管而已
這條路走了十一個月，真正的轉折點是第二站那個沒有變的數字。單量長到兩倍多、每張快了一半以上，後台那個人的兩小時卻原封不動——省下來的秒數，全部被新增的單量吃回去了。那就是該往右移的訊號：效率改善的速度追不上單量成長的速度，人就永遠釘在那個位置上，而且釘得很體面，因為每一張單看起來都更快了。回頭看，第一站那兩個小時反而花得最值：它用一個晚上的體力，換到一個寫再多程式都問不出來的答案。以上為說明結構用的示意情境，僅供理解框架之用。
這條光譜什麼時候會騙你
- 客人看到的一樣，不代表你學到的一樣。後台是人的時候，人會自動把破掉的地方補起來：備註看不懂就打電話問、品項對不上就自己改一個、單子漏了就重打一張。客人的體驗因此好得不真實，你驗到的其實是「旁邊有人補的時候，這個服務可用」。那些補救動作本身就是需求規格，別當成雜事丟掉——把每一次出手的原因記下來，往右移的時候才不會把最關鍵的那段判斷漏掉。
- 光譜看起來像路線圖，但有些服務不該走完。愈往右，單位成本愈低，可調整的空間也愈小。高單價、每一單長得都不一樣的生意——整套導入、需要現場判斷的服務——停在第一站或第二站可能才是對的商業模式，硬要自動化只會把最值錢的那段判斷力洗掉。判斷的依據是這一站的成本結構撐不撐得住，離終點還有幾格跟該不該走沒有關係。
- 往右的成本常被算成一次性，真正的帳在例外率。規則引擎寫完不是結束，例外會一直長出來：新品項、促銷組合、臨時改單。同樣是每天 400 張，例外率從 4% 回到 12%，人工就從一天 16 分鐘變成 48 分鐘，一次改版吃掉半年的效率。往右移之前先問清楚：例外從哪裡來、誰負責讓它收斂。沒有人管這件事，光譜會自己往左邊滑回去，而且滑的時候沒有聲音。
後台那個人，遲早要被換掉
往右一格，你就少了一雙會臨場補救的手。
《痛點》那把尺問的是四件事：誰在痛、痛多深、你的方法真能讓他不痛嗎、他願意為此付多少。這條光譜幫得上其中一段——它讓你在還沒花錢寫程式之前，先用人把答案問出來。它也很誠實地畫出自己的邊界：這張圖畫得出後台那個人每天被吃掉幾分鐘，畫不出他補救的那一刻，客人心裡是鬆了一口氣、還是覺得本來就該這樣。前者是工時，後者才是痛。很多團隊在第二站住太久，原因往往是那個人補得太好——痛被他一手吸收掉了，儀表板上一片平靜，客訴也乾乾淨淨。今晚就能做的一件事：打開後台那個人這個月的介入紀錄，把每一次手動出手的原因抄成一行，看哪一個原因重複最多次。重複最多的那一條，就是下一段程式該落地的地方，也是客人真正在痛的那一格。
常見問題
綠野仙蹤和全人工禮賓差在哪裡？
差在客人看到什麼。禮賓階段客人知道對面是人，你可以邊做邊問、邊改；綠野仙蹤階段客人以為前面是一套系統，後台才是人在補完。用途也跟著不同：禮賓在問「這件事有沒有人要」，綠野仙蹤在問「做成產品的樣子之後，人還會不會照著用」。順序寫反很吃虧——還沒確定有人要就先包裝成系統，你會拿到一堆關於介面的意見，卻拿不到那個最貴的答案。
後台是人，算不算欺騙客人？
界線在承諾：你答應的是結果（十分鐘內出單、資料不會錯），沒有答應這件事由機器完成。客人付錢買的是結果。真正要小心的是兩件事。第一是資料：人看得到的欄位就是人看得到，該寫進條款，經手的人也該簽保密。第二是速度承諾：人做不到的服務水準不要寫進合約——凌晨三點也十分鐘，那是系統才敢答應的話。
一站要待多久才該往右移？
別用月份當標準，用兩個條件同時成立當標準。條件一：這一站要問的假設已經有行為上的答案，客人用行動回答過你，而不只是在訪談裡說好。條件二：再多接幾個客戶，後台工時就會超過一個人能承擔的上限。只滿足第一個，你會太早自動化一個還會再改三次的流程；只滿足第二個，你會把一個沒被驗證的流程用程式鎖死，之後改一次要付兩次錢。
小團隊沒有工程師，還能用這條光譜嗎？
可以，而且更該用。表單加試算表就是很好的前端，人坐在後面補完，客人完全感覺不出來。往右移的第一步通常是把最重複的那一段交給現成工具（自動排程、串接、通知），不必先養一個工程師。真正的門檻通常出在紀錄上：有沒有人每天寫下「這一單為什麼要我出手」——那份紀錄就是你將來的規格書，沒有它，找誰來寫程式都一樣。
你正在做的那個新服務，後台現在是誰在跑。把這個問題問出口之後，通常會接著撞上兩件事：第一塊要做多小才夠、以及要先做給多小的一群人看。前者可以接著讀最小可行產品的切法，那張圖畫的是一整條蛋糕切片；後者去看最小可行受眾，那一頁問的是那群人可以小到什麼程度。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。