ご相談・提案事例
「送っていいですよ」の先に、住所と出荷がある。飲食店向けサンプル営業のAI電話設計
公開日：
よりひとサンプルを送っていいか聞く電話なら、短い台本で済みそうだけど？
ユウトCallforce編集部今回の相談では、その前の商品質問と、その後の住所確認が難しいところでした。送付の合意だけでは、出荷するデータがそろわないんです。よりひと電話で住所を一から聞き取るしかないのかな？ユウトCallforce編集部手元にある店舗住所を読み上げて確認する案が出ました。さらに、出荷登録と発送後のフォローまでつなげたいという構想でした。サンプルを送ってもよいか、飲食店に電話で確認する。やりたいことだけを聞くと、短い質問で終わる業務に見えるかもしれません。ところが実際には、商品をどう理解してもらうか、どこへ送るか、出荷に使える情報をどうそろえるかという、別々の課題が続いています。
今回ご相談いただいたのは、飲食店向けの商材を扱う会社様です。小規模な飲食店などへ新たにアプローチし、商品サンプルの送付先を開拓することがテーマでした。アポイントの日程を決めることより、送付の合意を得て、正しい住所へサンプルを届けることが求められていました。
打ち合わせでは、商品に関する質問の難しさ、住所の聞き取り、出荷システムとの連携、発送後の電話まで話が広がりました。電話の応答だけを自動化すれば済む相談ではありません。ここでは、導入前の打ち合わせで出た要望と、それを業務に落とし込む際に必要な設計を整理します。
ご相談の概要
- 事業
- 飲食店向け商材の販売
- 架電先
- 小規模な飲食店などのオーナー・担当者
- 電話の目的
- サンプル送付への合意と宛先の確認
- 主な論点
- 商品質問の難しさ、住所の正確さ、出荷登録への引き継ぎ
- 将来の構想
- LOGILESS・ecforceとの連携を含む出荷と追客の自動化
- 次に確認すること
- 商品に即した応答、住所確認のテスト、連携項目と運用条件
電話のゴールは、商談日程ではなくサンプルを届けること
先方は、大手チェーンよりも、まず小規模な飲食店からアプローチする考えでした。電話口にオーナーや判断できる方が出る可能性を見込みつつ、商品の説明をしてサンプルを勧め、送付してよいかを確認する流れです。法人向けの営業はこれから広げていく段階で、完成した電話運用を置き換える相談ではありませんでした。
この場合、電話がつながった件数や会話が続いた時間だけでは、目的に近づいたか分かりません。送付に同意されたか、受け取る店舗はどこか、必要な情報がそろったかを見る必要があります。さらに商品に関する質問が残っている場合は、送付の前に説明が必要かもしれません。電話の終了条件を、配送する仕事の入口から考えます。
住所を自由に話してもらう前に、手元の住所を確認する
先方が強く気にされていたのは、住所を正確に聞き取れるかという点でした。自然な音声で話せることと、相手が答えた住所を配送データにできることは、別に確かめなければなりません。打ち合わせでも、話す音声は確認できたが、聞き取る側の能力を見たいという質問が出ています。
そこで話題になったのが、既存のリストにある住所を読み上げ、その宛先でよいか確かめる方法です。一から住所を話してもらうより、確認する範囲を絞れます。ただし、同じ店舗名でも配送先が違う場合や、建物名の補足が必要な場合は残ります。相違があれば出荷を保留して確認するなど、読み上げた後の処理も合わせて設計する案です。
住所が合っている場合でも、宛名や受取担当者が必要かは出荷側の条件によります。電話の質問項目を先に増やすのではなく、実際の出荷登録に何が必須かを確認し、その項目を電話で聞くものと既存データで補うものに分けます。相手に同じ情報を何度も話してもらわず、配送に不足がないようにするための整理です。
| 確認した結果 | 次の処理として考えること |
|---|---|
| 記載の住所でよい | 確認済みの宛先として記録する |
| 建物名などの補足がある | 補足情報と元の住所を残し、出荷前に確認する |
| 別の場所へ送りたい | 元住所を上書きせず、新しい宛先の確認に回す |
| 返答が不明確 | 送付先未確定として保留し、確認を依頼する |
商品への質問は、よくある電話の分岐だけでは足りない
商品説明についても、先方から具体的な懸念が出ました。既存のお客様からも日々質問を受け、人が答えている商材だということです。これまでの質問の一覧はあるものの、伝わりづらい内容や、想定していない聞かれ方もあり得る。一般的な受付対応の経験だけで、簡単に答えられるとは判断できません。
この指摘を受けて、まず商品内容を確認し、AIが説明する範囲と人が説明する範囲を整理する必要が共有されました。設計では、既存の質問と回答をそのまま入れるだけでなく、どの説明をすれば相手がサンプルを試す判断をできるのかを見ます。説明できない質問は記録し、確認して答える流れを用意することが、具体的な準備になります。
録音型か生成対話型かは、合意までの会話で判断する
打ち合わせでは、録音した音声を使う方式と、返答を生成する方式の両方が説明されました。先方は、サンプルを希望する理由や商品への質問まで会話が広がることを踏まえ、生成対話型に関心を持たれていました。一方で、既知の住所を確認する部分など、やり取りを限定できる工程もあります。
判断のためには、商品説明から送付の合意に至る会話を具体的に作り、想定外の質問を入れて確かめることが必要です。質問に答えた後、自然にサンプルの案内へ戻れるか。回答できない場合、無理に送付へ進まず終えられるか。先方は転送をできるだけ減らし、自動化したい意向でしたが、その希望を実現できる範囲は商品に即した確認を経て決めます。
出荷登録までつなぐには、電話の結果を整える必要がある
先方が描いていたのは、電話の結果をCSVで受け取り、手作業で出荷登録する運用から、その後さらに自動化を進める姿でした。LOGILESSやecforceとの連携について質問があり、住所などの情報を送り、サンプルの出荷登録につなげたいという構想が共有されました。これらの連携は、この案件で実装や動作を確認できたものとして紹介しているわけではありません。
実際に進める場合は、送付の合意、宛先、担当者、発送するサンプルなど、渡す項目をそろえる必要があります。また、同じ相手の再架電で出荷が重複しないようにすることや、登録に失敗した情報を確認できることも大切です。先方からも最終チェックは必要という認識が示されており、人が確認する位置を残しながら接続範囲を決めていく考え方です。
連携を始める段階では、いきなり全件を自動で出荷へ流さず、まず少数の確認済みデータが正しく登録されるかを見たいところです。電話の店舗名と出荷先の店舗名が対応しているか、修正した宛先が反映されているか、登録結果を追えるかを確かめます。画面に成功と表示されることより、正しい相手に一度だけ届くことを基準に工程をつなぎます。
送付への合意と宛先の確認結果を、別の項目で記録する。
不足や相違がある情報は確認待ちにし、出荷へ進めない。
確認済みの情報を出荷登録へ渡し、登録できた結果まで確認する。
出荷済みの記録を残し、重複した発送を防ぐ。
発送後の電話は、届いた相手と契約した相手を分ける
構想はサンプルの発送で終わりませんでした。試していただいた後、まだ契約に至っていない企業へ、アフターフォローの電話をかけるところまで自動化したいという要望です。ここでは、最初の電話のリストだけでは足りず、その後に何が起きたかという情報が必要になります。
例えば、発送しただけの相手と、実際に受け取って試した相手では、聞く内容が変わります。すでに契約された相手に同じ案内を続けないためには、契約の状況も反映させる必要があります。これは連携を設計する際の整理ですが、発送後の結果を戻すところまで決めておくことで、電話の自動化を顧客の状況に合わせたフォローへつなげられます。
次の提案で示すのは、商品の質問に答える実際の流れ
今回の打ち合わせで、次に必要なものが明確になりました。管理画面をどう使うかが分かる資料と、その商材ならどのような応答になるかを示す具体的な台本です。一般的な機能説明よりも、質問に答え、送付に合意いただき、宛先を確かめるまでの流れを見たいという要望でした。
その確認では、合意が得られない場合も含めて会話を確かめます。住所の相違、説明できない質問、出荷登録の失敗など、通常どおりに進まない場面で誰が対応するかも決めます。電話、出荷、追客を一度に完成済みと捉えず、まず送付先の情報を正しくそろえる段階から確かめる。この順序が、先方の求める営業の自動化へ近づくための設計になります。
