顧客預約改期不撞期：香港中小企應如何設計流程

先決定改期請求可以改甚麼

改期是修改現有承諾，不是替新預約換個名稱。香港服務企業應先決定誰可提出改期、距離原定時間多近仍可修改、哪位員工或哪間房必須有空，以及訂金或附加服務如何處理。這些都是企業自身條款，不應由軟件推斷出通用截止時間或退款權利。確認前應在同一頁列出原預約、新時段和任何改變的條件，讓顧客看清楚再決定。

進入改期流程的方式也要設計。已登入的顧客可透過帳戶連到預約；電郵連結則可能需要只供改期使用、有效期有限的識別碼，敏感變更還要另作核實。公開頁面不能讓人只靠猜到預約號碼就看見詳細資料。由員工代辦改期，也應使用同一狀態流程和操作紀錄，並記下經辦人。若請求仍待員工批准，「已收到申請」的畫面絕不能令顧客以為新時段已確認。

政策還要說清楚原時段如何處理。若新時段可即時確認，應在新時段安全分配後才釋放舊時段。若需要審批，企業須決定審批期間是否保留舊時段。過早釋放可令顧客兩邊落空，無限期佔住兩個時段又會阻塞容量。若系統確有暫留安排，應設定有限期限並清楚顯示。改期失敗時，除非顧客按列明條款另行取消，原預約應繼續有效。

查核真正容量，再保護變更

畫面上看似空出的時間，只是初步選項。仍須按該預約檢查指定員工、房間、設備、服務長度，以及準備或交通緩衝。若企業使用 Google Calendar，其 FreeBusy 接口可回傳指定日曆的忙碌時段，幫助顯示可選時間；但它本身不會執行企業的預約政策，也不會替任何資源鎖位。顧客按確認時，權威預約系統必須再次判斷容量，因為列表顯示後，別的顧客或員工可能已佔用時段。

應把改期視為一次完整的業務操作：核實原預約屬於該顧客而且仍可改，分配新時段的容量，更新預約時間與資源，成功後才釋放舊容量。任何一步失敗，都要留下可處理且有人負責的狀態，不可顯示兩張已確認預約，或讓顧客完全失去預約。日曆事件可能只是業務紀錄的副本，而非最終權威；系統不一致時要事先定明以誰為準。查空位與最後寫入之間存在時間差，必須處理並發。

若與 Google Calendar 整合，Google 文件說明可用事件 etag 配合 If-Match 條件更新；若事件在讀取後已改變，接口會回傳 412，而不是悄悄覆寫。Google 亦指出完整更新會替換整個事件，所以應先讀取現有事件，再用其 etag 更新，保護其他人改過的欄位。這只保護單一事件的版本，並不會自動阻止兩個不同事件爭用同一員工時段。更全面的容量規則仍須由預約程式負責，例如透過交易或資源層級鎖定。

用一個撞期例子驗證流程

假設顧客已預約星期四下午九十分鐘諮詢，想改到星期六上午，而且必須用同一顧問和房間。列表載入時，星期六看似有空；但第一位顧客按確認前，另一位顧客已預訂該房間。改期程式須重新查核兩項資源，以文字告知新時段不可用，並清楚顯示星期四原預約仍已確認。系統可提供新的可選時段，但不能虛構一個星期六暫留位。確認頁只能呈現伺服器真正完成的狀態。

再假設顧客正在檢視星期六選項時，員工把原預約由九十分鐘改為兩小時。若使用 Google Calendar 事件，etag 檢查可發現事件已變；但如何解決，仍需由企業程式決定。應顯示最新預約資料，要求顧客重新檢視，不能把九十分鐘的改期操作套到已延長的預約上。這只是衝突例子，並不代表 Google Calendar 已提供完整的訂位交易。訂金、服務種類或負責員工改變時，也有同一問題。

另一個邊界情況是網絡停頓，顧客連按兩次確認。第一次請求可能已成功，只是回應遺失；第二次應找回已完成的預約狀態，不可再建立一張預約或再次收取改期費。請求進行時顯示等待狀態，之後讀取權威紀錄才顯示成功。若暫時無法判定結果，應說明正在查核，並提供客服途徑。在舊請求核對完成之前，不應叫顧客再預約一次。

發出一份清楚的新承諾紀錄

改期成功後，畫面及確認訊息應列出服務、新日期與時間、時區、地點或視像會議方式、如適用的服務人員，以及任何付款條件變動，並說明原時段已不再保留。若只是收到申請，必須用不同字句，並明示原預約目前的狀態。Google Calendar 更新接口可選擇向參與者發通知，但這只是整合選項，不能代替企業對顧客的正式確認。應測試顧客是否真的透過預定渠道收到正確通知。

通知可能不按順序送達，顧客亦可能幾天後才打開。每則通知應有預約編號和清楚狀態，並連到需要核實身份的最新預約頁，供顧客查核。不要把敏感諮詢內容放入沒有保護的電郵標題或公開連結。若員工其後再修改預約，新的通知須清楚表明取代舊安排。客服亦應看見同一歷史：由誰修改、何時確認、發出哪一則通知，以及是否仍有未處理例外。

面向顧客的錯誤提示，要具體到足以讓人補救。W3C 的錯誤辨識指引要求以文字指出自動偵測到的輸入問題；一句「發生錯誤」不能幫顧客選另一個時間。應分清楚是依店舖條款不能改期、時段剛被佔用，還是系統暫時故障。各種情況都應保留原預約，並提供相應下一步。若新選項在同一頁出現而沒有整頁跳轉，也要讓屏幕閱讀器讀得到狀態，並維持可預期的鍵盤焦點。

用完整流程驗證政策

驗收應由一張已存在的預約開始，而不是只測空白日曆。測試合資格改期、超出列明時限、兩人同時爭用房間、顧客檢視期間員工修改、重複按確認，以及日曆或通知服務故障。每個情況都要查看預約紀錄、資源分配、顧客畫面和訊息歷史。預期結果須寫明舊預約是否保留、新預約是否已確認，以及付款或員工跟進是否仍待處理。只測試日期選擇器通過，不能證明整個改期流程可靠。

開放自助改期前，請員工根據實際畫面，用清楚英文和繁體中文分別解釋一個成功例子及一個失敗例子。如果「已申請」、「暫留」和「已確認」都顯示同一訊息，就要修正狀態名稱。如果系統尚不能處理兩名顧客選同一資源，相關改期應先由員工協助處理，直至容量控制可靠。核心問題很實際：顧客按確認之後，他真正持有哪個預約，接下來又會發生甚麼事？