予約通知の Google Chat 連携を、再送と配信記録により安定化

この会社は、医院や整備工場などの店舗に向けて、予約の受付とスタッフのシフトを一つの仕組みで管理する SaaS を提供しています。利用者は複数の拠点を持つ事業者から一人で切り盛りする店舗まで幅広く、受付の担当者やスタッフは、日々の診療や作業の合間に予約の状況を確かめながら仕事を進めています。

同社のサービスでは、予約が入ったり変わったりしたときに、その内容を医院や店舗のチャットへ知らせる機能を備えています。なかでも Google Chat で通知を受け取る医院や店舗は多く、通知の確実さはサービスの品質そのものとして受け止められていました。同社は、この通知の仕組みを Webhook Admin に移し、連携の安定性と品質を高める取り組みを進めました。その経緯をご紹介します。

予約の通知が業務の起点になっている医院と店舗

予約・シフト管理のサービスを使う医院や店舗では、予約の通知が一日の業務の起点になっています。新しい予約が入れば、受付の担当者は準備の段取りを考え、スタッフは自分の担当する時間帯を確かめます。予約が取り消されれば空いた枠を別の患者や来店客に案内し、変更があれば関係するスタッフに伝え直します。

こうした動きを支えているのが、チャットへの通知です。医院や店舗の多くは、すでに Google Chat や Microsoft Teams、Slack、Chatwork などで院内や店内の連絡を取り合っています。予約の通知が同じ場所に届けば、管理画面を開き直さなくても状況がわかり、スタッフ同士でそのまま声をかけ合えます。同社が通知の送信先としてチャットを重視してきたのは、こうした現場の働き方に合わせるためでした。

通知の対象となる出来事は、予約の登録だけではありません。予約の変更や取り消し、来院や来店の記録、前日のリマインドなど、医院や店舗が知りたい出来事は多岐にわたります。どの出来事をどの送信先に届けるかは医院や店舗ごとに異なり、通知の設定は利用者の数だけ存在していました。

利用する医院や店舗が増えるにつれて、通知の件数も送信先の数も増えていきます。予約の多い時間帯には通知が集中し、チャットのサービスに短い間に多くのメッセージを送ることになります。利用者の広がりに合わせて、通知の仕組みも無理なく大きくできることが求められていました。

チャットのサービスが受け付けないときに失われていた通知

以前の仕組みでは、同社のサービスが予約の出来事を受けて、医院や店舗が登録したチャットへ直接メッセージを送っていました。送信が成功すれば問題はありませんが、チャットのサービスが一時的に混み合っていたり、短い時間だけ応答しなくなったりすると、その通知は届かないまま失われていました。

チャットのサービス側の一時的な不調は、送り手からは避けようがありません。しかし、受け取る医院や店舗にとっては、通知が来なかったという事実だけが残ります。予約が入っていたことに気づかず準備が遅れたり、取り消しを知らずに枠を空けたままにしたりすれば、業務への影響は小さくありません。

問題をさらに難しくしていたのは、通知が届いたかどうかを後から確かめる記録が十分でなかったことです。医院や店舗から通知が来なかったという問い合わせを受けても、送信の時点で何が起きていたのかをたどるのに手間がかかりました。チャットのサービス側の不調なのか、送信先の設定の誤りなのか、送信先そのものが削除されていたのかを切り分けられないまま、調査に時間を取られることもありました。

送信先の扱いにも課題がありました。医院や店舗がチャットのスペースを作り直したり、通知を一時的に止めたいと考えたりしても、そのための操作は限られていました。新しく送信先を登録した直後に、本当に届くかどうかを確かめる手段もなく、最初の予約が入るまで設定の正しさがわからない状態でした。

再送の仕組みを独自に作るか、配信の基盤を使うか

同社は、通知の仕組みを見直すにあたり、いくつかの方法を比較しました。一つは、社内で再送の仕組みを独自に作る方法です。送信に失敗した通知を保存し、時間をおいて送り直し、その結果を記録する処理を、自らのサービスの中に組み込むことになります。

この方法は一見すると手軽ですが、実際には考えるべきことが多くあります。送り直す間隔をどう決めるか、何度まで送り直すか、送り直している間に同じ予約の変更が重なったらどう扱うか、チャットのサービスごとに異なる送り方の違いをどう吸収するかなど、予約の機能とは関係のない作り込みが必要になります。作った後も、配信の状況を見守り、不具合に対応し続けなければなりません。

汎用のメッセージの待ち行列の仕組みを使い、その上に配信の処理を組む方法も検討しました。ただし、この場合も送り直しの規則や配信の記録、送信先ごとの管理は自ら作る必要があり、医院や店舗が送信先を自ら操作する画面まで含めると、負担は大きく変わりません。

最終的に同社が選んだのは、配信に必要な機能をまとめて備えた Webhook Admin でした。イベントの種類の登録、送信先ごとの管理、再送、配信の記録、テスト送信、送信先の停止と再開といった機能がそろっており、Google Chat や Teams、Slack、Chatwork へもそのまま届けられます。同社は、配信の仕組みを任せることで、予約とシフトの機能の改善に開発の力を注げると判断しました。

