結婚式場の見学予約を、電話とWebで一つの台帳にまとめる。電話受付で記録する項目と、予約枠を窓口どうしで同期させる作り方

この記事の結論：結婚式場の見学予約を電話とWebで一元管理するには、窓口ごとに表を持つのをやめ、「見学の枠」と「見学予約」の二つの記録を持つ台帳を一つだけ作ります。電話受付では、通話中に必須の6項目（日時と枠・名前と読み・折り返しの電話番号・確認を送る手段・人数・受けたスタッフ）だけを画面から入力し、メモ用紙を経由させません。枠の残りは、電話・自社サイト・比較サイトのどこから入った予約でも同じ一つの処理で減らし、その処理は「残りがあるときだけ減らす」条件付きの更新にします。こうしておけば、同じ枠に電話とWebの予約が重なっても、片方は満席として止まります。

この記事の読み手は、式場で見学やフェアの予約受付を担当する方と、その受付の仕組みを作る開発者です。説明は一般的な設計の考え方と公式の資料に基づくもので、特定の式場の事例は扱いません。予約が入った後の打ち合わせ・見積もり・成約の記録を、一組の結婚式の単位で持つ設計は、予約管理と顧客管理を一つにまとめる記事に書いたので、ここでは来館の前、見学予約を受け付ける入口に絞ります。

見学予約が窓口ごとの表に分かれると、枠の数え違いが起きる

電話・自社サイト・比較サイトのそれぞれに予約の一覧があると、同じ見学の枠を三か所で別々に数えることになり、満席の枠に予約が入る原因になります。まず窓口ごとに、予約がどこに残り、枠をどこで閉じているかを書き出します。

どの窓口にも、それぞれの場所で数えている理由はあります。問題は、残数の正しい値を持つ場所が一つも決まっていないことです。一元管理の目的は、「枠の残りの正しい値はこの台帳にしかない」という状態を作り、ほかの場所はすべてそこに合わせる側に回すことにあります。

台帳には「見学の枠」と「見学予約」の二つの記録を持つ

一つの台帳の中身は、空き状況を表す「見学の枠」と、お客様ごとの「見学予約」の二種類に分けて持ちます。枠と予約を一つの表に混ぜると、予約を取り消したときに枠の残りが戻らない、といった食い違いが起きやすくなるからです。

「入った窓口」を必ず残しておくと、どこからの見学予約が多いか、どこからの予約で来館なしが多いかを、後から同じ台帳で数えられます。比較サイトが付けた予約番号は、台帳の予約番号とは別の項目に保存し、同じ番号の予約が二度届いたら新しく作らずに更新する、という取り込みの約束に使います。

電話受付で記録する項目は、通話中に入れる6つに絞る

電話で受けた見学予約は、紙のメモに書いてから台帳へ写すのではなく、通話しながら台帳の受付画面に直接入力します。写す工程が残る限り、写し忘れと写し間違いはなくならないからです。そのかわり、通話中に入れる項目は絞り込みます。

任意の項目を必須にすると、受付の電話が長引き、聞きにくい質問を電話口でしなければならなくなります。必須の6つは「この予約を当日迎えるために欠かせない情報」に限り、それ以外は来館当日の会話で埋める、と役割を分けておくと受付が楽になります。

電話で名前や連絡先を聞くことも、個人情報の取得にあたります。通則編（個人情報保護委員会が定める指針）によると、個人情報を取得した事業者は、あらかじめ利用目的を公表している場合を除き、速やかに本人へ通知するか公表する必要があるとしています。電話受付の画面に、利用目的を伝えるときの一言を表示しておくか、確認の連絡に利用目的を載せたページのリンクを入れておくと、受付の担当者が迷いません。

予約枠の同期は、残りを減らす処理を一か所にまとめる

電話とWebで予約枠を同期させるときの要点は、窓口ごとに残数を持たず、すべての窓口が台帳の「枠の残りを減らす処理」を一つだけ呼ぶ作りにすることです。残数を減らす場所が二つあれば、それだけで数え違いの入口が二つになります。

処理は、残数を画面で確かめてから減らすのではなく、「残りがあるときだけ減らす」という条件付きの更新を一回で行います。PostgreSQLの例では次のようになります。

-- 見学の枠を1組分確保する。残りがなければ0行が返る（＝満席）
UPDATE visit_slot
   SET booked_count = booked_count + 1
 WHERE id = $1
   AND booked_count < capacity
   AND accept_until > now()
RETURNING id, capacity - booked_count AS remaining;

