電話に出るだけでは、夜間対応は終わらない ── 担当者が「起きる」までを設計する

AI受付を作るとき、力を注ぎたくなるのは会話の部分です。どれだけ自然に話せるか、どれだけ丁寧に伺えるか。
ところが、現役の葬儀ディレクターの方から開発チームへ寄せられた要望で最も具体的だったのは、会話ではなくその後のことでした。「寝ている時はアラームや電話など、必ず起こす対応も必要」。この記事では、通話が終わってから担当者が起きるまでの十数分を、どう設計したかをお話しします。夜間対応の仕組みを検討されている方が、比較の観点として使えるように書きました。

通知が飛んだことは、伝わったことではない

AI受付の説明で「通話後、担当者に通知が飛びます」という一文をよく見かけます。私たちも最初はそう書いていました。

しかし、深夜2時に届いたメッセージは、届いた時点では読まれていません。当たり前のことですが、設計上は決定的です。AIが完璧に電話を受けても、担当者が朝まで気づかなければ、業務としては何も起きていません。お迎えの車は出ませんし、ご家族は待ち続けます。

ヒアリングでの言葉を、そのまま引用します。

「AIが電話を受けて担当へLINEなりメッセージで送信、寝ている時はアラームや電話など必ず起こす対応も必要」
「担当者からの折り返し電話も安心感を高めるポイント。人が介在する安心感

後半も重要です。ご家族が安心されるのは、AIが上手に応対したからではなく、人から折り返しが来ると分かったときだという指摘です。折り返しを約束するなら、その人を確実に起こす仕組みが要ります。約束だけして起きないのが、いちばん悪い結果になります。

設計の全体像

通話が終わってから起きることを、順に並べます。

  1. 通話終了と同時に、ケース(業務単位の記録)を自動生成する
  2. 深夜帯かどうかを判定する
  3. 深夜帯なら、当番の担当者を選ぶ
  4. その担当者に、システムから電話をかける
  5. 電話のキーで受領を確認する
  6. 受領されなければ、次の担当者にかける

以下、判断が分かれた箇所だけを説明します。

判断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点は同じように確認できます。

  1. 担当者が気づかなかったとき、何が起きますか。「通知が飛びます」で終わるなら、そこで設計が止まっています
  2. 起きたことを、どうやって確かめていますか。着信履歴や応答だけでは、起きた証拠になりません
  3. 次の人に回るまで、何分かかりますか。そしてそれは設定できますか
  4. 全員が応答しなかったら、どうなりますか。ここに答えがあるサービスは、実は多くありません(私たちもまだです)

まとめ

ご相談ください

次のような状況でしたら、一度お話をお聞かせください。

Tomori は、葬儀社の夜間・早朝のお電話を AI が一次対応し、引継ぎメモを添えて担当者へお繋ぎするサービスです。

デモ・ご相談のお問い合わせはこちら 株式会社VODE ── 日本の業界知に、音声AIの実装力を。現場のお話を伺うだけのご協力も歓迎しております。