指南
如何防止重複預訂
Kasura 透過把預訂日期與同一物件上每一筆有效預訂比對，並在重疊時阻擋儲存，來防止重複預訂。
重複預訂為何發生
重複預訂發生在兩位顧客對同一車輛或客房持有重疊主張時。很少是一個清楚的失誤——更常見的是忙碌班次裡憑記憶操作、已經落後於現實的共用試算表，或兩個人同時處理同一物件的請求卻看不到對方的工作。能建立預訂的人數越多、請求進入的通路越多，風險越大。
Kasura 如何阻止已知衝突
每次建立預訂或更改日期，Kasura 都會在允許儲存前把請求期間與該物件的其他預訂比較。這發生兩次：一次在填寫表單的介面裡，讓人員立刻看到問題；另一次在儲存真正寫入的瞬間，讓數秒後操作的第二個人無法塞進衝突預訂。會與既有預訂重疊的儲存會被直接拒絕，而不只是標為警示。
可訂檢查
建立預訂時，所選物件的日曆會依既有預訂把每一天標為可訂、部分可訂或不可訂。一段剛好在另一段開始時結束的期間視為可訂，因為兩者並不真正重疊。人員在嘗試儲存前就能看到這次即時檢查，從而有機會改選日期，而不是送出表單後才發現衝突。
預訂衝突
預訂衝突是 Kasura 對同一物件上期間重疊的兩筆預訂的稱呼。只有仍計為有效的預訂——已預留、進行中、已入住、逾期或其他未解決——才能造成衝突。已取消、標為未到或已完成的預訂會從檢查中排除，該狀態一經設定，日期就立刻可供他人使用。因此被拒絕儲存時，人員看到的是物件在所選期間已被預訂的直接說明，而不是籠統失敗。
Workspace 界線
衝突檢查只考慮記錄在被預訂物件所屬同一 Workspace 內的預訂，因為每項物件恰好屬於一個 Workspace。它看不到實際輸入 Kasura 之外的內容：電話接下尚未登記的請求、紙上的預留、或另一份試算表裡的預訂，檢查都看不見，也不會被阻擋。把每筆預訂都放在 Kasura 內、而不是一部分在外，才讓這項防護有效。
本指南不代表的意思
- 這不是在任何情況下都永不發生重複預訂的絕對保證——它是對 Kasura 中實際存在的預訂所做的強、確定性檢查。
- Kasura 不會與線上旅行社或任何外部預訂通路同步可訂狀態；那需要通路管理器，而產品並未包含。
- 偵測衝突不涉及 AI 或預測模型——比較是一個期間對另一個期間的直接檢查。
- 在 Kasura 外做出的預訂——電話、紙本或另一份試算表——對這次檢查不可見，也不會被阻擋。