着信通知の送信先を、メールに加えてチャットや業務システムへ拡大

この会社は、法人に向けて AI による電話代行のサービスを提供しています。利用企業にかかってきた電話に AI が利用企業の名前で応対し、用件を聞き取って要約し、その内容を利用企業の担当者に知らせます。事務所に常に人を置けない企業や、電話の応対に手を取られたくない企業が、本来の業務に集中するための手段として利用しています。

電話代行のサービスでは、電話を受けることと同じくらい、受けた電話の内容を確実に伝えることが重要です。同社は、これまでメールで届けていた着信の通知を、Webhook Admin を通してチャットや業務システムにも届けられるようにしました。通知の送信先を広げた取り組みの経緯をご紹介します。

着信の内容を伝えることが電話代行の価値

電話代行を利用する企業にとって、電話の応対そのものは業務の入口にすぎません。取引先からの問い合わせや見込み客からの相談、折り返しの依頼など、電話で伝えられた用件に応えて初めて、電話を受けた意味が生まれます。そのため、着信の内容を担当者が早く確実に把握できるかどうかが、電話代行のサービスの価値を大きく左右します。

同社のサービスでは、AI が応対を終えると、通話の内容を要約して担当者に知らせます。誰からどのような用件で電話があったのか、折り返しが必要かどうかといった情報が要約に含まれ、担当者はそれをもとに次の対応を決めます。要約が届くのが遅れたり、届いても見落とされたりすれば、利用企業は取引先への対応の機会を逃しかねません。

電話は、受けた側が対応を急ぐことの多い連絡手段です。電話をかけた側は、すぐに用件が伝わることを期待しています。着信の通知は、その期待と利用企業の対応をつなぐ役割を担っており、通知の確実さと受け取りやすさはサービスの品質に直結する課題でした。

メールの中に埋もれていた着信の知らせ

これまで、同社のサービスは着信の通知をメールで届けていました。メールはどの企業でも使われており、送信先として扱いやすい手段です。一方で、担当者のもとには日々多くのメールが届くため、着信の通知がほかのメールに埋もれてしまうことがありました。

とくに、外出の多い担当者や、複数の業務を並行して進める担当者にとっては、メールを開くまで着信に気づかないことも少なくありません。急ぎの折り返しが必要な電話であっても、メールの確認が後回しになれば、それだけ対応が遅れます。着信の見落としを防ぐには、担当者が日常的に見ている場所に通知を届ける必要がありました。

利用企業の多くは、社内の連絡に Google Chat などのチャットを使っています。チャットであれば、担当者は業務の合間に通知に気づきやすく、同じ部署の同僚と着信の対応を分担することもできます。利用企業からは、メールに加えてチャットでも着信を受け取りたいという要望が寄せられていました。

さらに、着信の内容を顧客の管理や問い合わせの管理に使っている業務システムに取り込みたいという要望もありました。着信のたびにメールの内容を業務システムに転記するのは手間がかかり、転記の漏れも起こりえます。チャットだけでなく、業務システムにも着信を直接届けられる仕組みが求められていました。

着信の種類ごとに通知を分ける必要

送信先を広げるうえで、同社はもう一つの課題に向き合いました。それは、着信の種類によって利用企業が知りたい内容が異なることです。AI が用件を聞き取って応対を終えた電話もあれば、相手が用件を伝える前に切れてしまった電話、利用企業が着信を拒否するよう設定した番号からの電話もあります。

以前は、こうした違いにかかわらず、同じ形の通知がまとめて届いていました。応対を終えた電話の要約は担当者がすぐに確かめたい情報ですが、着信を拒否した番号からの電話は、記録として残れば十分な場合もあります。すべての着信が同じようにチャットへ届けば、本当に対応が必要な通知が目立たなくなります。

一方で、着信を拒否した番号からの電話や途中で切れた電話も、利用企業にとって無関係な情報ではありません。同じ番号から繰り返し電話がかかっていれば、利用企業はその状況を把握しておきたいと考えます。すべての着信を残しつつ、どの着信をどこで受け取るかを利用企業が決められることが、送信先を広げるうえでの前提になりました。

同社は、着信を種類ごとに分けて扱い、利用企業が必要な通知だけを選んで受け取れるようにすることを、送信先の拡大とあわせて実現することにしました。

チャットとシステムへの配信を一つの仕組みで

同社は、送信先を広げる方法として、チャットのサービスごとに送信の処理を作ることも検討しました。しかし、チャットのサービスごとに送り方は異なり、業務システムへの連携まで含めると、送信先の種類だけ処理が増えていきます。送信に失敗した場合の送り直しや、配信の記録の管理も、送信先ごとに考えなければなりません。

