来訪の通知と担当者の呼び出しを、Webhook Admin を通して担当者の Google Chat・Microsoft Teams へ届けています。一時的に届かなかった通知は再送され、届いていない通知を届いたものとして扱わない運用を整えました。
導入前の課題
- チャットの一時的な障害で、来訪の通知が担当者に届かないおそれ
- 送り直しの際に、同じ来訪の通知が重なって届くおそれ
- 通知が届いたかどうかを、受付の案内に正しく反映できていなかった
導入後の効果
- 一時的に届かなかった来訪の通知が再送され、配信の記録も残るように
- 同じ通知の二重送信を防ぎ、担当者が迷わず対応できるように
- 届いていない通知を届いたものとして案内しない受付の運用に
| 導入企業 | AI サービス企業 |
|---|---|
| 導入製品 | Webhook Admin |
| 導入時期 | 2026 年 10 月 |
この会社は、企業の事務所の受付に置くタブレットで来訪者を迎える受付システムを提供しています。来訪者がタブレットで用件を伝えると、受付の AI が訪問先の担当者を探し、その担当者に来訪を知らせます。受付に人を置かない事務所でも、来訪者を待たせずに担当者へつなぐことが、同社のサービスの役割です。
その仕組みの要となるのが、担当者への通知です。担当者は日ごろ使っている Google Chat や Microsoft Teams で来訪の知らせを受け取り、受付へ向かいます。同社は、この通知を Webhook Admin を通して届ける形に改め、通知の安定性と品質を高めました。通知漏れを防ぐために同社が取り組んだ内容をご紹介します。
通知が届かなければ来訪者が待ち続ける受付
受付の業務では、通知の遅れや漏れがそのまま来訪者の待ち時間になります。来訪者は、担当者が来るまで受付の前で待つしかありません。通知が担当者に届いていなければ、来訪者は誰にも気づかれないまま時間を過ごすことになり、訪問先の企業の印象にも影響します。
受付に人がいる事務所であれば、担当者が来ないことに受付の担当者が気づき、内線で呼び出すこともできます。しかし、同社のサービスを使う事務所の多くは、受付を無人にするか、受付の担当者を置かずに運用しています。通知が唯一の連絡手段となる場面も多く、通知が確実に届くことは、無人の受付が成り立つための前提でした。
さらに、来訪の通知は時間との勝負です。予約の通知であれば数分の遅れは大きな問題になりにくいものの、来訪の通知は来訪者が目の前で待っている状況で送られます。遅れて届いた通知は、届かなかった通知と同じくらい来訪者を困らせることになります。通知を確実に、かつできるだけ早く届けることが求められていました。
事務所の受付は、取引先や採用の応募者、配送の業者など、さまざまな立場の人が最初に接する場所でもあります。来訪者にとっては、受付での待ち時間がその企業の対応そのものとして記憶されます。同社のサービスを導入する企業の多くが、受付を無人にしても来訪者への対応の質を落とさないことを求めており、通知の確実さはその期待に応えるための基盤と位置づけられていました。
チャットの一時的な障害と、届いたかどうかの判断
以前の仕組みでは、同社のサービスから担当者のチャットへ直接メッセージを送っていました。Google Chat や Teams が正常に動いていれば通知はすぐに届きますが、チャットのサービスが一時的に受け付けない場合、その通知は失われていました。チャットのサービスの障害は短い時間で収まることが多いものの、その間に来訪した人への通知は届かないままになります。
失われた通知を後から送り直す仕組みを用意しようとすると、別の問題が生じます。送信に失敗したように見えても、実際にはチャットのサービス側で受け付けられていることがあります。その状態で送り直せば、担当者には同じ来訪の通知が二度届きます。担当者は来訪者が二人いるのか、同じ人なのかを判断しなければならず、通知の信頼性がかえって損なわれます。
もう一つの課題は、受付の AI の案内でした。受付の AI は、担当者に通知を送ったことを来訪者に伝え、そのまま待つよう案内します。通知が担当者に届いていないにもかかわらず、来訪者に「お知らせしました」と伝えれば、来訪者は来るはずのない担当者を待ち続けることになります。通知が届いたかどうかを受付の案内に正しく反映させることは、受付の品質に関わる重要な点でした。
配信の仕組みに求めた条件
同社は、通知の仕組みを見直すにあたり、配信の仕組みに求める条件を整理しました。一時的に届かなかった通知を送り直すこと、送り直しても同じ通知が重ならないこと、配信の結果を記録として残すこと、そして利用企業ごとに送信先を分けて管理できることです。
これらを社内で独自に作ることも検討しました。しかし、送り直しと二重送信の防止を両立させるには、通知ごとに送信の状態を管理し、チャットのサービスごとの応答の違いを踏まえて処理を組む必要があります。受付システムの開発とは別の専門的な作り込みであり、作った後も配信の状況を見守り続けなければなりません。
Webhook Admin は、これらの条件をそろえて備えていました。利用企業ごとに送信先を登録でき、Google Chat と Teams へそのまま届けられます。届かなかった通知は時間をおいて送り直され、同じ通知が二重に送られることを防ぐ仕組みも備わっています。配信の結果は記録として残り、後から確かめることができます。同社は、配信を Webhook Admin に任せ、受付の体験そのものの改善に開発の力を集中させることにしました。
来訪と呼び出しを分け、利用企業ごとに送信先を整える
導入にあたって、同社はまず通知の種類を整理しました。受付で起きる出来事のうち、担当者に知らせるものは、来訪の通知と担当者の呼び出しの二つです。来訪の通知は、来訪者が受付を済ませたことを担当者に知らせるものです。担当者の呼び出しは、来訪の通知とは別に、受付から担当者を呼ぶためのものです。この二つをイベントとして分け、受け取る側が通知の意味をすぐに判断できるようにしました。
次に、利用企業ごとに送信先を管理する形を整えました。同社のサービスは多くの企業の受付で使われており、来訪の通知は当然ながらその企業の担当者だけに届かなければなりません。Webhook Admin 上で利用企業ごとに送信先を分けて登録し、ある企業の受付で起きた出来事が、ほかの企業のチャットに届くことがない構成としました。
切り替えは、通知の利用が多い企業の受付から段階的に進めました。新しい仕組みで送った通知が担当者に届いていることを配信の記録で確かめ、問題がないことを確認したうえで、ほかの企業の受付にも広げています。利用企業の側では、受け取るチャットの見た目や操作に変わりはなく、担当者が新たに覚えることはありませんでした。
切り替えにあわせて、同社は利用企業に向けて送信先の登録状況を確かめるよう案内しました。新しい仕組みでは、送信先が登録されていない場合に通知が届かないものとして扱われるため、登録の漏れがあれば受付の案内が変わります。利用企業が事前に登録を確認できるよう、管理の担当者に向けたお知らせで、送信先を登録する場所と、登録がない場合の受付の振る舞いを説明しました。
送信先の登録を見直す過程では、部署の異動や組織の変更によって、使われなくなったチャットのスペースが送信先として残っている例も見つかりました。こうした送信先は、通知が届いても誰も読まない状態になります。同社は、配信の記録とあわせて送信先の状況を利用企業に伝え、実際に担当者が読んでいる場所へ通知が届くよう整理を促しました。
通知に載せる内容も、このときに見直しています。来訪の通知には、来訪者の名前や用件など、担当者が受付へ向かう判断に必要な情報を載せます。一方で、チャットのスペースには担当者以外の社員も参加していることがあるため、載せる情報は対応に必要な範囲にとどめました。通知の内容を種類ごとに決めておくことで、受け取る側が文面から状況を判断しやすくなっています。
届いていない通知を届いたものとして扱わない
同社が運用の面で最も重視したのは、通知が届いたかどうかを受付の案内に正しく反映させることです。送信先が登録されていない企業や部署では、通知は届いていないものとして扱います。この場合、受付の AI は「お知らせしました」とは伝えず、来訪者自身が担当者を呼び出す方法を案内します。来訪者は、通知が届かなかったことを知ったうえで、別の方法で担当者につながることができます。
この扱いを決めたことで、受付の AI の案内と実際の通知の状況が食い違わないようになりました。来訪者に誤った安心を与えないことは、無人の受付を信頼して使ってもらうための基本です。同社は、通知の確実さだけでなく、届かなかった場合の振る舞いまで含めて受付の品質と考えています。
送信先が登録されている場合でも、チャットのサービスが一時的に受け付けなければ、Webhook Admin が通知を送り直します。送り直しの際には二重送信を防ぐ仕組みが働くため、担当者に同じ来訪の通知が重なって届くことを防げます。担当者は、届いた通知を一件ずつそのまま受け止めて受付へ向かえます。
配信の記録は、同社のサポートの場面でも役立っています。利用企業から通知が来なかったという問い合わせを受けた場合、配信の記録をたどれば、その通知がいつ送られ、どのような結果になったかを確かめられます。送信先の設定に誤りがあれば、記録をもとに具体的に案内できます。

