実際の空き状況から予約システムを設計する

システムが約束すること

予約は時刻だけでなく、資源、所要時間、条件を約束するものです。画面を選ぶ前に約束の中身を書きます。カレンダー表示よりも、準備、清掃、担当者の資格、確定後の変更が難所になりがちです。

現実的な選択肢を比べる

既存サービスの空き判定と取消手順が合うなら、まずそれを検討します。複数資源を同時に押さえる必要や業務固有の例外が多ければ、個別開発が候補になります。顧客予約、管理業務、外部カレンダー連携を分け、空き情報の正しい情報源を決めます。予定のコピーだけでは競合を防げません。

一連の操作を試す

架空の整備工場では、技術者と作業区画の両方が必要です。九十分の整備に準備時間も加わります。両資源をまとめて確認し、確定中は仮押さえして、期限が切れたら解放します。日時変更では新しい枠を確保してから古い枠を解放するか、元の予約を失うことを明示します。

復旧を見えるようにする

空き表示を予約保証とみなさないでください。同じ枠への同時申込、欠勤、決済通知の重複、タイムゾーン変更を試します。取消の影響とリマインダー送信は分けます。確認メールが失敗しても、担当者が予約を確認し再送できるようにします。

時刻、仮押さえ、変更を別に扱う

整備工場の予定表より先に資源のルールを書きます。技術者の勤務、区画の利用、準備時間が枠を制限します。準備に同じ人と場所が必要か別資源かも決めます。店が開いていても担当者が空いているとは限りません。予約には現地のタイムゾーンを持たせ、顧客に見せる時刻を曖昧にしません。

仮押さえと確定予約を分け、期限を決めて入力中の顧客に知らせます。古い画面や他人の取消で空きは変わるため、確定時に再確認します。支払が必要なら、仮押さえの期限後に入金した場合を定義します。空きがあると勝手に約束せず、支払と予約を照合する手順が必要です。

欠勤に重なる日時変更を練習します。担当者に可能な候補、条件の変更、顧客合意の要否を示します。元の履歴を残し、リマインダーは現行の確定版に結び付けて古い時刻を通知させません。要確認の仮押さえ、確定失敗、未解決の支払を一覧にします。担当と安全な次の操作があるなら、例外を通常予約へ埋めるより別キューが分かりやすくなります。

予約の受入例

検討に持ち寄る例

確定で何が利用不可になるか。誰が定員を超えられ、その記録は残るか。どの変更に顧客の合意が必要か。通常予約、取消、日時変更を運用責任者と描いてから見積もります。