香港工作室遇到 Double Booking 點算：首十分鐘處理、六個成因同真正修正方法

呢個係前台 runbook。最好平時已經睇過一次，唔好等到客人企喺門口先第一次讀。

第一步，先確認兩個預約都真係存在。同一個客人出現兩次，係 duplicate booking，處理方法唔同；兩個唔同客人同一個時段，先係呢篇講嘅 double booking。

第二步，按建立預約嘅時間先後處理，唔係按邊個先到、邊個大聲、邊個係熟客、邊個買最大套票。最早 book 到嗰位保留原本時段。否則問題會由一個營運錯誤，變成「工作室偏心邊個客」嘅信任問題，後者更難救。

第三步，喺被影響客人到達之前打電話。WhatsApp 係快，但電話係應該做嘅基本交代。如果客人已經出門，仍然要打；如果無人接，十分鐘內 voicemail 加 WhatsApp／SMS 係最低要求。

講得通時，按呢個次序俾三個選擇：今日同一時間由另一位同事處理、今日最近一個時段仍然由原本同事處理、或者聽日同一位同事同一時間再安排，另加一個小補償。選項清楚，大部分客人都會喺頭兩個之中揀。

如果兩位客人都已經到左現場，帶被影響嗰位去一個安靜、其他客人聽唔到嘅位置講。唔好喺另一位客人面前道歉。被保留時段嘅客人唔應該覺得自己準時到反而有錯，被改期嘅客人亦唔應該喺公開場合被「降級」。

下一個預約入黎之前，先記低事件資料：每個預約由邊個渠道建立、建立時間、邊個確認、當時有無 warning。之後要查根本原因，就靠呢啲資料。到星期五先憑記憶重組，通常已經唔準。

四小時內發一個書面 follow-up，即使客人電話入面好客氣都要做。呢個訊息代表工作室認真處理事件，亦方便客人需要向同事、家人或同行朋友解釋改期時轉發。

除非上游原因已經真係修好，否則唔好承諾「以後唔會再發生」。一個之後又被打破嘅承諾，通常比原本撞期更傷信任。

以下三段可以當起點，再按你間 studio 嘅語氣改。重點係真誠、專業、唔推卸，亦要令客人即刻感覺到工作室知道下一步點做。

客人未到前電話：「Hi [Name]，我係 [Studio] 嘅 [Your name]。唔好意思，我哋發現你今日 11:30 Karen 嘅預約同另一個預約撞左時間。依家我可以即刻俾三個安排你揀：11:30 由另一位同事幫你做、Karen 今日 12:15 幫你做、或者 Karen 聽日同一時間幫你做。邊個安排對你最方便？」

即日 follow-up 訊息：「Hi [Name]，多謝你今朝咁體諒。我哋已經幫你確認聽日 11:30 Karen 嘅時段，另外加左 15 分鐘頭肩放鬆，費用由我哋承擔。聽日見。- [Your name]」

電話轉 voicemail 時同步發訊息：「Hi [Name]，我哋係 [Studio]。你今日嘅預約有一個排程問題，需要盡快同你確認安排。麻煩你方便時打返 [number]，我 10 分鐘內亦會再 WhatsApp 你。多謝。」

三件事要避開：唔好開名怪責某位同事，唔好一開始就講折扣而唔先安排改期，亦唔好用「如有不便，敬請原諒」呢類冷冰冰句式。客人聽到嘅通常係：你哋將我嘅時間當成一般投訴處理。

停喺最合適嗰一級就夠。除非客人明顯升級投訴，否則唔好一開始就過度補償。補償過大會令客人覺得：你哋自己都預左呢件事會繼續發生。

常見成因有六個。大部分工作室做得耐都會撞過至少幾個。頭五個應該由系統幫你預防，第六個至少要由系統清楚 warning。

第一個係兩個渠道同時搶同一個位。前台 10:30:00.4 幫電話客人 save 左預約；網站 booking widget 10:30:00.7 又確認另一個客人入同一個時段。兩邊都成功，因為系統將兩次寫入當成獨立動作。結果一個時段有兩行 confirmed booking。香港工作室常見渠道多：電話、WhatsApp、IG DM、網站、ClassPass 類平台、同事 app；越多渠道同時跑，熱門時段同宣傳後一星期越容易出事。

第二個係 calendar sync lag。Google、iCloud、Outlook 呢類第三方日曆唔係每秒同步，通常係每一至十五分鐘跑一次。呢段空窗期內，個人日曆事件可能未 import 到 booking system。治療師 13:15 先同步到牙醫 appointment；但 13:00 至 13:15 之間，客人已經 book 左 13:30。衝突係真實存在，只係系統當時未知道。

第三個係多資源衝突。一個按摩、物理治療、普拉提私人課或者美容療程，唔只係一位同事加一個時間。佢仲牽涉一間房、一張床、一部機、一件器材，甚至一個清潔時段。好多 scheduler 只檢查同事有無空，於是 Karen 14:00 有空就接受預約，但 2 號房同時間俾兒童瑜伽班用緊，系統根本無問過間房。

第四個係 buffer 設定唔一致。Deep Tissue 60 分鐘因為最早建立，清場 buffer 係 0 分鐘；Hot Stone 60 分鐘半年後加入，有 15 分鐘清場。客人 book Deep Tissue 11:00 完，另一個客人 book Hot Stone 11:00 同一間房開始。每個服務單獨睇都符合自己規則，但間房實際上需要 15 分鐘重疊時間。

