AI受付を作るとき、力を注ぎたくなるのは会話の部分です。どれだけ自然に話せるか、どれだけ丁寧に伺えるか。
ところが、現役の葬儀ディレクターの方から開発チームへ寄せられた要望で最も具体的だったのは、会話ではなくその後のことでした。「寝ている時はアラームや電話など、必ず起こす対応も必要」。この記事では、通話が終わってから担当者が起きるまでの十数分を、どう設計したかをお話しします。夜間対応の仕組みを検討されている方が、比較の観点として使えるように書きました。
通知が飛んだことは、伝わったことではない
AI受付の説明で「通話後、担当者に通知が飛びます」という一文をよく見かけます。私たちも最初はそう書いていました。
しかし、深夜2時に届いたメッセージは、届いた時点では読まれていません。当たり前のことですが、設計上は決定的です。AIが完璧に電話を受けても、担当者が朝まで気づかなければ、業務としては何も起きていません。お迎えの車は出ませんし、ご家族は待ち続けます。
ヒアリングでの言葉を、そのまま引用します。
「AIが電話を受けて担当へLINEなりメッセージで送信、寝ている時はアラームや電話など必ず起こす対応も必要」
「担当者からの折り返し電話も安心感を高めるポイント。人が介在する安心感」
後半も重要です。ご家族が安心されるのは、AIが上手に応対したからではなく、人から折り返しが来ると分かったときだという指摘です。折り返しを約束するなら、その人を確実に起こす仕組みが要ります。約束だけして起きないのが、いちばん悪い結果になります。
設計の全体像
通話が終わってから起きることを、順に並べます。
- 通話終了と同時に、ケース(業務単位の記録)を自動生成する
- 深夜帯かどうかを判定する
- 深夜帯なら、当番の担当者を選ぶ
- その担当者に、システムから電話をかける
- 電話のキーで受領を確認する
- 受領されなければ、次の担当者にかける
以下、判断が分かれた箇所だけを説明します。
判断1:深夜帯を、どう判定するか
日本時間の22時から翌7時までを夜間としました。単純に見えますが、実装では2か所つまずきます。
ひとつは、日付をまたぐことです。22時以降か、7時より前か。この「または」を素直に書かないと、23時が夜間でなくなったり、朝6時が判定から漏れたりします。
もうひとつは時差です。サーバーは協定世界時(UTC)で動いています。日本時間の23時はUTCの14時で、日付も違います。ここを取り違えると、日中に担当者を起こす事故になります。
地味ですが、失敗すると被害が大きい箇所なので、この判定だけで複数のテストを書いています。UTC 14時が夜間、UTC 3時は日中、UTC 21時(=翌朝6時)は夜間。境界を1つずつ固定しました。
判断2:誰にかけるか
スタッフ名簿に、通常の連絡先とは別に夜間に鳴らしてよい番号を持たせています。あわせて、その方が夜間に対応できる時間帯と、呼ぶ順番も保持します。
日中の担当者と夜間の担当者は、同じとは限りません。同じ人でも、日中はオフィスの番号、夜間は個人の携帯という運用が普通です。「連絡先」を1つしか持たない設計にすると、この運用が表現できません。ここは最初から分けておくべき箇所でした。
判断3:起きたことを、どう確かめるか
ここが、この設計で最も考えた部分です。
電話をかけて、コール音が鳴って、着信履歴が残る。これは起きた証拠になりません。寝たまま切ってしまうこともあれば、着信に気づかないこともあります。応答があったかどうかも十分ではありません。反射的に出て、また眠ってしまうことは実際に起こります。
そこで、電話に出た担当者にキーを押していただくことにしました。読み上げる内容はこうです。
「トモリ AI 受付からの緊急連絡です」
(ケースの要約を読み上げ)
「引継ぎを受領される場合は 1 を、別の担当者に回す場合は 2 を押してください」
1が押されて初めて、受領とみなします。10秒待って何も押されなければ「応答がありませんでしたので、別の担当者にお繋ぎいたします」と告げて、次の方にかけます。2が押された場合も同様に次へ回ります。
ここで、前の記事に書いた話と矛盾するように見えるかもしれません。ご家族には番号を押させてはいけない、と私たちは書きました。それがクレームに直結すると現場から指摘されたからです。
しかし担当者は違います。業務として受ける側であり、確認が必要な側です。相手によって、設計を変えてよい。むしろ変えなければ、どちらかが不適切になります。
判断4:何を読み上げるか
起き抜けの人に、長い説明は届きません。読み上げるのは1文に絞りました。ケースの内容から、次の要素だけを組み立てます。
- ご逝去のご連絡か、緊急のお問い合わせか
- お電話をくださった方のお名前
- 故人様のお名前(伺えていれば)
- お迎え先(伺えていれば)
詳細は、起きたあとに画面で見ていただきます。電話で伝えるのは「何が起きたか」と「急ぐかどうか」だけで十分です。読み上げには少し間を置き、ゆっくり話す設定にしています。
まだできていないこと
正直に書きます。この仕組みには、まだ穴があります。
全員が応答しなかった場合の受け皿がない
順に電話をかけていき、誰も1を押さなかった場合、エスカレーションは「失敗」として記録されます。しかしそこから先、別の経路で管理者に知らせる仕組みがまだありません。本来は、管理者へのメール・チャット・SMSなど、電話以外の経路で「至急対応」を通知すべき箇所です。
ここは、この記事を書いている時点で未実装です。夜間対応の最後の砦が抜けている状態なので、優先して塞ぐべき課題だと認識しています。
試行の履歴が、担当者の画面から見えない
誰に何時にかけて、応答があったかどうかは記録されています。しかし、ケースの詳細画面にその欄がまだありません。翌朝「なぜ自分に回ってきたのか」を確認する手段が、いまはデータベースの中にしかない状態です。
統計が取れていない
何回目でつながったのか、平均何分で受領されたのか。この数字が見えないと、呼ぶ順番が適切かどうかを判断できません。運用が始まってから必要になる画面です。
検討される方へ:この4つを聞いてください
他社のサービスをご覧になるときも、次の4点は同じように確認できます。
- 担当者が気づかなかったとき、何が起きますか。「通知が飛びます」で終わるなら、そこで設計が止まっています
- 起きたことを、どうやって確かめていますか。着信履歴や応答だけでは、起きた証拠になりません
- 次の人に回るまで、何分かかりますか。そしてそれは設定できますか
- 全員が応答しなかったら、どうなりますか。ここに答えがあるサービスは、実は多くありません(私たちもまだです)
まとめ
- 夜間対応は、電話を受けたところでは終わりません。担当者が起きるまでが受付です
- 通知は届いた時点では読まれていません。深夜は鳴らして起こす必要があります
- 起きた証拠は、着信でも応答でもなく能動的な操作で取ります。当社では電話のキー入力で受領を確認しています
- ご家族には番号を押させない、担当者には押させる。相手によって設計を変えるのが正解でした
- 全員が応答しなかった場合の受け皿は、まだ実装できていません
ご相談ください
次のような状況でしたら、一度お話をお聞かせください。
- すでに何らかの通知の仕組みがあるが、担当者が気づかず朝になったことがある。通知だけでは足りないと実感している
- 宿直の人が電話を受けたあと、担当ディレクターへの引継ぎが口頭になっている。朝まで正確に伝わるか不安が残る
- 夜間の当番を決めてはいるが、その人が出られなかったときの手順が決まっていない。結局は経営者の携帯が鳴っている
Tomori は、葬儀社の夜間・早朝のお電話を AI が一次対応し、引継ぎメモを添えて担当者へお繋ぎするサービスです。
デモ・ご相談のお問い合わせはこちら 株式会社VODE ── 日本の業界知に、音声AIの実装力を。現場のお話を伺うだけのご協力も歓迎しております。