資源模型
場地、設備、人——像現實那樣交叉在一起
「有空」是一個三方問題：服務人員、場地和設備必須同時空著才算。多數預約工具只模型化其中一個軸向，剩下的交給運氣；這一套模型化的是三者的交集。
角色與容器
一筆預約會依角色同時占用多項資源——場地、設備、服務人員——而容器關聯的意思是：被占用的場地裡的設備，也會正確地變成不可用，即使根本沒有人預約那台設備。
是約束，不是規則
防止重疊這件事，以排除約束的形式住在儲存層——兩個互相競爭的請求不可能同時成功，因為第二次寫入在物理上就被拒絕了。規則引擎給的是承諾；約束給的是保證。
容量以單位計算
一堂八個位子的課，就是八個單位，不是一個計數器——所以「剩一個」講的是某一個具體的單位，退款也不會把算術弄壞。
適用條件，另外算
「這個場地做不做得了這項服務」自成一張對應表，和占用狀況分開處理——所以空著但不對的資源永遠不會被開出來，而且原因查得到。
行事曆同步
您的行事曆，會從可預約時段裡扣掉
預約推出去
預約會以活動的形式出現在 Google 日曆、Outlook 行事曆或 Apple 行事曆——取消時就跟著消失。服務人員手機上的行事曆，不會比日程表慢上一天。
忙碌時間拉進來
外部活動會從可預約時段裡扣掉——當您個人的 Google 日曆上星期四 15:00 已經排了牙醫，AI 就不會把那個時段開出去。
每個來源各有角色與方向
每一個串接進來的來源都有自己的設定——只讀、只寫、雙向，或只看忙碌時間——診所的共用行事曆和個人行事曆因此可以各演各的角色，不會互相打架。
提醒與維運
後續追蹤，交給自動化
真的會發出去的提醒
客戶的確認與提醒，會依您設定的提前時間發出——電子郵件，需要的話再加上簡訊——另外還有新預約的員工通知。「之後再跟進」不用再靠記性。
歷史可以搬進來
從別套 CRM 換過來？移轉引擎會把您既有的預約歷史匯進同一本帳本——日程表不會失憶地從零開始。
不加修飾的細則
在您照著它排計畫之前就講明
還沒有獨立的預約連結
自助預約目前住在網站聊天元件裡——還沒有那種 Calendly 式、可以用電子郵件寄出去的公開預約頁。如果那是您主要的做法，告訴我們；這會影響藍圖的順序。
外部 CRM 裝得下的比較少
一筆預約寫進已串接的 CRM 時，設備和耗材的細節不一定活得下來——供應商的 API 沒有開放那些軸向，而同步會把漏掉的部分講出來，不是安靜地丟掉。
帳本永遠在我們這邊
不論串接了哪些行事曆和 CRM，預約帳本始終是 ConnectWiz 自己的資料表——外部系統是來源，也是鏡子，但永遠不是主控端。這是一個設計立場，我們把它寫出來。