Google Workspace CRM設計例｜小規模営業チームの台帳・案件・追客・資料・通知の組み合わせ
Google WorkspaceだけでCRMを組むときに、何を「主役」に置くかで設計の安定性が変わります。「全部Sheetsに詰める」「ChatとCalendarで運用」「Driveを正本にする」のどれか1つに偏ると半年で崩れます。役割別に部品を分け、6コンポーネントで組むのが最少構成です。
結論として、Workspace単体CRMは「Sheets台帳・Drive資料・Calendar追客・Forms流入・Chat通知・Gemini補助」の6コンポーネントで組み、原本ルールを最初に固めるのが現実的です。営業10名・取引先200社・履歴2万行を超えたら、Google Workspace CRM や AI CRM への移行検討ラインです。
本記事のポイント
- Workspace単体のCRM設計は「Sheets台帳・Drive資料・Calendar追客・Forms流入・Chat通知・Gemini補助」の6コンポーネントで組むと最も少ない部品数で回せます。
- 原本ルール（会社IDはSheets、資料原本はDrive、次回アクションはCalendar）を最初に固めると半年以上は安定します。
- 営業10名・取引先200社・案件履歴2万行を超えたら、Workspace親和型CRM/AI CRMへの移行検討ラインです。
この記事で扱うテーマ
関連キーワード
- Google Workspace CRM 設計例
- Workspace 簡易 CRM
- Google Workspace 営業 設計
- Workspace CRM テンプレ
- 小規模 CRM Workspace
このページで答える質問
- 小規模営業向けにGoogle Workspaceだけで組むCRMの全体構成はどうすれば良いか？
- 原本ルールはどう決めるべきか？
- 導入手順と必要な運用工数の見積りはどう立てるか？
- Workspace単体運用から、専用CRM・AI CRMへ移行するタイミングは？
設計例の全体像｜6コンポーネント
| コンポーネント | 役割 | 原本ルール |
|---|---|---|
| Sheets台帳 | 会社・担当者・案件・活動履歴の構造化データ | 会社IDの正本 |
| Drive資料 | 提案書・見積・契約書・議事録の保管 | 資料原本の正本（案件IDで命名） |
| Calendar追客 | 次回アクション・期日・リマインダー | 「次に動く日付」の正本 |
| Forms流入 | 問い合わせ・資料DL・イベント申込 | 新規流入のID付与起点 |
| Chat通知 | 停滞・新規流入・期日超過の即時通知 | 運用の声がけ層 |
| Gemini補助 | 要約・分類・文案・整形 | 下処理レイヤー（判断系には使わない） |
最初に決める原本ルール
役割を分けたあと、「どこに正本を置くか」で運用が安定します。次の3つを最初に固めます。
- 会社IDはSheets：表記ゆれの「ホール社・(株)ホール」をIDで一元化
- 資料原本はDrive：案件IDフォルダに集約、ファイル名は「案件ID_資料種別_日付」
- 次回アクションはCalendar：誰が・何を・いつまで、を予定で必ず1件作成
テンプレ詳細は スプレッドシート顧客管理テンプレート および Drive顧客フォルダ設計テンプレート をご覧ください。
コンポーネント別の設計
Sheets台帳
- 会社・担当者・案件・活動履歴・次回アクションの5シート
- ステージ6段階×確度5値×必須8列で軽量に設計
- QUERYで停滞検知・週次レビュー指標を自動表示（パイプラインテンプレ）
Drive資料
- 案件ID単位の親フォルダを「商談Drive」配下に作成
- 共有範囲：商談関係者のみ、四半期ごとに棚卸し
- ファイル名規則を社内ドキュメントで管理（Drive顧客フォルダテンプレ）
Calendar追客
- 「次回アクション=Calendar予定」のルールで、商談後すぐに予定を作る
- タイトル規則：「[案件ID] 次回アクション内容」
- 14日以上動きがない案件は停滞と判定し、Sheets側に表示（Calendar追客テンプレ）
Forms流入
- 問い合わせ／資料DL／イベント申込のFormsで一次受付
- 送信時にApps Scriptで案件ID付与、Sheets台帳とChat通知を同時起動
- 運用は Forms→CRMワークフロー を参照
Chat通知
- 新規流入・停滞・期日超過の3カテゴリで通知ルールを分ける
- 通知は「誰が次に動くか」を必ず指定
- Spaceは部署別（営業／CS）で分け、外部スレッドと混ぜない（Chat通知設計）
Gemini補助
- 整形・分類・要約・タグ付けの下処理に集中
- 判断系は人間レビュー前提（Sheets AI関数の業務活用例）
- 個人情報・契約条件はDLPルールで保護
導入手順｜2週間プラン
- Day 1-2：Sheets台帳の5シート構造を作成、会社・担当者の初期データ投入
- Day 3-4：Drive顧客フォルダ命名規則を社内合意、過去資料を案件IDで再配置
- Day 5-6：Calendar追客の運用ルール・タイトル規則を決定
- Day 7-8：Forms流入のApps Script実装、Sheets連携の動作確認
- Day 9-10：Chat通知のSpace設計と通知ルールを実装
- Day 11-12：Gemini補助の業務テンプレ作成、レビューフローを定義
- Day 13-14：パイロットチームで運用、改善点を反映
運用工数の見積り
| 役割 | 営業1名あたり週次工数 | 主な作業 |
|---|---|---|
| 営業 | 1〜2時間 | Sheets台帳更新、Calendar作成、議事録 |
| マネージャー | 1時間 | 停滞・期日超過レビュー、レポート確認 |
| 営業事務 | 2〜3時間 | Drive資料整理、Sheets品質管理 |
| システム担当 | 30分 | Apps Script動作確認、権限棚卸し |
営業1名あたり週3時間以上の入力工数になったら、CRM/AI CRMへの移行検討ラインです。
移行先の選び方
- Gmail起点でシンプルに：Streak/Copper（Gmail CRM比較）
- 分析・自動化が必要：HubSpot（vs HubSpot）
- 業種規制・大規模：Salesforce（vs Salesforce）
- AI支援を継続運用：AI CRM（AI CRMとは？）
よくある質問
Workspace単体のCRMは何名規模まで使えますか？
営業10名・取引先200社・履歴2万行までが安全圏です。これを超えると入力時間と権限事故が顕在化します。
Apps Scriptは必須ですか？
Forms→Sheets→Chatの自動連携で必要になります。コードは数十行で済むため、社内で1人が保守できる前提で組むのが現実的です。
Driveの共有範囲は誰が管理すべきですか？
営業事務またはオペレーション担当が四半期で棚卸しするのが一般的です。退職・異動と連動させて自動化すると工数が下がります。
Gemini補助は必須ですか？
必須ではありませんが、ライセンスがあるなら整形・分類・要約に組み込むと工数が下がります。導入前に プライバシーとトレーニング を確認してください。
CRMに移行する際、Workspace構成はどう活かせますか？
会社ID・案件ID・ステージ定義はそのまま移行できます。Drive資料・Calendar追客は併用パターンが多く、CRMの正本性とWorkspaceの入口性を共存させます。
複数チームで同じ設計を使えますか？
3チーム程度までは1セットで運用可能です。それ以上は「チーム別Sheetsファイル＋集約Sheets」の2層構造に分けると、関数遅延を抑えられます。
関連ページと関連記事
- Google Workspace CRMとは？：Workspace中心の顧客管理の基礎を確認できます。
- スプレッドシート顧客管理テンプレート：5シート構成の詳細を確認できます。
- スプレッドシート営業案件管理テンプレート：パイプライン設計を確認できます。
- Drive顧客フォルダ設計テンプレート：資料管理の設計を確認できます。
- Calendar追客テンプレート：次回アクション運用を確認できます。
- Chat通知設計：チーム通知の設計を確認できます。
- AI CRMとは？：AI支援を継続運用する設計の全体像を確認できます。
小規模営業のCRM設計を組み立てたい方へ
Sheets台帳・Drive資料・Calendar追客・Forms流入・Chat通知・Gemini補助の6コンポーネントを、自社の組織規模・営業プロセスに合わせて設計します。Workspace単体運用から、CRM/AI CRMへの移行設計まで、ファネル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 の正本と接続できる設計を、早めに小規模で試すと判断材料が揃います。
