予約管理をシステム化する｜定員・仮予約・キャンセルの設計

予約管理をシステム化するなら、予約カレンダーを作る前に、仮予約を定員に含めるか、電話予約をいつ共通台帳へ登録するか、キャンセルで枠を戻す条件を決めます。画面上の残席が正しく見えても、この3点が曖昧なら、受付経路や担当者によって定員判定が変わるためです。

以下の架空例では、業務上の受付上限を「定員」と呼びます。定員10人、確定6人、仮予約2人なら、仮予約を含めるかどうかで残席は2人にも4人にもなります。通常の計算ルールに加え、例外受付を認める場合の担当者と確認手順を決めます。

製品仕様は2026年10月1日に公式情報で確認しました。各社製品の仕様と、自社アプリに採用する設計案は分けて記載しています。

予約管理のシステム化は、受付状態の定義から始める

「予約あり」を一種類として扱うと、仮予約と取消済み予約の意味が混ざります。定員判定に必要なのは、少なくとも次の区別です。

状態名だけでは、残席を判定できません。「仮予約」という表示があっても、定員計算から外れていれば、システム上は席を押さえていない扱いです。反対に、取消操作を始めただけで枠を戻す設計なら、取消が完了していない段階で別の予約を受け付ける可能性があります。

製品の挙動も一様ではありません。やくばとの予約枠型では、仮押さえによって利用者側に見える空き定員が1名分減り、解除すると元の状態に戻ります。代理予約を追加すると仮押さえが解除され、代わりに予約が枠へ入ります。

一方、仮押さえの有無は予約申し込み一覧には表示されません。仮押さえを含めて満員なら予約追加ボタンが無効になり、仮押さえのある枠は削除できません。空き定員、申し込み一覧、管理操作で扱いが異なる点まで確認が必要です（やくばと「予約枠の空きを仮押さえしたい」）。

したがって、仮予約を定員に入れるかどうかだけでなく、その状態を受付担当者がどの画面で確認できるかまで決める必要があります。

定員10人の架空イベントで残席を判定する

架空のイベントを例にします。これは設計を比較するための条件であり、実在する製品、顧客、導入事例、自社実績ではありません。

• 定員（業務上の受付上限）：10人
• 確定予約：6人
• 仮予約：2人
• 取消済み：1人
• 取消済みの1人は、取消確定後に定員消費から除外する

取消済みを除外する点は同じでも、仮予約の扱いだけで結果が分かれます。

案Aでは 10 - (6 + 2) = 2、案Bでは 10 - 6 = 4 です。予約の件数も状態も同じなのに、表示する残席には2人分の差が生じます。カレンダーの表示方法ではなく、先に業務ルールを決めるべき理由がここにあります。

案Bの仮予約は、席の確保を保証しない状態です。確定へ移す際に残席を再判定し、空きがなければ確定を止めて受付担当者が案内する条件を決めます。

電話予約は確約前に共通の定員判定へ載せる

Web予約だけで残席を計算しても、電話や窓口で受けた予約が後から入力されれば、その間は空席に見えます。受付担当者が電話口で確約する前に共通台帳へ登録し、同じ空き状況を確認する手順を設計対象にします。

RESERVAのスクールタイプ・イベントタイプでは、店舗窓口、電話、メールで受けた予約を管理画面から登録でき、空き状況を確認しながら操作できます（RESERVA「管理画面から予約を登録する」）。RESERVA固有の提供仕様であり、すべての予約システムに共通する機能ではありません。

入力先を一つにするだけでは足りません。電話受付中の登録時点、仮予約か確定か、複数人を受ける場合の人数、登録完了前に別経路の予約が入った場合の再判定まで、一続きの手順にします。通常受付、仮予約の確定、例外受付では、残席の判定と登録確定の間に同じ枠の別予約が入らないようにします。通常受付の試験では、同時に届いた予約で上限を超えず、受付できなかった側には未成立と伝わることを確認します。

Excelなど既存の台帳から切り替える際は、Excelから業務システムへ移行する進め方も、移行対象と運用を整理する参考になります。

