電話で「空いています」と答えた直後に、予約サイトから最後の一席が埋まる。AI電話と予約台帳を連携する際には、こうした同時更新を扱う必要があります。空席を検索できることと、利用者のために席を確保できることは、異なる機能です。

飲食店の空席対応を自動化するには、空席参照、仮押さえ、条件確認、予約確定、通知の各段階で、台帳の状態と案内を一致させます。本記事では連携の判断に必要な条件を説明します。電話業務全体の整理は飲食店のAI電話対応ガイドを参照してください。以下の構成や会話は設計例であり、Bellで特定の予約・POSシステムと接続済みであることを意味しません。

「空席」は、人数分の椅子が空いていることだけではない

予約可能かどうかは、テーブルの組合せ、利用時間、コース、清掃や次の準備、店舗が受け付ける組数などで変わります。四席空いていても、二名席が離れた場所に二つあるだけなら、四名が一緒に座れるとは限りません。空席数だけをAIに渡す設計では、実際に成立しない予約を案内するおそれがあります。

どの情報を正しい基準とするかも決めます。予約台帳、POS、紙のメモ、予約サイトを同時に見ている店舗では、それぞれに違う状態が残ることがあります。予約を確定する基準となる台帳を定め、電話や来店で受けた予約もそこへ反映する運用が先に必要です。

POSから会計状況が分かっても、それだけで次の来店客を受け入れられるとは限りません。退店や片付け、店舗の受入判断が必要な場面は、その条件を別に管理します。「リアルタイム連携」という名称より、何の状態をどの時点で取得できるかを確かめる方が、導入判断に役立ちます。

空席確認から通知まで、一通の流れを設計する

以下は、通常のテーブル席について、連携先が仮押さえと確定結果の照会に対応していると仮定した例です。実際の利用可否は、連携先の仕様と店舗の運用を確認する必要があります。

1. 日時・人数・条件から空き枠を参照する

利用者が「今度の土曜、四名で19時」と電話したら、具体的な日付と人数を復唱します。席種やコースが予約枠に影響する店舗では、その条件も確認してから検索します。検索の結果には空き枠とともに確認時点を持たせ、古い情報を長く使い回さないようにします。

希望枠がなければ、利用者の条件に合う別時刻を少数提示します。通常席を希望している人にカウンター席を提示するなら、席種の違いを伝えます。候補を案内した段階では予約が確定していないため、確定と受け取られる言葉を使いません。

2. 候補を仮押さえし、復唱する

候補が選ばれたら、対応するシステムでは期限付きの仮押さえを行います。仮押さえは、氏名や連絡先を確認している間に同じ枠が埋まるのを防ぐためのものです。一方、利用者が通話を終了した後も枠が残り続けないよう、期限切れで解放する処理が必要です。

日時、人数、席種、コース、必要な利用条件を復唱し、利用者の同意を確認します。途中で人数や日時が変わった場合は、最初の仮押さえをそのまま確定せず、新しい条件で空席を確認し直します。古い仮押さえの解除も含めて、一件の処理として追跡します。

3. 確定結果を確認し、予約内容を案内する

確定操作の後は、成功した応答と予約番号、登録された内容を確認します。ここで初めて「予約が確定しました」と伝えます。仮押さえが期限切れになった場合や、最後の更新で競合が起きた場合は、確定したように案内せず、別候補を確認します。

氏名や連絡先を復唱する際も、聞き間違いを訂正できる時間を設けます。音声認識が曖昧なまま予約を作ると、来店時の照合や連絡に支障が出ます。確認しきれない場合には、職員に引き継ぐか、別の受付方法へ案内します。

4. 通知を送り、台帳と照合する

通知を利用する場合は、台帳上の確定内容を基準に作成します。会話の途中で作った候補をそのまま通知すると、最後の変更が反映されないことがあります。通知が失敗しても予約が消えるわけではないため、予約状態と送信状態を別に管理します。

最後に、予約番号と来店日時を案内し、後から変更する場合の窓口も伝えます。店舗側でも、その日の電話受付と台帳の登録件数を照合できるようにします。未確定、結果不明、通知失敗の案件だけが残る一覧を用意すると、全通話を確認する負担を減らせます。

