通知を見に行くのを忘れて、対応漏れが起きる
問い合わせへの返信が半日遅れた、商談後のフォローが抜けた、見積の回答期限が過ぎていた。中小企業の営業・営業事務の現場で、こうした「対応漏れ」の相談をよく受けます。担当者が怠けているわけではなく、案件がメール・CRM・スプレッドシート・チャットに分散し、「今どれに対応すべきか」が一目で分からないことが主な原因です。
多くの会社は案件一覧のダッシュボードや管理表を作って解決しようとします。ところが、見に行かないと気づけないダッシュボードは、忙しくなるほど見られなくなります。総務省の情報通信白書でも国内企業のデジタル人材の不足は繰り返し指摘されており、一人が複数業務を兼ねる現場ほど「見に行く時間」がそもそも取れません。
結論: ダッシュボードを増やすより、届くSlack通知に変える
対応漏れを減らす近道は、情報を「見に行く」形から「届く」形へ変えることです。案件の状態を人が確認しに行くのではなく、対応が必要になった時点でSlackに通知が届き、そこから対象へすぐ飛べる。この形にするだけで、同じ情報でも対応漏れは大きく減ります。
Tascaleは、繰り返し業務を「読む・判断する・入力する・共有する・報告する」の5つに分解して考えます。
Slack通知が担うのは、このうち「共有する・報告する」の部分です。ポイントは、通知を情報の垂れ流しにしないこと。「今日やること」「すぐ返信が必要なもの」のように行動単位に絞り、判断と対応そのものは人が担います。全部を流すと、通知は数日で無視されるようになります。
Slack通知に向いている業務
次のような、発生に気づけるかどうかで対応漏れが決まる業務は、通知への置き換えが効きます。
- 問い合わせ・見積依頼メールが届いたら、担当と期限つきで通知する
- 商談や面談が終わったら、フォローすべき相手と期日を通知する
- 一定期間フォローが止まっている案件を、朝にまとめて通知する
- ホットリードや「すぐ返信が必要」な返信を、即時に通知する
- 期限が近い・過ぎたタスクを、担当者本人へ通知する
逆に、緊急性がなく後でまとめて見れば十分な情報は、通知にしないほうがいいです。問い合わせ対応が月80件ある窓口を担当2名で回す想定なら、見直しにかけていた時間を月2〜3時間ほど減らせる目安で、通知は数を絞るほど効きます。
設計例: 入力 → AI処理 → 人の確認 → 既存ツール連携
「商談後のフォロー漏れを防ぐ通知」を設計すると、次の流れになります。
商談・議事録データ → AIが要点と次アクションを整理 → フォロー要否と期日を判定 → 担当者がSlackで確認・対応 → CRMのタスクと状態を更新
- 1カレンダーや議事録から、終わった商談の情報を取り込む
- 2AIが内容を読み、フォローが必要か・いつまでか・誰宛てかを整理する
- 3フォロー要否と期日を仕分け、対象だけを担当者のSlackへ通知する
- 4担当者が通知から内容を確認し、フォローの実行と要否の最終判断を行う
- 5対応結果がCRMのタスクと案件状態に反映され、次の通知条件に使われる
ここで決めるのは、通知の見た目より「どの条件で・誰に・いつ届けるか」です。月120件の商談を担当4名で回す会社を想定すると、1件あたり5分のフォロー確認・漏れチェックが1〜2分まで下げられる試算で、月にすると6時間前後の見直し作業に相当します。あくまで想定条件つきの目安ですが、通知設計の狙いをこの粒度で置くと判断しやすくなります。
実装経験: 「見に行くダッシュボード」を「届く通知」に作り替えた
私自身、自社の営業・CRM運用で通知の仕組みを組んだとき、最初に作ったKPIダッシュボードはほとんど見られませんでした。そこで方針を変え、「今日架電すべきリスト」を毎朝Slackのダイレクトメッセージで自動配信し、KPIも毎日Slackへ通知する形に作り替えました。人が見に行く前提をやめて届く前提に変えたことで、同じデータでも実際に見られる回数がはっきり増えました。
設計で効いたのは、通知を「行動単位」に絞ったことです。ホットリード・返信・要対応はその場で即時に通知し、日次のまとめは毎朝に定時配信する。緊急（即時）と定時（毎朝）を分け、それ以外の情報は通知に混ぜませんでした。営業が毎朝見るのは1つの通知だけ、という状態を目指しました。
もう一つ、展示会後のフォロー自動化を組んだときに痛感したのは、通知の「漏れ」が一番信頼を落とすということです。返信を検知して状態を更新する通知は、取りこぼすと「来たはずの反応が消える」ため、検知を二重にして漏れを防ぐ設計にしました。対応漏れを防ぐための通知こそ、取りこぼしを想定した作りにしておく必要があります。
注意点: 通知を業務に乗せる前に決めること
- 個人情報の扱いを先に決めます。顧客名や商談内容をSlackへ流す場合、チャンネルの公開範囲と閲覧権限を、業務に乗せる前に確認します。
- 誤判定を前提に、人の確認を残します。フォロー不要とAIが整理しても、対応するかどうかは人が決めます。人の関与を残す考え方は、経済産業省・総務省が公表したAI事業者ガイドラインでも、AIを利用する事業者に求められる基本的な視点として示されています。
- 例外の受け皿を用意します。「どちらとも判断できない」案件は自動で処理せず、人のキューへ通知して回します。
- 通知の仕組み自体が止まると対応漏れに逆戻りするため、失敗通知とログを持たせ、手動運用へ戻せる形を保ちます。
導入ステップ: 小さく始める順番
- 1対応漏れが実際に起きている業務を1つ選ぶ（返信・フォロー・期限のいずれか）
- 2その業務で「誰が・何をしたら・どう困るか」を洗い出し、通知すべき条件を1〜2個に絞る
- 3まず1種類の通知だけを作り、届く内容と頻度を現場と調整する
- 4通知から対応した結果を、CRMや管理表の状態へ戻す経路をつなぐ
- 5無視・漏れがないかを確認しながら、通知の種類を少しずつ足す
よくある質問
Q. 通知が多すぎて逆に見なくなりませんか？
そうならないために、通知は行動単位に絞るのが前提です。「今すぐ対応が必要なもの」と「毎朝まとめて見れば十分なもの」を分け、後者を即時通知にしないだけで、通知の数はかなり減ります。情報を全部流すのではなく、対応につながる通知だけを残すのがコツです。
Q. 今使っているCRMやスプレッドシートのままでも作れますか？
作れます。新しいツールへの乗り換えは前提ではありません。今の管理表・CRM・メールから必要なデータを読み、Slackへ通知する経路をつなぐ形が基本です。Slackを使っていない場合も本質は同じで、対応が必要になった時点でメールやほかのチャットへ届く形にできれば同じ効果が得られます。商談後の記録から通知までつなぐ流れは、商談後処理の自動化の考え方と地続きです。
まとめ: 見に行く運用から、届く運用へ
対応漏れは、担当者の注意力ではなく「気づける仕組みがあるか」で決まります。ダッシュボードや管理表を増やすより、対応が必要な時点で届くSlack通知に変え、通知を行動単位に絞って判断と最終対応を人に残すほうが、同じ情報でも漏れは減ります。
Tascaleは外部AI推進室として、通知すべき条件の設計から実装・本番運用後の調整までを月間支援枠の中で支援しています。営業まわりの半自動化の全体像は営業向け自動化を、費用の考え方は料金プランをご覧ください。あわせて、議事録から共有まで作る流れは議事録から次回タスク・お礼メール・Slack共有を作るAI活用法も参考にしてください。