ご相談・提案事例
月約300件の予約確認と、休憩中・夜間の電話。ホテルのAI対応は業務を分けて考える
ホテル・コテージを運営する会社様
予約確認の発信を2名で担い、現場では休憩中や夜間の電話にも対応する宿泊施設様との相談事例。予約情報の受け渡し、館内案内、スタッフへの通知と転送を、業務ごとに整理します。
優先したいのは、休憩時間と夜間に現場が電話を受ける負担
打ち合わせの中で、施設様がまず解決したいと説明されたのは、現場の休憩時間や夜間の電話対応でした。宿泊予約そのものをAIで確定できれば望ましいものの、それが最初の目的ではないという優先順位が示されました。
館内設備の利用時間や自動販売機の場所など、決まった情報を案内すれば終わる問い合わせがあります。こうした電話のために、休憩中や夜間のスタッフが都度対応する状況を見直したいという話です。電話の件数だけでなく、いつ対応が必要になるかが、この業務の負担に関わります。
ただし、施設からの電話には、案内だけで終わらないものも混じります。宿泊中のお客様が何かを届けてほしいと希望したり、設備や清掃について不満を伝えたりする場合です。AIが会話を受けることと、その用件を現場で解決することを分けて考える必要がありました。
予約確認は定型部分から。特別なリクエストまで一度に広げない
もう一つの対象は、本社の予約担当から宿泊予定のお客様へかける確認電話です。お客様の名前と予約情報が分かれば進められる定型的な確認に加え、予約時に受けたアレルギーの申告や、特記されているリクエストを掘り下げる場面があります。
通常の確認は3〜5分程度ですが、お客様から記念日のケーキなど追加の相談が入ることもあると伺いました。同じ『予約確認』でも、予定どおり確認して終わる通話と、個別の相談に進む通話があるわけです。
施設様の希望は、まず定型的な確認を任せたいというものでした。特記事項まで連携できればさらによいものの、最初からそこまでを必須とする話ではありません。実際に参照できる予約情報に合わせて、AIが聞く内容を決めるという考え方ができます。
この切り分けには、導入後の対応を明確にする意味もあります。定型確認は完了したが追加の相談が残っているのか、予約情報そのものの確認が必要なのか。人へ戻す際にその違いが分かれば、スタッフは必要なところから対応できます。
CSVで予約情報を渡せても、空室をその場で確定できるとは限らない
予約情報は、長年利用されている既存の管理システムに入っています。打ち合わせでは、APIによる連携が難しいという説明があり、CSVで情報を出し、定期的に取り込む方法が候補になりました。
すでに予約済みのお客様へ確認の電話をかける場合は、誰に、どの予約について連絡するかを渡せれば、業務を組み立てられます。ただし、情報の受け渡しには時間差が生じます。取り込み後に変更された予約をどう扱うかなど、実際の運用で確かめる点は残ります。
一方、新規の予約をその場で受け付け、空室を確認して確定するには、その時点の状況を扱う必要があります。予約情報をCSVで渡せることと、最新の空室を見ながら登録まで進められることは、必要な連携の範囲が異なります。
今回の相談では、この制約を踏まえて、現場の受電対応と予約確認を優先する方向を整理しました。予約確定までできることを前提にせず、既存の予約センターや現場の役割と組み合わせて、任せる範囲を考えています。
| 電話の種類 | 主に必要な情報 | 今回の設計上の論点 |
|---|---|---|
| 予約済みのお客様への確認 | 氏名・予約内容・確認項目 | CSV等による受け渡しと情報の更新 |
| 滞在中の施設案内 | 施設ごとの設備・営業時間・案内 | 正しい施設情報を参照できること |
| 新規予約の確定 | 最新の空室と予約登録の結果 | リアルタイムの取得・登録が可能か |
『タオルが欲しい』は、案内を返しただけでは完了しない
受電について具体的だったのが、コテージに滞在するお客様からの連絡です。館内の案内とは違い、タオルの追加などの要望は、誰かが現場で対応して初めて完了します。AIが用件を聞けたことと、宿泊者の困りごとが解決したことは分けて管理したいところです。
打ち合わせでは、聞き取った用件をLINEなどでスタッフへ知らせる案を話しました。また、清掃への不満など、直接の対応が必要な相談は人へつなぐ方向を確認しました。日常的な案内、行動が必要な依頼、直接対応すべき相談を、それぞれ別の出口へ進める設計です。
ホテルとコテージで案内が違うこともポイントになります。どちらの施設への問い合わせかによって、答える内容や連絡先が変わります。番号や会話による施設の判別など、誤った案内をしないための入口も整理する必要があります。
さらに、施設側では案内情報を蓄積する仕組みを用意されており、営業時間などが変わった際に、最新の情報を参照できるようにしたいという希望もありました。電話対応の台本と実際の施設情報を、どう一致させ続けるかという運用の話です。
- 01
問い合わせ先の施設と用件を確認する
- 02
案内で解決する内容には、施設情報をもとに回答する
- 03
現場の行動が必要な依頼は、内容を整理してスタッフへ通知する
- 04
直接の対応が必要な相談は、人への引き継ぎにつなげる
受電・発信・営業中の対応を、別々に見積もる理由
商談の終盤では、用途を分けて見積もりを確認する方向になりました。休憩中や夜間の受電、予約確認の発信、営業中のコテージ対応では、必要性と費用対効果を判断する基準が違うためです。
休憩・夜間対応は、その時間帯に人が電話を受ける負担との比較になります。予約確認の発信は、繰り返す確認業務の量と、スタッフが引き続き対応する個別相談の範囲を見ます。営業中の対応は、すでに勤務しているスタッフの業務と、どのように分担するかが論点です。
デモでも、案内が正しくできるかだけでなく、スタッフ通知や人への転送を確認する話がありました。施設の実際の問い合わせを入れて試せば、回答だけで済むものと、現場へ戻すものの境界を確かめられます。
このように用途を分けると、全部を一度に任せる前提で判断する必要がなくなります。どの電話から任せると現場が使いやすいか、どの連携を先に用意するかを、費用と合わせて選べます。
宿泊施設の電話は、予約・案内・現場対応をつないで設計する
今回のご相談は、業務ごとの提案と見積もり、専用デモを準備する段階です。予約管理システムとのリアルタイム連携や本番稼働、削減時間などの成果は確認されていません。
それでも、実装に向けて整理すべきことははっきりしています。予約確認では必要な情報をどう渡すか。受電では施設の情報をどう更新するか。AIだけで完了しない用件を誰が受け持つか。この三つを決めることが、現場で使える電話対応につながります。
宿泊施設の電話は、かける電話と受ける電話で、必要な仕組みが変わります。まず負担が大きい時間帯と用件を洗い出し、既存の予約センターやスタッフと役割を分けることから始めるのが、今回の相談から見えてきた進め方です。
