%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}
この記事の結論
HubSpot提案の品質は、機能の説明量だけでは決まりません。業務・データ・運用の境界を先に決めることが核心です。
HubSpot提案の品質は、機能の説明量だけでは決まりません。業務・データ・運用の境界を先に決めることが核心です。
「提案時には合意したはずなのに、構築開始後から追加要望が増えている」「営業とマーケティングで、リードや商談の定義が異なる」「設定は完了したものの、現場に入力が定着しない」——HubSpotの提案・要件定義では、このような認識のずれが後工程の手戻りにつながります。
HubSpotの提案・要件定義とは、顧客の業務課題を起点に、HubSpotで扱うデータ、業務プロセス、設定範囲、運用責任を合意する工程です。機能一覧を決めるだけではなく、コンタクトから取引、顧客、請求へ続く業務全体の中で、HubSpotが担う範囲を定めます。
StartLinkでは、CRMを単なるデータの保管場所ではなく、営業プロセスの標準化、部門間連携、経営判断を支える仕組みとして捉えることをおすすめします。そのため、提案時には現在のExcelやスプレッドシート、手動連絡、既存システムの使われ方まで確認し、導入後の業務フローから逆算して設計します。
この分野の体系的な情報はHubSpot導入・活用ガイドでまとめています。
本記事はStartLinkの「HubSpotコンサルタント向けシリーズ」の一部です。
この記事でわかること
HubSpot案件の提案や要件定義を担当するときに、契約前から運用開始後まで一貫して整理したい論点を解説します。機能の選定だけでなく、顧客とコンサルタントが合意すべき判断基準まで確認できます。
- HubSpot案件特有の要件定義7ポイント — 業務フロー、パイプライン、データ連携、権限、KPI、データ移行、運用責任の順に確認事項を整理します。
- 提案書で示すスコープの境界 — 対応する作業と対応しない作業を分け、追加要望が出たときの判断基準を明文化します。
- パイプラインを仕組みとして設計する方法 — 取引ステージ、角度、ステージ定義、必須入力プロパティを関連づけて設計します。
- 案件のNGサインと受注判断 — 顧客側の体制や期待値を確認し、再提案、範囲縮小、辞退を選ぶ基準を示します。
- Breezeと人間の役割分担 — 資料の叩き台作成と、顧客固有の判断や合意形成を切り分けます。
HubSpot案件で提案・要件定義を担当するコンサルタント、パートナー企業経由で案件に入る業務委託の方に向けた実務内容です。
HubSpot案件の要件定義が難しい理由
HubSpotは設定の自由度が高く、顧客自身でも変更できる領域があります。その一方で、誰が何を設定し、どのデータを正とし、どこまでを今回の支援範囲にするかが曖昧になりやすいという特徴があります。要件定義では、機能の可否だけでなく、業務上の判断と設定作業の境界をそろえることが重要です。
「何ができるか」から始めるとスコープが広がる
顧客から「マーケティングを自動化したい」「営業管理を見えるようにしたい」と相談されたとき、すぐに機能へ置き換えると、目的と設定がずれることがあります。自動配信を構築しても、対象となるリードの定義やフォームから取得する項目が決まっていなければ、期待した運用にはつながりません。
最初に整理するのは、現在の業務、困っている場面、導入後に変えたい判断です。そのうえで、どの業務をHubSpotへ移し、どの業務を既存システムに残すかを決めます。
| 観点 | 機能起点の進め方 | 業務起点の進め方 |
|---|---|---|
| ヒアリングの出発点 | 使いたい機能 | 現在の業務と課題 |
| 設計の中心 | 設定できる内容 | 導入後の判断と行動 |
| スコープ | 要望が出るたびに広がる | 対象業務と除外業務を合意する |
| 成果の確認 | 設定が完成したか | 業務フローが回るか |
ビジネス担当者が変更できるからこそルールが要る
HubSpotでは、ビジネス担当者が日常運用に関わる設定を扱う場面があります。操作できることと、自由に変更してよいことは同じではありません。パイプラインやプロパティを各担当者が独自に変更すると、入力基準とレポートの前提がそろわなくなります。
Salesforceなどの案件で詳細な要件定義書に慣れている方は、その粒度をHubSpotでも維持すると判断しやすくなります。画面設定だけでなく、変更権限、変更依頼の窓口、変更前に確認するレポートまで要件に含めます。
CRMを一元管理・自動化・可視化の流れで捉える
HubSpotの価値は、コンタクト、会社、取引、チケットなどの情報を関連づけ、必要な処理を自動化し、結果をレポートで確認できる点にあります。要件定義では、個別機能をばらばらに並べず、「情報が入る」「担当者が行動する」「取引が進む」「顧客化後の情報を引き継ぐ」という流れで整理します。
ただし、HubSpotへ情報を集めれば運用が整うわけではありません。入力元、更新条件、確認する担当者が決まっていないデータは、集約しても使われにくくなります。各データが次の判断にどう使われるかまで決めてから、プロパティやワークフローへ落とし込みます。
ポイント1・2：業務フローと営業プロセスを定義する
要件定義の前半では、現在の業務とHubSpot導入後の業務をつなぎます。ここでExcelやスプレッドシートの管理をそのまま再現すると、手作業や属人化まで引き継いでしまいます。業務フローを整理したうえで、ライフサイクルステージと取引パイプラインを設計します。
ポイント1：現状業務と期待成果をすり合わせる
最初の問いは「HubSpotで何をしたいですか」ではなく、「誰が、どの情報を見て、何を判断していますか」です。営業、マーケティング、カスタマーサクセスなどの担当者から、現在の作業と判断の流れを聞き取ります。
特に、Excelやスプレッドシートで顧客情報を管理し、別のツールで連絡し、その結果を再び表へ転記している場合は、情報の重複や更新漏れが起きやすくなります。要件定義では、表をHubSpotへ移すことだけを目的にせず、重複入力を減らし、次の担当者へ情報を引き継げる状態を目指します。
確認結果は、次の形で整理します。
| 整理項目 | 確認内容 | 次へ進む条件 |
|---|---|---|
| 現状業務 | 担当者、利用ツール、入力内容、判断の順序 | 現在の流れを関係者が同じように説明できる |
| 課題 | 二重入力、更新漏れ、集計負荷、担当者依存 | 解決したい課題の優先順位が決まっている |
| 導入後業務 | HubSpotへ移す作業と残す作業 | 変更後の担当者と行動が決まっている |
| 成果 | 会議や日常業務で改善を確認する方法 | 成果を判断するデータが特定されている |
顧客が現状業務を図示できない場合は、設定内容を確定する段階ではありません。ヒアリング内容から現状フローを仮置きし、関係者が修正できる資料として提示してから、導入後のフローへ進みます。
ポイント2：ライフサイクルステージを部門共通の言葉にする
ライフサイクルステージは、見込み客が顧客になるまでの状態を部門横断で捉えるための基準です。リード、MQL、SQL、商談、顧客という名称だけを用意しても、移行条件が担当者の感覚に任されていれば、マーケティングと営業で数字の意味が変わります。
| ステージ | 定義の例 | 受注確度 |
|---|---|---|
| 見込み | フォーム送信・展示会接触 | 5% |
| MQL | スコア50点以上 or 特定ページ閲覧 | 15% |
| SQL | 担当者が商談可能と判断した段階 | 30% |
| 提案中 | 見積書を送付した段階 | 50% |
| 受注内示 | 口頭・書面で受注意思を確認した段階 | 80% |
| 受注 | 契約書・発注書受領 | 100% |
各ステージについて、移行のきっかけ、判断担当者、次に取る行動を定義します。例えば、フォーム送信だけで営業対応へ渡すのか、スコアや問い合わせ内容も条件にするのかを合意します。失注した見込み客をナーチャリングへ戻す場合も、対象条件と再アプローチの判断者まで決めます。
パイプラインは4要素で設計する
取引パイプラインは、次の4要素を組み合わせて設計します。
| 要素 | 決める内容 | 判断の目的 |
|---|---|---|
| 取引ステージ | 商談の進行状態 | 案件がどこで停滞しているかを把握する |
| 角度 | ステージごとの受注見込み | フォーキャストの前提をそろえる |
| ステージ定義 | そのステージへ移す客観的な条件 | 担当者ごとの判断差を減らす |
| 必須入力プロパティ | 移行時に入力する情報 | 次の担当者とレポートに必要なデータを残す |
ステージ名は、営業活動の名称ではなく、受注見込みや次の行動が変わる地点で区切ります。「提案中」という言葉だけでは解釈が分かれるため、「見積もりを提示し、顧客側の検討に入った状態」のように状況で定義します。
以下の画面は、取引ステージごとの列と、各列の合計金額・加重金額を確認できるボード表示です。
パイプラインの設計は、マネジャーや経験のある担当者の知見だけで完成させず、実際の受注・失注の傾向とも照らし合わせます。必須入力プロパティには、営業が次に確認すべき内容を反映できるため、新人でも同じ手順で案件を進めやすい仕組みになります。
ポイント3・4：データ連携と権限の境界を決める
業務フローが決まったら、HubSpotへ入るデータと、そのデータを変更できる人を整理します。HubSpotのデータ同期では項目の対応付けが同期方向と競合時の扱いを決め、プロパティーごとに編集権限を設定できます。（出典：データ同期の項目マッピング、プロパティーの表示・編集権限）このため、連携で更新する項目と手作業で変更する項目を区別し、データの流れと変更権限を一つの設計として扱います。
ポイント3：既存システムとの連携範囲を可視化する
連携要件では、システム名を並べるだけでなく、どのデータを、どちら向きに、どの時点で渡すかを決めます。SFA、MA、会計、ERP、Excelなどを棚卸しし、HubSpotとの役割分担を整理します。
連携マップには、次の項目を記載します。
- データの発生元と正として扱うシステム
- HubSpotへ渡す項目とHubSpotから戻す項目
- 手動更新と自動連携の区別
- 重複やエラーが起きた場合の確認担当者
- 初期スコープに含める連携と後のフェーズへ分ける連携
例えば、コンタクト情報をHubSpotで管理し、受注後の請求情報を別システムで管理する場合は、受注時にどの項目を引き渡すかを定義します。コンタクトから取引、顧客、請求までの流れを図にすると、二重入力が残る場所と連携が必要な場所を区別できます。
ただし、連携を初期導入へ詰め込みすぎると、業務フローが変わるたびに連携仕様も修正することになります。まずHubSpot内の基本運用を固め、手動でも検証できたデータから連携対象に加える段階的な進め方が現実的です。
ポイント4：役割ごとの権限を表にする
権限設計では、部門名だけでなく、日常入力、レポート閲覧、設定変更、ユーザー管理などの操作単位で役割を分けます。全員へ広い権限を渡すと設定変更の経緯を追いにくくなり、絞りすぎると現場が必要な更新を行えません。
| 役割 | レコード入力 | レポート閲覧 | パイプライン変更 | プロパティ変更 |
|---|---|---|---|---|
| 営業担当者 | 担当範囲を更新 | 担当業務に必要な範囲 | 対象外 | 対象外 |
| マネジャー | チーム範囲を確認・更新 | チーム実績を確認 | 変更依頼を提出 | 変更依頼を提出 |
| 運用管理者 | 全体を確認 | 全体を確認 | 合意後に変更 | 合意後に変更 |
| 閲覧者 | 対象外 | 必要なレポートを確認 | 対象外 | 対象外 |
変更権限を運用管理者へ集めるだけでは、変更依頼が滞ることがあります。依頼の受付方法、判断者、反映後の周知方法まで決めると、個人の判断ではなく運用ルールとして管理できます。
データと設定の変更履歴を運用に組み込む
レポートの数値が変わったとき、入力ミスなのか、ステージ定義の変更なのか、連携設定の影響なのかを確認できる状態が必要です。そのため、設定変更は依頼内容、変更理由、影響するレポート、反映日を記録します。
受注後の金額やクローズ日の扱いも、業務ルールとして先に決めます。過去の実績を後から書き換える運用を認めるのか、訂正用の手続きを設けるのかによって、レポートの読み方が変わるためです。
ポイント5・6：KPIと移行データをセットで設計する
レポートは、入力されたデータの結果です。見たいKPIだけを先に並べても、必要なデータが入力されなければダッシュボードは判断材料になりません。KPI、入力項目、入力責任者、データ移行を一つの流れで設計します。
ポイント5：会議で行動を変えるKPIを選ぶ
KPIは「見られる数字」ではなく、その数字を見た人が次の行動を決められるものから選びます。週次や月次の会議で何を判断しているかを聞き、現在の集計方法とHubSpotで必要になるデータを対応させます。
| KPI | 必要なデータ | 入力責任者 |
|---|---|---|
| 月次受注件数 | 取引ステージ「受注」の件数 | 営業担当者 |
| 加重パイプライン金額 | 取引金額 × 受注確度 | 営業担当者 |
| リード → 商談化率 | ライフサイクルステージの遷移記録 | HubSpot自動 |
| コンテンツ別リード獲得数 | フォームの送信元ページ | HubSpot自動 |
KPIが決まったら、欠けている入力項目を洗い出し、ステージ移行時の必須プロパティやワークフローへ反映します。入力されない原因を担当者の意識だけに求めず、業務の流れの中で入力を促す仕組みにすることがポイントです。
初期段階では、日常業務で確認しやすい受注件数や受注金額から始めます。入力が定着し、会議で数値を使える状態になったら、商談化やコンテンツの分析へ広げます。
ポイント6：移行対象と品質基準を先に決める
既存システムやExcelからの移行では、「保有データをすべて入れる」という要望をそのまま要件にすると、重複、表記揺れ、欠損の整理に想定以上の作業が発生します。移行対象は、導入後の業務やレポートで利用するデータから逆算します。
最初に元データの一部を確認し、次の観点で分類します。
- メールアドレスなど識別に使う項目があるか
- 同一人物や同一会社の重複を判定できるか
- 選択肢の表記が統一されているか
- 会社とコンタクト、取引の関連付けに使う値があるか
- 導入後に使わない古い項目が混在していないか
確認後は、「そのまま移行する」「顧客側で修正してから移行する」「今回の対象外にする」に分けます。品質基準を満たさないデータまで一度に移すのではなく、現在の営業活動で使うデータから始め、必要性が確認できたデータを後から追加します。
インポート完了ではなく業務で使えるかを検証する
インポート処理が終わっても、会社とコンタクトが関連づいていなかったり、選択肢が別々の値として登録されていたりすれば、レポートやワークフローで利用できません。検証では、レコード件数だけでなく、検索、関連付け、担当者割り当て、レポート表示まで確認します。
検証用データで業務フローを通し、担当者がレコードを開いて次の行動を判断できれば、本番移行へ進みます。判断に必要な情報が欠けている場合は、元データの修正かプロパティ設計の見直しに戻ります。
ポイント7：運用定着の責任分担を合意する
HubSpotは、設定が完成した時点で運用が完成するわけではありません。現場が入力し、マネジャーが確認し、運用管理者が改善する流れが必要です。提案段階で導入後の責任分担まで合意すると、担当者の異動や引き継ぎにも対応しやすくなります。
ポイント7：顧客側とコンサル側の責任を分ける
責任分担表には、構築期間中の作業だけでなく、導入後の日常運用も含めます。「支援する」という曖昧な表現を避け、情報提供、設定、確認、承認の担当を分けます。
| 責任 | 顧客側 | コンサル側 |
|---|---|---|
| 業務フロー定義 | 〇（一次情報の提供） | △（整理・可視化支援） |
| HubSpot設定・構築 | △（情報提供） | 〇（設定実施） |
| ユーザートレーニング | 〇（参加・実践） | 〇（トレーニング実施） |
| 日常データ入力 | 〇（必須） | ✕ |
| 設定変更・改善 | 〇（導入後オーナー） | △（契約範囲内で支援） |
| KPI追跡・レポート確認 | 〇（週次・月次） | △（定着支援期間内） |
運用オーナーが決まっていない場合は、構築を進める前に役割を置く必要があります。特定の担当者しか理解できない状態を避けるため、マニュアル、操作動画、FAQ、変更依頼の手順を残し、新しい担当者でも運用を引き継げる形にします。
定着を入力・確認・改善の循環で捉える
定着状況は、ログインの有無だけでは判断できません。必要なプロパティが入力されているか、マネジャーがレポートを会議で利用しているか、現場から出た改善要望が設定へ反映されているかを確認します。
入力が不足している場合は、担当者へ注意を促すだけで終わらせず、項目数が多すぎないか、入力するタイミングが業務と合っているかを見直します。項目を最小限に絞り、ステージ移行と入力のタイミングをそろえると、運用へ組み込みやすくなります。
スモールスタートで改善余地を残す
初期導入から連携、自動化、詳細レポートまで広げると、前提となる業務ルールが変わったときの修正範囲も広がります。基盤となるオブジェクト、プロパティ、パイプライン、基本レポートから始め、実際の運用を確認しながら追加します。
ただし、段階的に進めることと、後工程を決めないことは異なります。各フェーズの対象、開始条件、次のフェーズで扱う要件を提案書へ記載し、今回対応しない内容も見える状態にします。
意思決定しやすい提案書の構成
提案書は、HubSpotの機能を紹介する資料ではなく、顧客が課題、解決方針、作業範囲、役割を判断するための資料です。要件定義前の仮説と、要件定義で確定する内容を分けて書くと、提案時の説明が後から要件として誤解されにくくなります。
課題からスコープまでを一つの流れで示す
提案書は、次の順序で組み立てます。
- 現状課題の整理 — ヒアリングで把握した業務、利用ツール、困っている場面を顧客の言葉に沿って整理します。
- ゴール設定 — 導入後に変えたい業務と、確認に使うKPIを示します。
- 提案概要 — 現状業務がHubSpotによってどのように変わるかを説明します。
- スコープ定義 — 対応する設定、移行、連携、トレーニングと、今回対応しない作業を分けます。
- フェーズ計画 — 基盤設定、自動化や連携、分析と改善を段階的に配置します。
- 費用・期間 — 初期設定、ライセンス、継続支援を分けて示します。
- 体制・責任分担 — 顧客側とコンサル側の担当者、確認者、承認者を記載します。
- リスクと前提条件 — 情報提供や確認が遅れた場合に影響する工程を示します。
提案概要では、機能名よりも業務の変化を先に説明します。例えば、「ワークフローを構築する」だけでなく、「フォーム送信後に対象を分類し、担当者へ引き継ぐ流れを整える」と表現すると、設定と業務の関係が伝わります。
「含まれないもの」を作業単位で書く
スコープ外の記載は、「追加対応は別途相談」の一文だけでは不十分です。既存システムとのAPI連携、移行前後のデータクレンジング、追加レポート、導入後の設定変更など、判断が分かれやすい作業を列挙します。
| 項目 | 今回のスコープ | 別フェーズ・追加対応 |
|---|---|---|
| パイプライン | 合意したステージと必須項目の設定 | 新商材向けパイプラインの追加 |
| データ移行 | 合意した項目と対象データの移行 | 対象外データの整理と追加移行 |
| システム連携 | 連携要件の整理 | APIやiPaaSによる実装 |
| レポート | 合意したKPIの基本レポート | 新しい分析要件への対応 |
| 定着支援 | トレーニングと引き継ぎ | 継続的な運用改善 |
追加要望が出た場合は、既存スコープへの影響、追加する作業、後のフェーズへ送る選択肢を並べます。顧客が優先順位を判断できるため、要望を受けるか断るかだけの話になりません。
提案時の仮説と確定要件を区別する
提案段階では、顧客の業務をまだ十分に確認できていない場合があります。その段階で作成したパイプラインやKPIを確定事項として示すと、要件定義で変更した際に認識のずれが生まれます。
資料内では、「提案時点の想定」「要件定義で確認する項目」「合意済みの前提」を区別します。どの会議で誰が承認すれば確定するかも記載すると、合意の経緯を追いやすくなります。
顧客のNGサインと案件を断る判断軸
提案フェーズは、顧客がコンサルタントを選ぶ場であると同時に、コンサルタントが成功条件を確認する場でもあります。期待値、体制、意思決定、工数の前提が合わない場合は、範囲を縮小するか、準備工程を先に提案するか、案件を辞退する判断が必要です。
| NGサイン | リスク |
|---|---|
| 「とにかく全部設定してほしい」（スコープ無制限の要求） | 追加要求が際限なく発生し、採算が合わなくなる |
| 「担当者が1ヶ月以内に異動予定」（運用オーナー不在） | 定着フェーズで誰も引き取れず、成果が出ない |
| 「HubSpotを試したことがない」かつ「3ヶ月で完成を求める」 | 顧客の期待値と現実のギャップが埋まらない |
| 「稟議なしで進める」（意思決定権者がプロジェクトにいない） | 途中で上長からの覆しが発生し、設計を全面変更する羽目になる |
| 要件定義のヒアリングに「営業だけ」が出席（現場担当者不在） | 実際の業務フローと乖離した設計になる |
| 「失敗した前任コンサルの穴埋め」として呼ばれている | 前回案件の負債（設計不整合・データ品質・顧客不信）を引き継ぐリスクがある |
提案段階で確認したいNGサイン
| NGサイン | 想定されるリスク | 提案時の対応 |
|---|---|---|
| 設定範囲を限定せず、すべて任せたい | 追加要望の境界を判断できない | 対象業務と除外作業を先に合意する |
| 運用オーナーが決まっていない | 導入後の判断と改善が止まる | 顧客側の役割決定を開始条件にする |
| HubSpotを試していないまま短期間の完成を求める | 期待する操作と実際の運用がずれる | デモや試行を挟み、要件を再整理する |
| 意思決定者が参加しない | 後から前提が覆る | 承認が必要な論点と承認者を決める |
| 現場担当者がヒアリングに参加しない | 実務と異なる設計になる | 現場確認を要件確定の条件にする |
| 前任者の設定を把握しないまま改修を求める | 既存設定とデータ品質の影響を読めない | 現状調査を独立した工程にする |
複数のサインが見られる場合は、そのまま一括構築を提案しません。現状調査、業務整理、限定範囲での試行など、前提を整える提案へ切り替えます。
受注・再提案・辞退を分ける基準
判断軸は、成功条件、必要工数、専門領域の適合です。顧客側に運用責任者がいて、判断に必要な情報が提供され、合意した工数を確保できるなら受注を検討できます。
必要な担当者が参加できない場合でも、業務整理を先に実施することで前提が整うなら再提案が可能です。一方、責任分担を合意できない、作業範囲を限定できない、専門外の要件まで一括で引き受けることを求められる場合は、範囲限定や辞退を選ぶ方が誠実です。
HubSpotコンサルタントとしての対応領域を整理する際は、HubSpotスキルマップ｜10領域で見る現場で求められる力も参考にしてください。
正直な限界を提案書に含める
提案では、できることだけでなく、標準機能では要望どおりにならない部分、運用で補う部分、追加開発が必要になる部分も説明します。制約を伏せたまま受注すると、構築後に顧客の期待と設定結果がずれます。
また、HubSpot以外の仕組みを残した方がよい業務もあります。データの正となるシステムや現場で定着している手順を踏まえ、HubSpotへ集約する範囲と連携する範囲を分けます。
Breezeと人間の役割を分ける
提案や要件定義では、Breezeを含むAIを資料作成や情報整理に活用できます。ただし、顧客固有の業務判断、パイプラインの設計、責任分担の合意は、人間が関係者と対話して決める領域です。AIが作成した内容は、そのまま顧客へ渡さず、一次情報と照合してから利用します。
Breezeを使いやすい作業
次のような作業は、AIで叩き台を作りやすい作業です。
- ヒアリングメモの整理
- 論点の分類
- 要件定義書の初稿
- 提案書の章立て
情報が散らばっているときに、未決事項と合意事項を分ける用途にも向いています。
ただし、入力する情報が不正確であれば、整理された文章でも内容は正しくなりません。議事録、既存資料、担当者の確認結果を参照し、推測で補われた内容を除きます。
人間が判断する領域
ライフサイクルステージや取引ステージは、顧客の営業プロセスと部門間の役割を理解しなければ設計できません。次の判断も、関係者の合意が必要です。
- KPI ── どのKPIを会議で使うか
- 入力責任 ── 誰が入力責任を負うか
- スコープ ── 追加要望をスコープへ含めるか
大型案件や重要な提案では、AIが作った文章の表現を整えるだけでは足りません。顧客の意思決定構造、過去の経緯、契約範囲を確認し、コンサルタントが内容を再構成します。
送信前レビューを工程に組み込む
AIで作成した提案書や要件定義書には、次の確認を行います。
- 事実確認
- スコープ確認
- 顧客向け表現の確認
レビュー担当者は、元のヒアリング内容と照らして、顧客が合意していない要件や数値が追加されていないかを確認します。
レビューで修正が見つかった場合は、文章だけでなく入力情報や指示も見直します。同じ誤りを繰り返さないよう、顧客固有の用語、除外事項、表記ルールを資料作成の手順へ反映します。
AI活用を含むコンサルタントのスキルについては、HubSpot×AIコンサルタントに必要なスキルセットで詳しく解説しています。
よくある質問
HubSpot提案・要件定義で判断に迷いやすい論点を整理します。回答は一般的な基準なので、実案件では契約範囲と顧客の業務フローに合わせて調整します。
提案前に業務フローが整理されていない場合はどうしますか
設定内容を先に決めず、現状業務を可視化する工程を提案します。担当者、利用ツール、入力情報、判断の順序を仮の業務フローへまとめ、営業、マーケティング、管理者が同じ認識を持てたら導入後の設計へ進みます。
パイプラインは顧客から提示されたステージをそのまま設定してよいですか
名称だけでなく、各ステージの定義、角度、移行時の必須入力プロパティを確認します。担当者によって定義が異なる場合は、設定前にマネジャーと現場担当者の合意を取り、同じ状況を想像できる表現へ直します。
データ連携は初期導入に含めるべきですか
日常業務に欠かせず、データの発生元と更新ルールが決まっている連携は初期対象として検討できます。業務フローが未確定、または正とするシステムが決まっていない場合は、手動運用でデータの流れを検証してから後のフェーズへ分けます。
顧客から追加要望が出たらどう判断しますか
提案書のスコープ表と照らし、既存作業の具体化なのか、新しい業務や設定の追加なのかを分けます。追加の場合は、必要な作業、期間への影響、既存要件との優先順位を示し、今回へ含めるか後のフェーズへ送るかを合意します。
Breezeに要件定義書を作らせてもよいですか
初稿や論点整理には利用できますが、顧客の合意事項としてそのまま扱うことは避けます。ヒアリングの一次情報、契約範囲、既存システムの仕様と照合し、顧客固有の判断はコンサルタントが確認して反映します。
まとめ
HubSpot提案・要件定義では、機能を選ぶ前に業務、データ、判断、責任の流れを整えます。CRMを一元管理・自動化・可視化の仕組みとして設計し、現場の入力からマネジャーの判断までつなげることが重要です。
提案・要件定義で押さえる7ポイント
- 業務フローと期待成果 — Excelやスプレッドシートを含む現状業務を整理し、導入後の変化を定義します。
- ライフサイクルステージとパイプライン — ステージ、角度、定義、必須入力プロパティを関連づけます。
- データ連携 — データの発生元、連携方向、更新条件、正とするシステムを決めます。
- 権限 — 入力、閲覧、設定変更の範囲を役割ごとに明文化します。
- KPI — 会議で行動を決められる指標と、そのための入力項目をセットで設計します。
- 移行データ — 利用目的と品質基準から対象を絞り、業務で使える状態まで検証します。
- 運用責任 — 顧客側とコンサル側の担当を分け、引き継げる仕組みを残します。
まずは現状業務の可視化から始める
最初の一歩は、HubSpotの設定画面を開くことではなく、現在の業務とデータの流れを書き出すことです。次の順序で準備すると、提案と要件定義の論点を整理しやすくなります。
- 現在使っているExcel、スプレッドシート、CRM、会計システムと、それぞれの入力担当者を整理します。
- コンタクトの獲得から取引、顧客化、請求までの流れを図にし、二重入力や判断の停滞が起きる場所を特定します。
- 初期導入で改善する範囲と後のフェーズへ分ける範囲を決め、提案書のスコープ表へ反映します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
提案・要件定義とあわせて、コンサルタントのキャリア、案件管理、対応領域、AI活用を整理できる記事です。担当する案件の段階に合うものからご覧ください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
