預約系統——
前三篇都是門面，這篇才是真的核心
水電工阿水｜SoloAI AI 數位轉型顧問
前三篇，我們做了寵物旅館、冰品店、冷氣工程行。三個產業、三種設計思路，但它們有一個共同點：都是展示型網站。
展示型網站的工作是什麼？讓客人看到你、了解你、願意聯絡你。做得再漂亮，它本質上是一張名片——一張很精緻的數位名片。
這一篇不一樣。
這一篇要講的是一套真正在處理業務的系統。客人可以自己預約、系統會自動分配師傅、排班即時更新、耗材自動扣庫存、訂單從建立到結帳有八種狀態在流轉。
這不是名片，這是一台機器。而且這台機器的前身，是一套我跟合夥人花了一年打磨出來的舊系統。
這套系統怎麼來的
幾年前的一次聚會上，一位朋友跟我聊到她的困擾。她開連鎖養生館，櫃台人員每天最頭痛的事情是幫客人預約師傅——客人有空的時間、師傅有空的時間、店裡的設備有沒有空，三方要同時對得上。如果遇到非上班時間，電話來來回回喬不定，經常一個預約搞半小時。
我跟她說：「這個可以做成線上預約系統。」
她苦笑著跟我說：「你不知道我們這行的排班有多複雜。」
她告訴我，養生館業界指派有兩套制度：順牌制和插牌制。
順牌制（排隊制）——技師依照既定順序排隊，客人來時依序指派給下一位技師，做完服務後排到隊伍最後。本質上是 FIFO（先進先出）。
插牌制（插隊制／搶單制）——原本有順序，但允許特定條件技師插隊，例如客人指定、技師等級、業績抽成機制、店家策略。本質上是在 FIFO 上加入優先權機制。
順牌制是師傅按照排序輪流被指派給客人，插牌制又是客人指定師傅。聽起來簡單，但實際上師傅之間經常為了排班的公平性爭吵不休。她也聽說很多同業花了幾百萬找軟體公司做系統，結果做出來的東西根本沒人想用。
我問她為什麼。
她說：「軟體公司做完之後，就要我們去配合系統的流程。但我們實際的工作流程不是那樣的。」
這句話我太熟悉了。二十年前我做網路銷售的時候就遇過一樣的問題——軟體開發商只懂軟體，不懂現場。他們預設了一套「應該這樣跑」的流程，但實際上店裡的運作根本不是那樣。最後軟體做完了，員工不想用、老闆不會用，幾百萬就擱在那裡長灰塵。
所以我做了一個決定：我要自己去現場搞懂整套流程。
我花了很長的時間，跟養生館的櫃台人員、師傅、管理階層一個一個聊。從客人打電話預約那一刻開始，到師傅服務完結帳離開，中間每一個步驟、每一個判斷點、每一個可能出問題的環節，我全部記錄下來。然後再把這些真實流程，一步一步轉化成系統的邏輯。
這套系統跑了兩年。兩年裡經過了幾百次的修正，每一次修正都是因為現場又發現了一個「系統跟實際不符」的地方。兩年之後，它終於變成了一套真正貼合現場的預約系統。
後來因為合夥關係結束，系統停止營運了。但那兩年累積的所有業務邏輯和流程設計，全部留在我腦袋裡。
這次，我用 AI 團隊把它重新做了出來。不只復刻了原有的預約和師傅指派流程，還加上了線上自動客服和耗材管理系統。
客人看到的 vs 真正在跑的
這套預約系統最有意思的地方，是客人看到的跟背後在跑的完全不成比例。
客人打開網站，看到什麼？一個漂亮的首頁、四個服務項目、一個三步驟的預約流程。選服務 → 選師傅 → 選時段，三步搞定。整個客戶端只有三個大區塊，比冰菓城還簡潔。
但打開後台，裡面有十四個功能模組。
預約管理、訂單管理、會員管理、排班管理、美容師管理、服務項目管理、設備管理、庫存管理、營收報表、打卡簽到、出勤管理、系統設定、客戶服務、操作指南。
前三篇的展示型網站，所有精力都花在前端——怎麼讓頁面好看、怎麼讓客人有感覺。預約系統剛好相反：前端越簡單越好，因為客人只想趕快預約完；真正的複雜度全部在後台。
這就像你去餐廳吃飯。你看到的是菜單和服務生，但廚房裡有備料區、烹飪區、洗碗區、出餐口，每一個環節都有它的流程。好的餐廳讓你感覺不到廚房的存在，你只覺得菜上得快、味道好。好的預約系統也是一樣——客人覺得預約很簡單，是因為後台的複雜度替他扛住了。
順牌制——聽起來簡單，但它解決的問題一點都不簡單
來講一個後台最核心的功能：順牌制。
客人預約的時候，有兩個選擇：指定某位師傅，或者不指定。如果不指定，系統會自動幫他分配師傅。這就是順牌制——師傅按照排序輪流接客，確保每個人的接客量公平。
這聽起來很簡單，對吧？但如果你真的經營過養生館或美容院，你就知道這件事有多難搞。
師傅之間最容易吵的就是接客的公平性。「為什麼她今天接了五個客人，我才接三個？」「為什麼好客人都被她接走了？」這種爭吵會影響團隊士氣，進而影響服務品質，最後影響客人回流。
順牌制就是用系統來解決這個管理問題。不是老闆說了算、不是誰嗓門大誰接客，是系統按照規則公平分配。
但更有意思的是抽佣比例的設計。系統派客的抽佣比例是 40%，客人指定師傅的抽佣是 50%。為什麼？因為指定代表這位師傅有個人品牌力，她的客人是衝著她來的，所以她應該拿更高的比例。而系統派客的師傅，客源是系統帶來的，店家承擔了獲客成本，所以抽佣比例不同。
這不是技術功能，這是商業規則的數位化。軟體公司做不好預約系統的原因就在這裡——他們只想到「怎麼分配客人」，沒想到「分配之後的利益怎麼算」。這種設計，是你蹲在現場聽過師傅抱怨、看過老闆頭痛之後，才會知道要做的。
耗材管理——把「老闆娘手抄的本子」變成系統
再講一個前三篇完全不會出現的功能：耗材管理。
美甲店要用貼片、美容院要用精油、養生館要用艾草——每一次服務都會消耗材料。傳統做法是什麼？老闆娘拿一本筆記本，手抄庫存。用了多少、還剩多少、什麼時候要補貨，全部靠手寫跟記憶。
我們做的耗材模組有三種追蹤方式，對應三種不同的消耗模式：
第一種，按容量追蹤。比如染劑，一瓶 500ml，每次用多少就扣多少，庫存量用 ml 計算。
第二種，按次數追蹤。比如錫箔紙，一卷可以用 200 次，每次服務扣一次，用完就要換新的。
第三種，按數量追蹤。比如美甲貼片，一盒 10 片，用一片扣一片。
每個服務項目在建立的時候，就可以預先設定會用到哪些耗材、用量多少。客人服務完畢結單之後，系統自動扣除對應的庫存。庫存量低於警戒線，系統會跳出警示。而且耗材管理模組裡直接有供應商的聯絡方式——看到庫存不夠，點一下就可以訂貨。
整條鏈路：服務完成 → 自動扣庫存 → 低庫存警示 → 一鍵聯絡供應商。
這就是「把手動流程變成自動流程」。老闆娘不用再翻筆記本、不用再靠記憶補貨、不用再因為忘記補貨而臨時缺料影響服務。
設備管理——你不會在展示型網站裡看到的東西
還有一個功能值得特別講：設備即時狀態。
美容院的美容床、養生館的泡腳區、美甲店的工作台——這些設備是有限的。當三位師傅同時在服務的時候，哪個設備在用、哪個空著、哪個在清潔中，老闆必須知道。
我們的設備管理介面是卡片式設計。每張卡片顯示設備的名稱和狀態。如果設備正在使用中，卡片上會顯示：哪位師傅在用、服務哪張訂單、剩餘時間倒數。
這個功能在展示型網站裡完全不需要。毛孩旅舍不需要知道犬舍裡的毛巾用到第幾條，冰菓城不需要追蹤冰櫃裡的芒果剩幾顆。但對於一間真正在營運的美容院來說，設備狀態直接影響能不能接下一位客人。
這就是展示型網站跟業務系統的根本差異——展示型網站解決的是「讓客人認識你」的問題，業務系統解決的是「讓你的店順暢運轉」的問題。
踩坑：資料庫密碼寫在程式碼裡的那一天
做業務系統踩的坑，跟做展示型網站完全不同。
展示型網站的坑是什麼？SSL 衝突、品牌名侵權、API Key 外洩——這些問題嚴重，但最壞的情況是網站打不開。
業務系統的坑呢？客人的個資、師傅的排班、店家的營收——這些是真金白銀的資料，一旦出問題就是大事。
我們做資安掃描的時候發現了一個問題：資料庫的連線密碼被直接寫在程式碼裡，而且不是一個兩個檔案，是三十六個檔案。
CTO（首席技術長）在做安全評估的時候，預估這個問題的範圍是零——他認為我們的開發流程應該不會出現這種低級錯誤。結果掃描出來，三十六個。
這就是業務系統的可怕之處：它的程式碼量大、模組多、檔案多，任何一個角落都可能藏著你沒注意到的問題。展示型網站全部加起來可能就幾個檔案，翻一翻就看完了。業務系統？你不做系統性的掃描，根本不知道問題在哪裡。
後來我們花了一整輪的資安修復：把三十六個檔案裡的硬編碼密碼全部改成環境變數、清除 Git 歷史裡殘留的機密字串、跑了二十一個場景的多租戶隔離驗證。
這個坑教會我的是：業務系統不存在「差不多就好」。展示型網站上線之後如果有個小 Bug，客人可能不會注意到。業務系統上線之後如果資料外洩，你的客戶的客戶的個資就全部曝光了。
為什麼軟體公司做出來的東西沒人用？
最後回到開頭的問題。
我那位朋友說的話我一直記得：「軟體公司做完之後，就要我們去配合系統的流程。」
這句話精準地點出了這個行業最大的問題：軟體開發商懂技術，但不懂現場。
他們會做出一套邏輯完美的預約系統，每一個功能都有、每一個按鈕都能點。但櫃台人員用了兩天就不想用了，因為系統的操作順序跟她們實際的工作順序不一樣。師傅用了一週就抱怨連連，因為系統沒有考慮到順牌制的公平性問題。老闆看了報表發現數字對不上，因為系統的結帳邏輯跟實際的收款方式不同。
最後那套花了幾百萬的系統，就安靜地躺在那裡，員工繼續回去用手抄本子。
我做這套預約系統的方法是反過來的：先搞懂現場的每一個動作，再把它翻譯成程式碼。
不是先設計系統再讓客戶配合，是先理解流程再讓系統配合。
這跟我做了二十年水電學到的道理一模一樣——你不會先裝好管線再叫客戶把家具搬開，你是先看過客戶家裡的格局，再決定管線怎麼走。
系統是為了人服務的，不是人為了系統服務的。
AI 團隊在這個案子裡扮演的角色，就是幫我把「腦袋裡的流程知識」變成「真正能跑的程式碼」。我畫不出系統架構圖、寫不了 API、搞不定資料庫。但我知道養生館的櫃台小姐在想什麼、師傅在意什麼、老闆最怕什麼。
AI 把我的經驗變成了系統。而那些經驗，是花了兩年蹲在現場才換來的。
📌 本文是「從零到一：一個人 + 六個 AI 的創業實錄」系列第四篇
✅ 第一篇：毛孩旅舍——用 AI 團隊幫寵物旅館建站
✅ 第二篇：冰菓城——在網路上賣出吃不到的清涼感
✅ 第三篇：冷氣工程行——做了二十年水電的人怎麼做這個行業的網站
✅ 第四篇：預約系統——前三篇都是門面，這篇才是真的（本篇）
👉 第五篇：站群系統——下週上線
🔒 第六篇：壹智科技的誕生
下一篇要講的是另一個完全不同的挑戰——不是幫一間店做一個網站，而是一次管理幾十個網站的內容引擎。這是我們證明 AI 團隊能做到「規模化」的一仗。
本文發佈於「水電工阿水的 AI 轉型日誌」沙龍｜AI 協作實戰