キャンセルで空き枠を戻す時点を分ける

キャンセルが発生したら即座に残席を増やせばよい、とは限りません。取消操作の開始、取消確定、予約日時の変更依頼は、業務上の意味が異なります。

架空例では取消確定時に枠を戻します。仮予約に期限を設ける場合も、期限切れが確定した時点で、算入していた人数だけを定員消費から除外します。取消や期限切れの処理を繰り返しても、同じ予約の枠を二重に戻さないことを試します。

実際に、やくばとの予約枠型では、予約日時の変更依頼を患者へ送信した時点で予約と予約枠の関連が解除され、空きが1つ増えます。変更確定後ではなく依頼送信時に枠が空く同製品固有の仕様です（やくばと「予約日時の変更を患者に案内したい」）。

空きが生じることと、次の予約が成立することも別です。RESERVAのキャンセル待ち機能では、対象枠でキャンセルが発生した際の通知を手動または自動に設定できますが、キャンセル待ちの申し込みと空き発生後の予約は予約者自身が行います。ゴールドプラン以上が対象で、宿泊施設タイプは対象外です（RESERVA「キャンセル待ち機能を利用したい」）。通知済みを予約済みとみなさず、空き発生、通知、再予約成立を分けて管理する設計が必要です。

管理者の例外登録は、定員判定を壊さない形で試験する

この設計例で例外受付の対象にするのは、業務責任者が調整を認めた受付上限です。施設の安全定員や法令上の制約を上書きする操作にはしません。例外を認めない業務では、管理者も超過登録できない設計にします。

先ほどの架空イベントで、仮予約を定員に含める案Aを採用し、定員消費8人の状態から新たに3人分を登録するとします。登録後は11人となり、定員10人を1人超過します。安全上の制約などには抵触せず、例外受付を認められる条件と仮定して、各試験を定員消費8人の状態から個別に始めます。

RESERVAの同管理画面では、予約枠が埋まっている場合や予約制限の上限を超える場合に警告が出ますが、警告内の操作から強制登録できます。管理者例外を検討する際の参考になるRESERVA固有の仕様で、自社サービスの標準機能ではありません（RESERVA「管理画面から予約を登録する」）。

警告の有無だけを試しても不十分です。通常権限の拒否、例外権限による明示確認、操作記録、確定直前の再判定を確認します。例外受付の条件を満たさない場合に、管理者でも確定できないことも試してください。

画面を選ぶ前に、運用ルールを一枚にまとめる

Jicooの席数指定型予約は、時間帯ごとの参加可能人数を設定して予約ページに予約人数を表示でき、ホストは予約詳細画面で予約・キャンセル状況を一覧確認できます。対象プランはTeam・Business・Enterpriseです（Jicoo「席数を指定した予約管理」）。

ただし、表示機能があっても、自社の仮予約、電話受付、取消確定、管理者例外のルールが自動的に決まるわけではありません。SaaSで運用を合わせるか、kintoneで構成するか、独自開発するかを考える段階では、SaaS・kintone・独自開発の比較も判断材料になります。

最初に一枚へまとめる項目は、次のとおりです。

• 各予約状態が定員を消費するか
• 電話・窓口予約を共通台帳へ登録する時点
• 取消や変更で枠を戻す条件
• 空き発生の通知と再予約成立の区別
• 例外受付を認める条件、承認者、確認操作と操作履歴
• 同時登録時に定員を再判定する時点

ルールを決めたら、定員10人・定員消費8人の例で3人分を追加し、通常権限では拒否されるかを確かめます。例外受付を認める条件では、1人超過の警告、確認操作、承認者と理由の記録、確定直前の再判定まで試します。カレンダーの残席表示だけで合否を決めず、受付担当者の操作と結果を照合してください。

自社業務に合わせた予約管理Webアプリを検討する場合は、連携、データ移行、権限、データ出力の範囲を契約前に確認する必要があります。初期開発と運用保守は個別見積もりです。受付業務ひとつから整理したい場合は、業務アプリの相談をご利用ください。