二重予約を防ぐには、最後の一枠を同時に試す

空席検索で空きが見えていても、検索から確定までの間に別の予約が入ることがあります。電話を何件同時に受けられるかという性能と、一つの予約枠を正しく管理できるかという性能は別です。連携先で、同じ枠への同時確定を制御できる必要があります。

仮押さえがないシステムでも、確定時に空席を再確認し、条件を満たす場合だけ登録する仕組みがあれば設計できる場合があります。ただし、「先に確認したから必ず取れる」とは伝えられません。単純な読取りと書込みしかできず競合を防げないなら、最初は予約希望の受付にとどめる判断が現実的です。

受入試験では、残り一枠へ電話と予約サイトから同時に予約を入れます。どちらか一方だけが成立し、もう一方に確定と案内しないことを確認します。通常の一件だけが成功しても、この条件を検証したことにはなりません。

連携が止まったときは「失敗」と「結果不明」を分ける

特に結果不明の場合、無条件に同じ予約を送り直すと二重登録につながります。一度の受付に識別子を付け、同じ処理が重ねて届いても予約を重複作成しない仕組みや、既存結果を照会する方法を確認します。連携先が対応していなければ、職員による照合が必要です。

障害時にすべての電話を職員へ転送すると、店内が受けきれない場合があります。希望受付へ切り替える、公開案内のみ続ける、通常の有人回線に戻すなど、店舗が実行できる代替運用を決めます。復旧後には、障害中の受付と台帳を照合してから自動確定を再開します。

大人数・変更・アレルギーは通常枠から外す

大人数や貸切は、テーブルの組合せだけでなく、厨房や接客の受入体制に関わります。通常の予約枠を複数まとめて確保するだけでは対応できないことがあるため、店舗の承認が必要な人数や条件を定義します。

変更予約では、新しい枠が取れなかったのに元の予約だけが消えることを避けます。連携先の変更機能で一貫して処理できるか、失敗時に元へ戻せるかを確認します。確認できない構成では、変更希望を受け付けて職員が処理する方が、利用者への案内を明確にできます。

食物アレルギーなどの要望は、空席確保だけでは解決しません。消費者庁の外食・中食に関する資料も踏まえ、原材料や調理工程は店舗が確認し、AIは安全に提供できると保証しないようにします。相談の記録を予約と結びつけつつ、要望が承認済みか確認待ちかを分けます。出典：消費者庁「外食・中食における食物アレルギーの情報提供に関する実態調査報告書」、2026年10月7日確認

どこまで連携するかを、残る作業で決める

最も深い連携が、すべての店舗で費用対効果に優れるとは限りません。電話予約が少なく例外が多い店舗では、受付内容を整理して職員へ渡す方が運用しやすいこともあります。連携費用だけでなく、台帳の整備、更新確認、障害時の照合に必要な時間を含めて比較します。

導入後は、応答率、予約確定率、二重登録、店舗修正、結果不明の件数、確認待ちの滞留時間を見ます。予約件数の増加には季節やキャンペーンも影響するため、導入前後の差だけでAIの効果と断定しません。同程度の営業時間や予約経路をそろえ、職員の作業時間と併せて評価します。

連携の確認では、現在の予約台帳、電話以外の受付経路、席・コースの条件、仮押さえや変更機能の有無を見ます。APIという接続手段があるだけでは、通話中の予約確定が可能とは限りません。利用権限、書込みの可否、呼出し制限、障害時の結果照合まで確認する必要があります。

「最後の一席に予約が重なった場合」「確定操作の返事が来ない場合」を試すと、店舗に残る確認作業も見えてきます。利用者に確定と伝えた席を、来店時に用意できる状態へつなぐことが導入の基準です。

空席確認のたびに手を止める、その負担から相談しませんか

電話を受けるたびに台帳を開き、予約サイトと見比べ、席を確認する。そんな日々の作業を見直すなら、今の予約方法でBellをどう使えるか、一緒に考えてみましょう。希望の受付から始めるか、予約確定までを目指すかも、店舗に合う形を探すところからで大丈夫です。

台帳の詳しい仕様が分からなくても、まずは普段の予約の受け方をお聞かせください。Bellへ空席対応と予約連携を相談する