予約の出来事をイベントとして整理し直す

導入の最初の作業は、予約にまつわる出来事をイベントの種類として整理することでした。予約の登録、変更、取り消し、来院や来店の記録、前日のリマインドを、それぞれ別のイベントの種類として Webhook Admin に登録しました。出来事ごとに種類を分けておくことで、医院や店舗は必要な通知だけを選んで受け取れます。

イベントに載せる内容も、このときに見直しました。チャットに届く通知は、院内や店内の多くのスタッフの目に触れます。予約の日時やメニューなど、準備に必要な情報は伝えつつ、患者や来店客に関する情報は業務に必要な範囲にとどめるよう、出来事ごとに項目を整理しました。種類ごとに内容を決めておくことで、通知の文面も医院や店舗の間でそろうようになりました。

次に、医院や店舗ごとに送信先を管理する形を整えました。同社のサービスでは、医院や店舗が設定画面から通知の送信先を登録します。登録された送信先は Webhook Admin 上でそれぞれの医院や店舗にひもづけられ、どの出来事をどこへ届けるかが一か所で管理されます。同社のサービスは、予約の出来事が起きたときにイベントを一度送るだけで済み、その先の配信は Webhook Admin が受け持ちます。

既存の送信先の移行は、通知の利用が多い Google Chat から始めました。それまでに登録されていた Google Chat の送信先を Webhook Admin に移し、配信の記録を確かめながら、通知が以前と同じように届いていることを確認しました。Google Chat での運用に問題がないことを確かめた後、Teams や Slack、Chatwork の送信先も順に移しています。

医院や店舗への周知では、操作の変化をできるだけ小さくすることを重視しました。送信先を登録する場所や手順は大きく変えず、新たに加わったテスト送信と停止・再開の操作を、設定画面の案内とお知らせで伝えました。利用者が新しい操作を覚えなくても、これまでどおり通知を受け取れることを優先しています。

失敗した配信を確かめられる運用

運用の面で同社が特に重視したのは、届かなかった通知を見落とさないことです。チャットのサービスが一時的に受け付けなかった場合、Webhook Admin は時間をおいて通知を送り直します。短い不調であれば、医院や店舗が気づかないうちに通知が届き、業務に影響は出ません。

送り直しても届かない場合は、その結果が配信の記録に残ります。同社のサポートの担当者は、配信の記録から失敗した通知を確かめ、送信先からどのような応答が返ってきたかを確認できます。送信先のスペースが削除されていたのか、設定に誤りがあったのかを記録から切り分けられるため、医院や店舗への案内も具体的になりました。

医院や店舗の側でも、送信先を自ら確かめられるようになりました。新しく送信先を登録したときは、テスト送信で通知が届くことをその場で確認できます。チャットのスペースを作り直すときや、通知を一時的に止めたいときは、送信先を停止し、準備が整ってから再開できます。作り直しの途中で、使わなくなったスペースへ通知が送られ続ける心配も減りました。

問い合わせへの対応と開発の進め方の変化

Webhook Admin への移行により、予約の通知は一時的な不調があっても再送され、Google Chat との連携は安定しました。通知が届いたかどうかは配信の記録で確かめられるようになり、通知が来なかったという問い合わせにも、記録をもとに落ち着いて対応できるようになりました。

医院や店舗にとっては、通知を自ら管理できる範囲が広がりました。送信先の登録から確認、停止と再開までを設定画面で完結でき、サポートに問い合わせなくても状況を整えられます。通知の設定に関するやりとりが減ったことは、同社のサポートの負担を軽くすることにもつながっています。

開発の面では、配信の仕組みを社内で抱えずに済むようになりました。新しい種類の通知を加えるときも、イベントの種類を登録し、同社のサービスから送るだけで、再送や配信の記録はそのまま備わります。開発の担当者は、予約の受付やシフトの管理といったサービスの中心となる機能の改善に、より多くの時間を使えるようになりました。

医院や店舗のシステムとの連携へ

今後、同社は通知の送り先をチャットにとどめず、医院や店舗が使う外部のシステムとの連携にも Webhook Admin を活用していく方針です。Webhook Admin は HTTP の送信先にも配信できるため、予約の出来事を医院や店舗のシステムに直接届ける形も同じ仕組みで扱えます。

外部のシステムとの連携では、医院や店舗の側で受け取る仕組みを用意する必要があります。同社は、どのイベントをどのような内容で送るかを医院や店舗とその連携先が確かめられるよう、イベントの種類ごとの説明を整え、テスト送信で受け取りの動作を確認できる形を案内していく考えです。

連携の相手が増えても、送り直しや配信の記録、送信先の停止と再開といった運用は変わりません。同社は、チャットへの通知で整えた運用をそのまま広げながら、医院や店舗が予約の情報を日々の業務に生かせる環境づくりを進めていきます。