同じリソース · 10:00〜11:00
同じリソースに重なる有効な予約は1件だけ確定されます。
枠の表示だけでは、同時予約を決められない
二人が、どちらも確定する前に同じ空き午後を見ることがあります。埋まった時間を隠しても、両方のブラウザーに以前の空きが残る場合があります。Tsumiraは作成時に再確認し、保存側でも有効な時間を保護します。対象は同じリソースの重なる確定予約で、無関係なすべての予定の競合を知るという説明ではありません。
候補の表示と、最後の約束を分ける
候補は、サービス時間、営業ルール、占有した区間から計算されます。現在の提案であり、画面を見るすべての人のために確保するものではありません。作成時にもう一度計算し、すでに約束できない時間は断れます。クリックしたというだけで、以前に見た時間が今も空いている証拠としないための区別です。
- 現在の候補枠
- 作成前の再確認
- 古い選択への拒否
同じリソースの有効な区間を保護する
データには、同じテナントとリソースの有効予約が重ならないルールがあります。対象は時間全体なので、一部分だけ重なる長いサービスも関係します。中止したものは有効な区間を占めず、前の終了と次の開始が接するだけなら許可されます。表示を補い、ブラウザーの動く速さだけで整合性を守ろうとしません。
- テナント・リソース単位のルール
- 実際の時間の重なり
- 有効と中止の区別
顧客や受付へ使える結果を返す
既知の同時作成の競合は、二つ目の成功ではなく、利用できない結果として扱います。公開予約とスタッフによる作成は、対応する確認に共通の作成経路を使います。その後、別の空きか既存の予約を確認します。外部カレンダーや別リソースの事情は、対応する流れのデータにない限り、自動的に推測することはできません。
- 競合を表す予約結果
- 共通の作成ルール
- 保護する範囲を明確にする
同じリソース · 10:00〜11:00
同じリソースに重なる有効な予約は1件だけ確定されます。
具体的な業務の流れ
現在の枠を提示する
営業ルールとリソースの占有からサービスに合う時間を計算します。
選択を送る
顧客か権限のある人が、対象の予約を要求します。
最新の状態で判断する
作成時に空きと保護された区間を確認します。
確定か選び直しか確認する
実際の結果を使い、不可なら別の時間を選びます。
実務を想定した例
利用例：二人が同じ相談枠を選ぶ
二人が同じ相談枠を見ているとします。先に成功した予約がそのリソースの約束となります。もう一人は古い表示が残っていても二重に確定されず、空きがなくなった結果から選び直せます。守るのはこのリソースの有効な予約で、各人の私的な予定全体ではありません。
この機能についての質問
ページを見る間に枠は確保されますか。
違います。現在の読み取りによる候補で、作成時にも確認します。
一部分の重なりも対象ですか。
はい。同じリソースの実際の予約区間を守り、開始時刻が同じ場合だけではありません。
前の終了時刻に次を始められますか。
境界が接するだけの連続した予約は、重複しないモデルです。
外部カレンダーの競合も全部見つけますか。
いいえ。対応するリソースと有効な予約データの保護です。無関係な外部システムは自動で含まれません。
この業務に合う連携を検討する。
想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。
