本文へスキップ
Funnel Ai Media AIで、業務を動かす。
📅 2025年11月29日 ⏱️ 8分で読めます

Google ChatでCRM通知を作る方法｜営業チームの対応漏れを止めるSpace・Webhook設計

執筆小林 編集ファネルAi編集部 監修ファネルAi監修チーム 最終更新2026年4月26日
Google Chat上の3カテゴリSpaceとWebhookフローがCRM通知を整理する構造の図

Google ChatをCRMの通知ハブにするときに、Spaceを1つにまとめてしまうと「重要通知が雑談に埋もれる」「メンションが分散する」「過剰通知でミュートされる」という3大失敗が起きます。Space設計・Webhook実装・通知ルールを最初に固めるのが、対応漏れを止める近道です。

結論として、CRM通知は「新規流入」「停滞・SLA超過」「受注・失注」の3カテゴリでSpaceを分け、Webhookでメッセージを送るときは「誰が次に動くか」を必ずメンションします。通知件数が1日30件を超えたら、Chatをハブにしつつ、Workspace CRM や AI CRM で集約と優先度判定を担わせます。

Google Chat CRM通知の3カテゴリSpaceとWebhookフローを示した図
CRM通知は新規流入・停滞・受注失注の3カテゴリSpaceで運用し、Webhookで自動送信する設計が基本です。

本記事のポイント

  1. CRM通知は「新規流入」「停滞・SLA超過」「受注・失注」の3カテゴリでSpaceを分けると埋もれません。
  2. Webhookでメッセージを送るときは「誰が次に動くか」を必ずメンションし、通知先を1名に固定するのが基本です。
  3. 通知件数が1日30件を超えたら、Chatをハブにしつつ、専用CRM/AI CRMで集約と優先度判定を担わせます。

この記事で扱うテーマ

関連キーワード

  • Google Chat CRM 通知
  • Google Chat Webhook 通知
  • Workspace Chat 通知設計
  • Chat 営業 通知
  • Apps Script Chat 通知

このページで答える質問

  • Google ChatでCRM通知を実装する基本構成は何か？
  • 通知のSpace設計と運用ルールはどう決めるべきか？
  • Webhookやアプリ通知は具体的にどう実装するのか？
  • 通知が増えすぎたときに、CRM/AI CRMへ移行するライン・連携設計は？

Space設計｜3カテゴリで分ける

Space用途主なメンバ
新規流入Forms / 名刺取込 / インバウンド架電の通知営業全員＋マーケ
停滞・SLA超過14日以上未更新／SLA超過案件のアラート営業マネージャ＋営業事務
受注・失注クロージング結果と理由営業＋経営＋CS

通知ルール｜守ると埋もれない5原則

  1. メンションは1名：「誰が次に動くか」を1名に絞る、複数メンションは不可
  2. 件名にカテゴリを明記：「[新規流入]」「[停滞14日]」など、冒頭で判別可能に
  3. 案件IDを必ず含める：Sheets台帳・Drive資料との紐付けで案件IDが起点
  4. 次のアクションを1行で示す：「24時間以内に初回連絡」「停滞理由を確認」など
  5. 関連リンクを3本以内：Drive資料・Sheets行・Calendar予定の3つ

Webhook実装｜Apps Scriptで30行

Google Chatの「Webhook」を使うと、Apps Script・外部システム・Cloud Functions のどこからでも通知を送れます。基本のメッセージ送信は次の流れで実装します。

  1. Spaceの「アプリと統合 ＞ Webhookを追加」でURLを取得
  2. Apps Script のスクリプトプロパティにURLを保存（コードに直書きしない）
  3. 送信時はJSON形式でカテゴリ・案件ID・本文・関連リンクを組み立てる
  4. レスポンスを記録して、失敗時のリトライ・ログを残す
// 概略コード
        const payload = {
          text: `[新規流入] DEAL-20260425-001 / ACME株式会社
        <users/12345> 24時間以内に初回連絡
        [Sheets行](https://...) [Drive](https://...) [Calendar](https://...)`
        };
        UrlFetchApp.fetch(WEBHOOK_URL, {
          method: 'post',
          contentType: 'application/json',
          payload: JSON.stringify(payload)
        });

トリガー別の通知シナリオ

トリガー送信先Spaceメッセージ要素
Formsで新規問い合わせ新規流入案件ID／会社名／業種／担当者メンション
Sheetsで14日停滞検出停滞・SLA超過案件ID／停滞日数／担当者メンション
SLA超過（24時間以内未連絡）停滞・SLA超過案件ID／受付時刻／マネージャメンション
受注受注・失注案件ID／金額／受注理由／関係者メンション
失注受注・失注案件ID／失注理由（5択）／再アプローチ条件
受注後30日定期フォロー新規流入（CSスレッド）案件ID／フォロー予定日／CSメンション

