ConnectWiz + Google 日曆

已上線的整合

Google 日曆:預約推出去,忙碌時間拉回來

在 ConnectWiz 裡成立的預約會出現在 Google 日曆,取消時也跟著消失;而 Google 日曆上原本就有的活動,會先從可預約時段裡扣掉——所以當您星期四 15:00 要看牙醫,AI 不會把那個時段開出去。

活動推出去 忙碌時間會扣除 每個來源各有角色與方向
Google 日曆 × ConnectWiz
預約 → 行事曆活動
忙碌時段 → 可預約時段扣除
讀取/寫入/雙向/只看忙碌
4
每筆活動推送的欄位——標題、備註、開始、結束。不帶與會者、不發邀請,其他什麼都不出去
3
每個來源三個獨立軸向——把預約餵進來、把預約鏡射出去、擋住可預約時段
Null ≠ 0
「讀不到您的行事曆」永遠不會被當成「您有空」
1
一份預約帳本——行事曆負責鏡射與提供資訊,沒有任何一本會變成主控端

行事曆

它到底能做什麼

Push,帶清理

新的預約會在 Google 日曆裡建立活動,取消時再把活動刪掉。服務人員手上的行事曆,不會比預約日程慢上一天。

忙碌時間也算數

任何一道入口——後台、AI、Flows 或網站元件——開出時段之前,外部活動都已經先從可預約時段裡扣掉。連撞上您私人行程的重複預約,也一併擋下。

同步方向是個設定項

每一個串接進來的來源,都由您決定:只讀、只寫、雙向,或只看忙碌時間——診所的共用行事曆和個人行事曆因此可以各司其職,不會互相打架。

技術細節

不會讓您重複預約的同步語意

兩個權限範圍,就只有兩個

Google 這一側的串接只要兩項權限:活動管理,以及 free/busy 讀取——沒有別的。它寫入您指定的那本日曆,並從您勾選的日曆讀取忙碌時間。

角色是三個軸向,不是一個下拉選單

每個來源都由您設定三件事:要不要把預約餵進來(從不、一次性匯入,或持續匯入)、預約要不要鏡射出去,以及它的忙碌時間要不要擋住可預約時段——診所的共用行事曆和個人行事曆,可以扮演完全不同的角色。

必要之處失敗即關閉

只負責擋住可預約時段的行事曆,讀取失敗時一律失敗即關閉——忙碌時間未知就擋下預約,而不是放行讓它撞期。把預約餵進帳本的來源則失敗即放行。這條線畫錯,是行事曆同步裡代價最高的一個錯誤,所以它是一條規則,不是當下的心情。

連線會自我修復

出錯的連線會被標記起來,並附上原因——下一次成功讀取就自動解除標記。故障結束之後,不需要有人跑來手動把勾勾取消掉。

事件內容最精簡

落進您行事曆裡的,就是預約類型的名稱、訪客的姓名與備註,以及時間——不發與會者邀請、不帶會議連結、不覆寫提醒設定。要不要吵,仍然由您自己的行事曆軟體決定。

衝突有明訂的處理規則

等雙向編輯上線時,每個來源早就帶著一套衝突處理規則——保留給真人判斷(預設值,同時也會暫停提醒)、以我們這邊為準,或以對方為準,落敗的那個版本會留下來並顯示出來。規則在需要之前就先講明,因為事故當下才臨時補一套衝突規則,正是資料不見的典型過程。

設定方式

串接方式

01

串接 Google 日曆

用 Google 帳號登入,挑出要串接的日曆。

02

指定它的角色

讀取、寫入、雙向,或只看忙碌時間——每一本行事曆分開設定。

03

到處都能預約

後台、AI、Flows 或網站元件——每一道入口看到的,都是同一份扣除過的可預約時段。

搭配起來更好用

能和什麼搭配

預約引擎

可預約時段、緩衝時間、提前預約期限,以及不會重疊的保留機制,全都住在: 預約系統 ——行事曆負責把真實情況餵給它。

Wiz 安全地預約

對話裡的 AI 客服 ——只給出扣掉忙碌時間之後仍然成立的時段;擋下重複預約的是資料庫層的約束,不是祈禱。

CRM 那邊的日程

在用 Estesoft Stella 嗎?它的日程和您的行事曆,都從同一份可預約時段裡扣除——見 Stella 整合。

安全與保證

無聊但管用的保證

權限範圍最小化

這個串接只要行事曆的存取權——不要信箱、不要聯絡人、不要雲端硬碟。token 靜態加密存放,並且自動更新。

事件始終是您的

讀取忙碌時間只拿時間,不拿內容——計算可預約時段需要知道的是您沒空,而不是為什麼沒空。

解除串接很乾淨

移除串接會立刻停止同步;已經鏡射到您行事曆裡的活動仍然屬於您,要留要刪都由您決定。

不加修飾的細則

邊界,寫清楚

帳本留在我們這邊

不論串接了哪些行事曆,預約帳本始終是 ConnectWiz 自己的資料表——行事曆是鏡子,也是來源,但永遠不是主控端。這是一個設計立場,我們把它寫出來。

提醒由我們發,不靠行事曆

預約提醒是從 ConnectWiz 發出去的——電子郵件,設定過的話還有簡訊——而不是靠行事曆通知,所以那些從來不開行事曆邀請的訪客也收得到。特地寫出來,是因為兩套提醒系統一起開火,比只有一套更糟。

Google 日曆 FAQ

直接的回答

更多內容見完整的 FAQ, 也可以直接聯絡我們。

預約會以活動的形式推出去(取消時一併移除),忙碌時間則拉進來,從可預約時段裡扣掉。每個來源各自帶著自己的角色——讀取、寫入、雙向,或只看忙碌時間。

不會——可預約時段是扣掉外部忙碌時間之後才算出來的,重疊的保留則由資料庫層的約束直接擋掉,任何一道預約入口都繞不過去。

哪一個掌握真正的可預約時段,就串哪一個——服務人員常見的做法,是把診所的共用日曆設為鏡射目標、個人日曆設為只看忙碌時間,再靠每個來源各自的角色設定讓它們不打架。

一筆以預約類型命名的活動,裡面放著訪客姓名和備註,時間就是預約的時間——成立時建立,取消時移除。不會從您的行事曆發出任何與會者邀請,行事曆裡其他東西也不會被動到。

誠實的串接,勝過響亮的串接。

這裡的每一個整合,都照它實際的行為來描述——資料方向、歸屬權和限制,一併寫清楚。