「予約した車が来ない」「迎えの場所が違う」「聞いていた金額と違う」。配車サービスへの電話は、いま待っている人と、運行中の車両と、受付担当者の間で情報を合わせる仕事です。数分前まで正しかった状況が変わることもあり、一般的なFAQだけでは回答できない場面が多くあります。

その中で暴言や過度な要求への対応が続くと、他の乗客の確認や運行現場への連絡が滞ります。AI電話を使う場合は、通常の照会を整理しながら、運行の判断や安全に関わる連絡を人へ確実に渡せる構成が必要です。「遅延への苦情を短く終わらせる」ことだけを目標にすると、迎車場所の間違いや手配の未完了を見逃すおそれがあります。

本記事は配車センター、ハイヤー・送迎事業の受付責任者に向けた運用設計のガイドです。会話や運用条件は想定例で、特定事業者の導入成果ではありません。AIコールのBellの機能・連携・契約範囲は、実際の提供条件を確認して判断してください。

配車の苦情は、まず運行上の事実をそろえる

乗客が怒っている理由を、最初から過剰要求と決めつけないことが出発点です。予約受付と配車確定を取り違えていた、東口と西口が食い違っていた、キャンセルが反映されていなかったなど、確認すべき業務上の問題が残っている場合があります。

通常照会では、予約を特定する情報、迎車場所、利用予定時刻、現在の状況を必要な範囲で確認します。予約番号が分からない人に同じ質問を繰り返すより、社内で認められた別の照合方法や有人担当者への切り替えを用意します。電話をかけた人が予約者本人とは限らないため、第三者へ伝えてよい内容も区別します。

カスタマーハラスメントへの対応では、相談の内容と、脅しや個人攻撃などの言動を別に記録します。「車が来ない」という問題は調査を続けながら、受付担当者を責任者と交代させることができます。声が大きい、急いでいる、変更を希望したという情報だけで受付を制限しない設計にします。

通常受付、運行判断、安全連絡を別の経路にする

車種や設備の指定にも、荷物の量や乗降上の事情など、運行調整に必要な理由があることがあります。「指定はすべて過度要求」とは扱わず、提供できる条件を確認します。対応できない場合は、その理由と利用可能な窓口を説明します。

予約管理とAIが接続していない段階なら、受付内容を「予約希望」として扱い、手配できたと回答しないようにします。接続していても、システムへの更新失敗や処理待ちがあり得ます。確定状態を読み取れない場合は、結果が未確認であることを伝えて有人担当者へ渡します。

想定例：迎車が遅れているという電話を受ける

以下では、乗客が駅前で待っており、AI受付は予約の聞き取りまで、配車担当者が最新の運行情報を確認する構成を想定します。

乗客：「もう予約時間を過ぎています。車はどこにいるんですか」

受付：「お待ちの車について確認します。ご予約の時間と、お迎え場所を教えてください」

乗客：「10時、中央駅の東口です。予約番号は今見られません」

受付：「10時、中央駅東口ですね。予約番号が確認できないことも含めて配車担当に伝えます。今お待ちの場所は、東口の指定乗り場でお間違いありませんか」

ここで東口・西口や駅名を復唱するのは、時間を延ばすためではなく、別の場所へ車を誘導する誤りを防ぐためです。ただし、乗客が危険な場所にいると伝えた場合は、通常の確認項目をすべて聞くことより安全対応への移行を優先します。

受付：「到着見込みは配車担当が確認します。現時点では到着時刻を確認できていません。担当へおつなぎします」

配車担当者は、予約の存在と手配状況を調べ、運行現場の連絡手順に沿って状況を確認します。前回の目安時刻しか分からない場合は、古い数字を現在の見込みとして繰り返しません。別の車への切り替えやキャンセルを相談する場合も、元の手配が残ったまま重複配車にならないよう、処理結果まで確認します。

引き継ぎ記録には「乗客申告の予約時刻・場所」「確認済みの予約状態」「未確認の到着見込み」「希望する対応」「連絡先」「次に確認する担当者」を残します。乗客が「遅れたなら無料にしてほしい」と話しても、要約を「無料対応を約束済み」に変えないことが重要です。

失敗例：遅延テンプレートが、現場の状況と違っていた

AIが「交通混雑のため遅れています」と回答した後、実際には予約が手配されていなかったと分かるケースを考えます。混雑の説明は自然に聞こえても、確認していない原因を伝えれば誤案内です。AIには、確認済みの状態と確認できない状態を区別させます。

この場合は、有人担当者が事実関係を調べ、先の案内との相違を説明し、次の手配を相談します。レビューでは顧客の怒り方だけを見るのではなく、参照した情報、更新時刻、どの文面が使われたかを確認します。原因が不明な場合に混雑と答える台本は停止し、確認中と伝える文面へ直します。