Webhook Admin は、Google Chat などのチャットと HTTP の送信先への配信を一つの仕組みで扱えます。イベントの種類を登録し、利用企業ごとに送信先を管理でき、届かなかった通知は送り直され、配信の結果は記録として残ります。同社は、送信先の種類が増えても同じ運用で扱えることを評価し、Webhook Admin の採用を決めました。

導入では、まず着信の種類を整理し、着信・応対・不在・着信拒否の四つをイベントの種類として Webhook Admin に登録しました。同社のサービスは、電話の状況に応じてこれらのイベントを送り、利用企業ごとに登録された送信先へ Webhook Admin が届けます。

利用企業ごとの送信先は、利用企業の数だけ登録されます。電話代行のサービスでは、ある企業にかかってきた電話の内容は、その企業の担当者だけに届かなければなりません。Webhook Admin 上で利用企業ごとに送信先を分けることで、着信の通知が別の企業に届くことのない構成としました。

メールとの並行運用と、通知の内容の整理

切り替えにあたって、同社はメールでの通知をやめず、チャットへの通知を加える形をとりました。メールでの受け取りに慣れている利用企業も多く、すべての利用企業が一度にチャットへ移るわけではありません。メールとチャットの両方で着信を受け取れるようにすることで、利用企業はそれぞれの働き方に合わせて受け取り方を選べます。

利用企業への案内では、チャットで受け取れる通知の種類と、送信先の登録の方法を説明しました。どの着信の種類をチャットで受け取るかを利用企業が選べることもあわせて伝え、応対を終えた電話の要約だけをチャットで受け取り、ほかはメールで確認するといった使い分けもできることを紹介しています。

チャットへの通知を設計するうえで、同社が気を配ったのは通知に載せる内容です。着信の要約には、電話をかけてきた相手の名前や連絡先、用件といった情報が含まれます。チャットのスペースには、担当者だけでなく多くの社員が参加していることがあります。同社は、担当者が対応を判断するのに必要な情報を通知に載せつつ、利用企業がどのスペースを送信先にするかを決められるよう、送信先の登録を利用企業に委ねる形としました。

着信の種類ごとに、載せる内容も分けています。応対を終えた電話であれば、要約と折り返しの要否を中心に伝えます。用件を聞き取る前に切れた電話や、着信を拒否した番号からの電話は、着信があった事実を記録として残すことを目的とし、内容は簡潔にとどめました。種類ごとに通知の形をそろえたことで、担当者は文面を見ただけで着信の状況を把握できます。

配信の記録は、運用を見守るうえで欠かせない情報になりました。同社の担当者は、どの利用企業のどの送信先で配信が失敗しているかを記録から確かめられます。送り直しても届かない状態が続いていれば、送信先の設定に問題がある可能性が高いと判断し、利用企業に早めに連絡できます。メールだけで通知していた頃には把握しにくかった配信の状況が、送信先ごとに見えるようになりました。

社内では、利用企業からの問い合わせに対応する担当者に向けて、チャットへの通知の仕組みと配信の記録の見方を共有しました。通知が届かないという相談を受けたときに、記録をもとに送信先の状況を確かめる手順をそろえておくことで、担当者によって対応が変わらないようにしています。

受け取りやすくなった着信の通知

Webhook Admin の導入により、利用企業はメールに加えて、Google Chat などのチャットで着信の要約を受け取れるようになりました。担当者は、日ごろ見ているチャットの中で着信に気づけるため、メールを開くまで着信を知らないという状況が減りました。同じ部署の同僚とチャットの上で着信の対応を相談することもできます。

着信の種類ごとにイベントが分かれたことで、利用企業は必要な通知だけを受け取れます。対応が必要な電話の要約が目立つようになり、担当者は優先して確かめるべき着信を判断しやすくなりました。

送信先を広げても、通知の確実さは保たれています。チャットのサービスが一時的に受け付けない場合、Webhook Admin が通知を送り直すため、着信の知らせが失われることを防げます。同社にとっても、送信先の種類ごとに送信の処理を作り込む必要がなくなり、電話の応対の質の改善に開発の力を注げるようになりました。

業務システムとの連携へ

今後、同社は利用企業の業務システムとの連携にも Webhook Admin の活用を広げる予定です。Webhook Admin は HTTP の送信先にも配信できるため、着信のイベントを利用企業の顧客の管理や問い合わせの管理の仕組みに直接届けることができます。着信の内容を手で転記する必要がなくなれば、利用企業の業務はさらに滑らかになります。

業務システムとの連携では、利用企業の側で着信のイベントを受け取る処理を用意する必要があります。同社は、イベントの種類ごとにどのような内容が届くかを利用企業や連携先が確かめられるよう、説明の整備を進めていく考えです。送り直しや配信の記録といった仕組みはチャットへの通知と共通のため、連携先が増えても運用の手順は変わりません。

同社は、メール、チャット、業務システムと、利用企業が着信を受け取る場所を広げながら、電話を受けた後の対応までを支えるサービスを目指していきます。