📅 2025年11月28日 ⏱️ 7分で読めます

Googleカレンダーで追客漏れを防ぐテンプレート｜次回アクション・SLA・停滞検知の設計

執筆小林編集ファネルAi編集部監修ファネルAi監修チーム最終更新2026年4月26日

案件IDタイトル、SLAリマインダー、停滞検知の3点セットがカレンダーで連動する構造の図

Googleカレンダーは予定管理ツールに見えますが、営業の文脈では「次回アクションを強制する道具」です。商談メモが残っていても、Calendarに次回予定が入っていなければ、ほぼ確実に追客は止まります。

結論として、追客漏れを止める設計は「タイトルに案件ID」「SLAごとのリマインダー」「14日停滞検知」の3点セットです。営業10名・案件100件を超えたら、Calendar単独ではなく Workspace CRM や AI CRM の連携前提に切り替えます。

Calendar追客テンプレートの3点セット（タイトル・SLA・停滞検知）を示した図 — Calendar追客テンプレートは「タイトルに案件ID」「SLAごとのリマインダー」「14日停滞検知」の3点で組みます。

本記事のポイント

追客漏れを止める設計は「タイトルに案件ID」「SLAごとのリマインダー」「14日停滞検知」の3点セットです。
次回アクションは商談直後にCalendar予定を作るルールにし、Sheets台帳と双方向で同期させます。
営業10名・案件100件を超えたら、Calendar単独ではなく専用CRM/AI CRMの連携前提に切り替えます。

この記事で扱うテーマ

タイトル規則｜案件IDを必ず含める

追客予定のタイトルは [案件ID] 何をする_対象会社 を標準にします。検索性・並び替え・台帳との結合のすべてに効きます。

例：[DEAL-20260425-001] 提案書送付_ACME株式会社
商談・初回連絡・送付・フォロー・督促の5動詞で動詞を固定
会社名は省略せず、会社IDと併記しない（タイトルが長くなる）

SLA別のリマインダー設計

カテゴリ	SLA（最遅期日）	リマインダー
新規問い合わせ初回連絡	24時間	4時間前＋ 1時間前
提案書送付	3営業日	前日＋当日朝
クロージング後の督促	5営業日	3日前＋前日
定期フォロー（受注後）	30/90/180日	1週間前
長期休眠掘り起こし	180日	2週間前

14日停滞検知をSheetsで自動化

Calendarに予定があっても、完了せず「過去日付のまま」になる予定が出ます。Sheetsで14日以上更新がない案件を自動検知して、停滞リストに表示します。

=QUERY(案件!A:H, "select A,B,C,D,F where D!='決着' and B<date '"&TEXT(TODAY()-14,"yyyy-mm-dd")&"'", 1)

停滞検知の詳細はスプレッドシート営業案件管理テンプレートをご覧ください。

CalendarとSheetsの双方向同期

Calendar単独で運用すると、Sheets台帳の「次回アクション列」と乖離します。次の自動化を入れて、片方を更新したら他方も更新される状態を作ります。

Sheetsに「次回アクション日付」を入力すると、Apps ScriptでCalendar予定を作成
Calendar予定を完了マークすると、Sheetsの活動履歴に転記
Calendarで予定を移動すると、Sheets側の日付も自動更新
Sheetsで案件のステージを「決着」にすると、Calendar予定を自動削除

営業マネージャの週次レビュー

停滞検知をマネージャの月曜朝の定例にすると、追客漏れの早期発見につながります。

14日以上動きがない案件を停滞リストで確認
担当別の未更新件数で偏りを把握
SLA超過の予定を別シートで一覧表示
金額×確度の上位案件で動きが鈍いものを抽出

Calendar単独運用の限界

営業10名超で予定の所有者が分散し、横串の停滞検知が手作業化
案件100件超で、案件IDの重複や誤入力が頻発
受注後のCS引き継ぎが、Calendar単独ではトレースできない
SLA達成率を継続的に分析する基盤がない
AI支援（次アクション提案・要約）を組み込みづらい

CRM/AI CRMへの接続

Calendarをそのまま捨てるのではなく、CRMやAI CRMの「次回アクションを動かす入口」として残すと、運用負荷が一気に下がります。

CRMの活動履歴とCalendarの予定を案件IDで結合
AI CRMで停滞検知＋次アクション提案を自動化（AI CRMとは？）
CalendarはGmail/Meetとの連動性を活かす入口に固定

よくある質問

Calendarのタイトルに会社名を入れるとプライバシー上問題ありませんか？

共有範囲を「自分のみ」または「営業チーム限定」にしている前提なら問題ありません。タイトルが社外Slack/Teamsへ流れるアラート連携を入れている場合は、案件IDのみに留めます。

Apps Scriptでの自動化は誰が保守すべきですか？

営業事務またはオペレーション担当が保守する想定で、コードは50行以内に収めるのが目安です。複雑化したら専用CRMでの実装に切り替えます。

SLAを守れない場合の対処は？

マネージャに即時通知（Chat）して、別担当への振り替えを早期に決めます。SLAは厳守ではなく、超過時のエスカレーション設計が重要です。

受注後のCSフォローはどう設計しますか？

受注時に「30日後・90日後・180日後」の定期フォロー予定を一括作成します。Apps Scriptでテンプレ予定を生成すると、抜け漏れがなくなります。

休眠顧客の掘り起こしはどう運用すべきですか？

失注理由・最終接触日に応じて180日後・360日後の予定を自動作成します。再アプローチ時の文脈をAI CRMで補助すると、初動が速くなります。

予定の所有者が異動した場合の引き継ぎは？

異動時に「該当案件IDの予定を新担当へ移管」するスクリプトをまとめて実行します。共有カレンダーで運用すると、所有者依存を減らせます。

追客漏れを止める運用を作りたい方へ

タイトル規則・SLAリマインダー・停滞検知の3点セットを、自社の営業プロセス・案件量に合わせて設計します。Calendar単独運用から、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 の正本と接続できる設計を、早めに小規模で試すと判断材料が揃います。

メディア一覧へ戻る