予約の注意点
予約は一見シンプルですが、運用を始めると細かな判断が必要になります。
ここでは、要件定義の前に把握しておきたい論点を整理します。
%%{init: {"flowchart": {"nodeSpacing": 24, "rankSpacing": 48}}}%%
flowchart LR
R(["予約の注意点"])
A["`**1. ダブルブッキング**
同時申込
チャネルの混在`"]
B["`**2. 無断キャンセル**
リマインダー
ペナルティ
誤認定の救済`"]
C["`**3. リソース設定**
前後の準備時間
定休・臨時休業
優先度・自動割当`"]
D["`**4. キャンセル・変更**
期限と料率
変更時の再計算
繰上げ`"]
E["`**5. 時間と暦**
タイムゾーン
日付またぎ
祝日・長期休暇`"]
F["`**6. 通知のしすぎ・未達**
段階の多さ
経路と到達性`"]
G["`**7. データ保持・問い合わせ**
保持期間
削除・匿名化
代行操作の追跡`"]
A --- R
B --- R
C --- R
D --- R
R --- E
R --- F
R --- G1. ダブルブッキング
同時申込による衝突
同じ枠を複数ユーザーがほぼ同時に選ぶと、確定処理の順序次第で二重確保が起きます。
検討したいこと:
- 確定時に再度空きを取り直すか（楽観ロック）
- 仮押さえ期限を設けるか
- 店頭入力とオンライン予約を同じ台帳に載せるか
チャネルの混在
電話・来店・オンラインなど、予約経路が複数あるほど衝突が起きやすくなります。
検討したいこと:
- 予約経路を最終的に1つの台帳に集約するか
- 経路ごとに枠を分けるか
- 店舗スタッフの代行入力ルール
2. 無断キャンセル
予約時点では期待値が高くても、予約時刻に来店がない「無断キャンセル」は一定数発生します。
- リマインダーの通知頻度と到達性
- ペナルティの段階設計（警告 → 期間制限 → 予約不可設定）
- 誤った無断キャンセル認定（遅延チェックイン・記録漏れ）の救済
特に予約受付の制限では、予約を受け付けない場合の画面表示・案内方法（明示的に断るかどうか）によって、顧客とのトラブルリスクが変わります。公開向けには一律の正解を書くより、事業方針として決めるべき論点として扱うのが安全です。
3. リソース設定の見落とし
前後の準備・清掃時間
「60分の施術」に対して、準備・清掃を含めると実際は70〜80分使うケースがあります。これを枠計算に含めないと、直後の予約で現場が回らなくなります。
- 前後バッファをリソースごとに設定します
- サービス種別ごとに所要時間を変えます
- バッファを枠に見せるか、内部的に持つかを決めます
定休日・臨時休業・営業時間
- 定休日は枠を開きません
- 臨時休業は告知と枠の自動閉鎖を行います
- 営業時間をまたぐ枠は作りません
- 祝日の特例営業をどう扱うか決めます
リソースの優先度・自動割当
指名なしの場合、誰にどう割り当てるかで満足度と稼働率が変わります。
- 均等配分
- ベテラン優先／アシスタント優先
- 空き時間が短くなる詰め込み優先
4. キャンセル・変更の扱い
キャンセル料や返金は、顧客との認識ずれを起こしやすい領域です。
- キャンセル期限と段階的な料率
- 無料キャンセル期限ちょうどの扱い
- 変更と新規予約の差（料金再計算の有無）
- キャンセル待ちへの繰上げルール
事前決済の場合は、返金経路と手数料の扱いも公開時点で明示しておかないとトラブルになりやすくなります。
5. 時間と暦の扱い
予約は「時間」を扱うため、暦・タイムゾーンの事故が起きやすい領域です。
- タイムゾーン（サマータイム切替時の二重・消失）
- 営業時間の日付またぎ（深夜営業など）
- 祝日判定の更新
- 年末年始・長期休暇の特例
6. 通知のしすぎ・未達
リマインダーは有効ですが、多すぎると通知疲れにつながります。
- 前日・当日・直前の3段階は多すぎないか
- 変更・キャンセル時の通知停止
- メール／プッシュ／SMSの優先度と到達性
- 営業時間外の通知抑制
7. データ保持と問い合わせ対応
予約データは売上や顧客対応に直結するため、保持期間と取り出し方を整理しておく必要があります。
- 過去予約をどの期間まで表示するか
- 削除・匿名化のタイミング
- 問い合わせ時に状況を確認できるか
- スタッフ側の代行操作を誰が追跡できるか
公開資料としては、機能一覧よりも、こうした運用上の問いを先に整理できることに価値があります。