行事曆
它到底能做什麼
Push，帶清理
新的預約會在 Apple 行事曆裡建立活動，取消時再把活動刪掉。服務人員手上的行事曆，不會比預約日程慢上一天。
忙碌時間也算數
任何一道入口——後台、AI、Flows 或網站元件——開出時段之前，外部活動都已經先從可預約時段裡扣掉。連撞上您私人行程的重複預約，也一併擋下。
同步方向是個設定項
每一個串接進來的來源，都由您決定：只讀、只寫、雙向，或只看忙碌時間——診所的共用行事曆和個人行事曆因此可以各司其職，不會互相打架。
技術細節
不會讓您重複預約的同步語意
CalDAV 搭配 App 專用密碼
Apple 對第三方開的那道門是 CalDAV：您在自己的 Apple ID 裡產生一組 App 專用密碼（真正的密碼從來不會離開 Apple），活動就透過這項開放標準，對您的 iCloud 行事曆集合讀取與寫入。
角色是三個軸向，不是一個下拉選單
每個來源都由您設定三件事：要不要把預約餵進來（從不、一次性匯入，或持續匯入）、預約要不要鏡射出去，以及它的忙碌時間要不要擋住可預約時段——診所的共用行事曆和個人行事曆，可以扮演完全不同的角色。
必要之處失敗即關閉
只負責擋住可預約時段的行事曆，讀取失敗時一律失敗即關閉——忙碌時間未知就擋下預約，而不是放行讓它撞期。把預約餵進帳本的來源則失敗即放行。這條線畫錯，是行事曆同步裡代價最高的一個錯誤，所以它是一條規則，不是當下的心情。
連線會自我修復
出錯的連線會被標記起來，並附上原因——下一次成功讀取就自動解除標記。故障結束之後，不需要有人跑來手動把勾勾取消掉。
事件內容最精簡
落進您行事曆裡的，就是預約類型的名稱、訪客的姓名與備註，以及時間——不發與會者邀請、不帶會議連結、不覆寫提醒設定。要不要吵，仍然由您自己的行事曆軟體決定。
衝突有明訂的處理規則
等雙向編輯上線時，每個來源早就帶著一套衝突處理規則——保留給真人判斷（預設值，同時也會暫停提醒）、以我們這邊為準，或以對方為準，落敗的那個版本會留下來並顯示出來。規則在需要之前就先講明，因為事故當下才臨時補一套衝突規則，正是資料不見的典型過程。
設定方式
串接方式
串接 Apple 行事曆
用 Apple ID 產生的 App 專用密碼，透過 CalDAV 串接。
指定它的角色
讀取、寫入、雙向，或只看忙碌時間——每一本行事曆分開設定。
到處都能預約
後台、AI、Flows 或網站元件——每一道入口看到的，都是同一份扣除過的可預約時段。
安全與保證
無聊但管用的保證
權限範圍最小化
這個串接只要行事曆的存取權——不要信箱、不要聯絡人、不要雲端硬碟。token 靜態加密存放，並且自動更新。
事件始終是您的
讀取忙碌時間只拿時間，不拿內容——計算可預約時段需要知道的是您沒空，而不是為什麼沒空。
解除串接很乾淨
移除串接會立刻停止同步；已經鏡射到您行事曆裡的活動仍然屬於您，要留要刪都由您決定。
不加修飾的細則
邊界，寫清楚
帳本留在我們這邊
不論串接了哪些行事曆，預約帳本始終是 ConnectWiz 自己的資料表——行事曆是鏡子，也是來源，但永遠不是主控端。這是一個設計立場，我們把它寫出來。
提醒由我們發，不靠行事曆
預約提醒是從 ConnectWiz 發出去的——電子郵件，設定過的話還有簡訊——而不是靠行事曆通知，所以那些從來不開行事曆邀請的訪客也收得到。特地寫出來，是因為兩套提醒系統一起開火，比只有一套更糟。