%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
経営会議を意思決定の場として機能させる鍵は、アジェンダそのものの設計にあります。報告は事前共有で済ませ、会議の時間は議論と決定だけに使う。この一点を設計に落とし込めるかどうかで、同じ90分の価値はまったく変わります。
経営会議を意思決定の場として機能させる鍵は、アジェンダそのものの設計にあります。報告は事前共有で済ませ、会議の時間は議論と決定だけに使う。この一点を設計に落とし込めるかどうかで、同じ90分の価値はまったく変わります。
「経営会議の時間の大半が、各部門からの報告で終わってしまう」「会議で決まったはずなのに、翌月も同じ議題を話している」「資料を集めるだけで、会議の準備がひと仕事になっている」——このような悩みを抱えている場合、原因は参加者の意識ではなく、アジェンダの設計にあるケースがほとんどです。
経営会議のアジェンダ設計とは、各議題に「報告・討議・決定」のどれなのかという目的と、「この議題で何を決めるのか」という到達点をあらかじめ書き込み、会議時間の配分まで含めて事前に固定する設計作業です。会議の質を人の力量ではなく、アジェンダという仕組みで担保する考え方だとお考えいただくとわかりやすいかと思います。
本記事では、経営会議を意思決定の場として機能させるためのアジェンダ設計と運営方法を解説します。
本記事は「経営管理とは？目的・業務内容・必要なスキルをわかりやすく解説」シリーズの一部です。
本記事はStartLinkの「経営管理DX完全ガイド」関連記事です。
この記事でわかること
経営会議が「報告会」になってしまっている方に向けて、会議を議論と決定の場に変えるための設計手順を、テンプレートとフレームワーク込みで整理しています。
- 経営会議の目的を「報告の場」から「意思決定の場」に再定義する考え方 — 業績の把握・意思決定・アクション設定という3つの目的を整理し、「報告を聞く」が目的から外れる理由を説明します。
- 月次経営会議のアジェンダテンプレート（90分・6議題構成） — 各議題の目的・時間配分・必要資料を表で示し、そのまま自社の会議に当てはめて調整できる形にしています。
- アジェンダ設計の4つのポイント — 報告と討議をタグで分離する、重要議題を集中力の高い前半に置いて議題数に上限を設ける、データに基づく議論を促す、「決定しない」ことを正式な結論として記録する、という設計の考え方を解説します。
- YWT・信号機方式・OARRの3つのフレームワークの使い分け — どの会議課題にどのフレームワークが効くのかを、向き・不向きまで含めて整理します。
- CRMダッシュボードを会議のインフラにする手順 — スプレッドシートで資料を作り直す運用から抜け出し、リアルタイムの数字を会議の共通言語にする方法を解説します。
経営会議が報告会になっていると感じている経営者・経営企画・管理部門の方に向けて書いています。最後まで読むと、自社の次回の経営会議から使えるアジェンダの型を、自分の手で組み立てられるようになります。
経営会議の目的を再定義する
アジェンダを設計する前に、そもそも経営会議が何のための時間なのかを言語化しておく必要があります。ここが曖昧なまま議題を並べると、「とりあえず各部門から報告してもらう」という構成に戻ってしまうためです。目的が決まれば、その目的に貢献しない議題を落とす判断ができるようになります。
経営会議が果たす3つの役割
経営会議の本来の目的は、以下の3つに整理できます。
| 目的 | 内容 |
|---|---|
| 業績の把握 | 経営状況をリアルタイムに把握する |
| 意思決定 | 経営課題に対する方針を決定する |
| アクション設定 | 決定事項を具体的なアクションに落とす |
この3つの並びを見ると、「報告を聞く」という行為がどこにも入っていないことに気づきます。報告は業績の把握のための手段であって、目的ではありません。手段が目的化すると、報告が丁寧であるほど良い会議だという錯覚が生まれ、資料の読み上げに時間が吸い取られていきます。
「報告を聞く」を目的から外す
報告は事前共有で済ませ、会議では議論と決定に時間を使う。この切り分けが、アジェンダ設計の出発点になります。
事前共有に回すと決めた瞬間、会議中に「その数字はどういう意味か」「だから何をするのか」という問いから始められるようになります。
| 観点 | 報告会型の経営会議 | 意思決定型の経営会議 |
|---|---|---|
| 時間の使い方 | 大半を資料の読み上げに使う | 半分以上を討議と決定に使う |
| 資料の扱い | 会議中に読み合わせる | 48時間前に共有し事前に読む |
| 議題の着地点 | 曖昧なまま終わることがある | 各議題に「決めること」を明記する |
| 決定の記録 | 合意内容が記録に残らず、翌月同じ議題が繰り返されがち | 議事録に決定事項を明記して参加者に共有する |
ただし、事前共有に切り替えてすぐに全員が資料を読んでくるようになるわけではありません。最初の数回は「読んでいない前提」で冒頭に5分の黙読時間を取るなど、移行期間を織り込んだ運営を想定しておくのが現実的です。
目的から逆算して議題を削る
目的が3つに定まると、議題の取捨選択の基準ができます。「この議題は把握・意思決定・アクション設定のどれに当たるか」を問い、どれにも当てはまらない議題は経営会議から外し、別の場に移します。部門内の進捗共有や、担当者レベルで完結する調整は、経営会議で扱う必要がないケースがほとんどです。
月次経営会議のアジェンダ・テンプレート
目的が整理できたら、それを時間配分に落とし込みます。ここでは月次経営会議を想定した90分・6議題の構成を示します。あくまで出発点のテンプレートですので、企業様によって最適な形は異なります。自社の事業構造や意思決定のスピード感に合わせて調整いただく前提でご覧ください。
90分・6議題の基本構成
- 前月業績レビュー ── 目的：把握／時間：15分／資料：月次P/L・予実比較表
- KPIダッシュボード確認 ── 目的：把握／時間：10分／資料：経営ダッシュボード
- 異常値・要注意項目の討議 ── 目的：意思決定／時間：20分／資料：差異分析レポート
- 戦略課題の審議（1〜2件） ── 目的：意思決定／時間：30分／資料：議案書
- アクションアイテム確認 ── 目的：アクション設定／時間：10分／資料：議事録
- 次回までの宿題確認 ── 目的：アクション設定／時間：5分／資料：—
この構成の特徴は、把握に25分、意思決定に50分、アクション設定に15分という配分になっている点です。会議時間の半分以上を意思決定に充てることをひとつの目安とし、この比率が崩れていないかを毎回の振り返りでチェックする指標として使えます。
運営ルールをアジェンダに書き込む
テンプレートだけを配っても、運用のルールが共有されていなければ元の報告会に戻ります。以下のルールをアジェンダ文書の冒頭に固定で記載しておくことをおすすめします。
| ルール | 内容 | 狙い |
|---|---|---|
| 資料は会議の48時間前に共有 | 事前に読んでくることを前提にする | 会議中の読み上げ時間をなくす |
| 報告は3分以内 | 長い報告は資料で済ませる | 討議の時間を確保する |
| 議題ごとに「決めるべきこと」を明記 | 各議題の冒頭に決定事項を記載する | 議論の着地点を全員で共有する |
| 議事録は24時間以内に共有 | 決定事項とアクションアイテムを明記 | 記憶が新しいうちに合意内容を固定する |
自社に合わせた調整の考え方
90分・6議題はあくまで一例です。調整の例を挙げます。
- 週次で経営会議を開いている企業様 ── 戦略課題の審議を月1回に集約し、週次は業績把握とアクション確認だけの30分構成にするほうが機能します。
- 四半期に一度の取締役会に近い会議 ── 戦略課題の審議枠を大きく取り、業績把握は事前共有に全面的に寄せる設計が向いています。
調整する際に守りたいのは、「意思決定に使う時間が全体の半分を下回らない」という一点です。時間が足りないときは、議題を追加するのではなく、把握パートを事前共有に移すことで対応します。
アジェンダ設計の4つのポイント
テンプレートをそのまま使っても、設計思想を理解していないと少しずつ形骸化していきます。ここでは、アジェンダを自社向けに組み替えるときに押さえていただきたい4つのポイントを解説します。どれも「人が気をつける」ではなく「アジェンダの書式で強制する」形にできるのがポイントになってきます。
ポイント1：報告と討議を明確に分ける
アジェンダの各議題に「報告」「討議」「決定」のタグをつけることで、参加者が各議題に対してどのようなスタンスで臨めばよいかが明確になります。「報告」とタグが付いた議題で長い議論が始まったら、ファシリテーターは「これは報告議題なので、討議が必要であれば次回の討議議題に上げましょう」と介入できます。
タグの効果は、介入の根拠が個人の判断ではなくアジェンダに書かれたルールになる点にあります。
誰が司会をしても同じ介入ができる、担当者が変わっても同じ型で会議が回る。これが仕組み化ということです。
ポイント2：重要な議題は前半に、議題数は上限内に収める
経営会議の後半は集中力が下がります。重要度の高い意思決定事項は会議の前半30分以内に置き、業績レポートは後半や事前共有に回すことも検討できます。
ここは前掲のテンプレートとトレードオフになる部分です。テンプレートでは把握から入る構成にしていますが、戦略課題の重みが大きい月は、議題4を議題1に繰り上げる判断があってよいと考えています。順序を固定することより、重要な議題が集中力のある時間帯に置かれていることのほうが大切です。
あわせて、1回の経営会議で扱う議題は5〜7個を上限にします。議題が多すぎると各テーマの討議が浅くなり、重要な意思決定が先送りされます。上限を決めると、議題を追加したい人は既存の議題を落とす提案をしなければならなくなります。この「枠が有限であること」が、議題の優先順位づけを自然に発生させます。上限なく議題を受け付けている限り、優先順位の議論は起きません。
ポイント3：データに基づく議論を促す
「感覚的にはうまくいっていると思う」ではなく、「受注率が前月比5ポイント低下しており、パイプラインの案件質に問題がある」というデータに基づく発言を促す設計が重要です。
この差は、発言者の意識の問題というより、その場で参照できるデータがあるかどうかで決まります。数字を確認するのに誰かがファイルを探し始める会議では、感覚的な発言が増えるのは自然なことです。経営ダッシュボードを会議室のモニターに常時表示し、リアルタイムのデータを参照しながら議論する形式が効果的です。経営ダッシュボードの作り方を参考に、会議用ダッシュボードを設計しましょう。
ポイント4：「決定しない」を決定する仕組み
すべての議題がその場で決定できるわけではありません。「追加情報を○○が△月△日までに収集し、次回決定する」という「決定しないことの決定」も立派な結論です。曖昧なまま放置することだけは避けましょう。
この「決定しない決定」を議事録の正式な分類として用意しておくと、判断を先送りしたこと自体が記録に残ります。記録に残れば次回の冒頭で確認されるため、先送りが無限に続くことを防げます。
経営会議の「型」を作る3つのフレームワーク
アジェンダの枠組みができたら、その中で使う議論の型を決めます。型があると、参加者ごとの報告の粒度がそろい、比較しやすくなります。ここでは3つのフレームワークと、それぞれが効く場面を整理します。すべてを同時に導入する必要はなく、自社の会議で一番困っている部分に効くものを1つ選んでいただくのが現実的です。
フレームワーク1：YWT（やったこと・わかったこと・次にやること）
シンプルな振り返りフレームワークです。各部門のレビューをこの形式で統一すると、報告の質が均一化します。
YWTが効くのは、部門によって報告の粒度がバラバラで比較しづらいという課題があるケースです。「やったこと」だけを長く話す部門と、「次にやること」しか話さない部門が混在していると、経営側は判断材料をそろえられません。3項目に固定することで、少なくとも同じ軸で並べられるようになります。
ただしYWTは振り返りの型なので、まだ実行していない新規の戦略課題を議論する場面には向きません。そうした議題には、後述のOARRで会議の到達点を明示するほうが適しています。
フレームワーク2：信号機方式
KPIをグリーン（順調）・イエロー（注意）・レッド（問題あり）で色分けし、イエローとレッドの項目だけを討議対象にするアプローチです。順調な項目に時間を使わず、問題領域に集中できます。
信号機方式の要は、色の境界をどこに置くかを事前に合意しておくことです。ここが曖昧だと、報告する側が自分に都合のよい色をつけてしまい、会議でその色の妥当性を議論する時間が発生します。色の基準はKPIごとに数値で定義し、判定は人の裁量ではなく基準への当てはめで機械的に行う。ここも仕組みで解決する部分です。
フレームワーク3：OARR（Outcome・Agenda・Role・Rule）
会議の冒頭でOARR（目標・議題・役割・ルール）を確認するフレームワークです。Amazonが全社会議で採用していることで知られています。
| 要素 | 内容 |
|---|---|
| Outcome | この会議で何を達成するか |
| Agenda | どの順番で何を議論するか |
| Role | ファシリテーター・タイムキーパー・議事録者は誰か |
| Rule | 会議中のルール（PC閉じる、発言は1分以内、等） |
OARRの価値は、Role（役割）を毎回明示的に決める点にあります。タイムキーパーが誰か決まっていない会議では、時間超過を誰も指摘できません。役割を会議冒頭で割り当てることで、参加者の誰でもその役を担えるようになり、特定の人がいないと会議が回らない状態を避けられます。新人でも司会やタイムキーパーを引き受けられる形にしておけば、会議運営そのものが引き継げる仕組みになります。
3つの使い分け
| フレームワーク | 効く課題 | 向かないケース |
|---|---|---|
| YWT | 部門ごとの報告の粒度がバラバラ | 未実行の新規戦略課題の議論 |
| 信号機方式 | 順調な項目の報告に時間を取られる | KPIの閾値が未定義な段階 |
| OARR | 時間超過・役割の不在・脱線 | 少人数で目的が明確な定例 |
会議後のアクション管理でループを閉じる
経営会議の効果は、会議中の議論よりも会議後のアクション管理で決まります。どれだけ良い議論をしても、決まったことが実行されなければ次回の会議で同じ議論を繰り返すことになるためです。ここでは、決定を実行につなげる仕組みを整理します。
議事録の必須記載項目
議事録には、次の4項目を漏れなく記載する運用にします。自由記述の議事録ではなく、この4分類に振り分ける形式にしておくのがポイントです。
| 分類 | 記載内容 |
|---|---|
| 決定事項（Decision） | 会議で確定した方針 |
| アクションアイテム（Action） | 担当者・期限・成果物 |
| 継続検討事項（Pending） | 次回までの宿題 |
| 特記事項（Note） | 議論の要点 |
アクションアイテムで欠けやすいのが「成果物」です。担当者と期限だけを書くと、何をもって完了とするかの解釈が分かれます。「市場調査を行う」ではなく「競合3社の価格体系を比較した1枚資料を提出する」まで書き切ることで、次回の進捗確認が事実確認で済むようになります。
24時間以内の共有と冒頭確認
議事録は24時間以内に全参加者に共有し、翌月の会議冒頭で前回のアクションアイテムの進捗を確認します。この「ループを閉じる」仕組みが、会議を形骸化させないための鍵です。
冒頭確認を固定の議題として組み込んでおくと、アクションアイテムが毎回人目に触れる状態になります。未着手のまま次回を迎えることが可視化されるため、「会議で決まったが誰もやっていない」という状態が続きにくくなります。
スプレッドシート管理の限界
議事録はドキュメント、アクションアイテムはスプレッドシート、業績データは別のファイル、という具合に情報が分散すると、進捗を確認するたびに複数のファイルを行き来することになります。
さらに、担当者が自分でスプレッドシートを更新する運用は、更新漏れが常に起き続けます。人に「ちゃんと更新してね」とお願いする運用ではなく、アクションアイテムを既存のタスク管理やCRMのタスク機能に載せ、期限が近づいたら自動で通知が飛ぶ形にするほうが、結果的に長続きします。
CRMダッシュボードを経営会議のインフラにする
ここまでの設計を支えるのが、会議で参照するデータそのものです。経営会議でよく議題に上がるのが営業パイプラインの状況ですが、その数字を毎月手作業で集計していると、会議の準備だけで相当な工数がかかります。データを取りに行く場所を一本化することが、アジェンダ設計を実務で回すための前提条件になってきます。
スプレッドシート集計から脱却する
スプレッドシートで手作業集計を続ける方法には、次の3つの問題があります。
- 集計に時間がかかること
- 入力時点と会議時点でデータがずれること
- 数字の定義が部門ごとに微妙に異なること
特に3つ目は議論の質に直結します。営業部門が言う「商談数」と経営企画が集計した「商談数」の定義が違うと、会議の時間が数字のすり合わせに消えてしまいます。CRM上で取引ステージを定義し、そこから自動集計する形にすれば、数字の定義は1つに固定されます。
パイプラインの加重予測を会議の共通言語にする
HubSpotのカスタムダッシュボードを使えば、パイプラインの金額・件数・ステージ別推移・受注予測をリアルタイムで表示でき、データに基づいた営業議論が可能になります。
ここで効いてくるのが、取引ステージごとに受注確度を設定しておく設計です。この加重予測をダッシュボードに置いておくと、「今月の着地はいくらになりそうか」という問いに対して、感覚ではなく数字で即座に答えられるようになります。ステージ設計・受注確度・ステージ定義・必須入力プロパティという4つの要素を先に整えておくことが、経営会議で使える数字を作る土台になります。
上の画面は、デモ環境のHubSpotレポートで、取引パイプラインの件数と金額をステージ別に表示した例です。どのステージに案件が滞留しているか、金額ベースでどこに偏りがあるかをひと目で確認できます。
全体フローの中での位置づけ
経営会議のダッシュボードは、単独で存在するものではありません。コンタクトの獲得、リードの選別、取引の創出、受注、そして請求までの一連の流れの中で蓄積されたデータが、最終的に経営会議の数字として立ち上がってきます。
つまり、経営会議で見たい数字を決めることは、その手前のどこでどんなデータを入力すべきかを決めることと同じです。
会議で受注率を見たいなら取引ステージの移行が正確に記録されている必要がありますし、失注理由の傾向を見たいなら失注時に理由を必須入力にする設計が要ります。会議のアジェンダから逆算して、日々のデータ入力ルールを決める。この順序で考えると、現場に入力をお願いする理由も説明しやすくなります。
なお、この考え方自体はHubSpotに限ったものではありません。リレーショナルデータベースを持つCRMでも、ステージ定義と必須入力の設計は同様に実現できます。大切なのはツールの選択よりも、会議で見たい数字から逆算して入力の型を決める順序です。
経営管理指標・KPIの設計方法で解説したKPIツリーをダッシュボードに反映し、経営会議のインフラとして活用しましょう。
AIに任せられる部分と、人が判断すべき部分
会議運営の一部はAIで効率化できます。議事録の一次作成、各部門の報告テキストの要約、ダッシュボードの数字から異常値を拾い上げる作業などは、AIの得意領域です。一方で、事業の文脈を理解した人間が担うべき領域もあります。
| AIに任せられる作業 | 人が判断すべき領域 |
|---|---|
| 議事録の一次作成 | 経営会議に上げる議題の選別 |
| 各部門の報告テキストの要約 | 戦略課題に対する最終的な意思決定 |
| ダッシュボードの異常値の拾い上げ | 議題の優先順位づけ |
私たちも、AIが作った議事録の下書きをそのまま配布することは推奨していません。決定事項の文言は、後から解釈の余地が残らないよう人の目で確認する運用が無難です。叩き台をAIに作らせ、要所を人が詰める。この役割分担が現実的かと思います。
段階的に導入するための進め方
ここまでの内容をすべて一度に導入しようとすると、現場の負荷が高くなり、途中で元の運用に戻ってしまいます。なかなか全てを一気に進めるのは難しいかと思いますので、効果が出やすいところから優先順位をつけて取り組んでいただければと思います。
第1段階：アジェンダの書式を変える
最初の一歩として、システムを触る必要のない部分から始めます。次の2つだけであれば、次回の会議から着手できます。
- アジェンダの各議題に「報告・討議・決定」のタグと「この議題で決めること」の一文を追加する
- 議題数を7件以内に絞る
ここで効果が実感できると、その後の変更にも協力を得やすくなります。逆に、最初からダッシュボード構築のような重いタスクから入ると、成果が見えるまでの期間が長く、推進力が続きません。
第2段階：事前共有と議事録のループを固める
次に、資料の48時間前共有と、議事録の24時間以内共有・冒頭での進捗確認を定着させます。この段階では、資料の中身を変えるのではなく、タイミングのルールだけを固定するのがコツです。
ここまでで、会議の「型」はおおむね整います。まだデータは手作業で集めている状態ですが、会議そのものは議論と決定の場に変わっているはずです。
第3段階：データ基盤を会議に接続する
最後に、手作業で作っていた資料をCRMのダッシュボードに置き換えていきます。ここも一気に全KPIをダッシュボード化するのではなく、まずは受注金額や受注件数といった、定義がはっきりしていて集計しやすい指標から着手するのが進めやすいかと思います。
| 段階 | 取り組む内容 | 主な変化 |
|---|---|---|
| 第1段階 | アジェンダの書式変更・議題数制限 | 議論の着地点が明確になる |
| 第2段階 | 事前共有と議事録ループの固定 | 決定が実行につながる |
| 第3段階 | ダッシュボードの会議接続 | 資料作成工数が下がり数字が共通言語になる |
この設計が向かないケース
正直に申し上げると、この設計がすべての組織に当てはまるわけではありません。意思決定者が1〜2名で、日常的に同じ場所で議論できている少人数の組織では、フォーマルなアジェンダ設計がかえって意思決定を遅くすることがあります。
また、事業環境が急速に変化していて、月次のサイクルでは判断が間に合わない局面でも、月次経営会議の型に固執するのは得策ではありません。そうした場合は、意思決定そのものは随時行い、経営会議は決定の共有と振り返りの場に位置づけ直すほうが機能します。型は目的を果たすための手段ですので、目的に合わなくなったら型のほうを変える。この前提は持っておいていただければと思います。
よくある質問
Q1. 経営会議の時間はどのくらいが適切ですか？
月次経営会議は90分を推奨します。会議時間の多くが報告に費やされると、意思決定に使える時間はごくわずかになります。アジェンダを5〜7議題に制限し、報告は事前共有（48時間前）で済ませて、会議では議論と決定に集中する設計が必要です。
Q2. 経営会議が報告会になってしまう場合、どう改善すればよいですか？
各議題に「報告」「討議」「決定」のタグを明記し、報告は3分以内に制限してください。議題ごとに「決めるべきこと」を冒頭に記載し、データに基づく発言を促す設計が効果的です。経営ダッシュボードを会議室に表示し、リアルタイムデータを参照しながら議論する形式も有効です。タグがあることで、司会が誰であっても同じ基準で介入できるようになります。
Q3. 議事録の運用で最も重要なポイントは何ですか？
決定事項・アクションアイテム（担当者・期限・成果物）・継続検討事項を漏れなく記載し、24時間以内に全参加者に共有することです。翌月の会議冒頭で前回アクションの進捗を確認する「ループを閉じる」仕組みが、会議の形骸化を防ぐ鍵になります。特にアクションアイテムの「成果物」を具体的に書き切ることが、進捗確認を事実確認で済ませるポイントです。
Q4. 事前に資料を読んでこない参加者がいる場合はどうすればよいですか？
移行期は「読んでいない前提」で運営するのが現実的です。会議冒頭に5分程度の黙読時間を設け、そのうえで報告は3分以内に制限する運用から始めます。事前共有のルールを守らない人を責めるのではなく、守らなくても会議が回る設計を先に作り、徐々に黙読時間を短くしていく進め方をおすすめします。
Q5. CRMのダッシュボードは、どのKPIから作るのがよいですか？
定義がはっきりしていて集計しやすい指標から始めるのが進めやすいかと思います。受注金額や受注件数のように、取引データから直接算出できるものが取り掛かりやすい部類です。最初から全KPIを網羅しようとすると設計が止まりがちですので、経営会議で毎回確認する数字を3つ程度選び、そこから広げていく進め方をおすすめします。
まとめ
経営会議の時間は、放っておくと大半が報告に費やされます。報告は事前共有（48時間前）で済ませ、会議は議論と決定に集中する。この切り分けをアジェンダの書式に落とし込むことが、会議設計の核心です。
本記事の要点を整理すると、以下のようになります。
- 経営会議の目的は業績の把握・意思決定・アクション設定の3つであり、「報告を聞く」は目的ではないこと
- アジェンダは5〜7議題に制限し、各議題に「報告・討議・決定」のタグと「決めるべきこと」を冒頭に明記すること
- 議事録は24時間以内に共有し、翌月冒頭で前回アクションの進捗を確認してループを閉じること
- CRMダッシュボードを経営会議に組み込み、リアルタイムデータを会議の共通言語にすること
まずは、次回の経営会議のアジェンダに「報告・討議・決定」のタグを付けるところから始めてみてください。システムを触る必要がなく、その日のうちに着手できる一歩です。
具体的には、次の3ステップで進めていただくのが取り掛かりやすいかと思います。
- 直近3回分の経営会議のアジェンダを並べ、各議題が「報告・討議・決定」のどれだったかを分類し、報告に使われた時間の割合を出す
- 次回のアジェンダで議題を7件以内に絞り、各議題に目的タグと「この議題で決めること」の一文を追加する
- 会議で毎回確認する数字を3つ選び、それがCRMやシステムから自動で取り出せる状態になっているかを確認する
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