転送先が不通の場合も重要な失敗条件です。運行中の案件を翌営業日の折り返しに回せない場合があるため、通常の営業時間外受付とは別に、当番の連絡経路を定めます。人につながらないときに、実際には対応できない「まもなく担当者が連絡します」という約束を作らせないでください。

料金・変更・キャンセルの回答は、根拠を管理する

料金への質問は、請求への正当な疑問か、確認後も条件外の対応を強要しているかで扱いが異なります。AIが「値引きはできません」と繰り返す前に、何の料金に疑問があるのかを聞く必要があります。迎車料金、待機、通行料など、サービスによって確認する項目は変わります。

たとえば「予約時の見積もりより高い」という電話なら、見積もり時の条件と実際の利用内容の差を担当者が調べます。AIには承認された一般案内を読ませても、請求が正しいと断定させません。個別の請求訂正・返金は、権限を持つ人が確認します。

変更やキャンセルでも、「希望を受け付けた」「規定を説明した」「変更が確定した」「車両への連絡が済んだ」は別の状態です。キャンセル料などの扱いは、サービスの規定と適用条件を確認して説明し、例外は責任者へ移します。ここでの運用例は、個別の運賃や契約条件についての法的判断を示すものではありません。

安全に関わる電話を、通常の苦情処理に閉じ込めない

事故、車内でのトラブル、具体的な脅しなどが伝えられた場合は、安全対応のための経路へ移す必要があります。AIの分類結果を待つことを必須にせず、受付担当者や乗客が安全上の問題を伝えたときに、人へ進めるようにします。緊急機関への連絡が必要な場面の案内は、事業者の安全責任者が事前に定めます。

運転手への連絡も、乗客をそのまま運転手につなげばよいとは限りません。運転中の応答を前提にせず、運行管理側で安全に連絡できる方法を使います。運転手の私的な番号や居場所の詳細を、苦情を伝えた人に自動開示する設計は避けます。

威圧的な通話が続いた際は、責任者が前面に立ち、受付担当者に単独で説得させない体制を作ります。利用継続や対応方法の変更などの判断は、事情とサービス上の責任を踏まえて行います。単語検出や通話時間だけで利用を拒むことを、初期導入の範囲に含めない方が慎重です。

Bellの検証では「情報がないとき」を重点的に試す

配車で重要なのは、流暢さに加えて、情報が足りないことを正しく伝えられるかです。Bellを含む候補サービスでは、予約情報の参照・更新が可能か、反映の遅れをどう扱うか、当番への転送ができるか、通知の失敗を誰が把握するかを確認します。

感情分析、予約の自動可否判定、運行情報との連携、通話の自動終了といった機能は、個別に対応状況を確認してください。AI受付が使えることから、これらも利用できると推測することはできません。まず聞き取りと記録から始める構成も候補になります。

試験シナリオには、似た地名、駅の出口違い、代理予約、予約番号なし、情報更新の遅れ、キャンセル直後の再入電を含めます。一連の電話だけでなく、その後で担当者が何を修正したかまで検証すると、自動化によって残る作業が見えます。

効果は、配車と折り返しの完了まで追って評価する

通話時間が短くなっても、折り返しや二重手配が増えれば、現場の負担は減っていません。通常照会では正しい予約への到達率や確認のやり直し、安全連絡では当番への到達と確認までの時間、料金相談では担当者への引き継ぎ漏れを追います。

繁忙時間帯、天候、イベントによって問い合わせ量は変わります。導入前後を比べる際は、同じ種類の電話と時間帯で見ることに加え、対象外の案件を記録します。自動受付から離脱した電話を除いて「成功率」を計算すると、つながらなかった人の問題を見落とします。

最初の運用範囲は、案内の根拠が管理できる定型照会や、有人担当者が必ず受け取れる時間帯の一次受付が候補です。安全上の見落としや未確認の配車確定が出た場合には、対象業務を止めて原因を修正できるよう、切り戻し担当者も決めてください。全社共通の記録権限・責任者レビューは、AIによるカスハラ対策の実装ガイドで詳しく整理しています。

配車の確認に追われる時間を、見直してみませんか

「車はどこですか」という電話が重なり、状況を確認するための連絡まで後回しになる。受付担当者に負担が集中する時間帯があるなら、Bellを使った電話の分担を考えるきっかけです。

予約の聞き取りをどこまで任せ、どの連絡を配車担当や運行管理へ渡すか。今の流れに沿って、無理なく始められそうな範囲を一緒に見つけましょう。「混み合う時間だけ受付を見直したい」という段階から、Bellへご相談ください。