アポが確定した瞬間は、運用上もっとも情報を配る必要がある場面です。ここで通知が1つ欠けると、当日に誰も準備していないという事故になります。ここでは3者への通知設計を整理します。
3者に届ける
| 宛先 | 目的 | 欠けると |
|---|---|---|
| ① 予約した本人 | 日時の確認と当日の準備 | 忘れる・接続先が分からない |
| ② 商談を担当する側 | 準備と出席 | 当日誰も出てこない |
| ③ 前日架電の担当 | 翌日の架電対象に入れる | 前日の確認が抜ける |
②が抜けると最悪の事故になります。相手は来たのに、こちら側が把握していないという状態です。この1回で信用は失われます。
① 本人への通知
予約した相手に送る内容です。ここに入れるものが決まっています。
| 項目 | なぜ必要か |
|---|---|
| 日時（曜日つき） | 曜日があると勘違いを防げる |
| 接続方法 | 当日「どこに入るのか」で止まらない |
| 所要時間 | 相手が予定を組める |
| 前日に確認の連絡をする旨 | 突然の電話に驚かせない |
| 変更・取消のリンク | 都合が悪くなったときに黙って欠席させない |
| カレンダーに追加する手段 | 相手の予定表に入り、衝突に気づける |
4行目を入れておくと、前日の電話が自然になります。予告なしにかけると「営業の追撃」と受け取られることがあるため、確定時に伝えておきます。
6行目は忘れによる欠席に直接効きます。標準的な形式のカレンダーファイル（.ics）を添付するか、カレンダーに追加するリンクを置きます。
② 社内への通知 ― チャットが向く
社内向けはメールよりチャットが確実です。理由は速度と可視性です。
| 手段 | 向く場面 | 難点 |
|---|---|---|
| チャット（Slack/Chatworkなど） | 確定を即座に知る | 流れて埋もれる |
| メール | 記録として残す | 受信箱で埋もれる |
| 画面（一覧） | まとめて把握する | 見に行かないと気づかない |
3つとも一長一短なので、チャットで即座に知らせ、画面で全体を把握できる形が扱いやすくなります。チャットに流す内容は短くします。
- 会社名・担当者名
- 日時（曜日つき）
- 商談の担当者
- 詳細を開くリンク
ヒアリングの内容までチャットに流すと長くなって読まれません。チャットは「起きたことを知らせる」役割に絞り、内容は画面で見せます。
③ 前日架電の担当への連携
個別の通知よりも、毎日自動で「明日のアポ一覧」が出る形が確実です。
| 方式 | 抜けやすさ |
|---|---|
| 確定ごとに通知を送るだけ | 通知を見落とすと抜ける |
| 毎日「明日の架電リスト」を出す | リストを消化すれば抜けない |
加えて「架電済みだがヒアリング内容が共有されていない」件を検知する仕組みを持つと、渡し忘れが防げます。電話はしたが内容が商談担当に届いていない状態は、外から見えません。
通知が飛ばなかったことを検知する
もっとも危険なのは、通知が失敗したことに気づかない状態です。
| 起きること | 対策 |
|---|---|
| 通知先の設定ミス（URLの失効など） | 送信の成否を記録し、失敗を一覧で見る |
| 相手へのメールがバウンス | バウンスを検知して人に知らせる |
| 通知が1つだけ失敗 | 3者すべての送信結果を個別に記録する |
3行目のように、3者のうち1つだけ失敗することが実際に起きます。「通知処理を実行した」という記録ではなく、宛先ごとの成否を残します。
変更・取消時の通知
確定時と同じく、変更や取消のときも3者に伝えます。
| 出来事 | 通知すること | 忘れやすい処理 |
|---|---|---|
| 日程変更 | 新しい日時を3者へ | 元の枠を再開放する |
| 取消 | 取消の事実を3者へ | 架電リストから外す |
| 欠席 | 実施されなかった記録 | 無効アポの判定に回す |
2行目が抜けると、取消されたアポに前日の電話をかけてしまいます。相手にとっては「取り消したのに電話が来た」という体験になり、再設定の可能性が下がります。
まとめ
- 確定時は3者に通知する。①本人 ②商談担当 ③前日架電の担当
- 本人には日時（曜日つき）・接続方法・所要時間・前日連絡の予告・変更リンク・カレンダー追加手段
- 社内向けはチャットで即座に、詳細は画面で。チャットに長文を流すと読まれない
- 前日架電は個別通知より毎日の架電リストのほうが抜けない。渡し忘れの検知も持つ
- 宛先ごとに送信の成否を記録する。1つだけ失敗することが実際に起きる
- 変更・取消でも3者に通知し、枠の再開放と架電リストからの除外を忘れない
