はじめに：終わっても何も変わらない会議
営業会議を毎週やっている。しかし終わったあとに残るのは、数字の読み上げ、遅れている案件の確認、「頑張ります」で終わる会話、Excelの更新依頼、CRM入力の催促だけ——そして翌週も同じ話を繰り返している。
これは、営業担当者や会議の進め方の問題ではありません。構造の問題です。
営業会議が機能しない根本原因は、会議の設計ではなく、会議に流れ込むデータ・KPI・CRM運用の設計が存在しないことにあります。Revenue Architectureの観点から見ると、会議は「収益構造の出口」であり、構造が整っていなければ何度やっても同じ結果になります。
機能しない営業会議に共通する3つのパターン
01
数字の定義が揃っていない
営業部長はSalesforceを見て、マーケティングはHubSpotを見て、経営はExcel集計を見る。すると商談数・受注率・ARR・パイプラインがすべて微妙に違う数値になります。会議は「どの数字が正しいか」という確認から始まり、改善議論に入れないまま終わります。これは数字照合作業であって、改善会議ではありません。
02
CRMが「報告ツール」になっている
CRMが売上分析・パイプライン改善・ボトルネック分析のためではなく、「上司への報告」として使われている。すると営業は会議前だけ更新し、ステージを適当に変更し、活動履歴を後入力し始めます。結果としてCRMが信用されなくなり、Excelが主役に戻ります。
03
KPIが「結果」しか見ていない
売上・受注・着地予測だけを確認している会議では改善できません。どこで商談が止まっているか、どの案件が停滞しているか、なぜ受注率が下がったか、どのチャネルの質が悪いか——構造を分析できる指標がなければ、会議は現状確認で終わります。
営業会議が崩壊する5つの構造的原因
問題はさらに深いところにあります。会議そのものを変えても解決しない理由が、構造の中にあります。
01
「何を見る会議か」が決まっていない
営業会議には本来、目的別にいくつかの種類があります。Forecast会議（売上予測確認）、Pipeline会議（商談進捗確認）、KPIレビュー（ボトルネック分析）、Deal Review（重要案件レビュー）、RevOpsレビュー（プロセス改善）——しかし実際には、これらを一つの会議でやろうとします。すると議論が散り、時間が足りず、改善が決まらなくなります。
02
商談ステージ定義が曖昧
「提案中」とは何か、「見込み高」とは何か——営業ごとに解釈が違う状態では、パイプライン・受注予測・商談化率が意味を失います。数字を見ても議論できないため、会議は感覚的な議論か現状報告になります。
03
停滞案件が可視化されていない
営業会議で本来見るべきは「止まっている案件」です。しかし多くの会議では、大きい案件・目立つ案件・声が大きい営業ばかりが議論されます。14日更新なし、次回アクションなし、意思決定者不明——こうした停滞条件が設計されていなければ、問題案件は見えないまま流れます。
04
マーケティングと接続されていない
営業会議では「今ある商談」だけを見ています。しかし本来は、どのチャネルから来たか、どの施策経由か、どの訴求が刺さったかまで見なければ改善できません。営業会議は営業だけの会議ではなく、Revenue Operations全体の会議である必要があります。
05
次アクションが決まらない
数字確認で終わる会議は、誰が・いつまでに・何を改善するかが残りません。これがなければ会議はイベントとして終わり、翌週も同じ状態が繰り返されます。会議を「改善サイクルの起点」にするためには、アクション設計まで含めた構造が必要です。
会議の前に必要なのは「Revenue Architecture」
Revenue Architecture（レベニューアーキテクチャ）とは、営業・マーケティング・カスタマーサクセス・CRM・KPI・データを、売上につながる一つの流れとして設計する考え方です。
営業会議は、この構造の一部です。どの数字を見るのか、何を改善対象とするのか、誰が責任を持つのか、どのKPIを追うのか——これらが設計されていなければ、会議は機能しません。会議だけを変えても、流れ込むデータと定義が整っていなければ、結果は変わりません。
改善型営業会議を設計するために必要なこと
KPIを「結果」だけでなく「構造」で見る
結果KPIだけでは改善できません。途中の構造を見る指標を会議に組み込む必要があります。
| 結果KPI（確認だけになりやすい） | 構造KPI（改善議論ができる） |
|---|---|
| 売上 | 商談化率 |
| 受注率 | 提案率 |
| ARR | 停滞日数 |
| 受注件数 | SQL転換率 |
会議の目的を分割する
一つの会議にすべてを詰め込まず、目的ごとに設計します。
| 会議 | 目的 |
|---|---|
| Forecast会議 | 売上予測確認 |
| Pipeline会議 | 商談進捗確認・停滞案件レビュー |
| KPIレビュー | ボトルネック分析 |
| Deal Review | 重要案件の深掘り |
| RevOpsレビュー | プロセス改善・次サイクル設計 |
Revenue Architectureを整えると、営業会議は変わる
01
どこがボトルネックか分かる
商談化率・提案率・停滞率・更新率が可視化されます。「なぜ受注が取れないのか」ではなく、「どのステージで止まっているか」を構造で議論できるようになります。
02
部門間の責任が整理される
マーケが悪いのか、営業なのか、CSなのか——感覚ではなく、データと構造で議論できます。Revenue Data Flowが設計されていれば、どのフェーズで何が起きているかが見えます。
03
CRMが信頼される
数字のズレが減り、「CRMを見れば分かる」状態になります。CRMへの入力が増えるのではなく、入力する意味が生まれることで自然と使われるようになります。
04
会議時間が短くなる
数字確認に時間を使わなくなると、改善議論だけに集中できます。会議が短くなるのは、効率化ではなく、設計が正しく機能している証拠です。
Consilegyの考え方
Consilegyでは、営業会議の改善を単なる会議改善とは捉えていません。本質はRevenue Architecture・KPI構造・CRM設計・RevOps・Revenue Data Flowの再設計にあります。
Salesforce・HubSpot・Kintone・BI・Slackなどを横断しながら、営業会議が「売上改善の場」として機能する構造を設計します。目的は会議を変えることではなく、会議に流れ込む構造を整えることです。
| 支援領域 | 内容 |
|---|---|
| Architecture | Revenue Data Flow設計・KPI体系設計 |
| Process | 商談ステージ・停滞条件・ハンドオフ条件の定義 |
| Operations | 会議体設計・RevOps体制構築・改善サイクル設計 |
| Technology | HubSpot / Salesforce等のダッシュボード・CRM設計 |
まとめ：営業会議は、構造を映す鏡
営業会議が機能していないとき、問題は会議にあるのではありません。問題は、KPI・CRM・データ・Revenue Architectureにあります。会議はその構造を映す鏡です。
だからこそ、会議だけを改善しても根本解決にはなりません。ファシリテーションを変えても、レポートを追加しても、会議の前段にある設計が変わらなければ、翌週も同じ話が繰り返されます。
必要なのは、「売上がどう生まれるか」を構造から再設計することです。Revenue Architectureが整ったとき、営業会議は「数字確認」から「改善意思決定」へと変わります。