Google Workspace営業ダッシュボードテンプレート｜SheetsとLooker Studioで見るべき12指標
Google Workspaceで営業ダッシュボードを作る目的は、見た目の派手さではなく「会議で意思決定が決まること」です。検索する人の多くは、雛形だけでなく、どの指標を、どの粒度で、誰のために置くかという設計の判断軸まで知りたいと考えています。
結論として、Workspace営業ダッシュボードは、Sheetsに集約した3シートをデータソースにして、Looker Studioで12指標以内・3層構成（週次・月次・四半期）に分けるのが基本構成です。案件数200・複数チーム・予実管理が必要になったら、Google Workspace CRM や AI CRM への移行検討ラインに入ります。
本記事のポイント
- 営業ダッシュボードは、週次・月次・四半期の3層に分け、合計12指標以内で構成すると壊れにくくなります。
- Sheets側のデータは「案件マスタ」「活動履歴」「失注理由」の3シートに集約し、Looker Studioは1ページ6指標・フィルタ4つまでに収めます。
- 案件数200・複数チーム・予実管理が必要になったら、CRMやAI CRMへの移行検討ラインです。
この記事で扱うテーマ
関連キーワード
- Google Workspace 営業ダッシュボード
- Looker Studio 営業 KPI
- Sheets ダッシュボード テンプレート
- Workspace 営業 レポート
- 営業 ダッシュボード 作り方
このページで答える質問
- Google Workspaceで営業ダッシュボードを作るときの基本構成は何か？
- 週次・月次・四半期で何の指標を見ればよいか？
- Looker Studioのダッシュボードを壊さない設計のコツは何か？
- ダッシュボードがスプレッドシート単体で限界に来たときに何へ移すべきか？
基本構成｜Sheets 3シート × Looker Studio 3ページ
Workspace単体で営業ダッシュボードを作るとき、以下の構成が最も壊れにくいパターンです。シートを増やすほど、データソース不一致で集計がずれます。
| レイヤー | 役割 | 主な内容 |
|---|---|---|
| Sheets：案件マスタ | データソース | deal_id、ステージ、確度、想定金額、想定クローズ日、主担当 |
| Sheets：活動履歴 | データソース | deal_id、日付、種別、要約、次アクション |
| Sheets：失注理由 | データソース | deal_id、失注日、理由（5択）、コメント |
| Looker Studio P1 | 週次レビュー | 停滞・新規商談・次アクション件数 |
| Looker Studio P2 | 月次予実 | パイプライン総額・期待値・受注額 |
| Looker Studio P3 | 四半期分析 | 失注理由分布・チーム別生産性・トレンド |
12指標で構成する｜層ごとの選び方
営業ダッシュボードで指標を増やすほど、見られなくなります。週次・月次・四半期の3層に分け、各4指標、合計12指標以内に収めます。
| 層 | 指標 | 用途 |
|---|---|---|
| 週次（P1） | 停滞案件数（14日以上未更新） | 追客漏れの早期発見 |
| 週次（P1） | 新規商談化数 | パイプライン入口の動き |
| 週次（P1） | 翌週の次アクション件数 | 予定の埋まり方 |
| 週次（P1） | 担当別未更新案件数 | 個人の入力遅延 |
| 月次（P2） | パイプライン総額 | 残高観察 |
| 月次（P2） | 期待値（金額×確度） | 当月着地の予測 |
| 月次（P2） | 受注額・受注件数 | 達成と粗の単価 |
| 月次（P2） | 勝率（受注/決着） | 提案後のクロージング力 |
| 四半期（P3） | 失注理由分布（5択） | 商品・価格・タイミングの構造 |
| 四半期（P3） | ステージ別滞留日数 | パイプラインの詰まり |
| 四半期（P3） | チーム別 期待値達成率 | 組織横断の比較 |
| 四半期（P3） | 商談ソース別貢献 | マーケ施策の貢献度 |
Looker Studioで壊さないための設計ルール
Looker Studioのダッシュボードは、設計を間違えると半年で読まれなくなります。最低限の設計ルールを5つ守ると、寿命が伸びます。
- 1ページに指標は6つまで。それ以上は別ページに分ける。
- フィルタコントロールは4つまで（期間・チーム・ステージ・主担当）。
- 計算フィールドは最小化し、極力Sheets側で完結させる。
- データソースは1つに統合する。複数データソース結合はメンテで壊れやすい。
- ステージ・確度・失注理由は「コード値」で持ち、表記ゆれを発生させない。
スプレッドシート単体で起きる典型故障
Workspace営業ダッシュボードは、ほぼ同じ理由で壊れます。先回りで設計に折り込めば、運用寿命が大きく伸びます。
- 指標の追加：「今月だけ見たい」を理由に指標が増え続け、誰も見なくなる。
- ステージ定義の変更：途中でステージを増やし、過去データと比較できなくなる。
- データソースの分散：チームごとにシートを分け、結合に失敗する。
- 関数遅延：QUERY/IMPORTRANGEが遅くなり、Looker Studio側がタイムアウトする。
- 権限事故：Looker Studioの公開URLが社外に渡る。
CRM・AI CRMへ移すべき判断ライン
次のいずれかに当てはまったら、Workspace単体のダッシュボードでは限界に来ています。
- 案件数が200を超え、関数遅延でLooker Studioのページが遅くなった
- 複数チームの予実管理が必要で、ダッシュボードを役員会の正本にする必要がある
- 四半期分析を毎月の判断材料に組み込む必要がある
- 商談ソース別の貢献度を、マーケ・営業・CS横断で可視化したい
専用CRMやAI CRMに移すと、データソースが標準化され、ダッシュボードのメンテ負荷が大きく下がります。AI CRMはさらに、停滞検知・次アクション提案・営業文脈の要約を継続的に組み込めます。設計の全体像は AI CRMとは？ をご覧ください。
よくある質問
指標は何個までに絞るべきですか？
合計12指標以内、1ページ6指標までを推奨します。それ以上はノイズになり、会議で読まれなくなります。
Looker Studioを使わずSheetsだけで作っても問題ありませんか？
10名以下・案件100件未満なら問題ありません。それ以上はLooker Studioに分けたほうが、関数遅延と権限事故を抑えられます。
期待値（金額×確度）の計算はSheets側とLooker Studioのどちらで持つべきですか？
Sheets側で計算し、Looker Studioでは集計のみを行うのが安全です。計算ロジックを2か所に分けると、不一致が発生します。
複数チームのパイプラインをまとめるにはどうすればよいですか？
チームごとにシートを分けず、案件マスタに「チーム」列を持たせて1シートに集約するのが基本です。フィルタで切り替えます。
Geminiやスプレッドシート上のAI関数を組み合わせる利点はありますか？
停滞案件の次アクション提案・失注理由のテキスト要約・議事録の要約に向きます。判断系には組み込まず、下処理に集中させると安全です。詳細は Google Sheets AI関数の業務活用例 をご覧ください。
CRM移行後もLooker Studioのダッシュボードは活きますか？
多くのCRMはBigQueryやREST APIでLooker Studioに接続できます。データソースを差し替えれば、ダッシュボード資産は活きたまま移行可能です。
関連ページと関連記事
- スプレッドシート営業案件管理テンプレート：データソースになる案件シート設計を確認できます。
- Googleスプレッドシート顧客管理テンプレート：会社・担当者・案件の5シート構成を確認できます。
- 無料スプレッドシートCRMの限界：移行を考えるべき境界を確認できます。
- Google Sheets AI関数の業務活用例：AI関数を下処理に使う型を確認できます。
- Google Workspace向けCRMおすすめ：移行先の選び方を確認できます。
- AI CRMとは？：AI支援を継続的に組み込む設計の全体像を確認できます。
営業ダッシュボードを「会議で読まれる状態」に整えたい方へ
指標選定・データ設計・移行計画を、自社の案件規模・チーム構成・予実要件に当てはめて整理します。Sheets単体運用から、CRM・AI CRMを使った継続運用まで、ファネルAi編集部・監修チームが個別に確認します。