通知の確実さが支える無人の受付
Webhook Admin への移行により、来訪の通知は一時的な障害があっても送り直され、担当者に届くようになりました。二重送信の防止によって、送り直しが新たな混乱を生むことも抑えられています。通知の確実性が高まったことで、来訪者を待たせない受付の運用を、より安心して続けられるようになりました。
受付の AI の案内も、通知の実際の状況に沿ったものになりました。届いた通知は届いたものとして、届いていない通知は届いていないものとして扱われ、来訪者には状況に合った案内が行われます。来訪者が来るはずのない担当者を待ち続ける事態を防げるようになりました。
開発の面では、配信の仕組みを社内で抱えずに済むようになりました。送り直しや二重送信の防止、配信の記録といった機能を Webhook Admin に任せたことで、同社の開発の担当者は、来訪者との会話や担当者の探し方といった受付の体験の改善に時間を使えるようになっています。
受付の品質を高める次の取り組み
同社は今後も、受付の通知を確実に届ける運用を続けながら、配信の記録を受付の品質の改善に生かしていく方針です。どの企業で通知が届きにくい状況が起きているかを記録から把握できれば、送信先の設定の見直しを利用企業に早めに提案することもできます。
利用企業の中には、Google Chat と Teams を部署ごとに使い分けているところもあります。同社は、利用企業ごとに送信先を管理する仕組みを生かし、部署ごとに異なるチャットを使う企業でも、それぞれの担当者が普段使っている場所で通知を受け取れるよう、送信先の設定の案内を充実させていく考えです。
無人の受付は、来訪者と担当者の双方が仕組みを信頼して初めて成り立ちます。同社は、通知の確実さと、届かなかったときの誠実な案内の両方を大切にしながら、来訪者を待たせない受付の実現に取り組んでいきます。
主な利用機能
- 会社ごとの配信先
- Google Chat・Teams への配信
- 送り直しと配信の記録
- 同じ知らせの二重送信の防止