この更新が0行で返ってきたら、電話の受付画面には「この枠は満席になりました」と出し、別の枠を案内します。PostgreSQLの公式ドキュメントでは、標準の分離レベル（Read Committed）で二つの更新が同じ行に重なった場合、後の更新は先の更新が確定するのを待ち、更新された行に対して条件を評価し直すと説明されています。残数の確認と減算を一つの文にしておくことで、電話とWebの予約が同時に届いても、二つとも通ることはありません。

電話受付で通話中に枠を選んだ時点の扱いも決めておきます。

日時の変更で古い枠を先に戻してしまうと、新しい枠が満席だったときに、お客様の予約がどこにもない状態が生まれます。確保を先に、解放を後にする順番は、変更の処理の中で固定しておきます。

比較サイトの枠は、台帳の残りに合わせて閉じる

比較サイトの予約は、台帳に取り込む方法と、比較サイト側の枠を閉じる方法を、窓口ごとに一つずつ決めます。比較サイトとのデータの受け渡しの仕組みは、サイトごとに用意されているものが違うので、確かめたうえで次のどれかに当てはめます。

通知メールの本文から読み取る方法は、比較サイトがメールの書式を変えたときに止まります。読み取りに失敗したメールを必ず担当者へ回し、取り込めなかったことに気づける作りにしておきます。どの方法でも、枠の残りの正しい値は台帳にしかないことは変えません。比較サイトの管理画面は、台帳の残りを映す窓の一つ、という位置づけです。

来館前日までの確認は、台帳から一つの手順で送る

確認の連絡は、窓口によって送り方を変えず、台帳に記録された「確認の連絡を送る手段」に従って、同じ手順で送ります。電話で受けた予約にだけ確認の連絡が届かない、という抜けを防ぐためです。

電話で受けた予約では、確認の連絡を受け取ったお客様から「名前の漢字が違う」「人数が増えた」といった訂正が届くことがあります。訂正を受けたら台帳を直し、直した人と日時が残るようにしておくと、当日の受付で古い情報を見てしまう事故を防げます。確認の連絡にSMS・メール・LINEのどれを使い、来館の何日前に送るかは、別の記事で扱う予定です。

一つの台帳へ移すときは、未来の予約から照らし合わせる

窓口ごとの表から一つの台帳へ移すときは、来館日がまだ来ていない予約だけを移し、移した後に枠の残りが合っているかを照らし合わせます。

1. 今ある予約の一覧をすべて集める。 電話の予定表、フォームの管理画面、比較サイトごとの管理画面から、来館日が先の予約を書き出す
2. 見学の枠を先に作る。 日付・開始時刻・種類・受けられる組数を、台帳に登録する
3. 予約を枠に入れる。 入った窓口と、比較サイトの予約番号を一緒に入れる。同じお客様が二つの窓口から予約していたら、どちらを残すか担当者が決める
4. 枠ごとの残りを照らし合わせる。 台帳の残りと、各比較サイトの管理画面に出ている残りが一致するかを、枠ごとに確かめる
5. 切り替えの時刻を決める。 その時刻からは、電話の予約も台帳の受付画面からだけ受ける。古い予定表には書かない

照らし合わせで残りが合わない枠が見つかったら、どちらかの窓口に取り込まれていない予約がある、という合図です。切り替えの前に原因を一件ずつ突き止めておくと、切り替えた後に「台帳では空いているのに、実は埋まっていた」という事態を避けられます。

見学予約の台帳を作るか、既製の予約サービスに載せるか

既製の予約サービスで足りるかどうかは、電話の予約を同じ枠から受けられるか、比較サイトの予約を取り込めるか、の二点で判断します。

株式会社bundlyzeでは、式場の見学と同じく業種ごとに形の違う予約を一つの仕組みで受ける予約管理システムを、構想の段階から本番の運用まで自社で開発しています。

電話・自社サイト・比較サイトの窓口を一つの見学の枠でまとめたいときの相談は、システム開発の相談窓口（bundlyze）で受けています。

出典

以下の3点を、2026年10月3日に読み直して確かめました。改訂が入る場合もあるため、作り始める前に最新版を見てください。

• 個人情報の取得と利用目的の通知を定めた通則編：取得に際しての利用目的の通知・公表（法第21条関係）。個人情報保護委員会
• PostgreSQL 公式ドキュメント「トランザクションの分離」：Read Committed で同じ行への更新が重なったときに、条件を評価し直す動き
• PostgreSQL 公式ドキュメント「UPDATE」：RETURNING 句で更新した行を受け取る書き方