動手之前
先把資料備齊，不必再多開分頁。
- 先決定好要怎麼營運：線上訂購、餐廳訂位、服務預約，還是幾樣一起。
- 店裡真正的菜單或服務項目、價格、營業時間、人員或桌位規則，以及付款政策。
- 工作區擁有者同意你使用這個專案交付方案或雲端權限內的模組。
你會學到
- 看得懂 CORE、AUTO、方案等級、必要條件和建議項目分別代表什麼。
- 把顧客看得到的元件背後那份資料設定好。
- 把顧客的動作和它在後台產生的紀錄一起測。
- 避免在已經上線的專案上做出會毀資料的模組變更。
01
先想清楚營運流程，再去開模組
看起來很像的兩家店，需要的系統可能完全不同。先決定顧客會產生什麼、東西進來之後老闆要管什麼。
- 顧客要挑商品然後送出訂單，就用線上訂購。
- 客人要照桌位空檔挑用餐時間，就用餐廳訂位。
- 客戶要選服務、指定人員、挑時段、報名課程或付訂金，就用預約與課程。
- 希望訂單和預約自動建立顧客檔案、之後還能拿來服務，就加上顧客模組。
做到這樣就算完成： 你打算開的每一個模組，都說得出顧客要填什麼、可用時段怎麼算、錢怎麼收，以及資料最後會進後台哪裡。
02
打開模組，先看清楚狀態再動手
這個面板會分清楚三種：永遠開著的基礎、被頁面元件點名要用的模組，以及受交付方案限制的選配能力。
- 在左側工具列打開模組，確認這個專案顯示的交付方案。
- CORE 是一定包含的；AUTO 表示現在頁面上有元件正在用它。
- 方案標籤是能不能用的界線，不是裝飾。在瀏覽器版裡，發布當下還是以伺服器端的權限為準。
- 只開店家真的答應要營運和維護的模組。
做到這樣就算完成： 每一個開起來的選配模組，都有指定的負責人、真實的來源資料，也在顧客流程裡有它的位置。
03
必要條件要照做，建議項目看情況
Naratake 會自動把硬性相依補上，也會建議常常搭配使用的模組。必要條件不能省；建議項目用不到就可以關掉。
- 線上訂購一定要有商品目錄和付款，通常還會建議加上顧客。
- 預約與課程一定要有商品目錄，可能還會建議付款和顧客。
- 餐廳訂位可以單獨運作，可能會建議加上顧客。
- 開完模組後，看一下「同時開啟了」的提示；真的用不到的建議項目才關掉。
做到這樣就算完成： 開起來的這組模組沒有漏掉任何硬性條件，選配的建議也跟實際營運計畫對得上。
04
把顧客真的會用到的營運資料填進去
開關打開不等於功能就緒。價格、可用時段、政策和對外的元件，四邊都要一致。
- 商品目錄和線上訂購：填分類、品項、價格、選項、稅金處理、自取或外送規則，以及可下單的時段。
- 餐廳訂位：設定營業時間、桌位數量或容納人數、可訂時段，以及確認方式。
- 預約與課程：設定服務項目、時長、人員班表、時段規則、名額，以及訂金政策。
- 用元件把對應的顧客端區塊放上頁面，再用動作設定相關按鈕。
- 回到上線指南，把商品目錄是空的、營業時間沒填之類的警告處理掉。
做到這樣就算完成： 顧客看到的區塊只會列出有效的品項或時段，送出前顯示的金額也跟預期一致。
05
把店面和後台當成同一條流程來測
最關鍵的證據是：顧客做完一個動作，老闆那邊就出現他預期要管的那筆紀錄。
- 打開預覽 → 店面，實際下一筆測試訂單、訂位或預約。
- 不要只走順利的那條路，錯誤驗證和空資料狀態也要測。
- 把預覽切到後台，到訂單、訂位或預約裡找出剛剛那筆測試紀錄。
- 把測試紀錄照狀態流程走一遍，核對金額、顧客身分和指定的時間。
- 最關鍵的那條路，再用 Mobile（手機版）寬度重測一次。
做到這樣就算完成： 店面送出的資料出現在後台正確的區域、細節無誤，而且能照營運狀態往下推。
06
改動線上模組，要當成資料搬遷，不是改設計
網站上線之後，訂單、顧客、訂位和預約可能已經存在模組專屬的資料表裡。把模組關掉，下一次部署可能就會要求做出會刪資料的結構變更。
- 關掉線上模組之前，先用工作區支援的功能把受影響的紀錄匯出或備份。
- 確認店家已經停掉這條流程，頁面上相關的元件和按鈕也拿掉了。
- 把編輯器對線上網站的警告整段讀完；資料保留計畫還不清楚就先取消。
- 變更核准之後，發布前把店面和後台的完整測試再跑一次。
做到這樣就算完成： 沒有任何線上營運模組是在沒有老闆核准的保留計畫、也沒有驗證過替代流程的情況下被拿掉的。
最後檢查
這幾項全部成立，才算真的做完。
- 每一個模組都對應到真實的顧客動作和負責的人。
- 必要條件、建議項目、交付方案和伺服器權限都檢查過了。
- 商品目錄、排程、名額、價格和政策資料都是真的。
- 在店面做一個動作，後台就出現預期的那筆紀錄。
- 在向工作區申請上線之前，手機版和錯誤狀態的測試都已通過。