第五個係人手 override。Wong 太太八年黎都係星期六 3 點到。星期二有新客人 online book 左星期六 3 點。到星期五，有同事手動將 Wong 太太拖返「佢一向嗰個位」，新客人就被擠走。系統可能有 warning，亦可能 warning 太細聲；但只要 override 成功，問題就留到新客人上門先爆。

第六個係候補自動補位超過容量。學生由星期二 7 點改去星期四 7 點。系統當成「星期二取消」加「星期四新預約」。候補見到星期二有空位，即刻自動補一個人上去。但如果同步順序或容量檢查唔夠嚴，星期二 18 人房可能變成 19 人，因為每個單獨事件睇起身都合法。

下面對應返上面六個成因。邊個咬到你，就先修邊個；唔需要一個週末內改晒所有設定。目標係逐個 root cause 拆走，令同一個原因唔會第二次造成事故。

對付 race condition，要用會喺客人嘗試預約一刻鎖定時段嘅系統，而唔係等到最後 confirmed 先鎖。如果現有軟件有 draft hold，但又唔能夠清楚處理過期同釋放，寧願關掉，因為呢種半鎖定位經常製造更多衝突。

對付 calendar sync lag，將同步間隔設到兩分鐘或以下。更好係用 push-based sync，第三方日曆一有變更就通知排程系統。個人日曆 import 入黎嘅事件要當 blocking event，而唔係只做參考資料；否則系統永遠有機會當同事仍然有空。

對付多資源衝突，每個預約都應該定義為同事、房間、器材、客人、時間，而唔係只得同事加時間。單人房、治療床、Reformer、拍攝房、羽毛球場、琴房，全部都應該係可被 block 嘅 resource，而唔係 booking 上面一個 label。

對付 buffer mismatch，每個服務設定清場、換房、準備時間，並且每季 audit 一次。每新增一個服務，都係 default setting 出錯嘅機會。每三個月用 30 分鐘睇一次服務設定，成本好低，但可以避開事後好難查嘅撞期。

對付 manual override，任何會擠走現有預約嘅 override，都要一 click 確認加必填原因。唔係完全禁止，而係加一個清醒位。同時要即時通知被影響客人，因為只有客人收到通知，靜悄悄嘅 override 先會浮上水面。

對付候補超容量，改期要當成單一 atomic operation，而唔係取消加新預約兩件事。候補補位一刻要重新檢查即時容量，唔好用兩秒前 cache 住嘅數字。如果你用緊嘅軟件無呢啲設定，問供應商候補係 event-driven 定 polled。Polled waitlist 通常就係容量超出嘅位置。

好多 scheduler 出錯時只會講：「This time slot is unavailable。」對前台黎講，呢句等於無講。係同事撞期？房間撞期？Google Calendar import 左 blocked time？清場 buffer？班堂已經滿？同事最後只會打開日曆、拉上拉落、估一個原因，然後可能直接 override。下一次 double booking 就係咁開始。

真正認真處理撞期嘅系統，應該喺前台查之前已經講清楚係邊樣撞。佢應該話：呢位同事同時間已有預約、呢間房或器材已被使用、呢位客人自己同時間已有另一個預約、或者呢堂已經到容量上限。四個訊息，四種處理方法。知道邊個原因，前台可以五秒內解決；唔知道，就好容易因為趕時間而 override。

同樣清楚度亦應該出現喺 audit log。每一次被擋低嘅預約嘗試，都應該記低係邊個野 擋住：員工、資源、客戶、人數上限。睇一星期 log，你就知問題係人手排程、房間爭用，定係客人自己喺幾個渠道重複 book。籠統嘅 unavailable error，只會產生籠統 log，最後無 diagnosis，下個月又再發生。

一次 double booking 係事故；同一個 root cause 一個月內出現兩次，就係系統仲未修好。出事後第一個月每星期查一次，之後每月查一次。

第一，衝突兩邊分別由邊個渠道建立？前台、網站 booking widget、同事 app、第三方平台、imported calendar。如果兩邊都來自同一渠道，bug 多數喺該渠道入面；如果來自唔同渠道，bug 多數喺同步或鎖定位機制。

第二，兩個預約建立時間相差幾耐？少過一分鐘，多數係 race condition；幾分鐘至幾小時，多數係 sync lag；相隔幾日，多數係 manual override。

第三，系統當時有無 warning？如果有，邊個見到？有無 override？如果無，代表 warning logic 漏左呢個情況，真正要修嘅就係呢度。

第四，有無人手 override？如果有，當時填左咩原因？如果無記錄原因，下一步就係改流程，令下次必填。長期儲落黎嘅 override reason，會係你訓練同事或重寫政策最有用嘅資料。

第五，同一個 root cause 過去 30 日有無出現過？如果有，修正唔可以只係單次補鑊，而係今個星期要落地嘅流程或設定改動。

Bookjor 嘅設計重點唔係只問「呢個時段有無空」，而係問「到底邊樣野撞左」。當一個預約被拒絕，工作室可以睇到係邊樣野擋住：同事、資源、客人，定係人數上限，而唔需要打開日曆估。呢種清楚度亦會入到 blocked-attempt log，令每星期 review 似睇紀錄多過靠記憶還原一日發生過咩。

Bookjor 預約預設包含同事、資源、客人同時間，所以房間、器材、課室呢啲多資源衝突唔會輕易漏過。如果預約撞期，Bookjor 會擋左並顯示原因，等同事揀一個真正可用嘅替代時段，而唔係夾硬塞入同一個位。

呢啲唔會令人為錯誤完全消失。真正價值係令一個潛在既撞期唔會留喺系統入面，直到客人走到門口先爆。Bookjor 只係將衝突提前浮現出黎，等團隊可以早一步處理。