%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}
この記事の結論
会議の決定事項が動かない原因は、担当者の意欲よりも記録と追跡の設計にあります。決定を「責任者・期限・理由」つきで記録し、CRM上で追跡できる状態をつくること。
会議の決定事項が動かない原因は、担当者の意欲よりも記録と追跡の設計にあります。決定を「責任者・期限・理由」つきで記録し、CRM上で追跡できる状態をつくること。
「先月の会議で決めたはずの件、結局どうなったんだっけ」「議事録には書いてあるけれど、誰がやるのかが分からない」「同じ議題がまた会議に上がってきた」——こうした声が出る組織では、決めることはできていても、決めた後の流れが仕組みになっていません。
意思決定の記録と追跡とは、会議で決めた内容を「誰が・何を・いつまでに・どのように」の形で残し、実行が完了するまで進み具合を関係者が見える状態に保つ運用です。記録の品質と追跡の仕組みの2つがそろうと、決定事項が実行に移る割合を上げられます。
本記事は会議ナレッジ活用カテゴリに属しています。経営管理全体を体系的に学びたい方は経営管理完全ガイドをご覧ください。
この記事でわかること
会議の運営を担うマネージャーや経営企画の担当者が、決定事項の記録から実行の追跡までを自社で設計できるよう、次の4点を順に扱います。
- 意思決定が実行されない原因と組織に与える影響 — 曖昧な記録、責任の所在の不明確さ、追跡の欠如という3つの原因と、その見分け方を整理します。
- 決定事項を正確に記録するためのフレームワーク — DACIフレームワークで役割を分け、決定理由・代替案・前提条件まで残すテンプレートを紹介します。
- アクションアイテムの追跡を仕組み化する具体的な方法 — 会議冒頭のレビュー、週次の棚卸し、ダッシュボードでの可視化を組み合わせる運用を解説します。
- CRMを活用した意思決定の一元管理と可視化の手順 — 顧客関連の意思決定を商談や取引と紐付け、担当者が替わっても経緯を追える状態のつくり方を説明します。
意思決定が実行されない3つの原因
会議で決めたのに動かない状態には、共通する原因があります。本記事では、それを記録・責任・追跡の3点に分けて整理します。自社がどれに当てはまるかによって、最初に手を入れる場所が変わります。
原因1：決定事項の記録が曖昧
「前向きに検討する」「方向性としてはA案で進める」といった曖昧な表現で記録された決定事項は、関係者の解釈がばらつきます。
対策は、決定事項を「誰が・何を・いつまでに・どのように」の4要素を含む形で書くことです。会議の最後に決定事項を1件ずつ読み上げ、4要素のうち欠けているものがあれば、その場で埋めます。その場で埋められない場合は「決定」ではなく「継続検討」として記録し、次回の議題に戻します。決定と検討を分けて書くだけでも、後から読んだ人の解釈のずれは小さくなります。
原因2：責任の所在が不明確
「チームで対応する」「関係部署で調整する」といった記録は、結局誰も動かない原因になります。複数人が関わる案件ほど、「誰かがやるだろう」という空白が生まれやすくなります。
責任者は個人名で指定し、その人が実行の推進と報告を担う形にします。実際の作業を複数人で分担するのは問題ありません。分担と責任を分けて考え、「進捗を報告する人」を1人に決めておくことがポイントになってきます。
原因3：追跡の仕組みがない
決定事項を記録しても、その後の進捗を見る仕組みがなければ、記録は死蔵されます。ナレッジマネジメントの観点からも、次回の会議で前回の決定事項を振り返る時間を設けていない組織は、同じ議題が繰り返し会議に上がる悪循環に陥ります。
3つの原因は、次のように見分けられます。
| 原因 | 見分け方 | 最初の打ち手 |
|---|---|---|
| 記録が曖昧 | 直近の議事録で、期限のない決定事項が混ざっている | 4要素（誰が・何を・いつまでに・どのように）の記入欄を設ける |
| 責任の所在が不明確 | 担当欄に部署名やチーム名が入っている | 担当欄を個人名のみに限定する |
| 追跡の仕組みがない | 前回の決定事項が次回の会議で話題に出ない | 会議の冒頭に前回決定事項のレビュー枠を置く |
複数に当てはまる場合は、記録の曖昧さから着手することをおすすめします。記録が曖昧なまま追跡の仕組みだけを整えても、追いかける対象がはっきりしないためです。
議事録とスプレッドシートでの管理が行き詰まる理由
決定事項の管理は、議事録ファイルとスプレッドシートの一覧から始めるケースが多くあります。最初はそれで回りますが、会議体や関係者が増えると限界が見えてきます。ここでは、手作業の管理がどこで行き詰まるかを整理します。
情報が複数の場所に散らばる
議事録は共有フォルダ、アクションの一覧はスプレッドシート、進捗の報告はチャットというように、情報が分かれて置かれるケースがあります。顧客リストと担当者の一覧が別々に存在し、内容に差分が生まれるのと同じ構造です。
更新が人の記憶に依存する
スプレッドシートの一覧は、誰かが手で更新しない限り変わりません。担当者が作業を終えても一覧に反映されなければ、会議では「未完了」のまま扱われます。更新役が1人に集中している場合、その人が不在になると一覧そのものが止まります。
決定の背景が商談・顧客情報とつながらない
「この顧客には値引きを認める」「提案内容をA案に決定」のような商談に関わる意思決定は、議事録だけに残すと、後から取引の経緯と突き合わせるのが難しくなります。担当者が替わったとき、取引の記録だけを見ても「なぜこの条件になったのか」が分からない状態が生まれます。
判断の目安として、次の2点を見てください。
- 更新が特定の1人に集中している場合 ── 決定事項の一覧を更新しているのが特定の1人だけで、ほかの人はチャットで状況を聞いているなら、更新の仕組みを人からシステムへ移す段階です。
- 顧客や商談に関わる決定が多い場合 ── 決定事項の多くが顧客や商談に関わるものなら、議事録とは別の場所ではなく、取引のレコードと同じ場所に記録を置くことを検討してください。
決定事項を記録するフレームワーク「DACI」
記録の曖昧さと責任の不明確さを同時に解消するために、役割の型を使います。意思決定の記録には、DACIフレームワークが有効です。DACIはDriver（推進者）、Approver（承認者）、Contributor（貢献者）、Informed（情報共有先）の頭文字を取ったものです。
| 役割 | 説明 | 人数 | 主な責務 |
|---|---|---|---|
| Driver（推進者） | 決定事項の実行を推進する責任者 | 1人 | タスクの分解、スケジュール管理、進捗報告 |
| Approver（承認者） | 最終的な承認権限を持つ人物 | 原則1人 | 上位管理職やプロジェクトオーナーが該当。1人に絞ることで承認プロセスの遅延を防止 |
| Contributor（貢献者） | 決定の実行に必要な知見やリソースを提供する関係者 | 複数人可 | Driverの支援者。実行の最終責任はDriverが負う |
| Informed（情報共有先） | 決定内容と進捗を知っておくべき関係者 | 複数人可 | 直接の作業は担当しないが、結果の影響を受ける。メール・チャットでの共有で十分 |
アトラシアンでは、製品開発の意思決定にDACIフレームワークを全社的に導入しており、Confluenceのテンプレートとして標準化されています。
4つの役割の読み方
表のうち、運用で特に効くのはDriverとInformedの区別です。Driverは「実行が止まったときに声を上げる人」、Informedは「結果だけ知っていればよい人」と捉えると分かりやすくなります。Informedに入る人を会議に呼ぶ必要はなく、決定内容と期限を共有するだけで足ります。会議の参加者を絞るときの基準にもなります。
DriverとApproverを1人に絞る理由
Driverが2人いると、進捗が遅れたときに互いが相手の対応を待つ状態が起きやすくなります。Approverが複数いると、全員の承認がそろうまで次に進めず、承認待ちの時間が延びます。どちらも1人に絞るのは、止まったときに「誰に聞けばよいか」を1か所にするためです。
判断に迷う場合は、「この件が期限までに進まなかったとき、理由を説明する立場にあるのは誰か」を問いかけてください。その人がDriverです。答えが2人に分かれるなら、決定事項そのものを2つに分けて、それぞれにDriverを置きます。
会議のその場でDACIを決める手順
DACIは会議の後で埋めるより、決定したその場で埋める方が漏れが少なくなります。手順は次のとおりです。
- 決定内容を1文で読み上げ、参加者の解釈がそろっているかを確かめる
- Driverを個人名で指名し、本人の了承を得る
- Approverを決める（会議の議長がそのまま承認者になるケースが多くあります）
- Contributorを挙げ、必要な協力の中身を一言ずつ添える
- Informedに含める部署・人を挙げ、共有の手段（メール・チャットなど）を決める
2でDriverの了承が得られない場合は、決定事項の範囲が大きすぎる可能性があります。その場合は、最初の一歩だけを切り出して決定事項にし、残りは継続検討に回します。
決定事項の記録テンプレート
DACIで役割を決めたら、それを含めて1件の決定事項として記録します。ここでは、決定事項を漏れなく記録するためのテンプレートを紹介します。項目ごとに「なぜ残すのか」を理解しておくと、自社に合わせて項目を調整しやすくなります。
テンプレートの項目
以下は、決定事項を漏れなく記録するためのテンプレートです。記入例はCRMシステムの選定を題材にしています。
| 項目 | 記入例 |
|---|---|
| 決定ID | D-001 |
| 決定日 | ○月○日 |
| 決定内容 | CRMシステムのベンダーを○○に決定 |
| 決定理由 | コスト・実績・サポート体制の3軸で評価し、総合評価が上位だったため |
| 代替案 | ○○（コスト面で劣位）、○○（実績不足） |
| 前提条件 | 予算○○万円以内、導入期限は○月末 |
| リスク | ベンダー側の担当者変更リスク → 契約書にSLA条項を追加 |
| DACI | 記入例 |
|---|---|
| Driver | 営業部 山田（実行推進・進捗報告） |
| Approver | 事業部長 佐藤（最終承認） |
| Contributor | IT部 鈴木（技術評価）、経理部 田中（予算確認） |
| Informed | 経営企画部、法務部 |
| アクションアイテムの担当 | 内容 | 期限 |
|---|---|---|
| 山田 | ベンダーと契約条件の最終交渉 | 3/20 |
| 鈴木 | 技術要件書の最終確認 | 3/15 |
| 田中 | 予算申請書の提出 | 3/18 |
決定理由・代替案・前提条件・リスクを残す意味
このテンプレートのポイントは、決定内容だけでなく「決定理由」「代替案」「前提条件」「リスク」を記録している点にあります。後から「なぜこの決定をしたのか」を振り返れる状態にしておくことが、組織学習の土台になります。
前提条件は、決定を見直すタイミングを教えてくれる項目でもあります。例えば「予算○○万円以内」が前提だった決定は、予算が変わった時点で見直しの対象になります。前提条件が崩れたら決定事項を「再検討」に戻す、という運用ルールを1行添えておくと、古い決定が惰性で続くのを防げます。
項目を増やしすぎない
テンプレートは、使われない項目が増えるほど入力が負担になり、空欄が目立つようになります。項目が少ない方が、記入する人は中身に集中できます。
本記事では、項目を次のように整理します。決定内容・Driver・期限の3つは、どの決定事項でも欠かせない項目です。決定理由・代替案・前提条件・リスクは、金額や影響範囲が大きい決定に限って記入する項目です。どの決定に詳細な記入を求めるかの基準（金額、関係部署の数など）は自社の状況に応じて決め、テンプレートの冒頭に明記してください。
アクションアイテムの追跡を仕組み化する方法
記録が整ったら、次は追跡です。追跡を個人の注意力に任せると、忙しい時期ほど抜けます。会議・週次・常時という3つの時間軸で確認の場を用意し、誰が担当しても同じように回る形にします。
次回会議の冒頭で前回の決定事項をレビュー
会議の冒頭に、前回の決定事項とアクションアイテムの進捗を振り返る枠を設けます。未完了のアクションについては、Driverが理由と新たな期限を報告する形にすると、期限の延長が「なんとなく」ではなく、理由つきの判断として記録に残ります。
レビューでは、決定事項を1件ずつ次のいずれかに振り分けます。
| ステータス | 定義 | 次の行動 |
|---|---|---|
| 完了 | アクションアイテムがすべて終わった | 結果を記録し、Informedに共有する |
| 進行中 | 期限内で作業が進んでいる | 次回のレビューまで継続 |
| 期限超過 | 期限を過ぎて未完了 | Driverが理由と新たな期限を報告する |
| 中止 | 前提条件が変わり、実行しないと決めた | 中止の理由を記録に残す |
「中止」を正式なステータスとして用意しておくことが要点になります。中止の選択肢がないと、実行しないと決まった事項も「進行中」のまま残り続け、一覧の信頼性が下がるためです。
週次でアクションアイテムの棚卸しを実施
個別の会議単位ではなく、組織全体のアクションアイテムを週次で棚卸しします。複数の会議体から発生したアクションの優先順位を整理し、リソースの競合を解消します。
棚卸しでは、担当者ごとにアクションを並べてみてください。特定の人に期限の近いアクションが集中しているなら、期限の調整か担当の付け替えを検討します。期限超過が2回続いたアクションは、担当者個人の問題として扱うのではなく、決定事項の範囲や期限設定そのものを見直す対象にします。
ダッシュボードで進捗を可視化
決定事項の総数、完了数、未着手数、期限超過数をダッシュボードで可視化します。数値で管理することで、組織全体の実行力を客観的に評価できます。
最初から多くの指標を並べる必要はありません。期限超過数のように、増えたら行動を起こす指標を1つ決め、その数が増えた週は棚卸しで原因を話し合う、という使い方から始めると定着しやすくなります。
CRMを活用した意思決定の一元管理
決定事項のうち、顧客や商談に関わるものは、議事録ではなくCRMに置く方が後から追いやすくなります。意思決定の記録と追跡をCRMで管理することで、顧客関連の意思決定を商談や取引と紐付けて一元管理できます。
| CRM活用領域 | 活用内容 | 効果・事例 |
|---|---|---|
| 商談における意思決定の追跡 | 「提案内容をA案に決定」「見積もり条件を承認」等の商談プロセス上の意思決定をタイムラインに記録 | 商談の経緯を時系列で振り返り可能 |
| 担当者変更時の引き継ぎ | 過去の意思決定とその理由がCRM上に蓄積され、即座に参照可能 | 日本IBMでは意思決定履歴をCRMに一元記録し、チーム間の情報共有を効率化 |
| 経営レポートへの活用 | 意思決定データを集計し、経営指標を自動算出 | 「意思決定にかかる平均日数」「決定後の実行完了率」等を定量化 |
HubSpot CRMでは、ミーティング記録・タスク・ノート機能を組み合わせることで、意思決定の記録からアクションの追跡まで一貫して管理できます。取引パイプラインと紐付けて管理することで、商談プロセス上の全決定事項を可視化できます。
決定事項をどのレコードに残すか
HubSpotでは、記録の種類ごとに置き場所を分けると整理しやすくなります。会議そのものはミーティング、決定内容と決定理由はノート、アクションアイテムはタスクとして残す形です。タスクには担当者・期限・ステータスを持たせることができ、コンタクト・会社・取引・チケットのレコードに関連付けられます（出典：HubSpot Developers｜Tasks API）。
置き場所を選ぶときは、「その決定が誰に関するものか」で判断します。特定の取引に関わる決定（値引き条件、提案内容の確定など）は取引に関連付けます。取引をまたいで顧客企業全体に関わる決定（契約方針の変更など）は会社に関連付けます。どの顧客にも紐付かない社内の決定は、無理にCRMへ入れず、議事録とテンプレートで管理する方が扱いやすいケースもあります。
全体フローの中での位置づけ
CRMで意思決定を管理する価値は、コンタクト→取引→顧客→請求という一連の流れの中に、決定の記録が並ぶことにあります。商談中に決めた条件が取引に残っていれば、受注後に顧客対応や請求を担当する人も、同じレコードから経緯をたどれます。
議事録とスプレッドシートで管理していると、この流れが部門ごとに途切れます。営業が決めた条件をカスタマーサクセスが知らない、経理が請求条件の根拠を営業に問い合わせる、といった状況です。決定の記録を取引に置いておけば、部門をまたいだ確認の手間を減らせます。
担当者が替わっても追える状態をつくる
人の入れ替わりがあっても運用が止まらないようにするには、記録のルールを個人の習慣ではなく、システム上の決まりにしておくことが重要です。例えば、取引のステージを進める際に「決定事項」に関するプロパティの入力を必須にしておけば、新しく加わった担当者でも何を記録すべきかが画面上で分かります。必須項目は、新人が商談で何を確認すべきかを学ぶ手がかりにもなります。
必須にする項目は、少なく絞ってください。必須項目が多いと、入力を避けるために中身の薄い記述が増えます。まずは受注・失注のタイミングなど、決定が集中するステージに1〜2項目だけ設定し、空欄や形だけの入力が多い項目は外していく、という順で調整します。
レポートで実行状況を見る
タスクとして管理したアクションアイテムは、担当者別・期限別に集計できます。決定事項の実行状況を、取引の成果と並べて見られるのがCRMで管理する利点です。
以下の画面は、HubSpotレポート「売上目標の達成」の例で、担当者別のクローズ済み金額を目標と並べて表示したものです。
このような成果のレポートと、期限超過タスクの件数を同じダッシュボードに置くと、「目標に届いていない担当者に、期限超過のアクションが集中していないか」を会議の場で読み取れます。集中している場合は、個人の努力を求めるより先に、アクションの量や優先順位を週次の棚卸しで調整してください。
小さく始めて広げる導入ステップ
意思決定の記録と追跡を、いきなり全社の全会議に広げると、ルールの説明だけで負担が大きくなります。効果が見えやすい会議体から始め、定着を見て範囲を広げる方が現実的です。ここでは3段階に分けて進め方を整理します。
| 段階 | 対象 | 管理方法 | 次の段階へ進む目安 |
|---|---|---|---|
| 第1段階 | 1つの定例会議 | テンプレート＋会議冒頭のレビュー | レビューで前回の決定事項が毎回話題に出るようになった |
| 第2段階 | 商談に関わる決定事項 | CRMのタスク・ノートに移行 | アクションの更新がCRM上で行われ、チャットでの状況確認が減った |
| 第3段階 | 複数の会議体・部門 | ダッシュボードでの可視化、商談データとの連携 | 期限超過の件数を会議で話し合う運用が回っている |
第1段階：1つの会議体でテンプレートを定着させる
最初は、決定事項が多く、参加者が固定されている定例会議を1つ選びます。経営会議や営業の週次会議が候補です。ここでテンプレートと冒頭のレビューを数回続け、決定事項の書き方が参加者の間でそろってきたら、次の段階に進みます。書き方がそろわないうちは、テンプレートの項目が多すぎないかを見直してください。
第2段階：商談に関わる決定事項をCRMへ移す
顧客や商談に関わる決定事項を、HubSpotのタスクとノートで管理する形に移します。ここで大切なのは、スプレッドシートの一覧と並行運用する期間を短くすることです。両方を更新する期間が長いと、どちらが正しいのか分からなくなります。移行日を決め、その日以降はCRMだけを更新するルールにします。
なお、利用できる機能や上限はHubSpotの製品・プランによって異なり、その内容は製品・サービスカタログで定められています（出典：HubSpot Product & Services Catalog）。ワークフローによるタスクの自動作成や、カスタムオブジェクトで「決定事項」を独立したレコードとして管理する方法を検討する場合は、自社の契約プランでの対応状況をカタログで見てから設計に入ってください。
第3段階：商談データとつなげて決定を振り返る
運用が回り始めたら、商談の結果と意思決定を結び付けて振り返ります。例えば、失注の理由を集計すると、「価格条件の決定が遅れた」「提案内容の決定が担当者任せだった」のように、意思決定のプロセスに関わる課題が見えることがあります。
以下の画面は、HubSpotレポート「失注分析（案件別の分析）- グラフ」のドーナツチャートです。
失注理由の内訳に偏りがあれば、それを会議の議題にし、対策を新たな決定事項として記録します。対策の結果は次の失注分析に表れるため、決定→実行→結果→次の決定というループが回り始めます。失注した顧客を、時期を改めて再アプローチする対象として扱う判断も、このループの中で記録しておくと、掘り起こしのタイミングを逃しにくくなります。
AIを使うときの役割分担と限界
会議の記録づくりには、AIの議事録作成や要約の機能が使えます。HubSpotのAI機能であるBreezeのように、CRM上の記録を扱うAIも選択肢になります。ただし、意思決定の記録では、AIに任せてよい作業と人が決めるべきことを分けておかないと、記録の信頼性が下がります。
AIに任せる作業
AIが得意なのは、会議の発言を文字にし、要点を整理し、決定事項の候補を抜き出す作業です。テンプレートの項目に沿って下書きを作らせれば、記録係の負担は軽くなります。初めて記録の型をつくる場合も、AIに叩き台を作らせ、後から人が手直しする進め方だと取りかかりやすくなります。
人が決めること
一方で、「何が決定で、何が検討中か」の線引きは人が判断してください。会議での「その方向でいきましょう」という発言が決定なのか、検討の継続なのかは、文脈や参加者の立場によって変わります。
| AIに任せる作業 | 人が判断すること |
|---|---|
| 発言の文字起こしと要約 | 決定事項か検討事項かの線引き |
| 決定事項の候補の抜き出し | Driverの指名と本人の了承 |
| テンプレートに沿った下書き作成 | 期限と前提条件の確定 |
| 関連する過去の記録の検索 | 決定事項を中止・再検討に戻す判断 |
AI要約を記録として確定させる手順
運用では、AIの下書きを会議の最後に画面へ映し、参加者で確定させる手順をおすすめします。決定事項ごとに「決定か検討か」「Driverは誰か」「期限はいつか」の3点を読み上げ、異論が出なければ確定させます。異論が出た事項は「継続検討」に分類し直します。確定前の下書きをそのまま関係者へ自動送信する設定は避け、人が確認した後に共有する形にしておく方が安全です。
よくある質問
Q1. 意思決定の記録で、最初に見直すべきポイントは何ですか？
決定事項が「誰が・何を・いつまでに・どのように」の4要素を含んでいるかを見直してください。「前向きに検討する」のような曖昧な表現は、関係者の解釈がばらつく原因になります。4要素がそろわない事項は、決定ではなく継続検討として記録し、次回の議題に戻すと区別がはっきりします。
Q2. DACIフレームワークは、小さなチームでも使えますか？
使えます。少人数のチームでは、ContributorやInformedが空欄になることもありますが、Driverを個人名で1人決めるだけでも効果があります。全項目を埋めることより、「進捗を報告する人」を明確にすることを優先してください。
Q3. アクションアイテムの期限が守られないときは、どうすればよいですか？
まず、会議の冒頭でDriverが理由と新たな期限を報告する運用にします。期限超過が続く場合は、担当者個人の問題ではなく、決定事項の範囲が大きすぎないか、特定の人にアクションが集中していないかを週次の棚卸しで点検します。範囲が大きい場合は、最初の一歩だけを切り出して決定事項にし直します。
Q4. すべての決定事項をCRMで管理するべきですか？
顧客や商談に関わる決定事項はCRMで管理し、取引や会社のレコードに関連付けると、担当者が替わっても経緯を追えます。一方、どの顧客にも紐付かない社内の決定は、議事録とテンプレートで管理する方が扱いやすいケースがあります。置き場所は「その決定が誰に関するものか」で分けてください。
まとめ
意思決定が実行されない問題は、記録の品質と追跡の仕組みで解決できます。本記事のポイントは次のとおりです。
- 実行されない原因は、記録の曖昧さ・責任の不明確さ・追跡の欠如の3つに整理でき、記録の曖昧さから手を入れるのが近道です
- DACIフレームワークでDriverとApproverを1人に絞り、決定理由・代替案・前提条件まで含めた記録テンプレートを標準化します
- 会議冒頭のレビュー、週次の棚卸し、ダッシュボードでの可視化を組み合わせ、「中止」も正式なステータスとして扱います
- 商談に関わる決定事項は、HubSpot CRMのミーティング・ノート・タスクで取引と紐付け、コンタクトから請求までの流れの中で追える状態にします
- AIは記録の下書きに使い、決定か検討かの線引きとDriverの指名は人が行います
まずは、次回の定例会議1つで、決定事項を4要素とDriverつきで記録するところから始めてください。
- 直近の議事録を読み、期限や担当者が欠けている決定事項を洗い出す
- 次回の会議で、テンプレートを使って決定事項を記録し、冒頭に前回の決定事項のレビュー枠を設ける
- 顧客や商談に関わる決定事項から、HubSpotのタスクとノートで管理する形に移す
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
- 議事録の書き方ガイド｜意思決定を正確に記録するテンプレートと運用ルール
- 議事録の共有・管理を効率化する方法｜全社ナレッジとして蓄積・検索可能にする仕組み
- 商談記録のCRM連携ガイド｜議事録・通話メモをCRMに自動連携して営業成果を最大化
- SOPの作り方｜標準作業手順書を効果的に作成する手順・テンプレート・運用ポイント
経営管理の理解をさらに深めるために、会議のAI要約を経営に活かす方法もあわせてご覧ください。また、AI議事録ツール比較も関連するテーマを扱っています。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