過剰通知を防ぐ運用ルール

  1. 1日30件を超えるカテゴリは、優先度（金額×確度）でフィルタ
  2. 同一案件の連続通知は1日1回に集約
  3. 業務時間外は新規流入のみ通知、それ以外は翌営業日の朝に集約配信
  4. クリックされない通知パターンは月次で見直し
  5. Spaceミュート率を月次でモニタリング

CRM/AI CRMへの移行・連携

  • 1日30件超：Chatをハブのまま、専用CRMで通知種別と優先度を集約
  • 営業横断分析が必要：CRM側で通知履歴をBigQuery / Looker Studioへ流し、SLA達成率を可視化
  • AI支援が必要：AI CRMで「対応すべき通知」「保留してよい通知」を分類提案（AI CRMとは？）

セキュリティと監査

  • WebhookのURLは秘密情報、スクリプトプロパティ／Secret Managerで管理
  • 通知本文には個人情報を含めず、案件IDとリンクで参照
  • 退職者のスクリプトオーナー権限を即座に移管
  • Chatのデータ保管・監査ログは管理コンソールで設定

機密データの扱いは Workspace DLPによるCRMデータ保護 を参照してください。

よくある質問

SpaceとDMはどう使い分けますか？

Spaceは部署横断・案件横断の通知、DMは個別の確認用と分けます。Webhook通知は原則Spaceに送り、個別エスカレーションのみDMで補います。

Apps Script以外でもWebhookは使えますか？

使えます。Cloud Functions / Cloud Run、外部CRMのAPI Gateway、ZapierなどのiPaaSからも送信可能です。可観測性とログ保管を担保するなら、Cloud側に寄せるのが現実的です。

通知の見落としを減らす工夫は？

メンション1名固定・件名にカテゴリ明記・関連リンク3本以内が基本です。1日30件を超えるカテゴリは集約配信に切り替えます。

ChatでなくSlack / Teamsを使う場合の違いは？

Workspace連携の密度はChatが最も高くなります。Slack / Teamsを併用する場合、Webhook転送で2系統への配信が可能ですが、運用ルールは1か所に集約するのが安全です。

通知の保管期間はどう決めますか？

Workspace側の管理コンソールでChatの保管・監査ポリシーを設定します。法令や監査要件に応じて、最低90日〜数年の幅で設定されるのが一般的です。

ChatでAIによる優先度判定は実現できますか？

Apps ScriptからGeminiやAI CRMのAPIを呼び、メッセージ送信前に優先度・カテゴリを判定する構成は実現可能です。判断系は人間レビューを挟むのが安全です。

関連ページと関連記事

対応漏れゼロのChat通知を組みたい方へ

Space設計・Webhook実装・通知ルール・運用負荷を、自社の営業組織と通知量に合わせて設計します。Chat単体運用から、CRM・AI CRMの統合通知ハブまで、ファネルAi編集部・監修チームが個別に確認します。

ファネルAiに相談する

実装の落とし穴と継続改善

Google Workspace 中心で CRM を組むときの最大の落とし穴は、データ原本の所在が複数になることです。Gmail のスレッド、Drive のフォルダ、スプレッドシート、Calendar の予定に同じ顧客情報が分散すると、「最新版がどこにあるか」を担当者が判断できなくなり、結果として CRM 全体が信用されなくなります。原本は1か所に集約し、メール・予定・資料は「補助情報」として参照する設計にするのが、Workspace 中心の CRM が長く使われる前提条件です。次の落とし穴は、専用 CRM への移行ラインを見誤ることです。100社・3名・1年運用を超えた段階で、入力時間と権限事故が一気に増えます。「無料で続けるべきか」「移行すべきか」を機能差ではなく、追客漏れ件数・入力時間・レポート負荷で判断するのが現実的です。

継続改善のサイクルは、週次の停滞検知と月次のレポートレビューで作ります。停滞検知は QUERY 関数で14日未更新の案件を自動抽出し、週次の営業会議で「次に動かす責任者」を1名指名します。月次のレポートレビューは、ステージ別の滞留日数・失注理由分布・受注金額のトレンドを Looker Studio で可視化し、改善ポイントを1つだけ決めて翌月に反映します。Gemini や AI 関数を併用する場合は、四半期で「下処理に効いている領域」と「判断に流れていないか」を確認するのが、属人化を防ぐ運用です。AI CRM への移行を視野に入れる組織は、Gmail・Calendar・Drive の文脈を CRM の正本と接続できる設計を、早めに小規模で試すと判断材料が揃います。

メディア一覧へ戻る