第一層 表單
客人看到的樣子
用 Fillout 做的線上訂位表單，封面是店門口的照片，下方直接嵌入當月營業日曆—— 哪天只供晚餐、哪天公休，填表時就看得到。
訂位、確認、點餐、寄信、追蹤——這些事全部由外場一個人處理。所以它被做成了一套會自己跑的流程：六張表單、一個 CRM、一組自動化工作流。
整套系統由六張表單組成，各自負責流程裡的一段。主表單累積了 122 筆送出紀錄。
主訂位表單。122 筆送出紀錄，已鎖定。
英文版。封面寫著 Hi there, Welcome to the reservation system.——十五批國際訪賓不是巧合。
讓客人自己查詢訂位狀態，32 筆使用紀錄。 不用打電話問。
提醒頁，22 筆。
獨立的點餐流程。
舊版付訂流程，留著沒刪——迭代的痕跡。
用 Fillout 做的線上訂位表單，封面是店門口的照片，下方直接嵌入當月營業日曆—— 哪天只供晚餐、哪天公休，填表時就看得到。
表單背後有完整的條件分支：依人數、依是否需要協助點餐，走不同的路徑。
六人以上（含六人）走另一條路徑，接到用餐預付的告知頁。
自己點餐的直接填點餐內容；需要協助的走 NeedHelp，由店家後續聯繫。
表單裡有 33 條運算規則在背後跑，客人只會看到結果。
訂位資料落進 Notion，但它不只是一張訂位表——欄位涵蓋訂位狀態、確認狀態、 是否已寄信、是否已發餐點後續信、是否已回建議、點餐是否完成。
同一份資料切成七個檢視：未成功訂位、要協助點餐、自己點餐、成功、 日曆、看板——每個檢視對應一種當下要處理的事。
CRM 裡還有一張 customers 表，
把每一位客人和他的每一次來訪日期關聯起來。翻開一筆，
看得到這個人 2020 年 11 月來過、2021 年 1 月又來、2021 年 4 月再來。
這不是訂位紀錄，是回訪紀錄——同一個人第幾次走進這扇門。
客人表另外掛了兩個關聯欄位：Google 評論與 iCHEF POS 的顧客資料。
線上訂位、實體 POS、Google 上的評價， 三邊的紀錄被收在同一個人身上。
（客人表含姓名、手機與 Email， 基於隱私不放截圖。）
用 n8n 串起 Notion 與 Gmail：讀取訂位資料 → 展開欄位 → 篩選 → 依條件判斷， 自動產生對應的回信草稿。
需要幫忙配菜的客人，收到的是協助點餐的信。
已完成點餐的，收到確認信與餐點內容。
自己點好的，走另一封。
流程編號是「1-2 一般客人的信件草稿產生」——代表這不是唯一一條， 而是一整組工作流裡的其中一支。
開店初期買過一套現成的線上訂位系統。它處理「幾點、幾位」沒有問題——問題是這間店的餐點必須事先訂， 沒有事先點餐就沒辦法備料，而現成系統沒有這個環節。於是每一筆訂位都要再寄一次信去問要吃什麼、 再確認一次有沒有回、再記一次誰還沒完成。工具沒有壞，是它的假設跟我們的流程不一樣。
2023 年中，我用 Fillout、Notion、n8n 與 Gmail API 自己搭了一套貼合這個流程的系統， 把那段不斷重複的人工確認收進流程本身。
它要解決的從來不是「訂位」這件事本身，而是一個人同時要外場、要回信、要記得誰還沒確認點餐。
餐點需要事先備料，所以點餐必須在訂位時就完成；六人以上要預付， 所以流程得先分流；客人吃完之後還要寄餐點後續信、收建議——這些如果全靠記憶和手動， 在忙的時候一定會漏。
所以它被拆成表單、資料庫、自動化三層， 讓「該做什麼」變成資料庫上的一個檢視，而不是腦袋裡的一件事。