%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 Spring Spotlightの発表内容は、自社の業務課題と照らして選ぶことで、CRM運用や営業・マーケティングの改善につなげられます。新機能を一度に入れず、現場の課題に近いものから小さく試すことがポイントです。
HubSpot Spring Spotlightの発表内容は、自社の業務課題と照らして選ぶことで、CRM運用や営業・マーケティングの改善につなげられます。新機能を一度に入れず、現場の課題に近いものから小さく試すことがポイントです。
「更新情報が多くて、今の運用に関係するものを見つけにくい」
「新しい機能が追加されても、現場での使い方が決まらない」
「今の契約プランや権限で使えるのか判断できない」——
HubSpot Spring Spotlightとは、HubSpotが春に発表する製品アップデートの総称です。発表された内容を、自社の業務課題、利用プラン、既存の運用に照らして確認し、試す機能を選ぶ機会として活用できます。
本記事では、Breeze、レポート、営業、マーケティング、サポート領域の更新内容を実務の視点で整理し、優先順位のつけ方と導入後の確認手順を紹介します。個々の発表内容や利用条件は、HubSpotの製品更新ページで自社アカウントに表示される情報を確認してください。
本記事は「HubSpot Data Hub完全ガイド｜データ統合・品質管理・自動化の設計」シリーズの一部です。
本記事はStartLinkの「HubSpot完全ガイド」関連記事です。
この記事でわかること
この記事では、HubSpotのアップデートを自社の運用に取り入れるか判断するための見方と、試行後に確認する手順をまとめます。
- Spring Spotlightの位置づけ — 製品更新情報を、自社の業務課題に結びつけて読む方法を説明します。
- 各領域の更新内容の捉え方 — Breeze、レポート、営業、マーケティング、サポート機能の活用場面を整理します。
- 導入優先度の決め方 — 効果と導入負荷、利用条件を基準に候補を絞る方法を紹介します。
- 運用変更を確認する手順 — ベータ利用や既存ワークフローへの影響を確かめ、手順書へ反映する流れを解説します。
Spring Spotlightの情報を自社の課題に結びつける
Spring Spotlightは、新機能を一覧で眺めるだけでなく、日々の業務でどこに負荷や情報の分断があるかを整理して読むと活用しやすくなります。手作業の集計や表計算ファイルでの個別管理が残っている場合は、CRMの記録、担当者間の引き継ぎ、レポート作成のどこに改善余地があるかを先に確認します。製品更新情報は、その課題に関係する機能を探す入口になります。
製品更新ページで状態と説明を確認する
HubSpotアカウントのプロフィールメニューから「製品の最新情報」を開くと、更新情報やベータ機能を確認できます。更新ページで気になる機能を見つけたら、自社アカウントで提供状態、対象プラン、必要な権限、参加ボタンの表示を確認し、試せるか判断します。lic-beta-feature)）。
次の画面は、HubSpotの「製品の最新情報」画面です。
そのため、更新の名称だけで導入を決めず、説明欄で解決する課題、提供状態、対象プランを読みます。ベータ機能を試す場合は、自社アカウントで参加ボタンが表示されるか、必要な権限があるかを確認し、対象者を個人にするかチーム全体にするかを決めます。
既存の作業と情報の流れを棚卸しする
例えば、営業担当が表計算ファイルで見込み顧客を管理し、メールやチャットで進捗を共有し、管理者が別途集計している場合、同じ情報を複数の場所で更新する負担が生まれます。更新情報を読む前に、どの情報がコンタクトや会社、取引に記録されているか、誰が次の対応を引き継ぐかを洗い出すと、必要な機能を絞りやすくなります。
CRMは記録の置き場だけでなく、部門をまたぐ業務の流れを支える仕組みとして設計できます。問い合わせからコンタクトの確認、取引化、顧客対応、請求情報の管理へとつながる流れのうち、どの段階で情報が途切れているかを見てから、更新機能を割り当てます。
発表内容と利用可能な機能を分けて記録する
製品更新情報には、提供中の機能、ベータ、今後の予定など異なる状態の情報が含まれます。チーム内で検討する際は、「発表された機能」と「自社で今使える機能」を同じものとして扱わず、状態と確認日を記録します。
| 確認対象 | 記録する内容 | 次の判断 |
|---|---|---|
| 更新の状態 | 提供中、ベータ、予定など | 今すぐ確認するか、後日再確認するか |
| 自社での利用可否 | 対象プラン、権限、参加ボタンの表示 | 利用可能なら試行候補にする |
| 現場の課題 | 対象となる作業と担当者 | 課題に関係すれば優先度を評価する |
| 変更の影響 | 既存のワークフローや手順との関係 | 影響範囲があれば先に検証する |
Breezeの更新を顧客対応の流れに組み込む
Breeze関連の更新は、顧客情報の確認や文章作成などの作業を支援する場面で検討できます。原記事では、CRM内のアシスタントによる取引レコードの要約、メール文面の生成、タスク提案や、案件創出エージェントなどのリサーチ精度向上を注目点として挙げています。実際に利用できる機能と動作は、製品更新ページで自社アカウントの情報を見て確認します。
CRM情報の確認から担当者の判断につなげる
取引レコードに関連情報を集める運用では、担当者が会社や過去のやり取りを探す手間を減らし、準備した情報をもとに次の対応を判断しやすくなります。AIによる要約や提案が使える場合も、それを顧客への確定回答として扱うのではなく、担当者が元の記録と照らして整える下書きとして位置づけます。
この流れは、コンタクトや会社の情報を確認し、取引の状況を把握して、顧客への連絡や次のタスクへつなぐ位置にあります。レコードに必要な情報が記録されていなければ、要約や提案にも反映されにくいため、まず記録項目を見直し、使われていない項目を増やさないことが運用上のポイントです。
AIの提案を人のレビューにつなぐ
メール文面やタスク案を生成する機能を利用する場合は、AIが得意な情報整理と、人が担う判断を分けます。顧客との関係、提案内容の妥当性、送信の可否は担当者が確認し、AIの生成物をそのまま送信する運用にしないようにします。
| 作業 | AIに任せる範囲 | 担当者が確認すること |
|---|---|---|
| 取引の準備 | レコード情報の要約や調査内容の整理 | 情報の正確さと商談上の意味 |
| メール作成 | 文面のたたき台 | 顧客との関係、内容、送信判断 |
| 次のタスク | 対応候補の提示 | 優先度、担当者、期限 |
この分担を決めておくと、担当者ごとに異なる使い方を抑え、引き継ぎ時にも確認の観点を共有できます。日本語の敬語や業界固有の表現が必要な場合は、指示文に文体や避ける表現を明記し、出力を担当者が確認してから使います。
AI機能の対象と限界を確認する
製品更新ページにAI機能が表示されても、すべてのアカウントで利用できるとは限りません。また、ベータは正式提供前の機能として扱い、対象範囲や利用条件を確認してから試行します。日本語での表現や自社固有の営業ルールに合うかは、短い業務から試して、担当者が修正した箇所を記録すると判断しやすくなります。
レポート更新を業務の可視化に生かす
レポートは、記録されたデータを集計し、営業やマーケティングの状況を共有する機能です。原記事では、次の点を注目点として挙げています。
- レポートビルダー ── 画面の改善
- フィルター ── 設定の仕方
- チャート ── 種類
見た目や操作性だけでなく、判断したい指標が正しいデータから作られているかを確認して導入します。
先に判断したい指標を定義する
表計算ファイルを担当者が個別に更新していると、集計の時点や条件が揃わず、同じ会議資料でも数字の根拠が異なることがあります。レポート作成に先立って、どの条件で数値を出すかを合意します。
- 対象期間
- ステージ
- 担当者
- 金額
営業の状況を見る場合は、取引ステージの定義、各ステージの受注確度、ステージ移行時に必要な入力情報がそろっていることが前提になります。データの意味が統一されていれば、ダッシュボードを営業担当の活動確認からマネージャーの見込み判断まで共通の基盤として利用しやすくなります。
カスタムレポートの利用条件と更新間隔を確認する
新しいデータがレポートに現れるまで時間がかかる場合があり、公式ヘルプでは通常の反映に10〜15分、カスタムレポートの自動更新に2時間ごとの間隔が示されています（出典：カスタムレポートビルダーでレポートを作成する）。
そのため、商談直後に数値が変わらないときは、まずデータの反映待ちか、絞り込み条件の不一致かを分けて確認します。会議で即時の数字が必要なら、更新時刻を見て手動更新を検討し、更新後も差が残る場合は対象データやフィルターを見直します。
集計結果を定期的な改善につなげる
レポートは作成して終わりではなく、誰が見て、どの判断に使い、次の業務へどう返すかを決めておく必要があります。例えば、取引ステージ別の状況を見て、停滞している案件の記録を確認し、必要な次の対応を担当者に割り当てる流れを作ります。
ただし、レポートのチャートやフィルターを変えても、入力内容の定義が曖昧なままでは判断材料として安定しません。数字が想定と合わない場合は、まずレポート条件を確認し、次に元レコードの入力状態、最後にステージ定義を見直す順で原因を切り分けます。
営業領域の更新を取引管理と検証する
営業領域では、原記事が次の点を注目点として挙げています。
- パイプラインビュー ── 見やすさ
- シーケンス ── A/Bテスト
- AI議事録やSlack連携
こうした機能は、単独の便利さではなく、見込み顧客への連絡から商談管理、受注後の顧客対応へ情報が引き継がれるかを基準に見ます。連携の対象や利用条件は、各機能の製品更新情報で確かめます。
パイプラインのステージを業務の定義に合わせる
取引パイプラインは、営業活動の進行状況を共通の基準で把握するための仕組みです。ステージを作るときは、受注率が変わる業務上の節目を選び、各段階に何ができていれば進めるのかを明文化します。
また、ステージごとに受注確度を置く場合は、確度の意味をチームで共有し、実際の受注状況と見比べて調整します。移行時に必要な金額やクローズ日などを定めておけば、担当者の記憶だけに頼らず、入力と確認の流れで情報を揃えられます。
シーケンスのA/Bテストは一つの差分から始める
原記事では、複数の担当者がシーケンスを作成し、反応を比べる活用例を紹介しています。シーケンスのA/Bテストを検討する際は、自社の契約プランと利用するシーケンスの種類について、公式ヘルプで利用条件を確認してください。-b-testing-emails-with-sequences)）。
検証では件名や本文などの変数を一度に複数変えず、比較したい点を一つに絞ります。対象リストや送信条件を揃えて反応を記録し、結果を見て採用する文面を決めます。利用できるプランやシーケンスの種類が条件に合わなければ、まず手動で文面と反応を記録し、機能を利用できる段階で移行を検討します。
議事録や連携機能は引き継ぎに役立つかを見る
AI議事録やSlack連携を検討する際は、記録が取引やコンタクトのどこに残るか、次の担当者が文脈を確認できるかを確かめます。通知だけが増えて記録が分散する場合は、連携の目的と保存先を再検討します。
マーケティングとサポート領域の更新を顧客体験につなげる
原記事の注目点は次のとおりです。
- マーケティング領域 ── スマートコンテンツ、リードスコアリング、フォーム分析
- サポート領域 ── AIチャットボット、ヘルプデスク、ヘルススコア
いずれも顧客の状態を把握し、適切な担当部門へ情報を渡す業務に関係します。候補機能が自社で利用できるかを確認したうえで、顧客接点の前後にあるプロセスと合わせて評価します。
スコアリングやフォーム情報を営業への引き継ぎに使う
リードスコアリングは、見込み顧客の関心や条件をもとに優先順位づけを支援する考え方です。フォーム分析やスコアの推奨機能を利用する場合も、点数だけで営業へ渡すのではなく、どの行動や属性が優先対応につながるかをチームで定義します。
フォーム送信後の情報がコンタクトに記録され、条件に応じて担当者や次の対応へつながる設計にすると、担当者が都度表計算ファイルを照合する作業を減らせます。まずは既存の問い合わせ分類と担当割り当てを整理し、その後に自動化や推奨機能を加えます。
スマートコンテンツは表示条件と対象を揃える
スマートコンテンツを使う場合は、誰にどの内容を表示するかを明確にし、対象条件に該当するコンタクトで表示を確かめます。条件を増やしすぎると、表示内容の違いが追いにくくなります。最初は業務上説明できる区分から始め、表示結果と問い合わせ後の動きを見て条件を調整します。
サポート機能は問い合わせから解決までの流れで見る
AIチャットボットやヘルプデスクの改善は、問い合わせの受付、チケットの割り当て、回答、解決状況の記録という流れの中で評価します。ナレッジを参照する機能では、回答の正しさが登録情報に左右されるため、まず記事や回答情報を整理し、どの問い合わせを自動案内の対象にするかを選びます。
ただし、顧客ごとの判断や例外対応まで自動回答に任せると、意図と異なる案内になる可能性があります。まずよくある質問など範囲を限定し、回答できない条件では担当者へ引き継ぐ運用を用意します。ヘルススコアを使う場合も、スコアの変化を誰が確認し、どの対応を取るかまで決めてから運用します。
導入優先度を効果と負荷で決める
すべての更新を同時に導入する必要はありません。既存課題との近さ、利用できる条件、現場での確認にかかる負荷を比べ、試す順を決めます。個別の機能を増やすより、コンタクトから取引、顧客対応へ続く業務全体で詰まっている箇所を優先します。
課題と導入負荷を並べて候補を選ぶ
例えば、レポートの集計作業に時間がかかっており、データと指標の定義が揃っている場合は、レポート機能の確認を優先できます。一方、営業ステージや入力基準が定まっていなければ、先にプロセスと項目を整える方が、後のレポートやAI提案も使いやすくなります。
| 優先度の目安 | 状況 | 次の行動 |
|---|---|---|
| 高 | 現在の業務課題と機能が直接結びつき、利用条件も確認できた | 対象業務を絞って試す |
| 中 | 活用の可能性はあるが、データやルールの整備が先に必要 | 前提となる記録や手順を整える |
| 低 | 自社で使わないHubの機能、または対象業務が決まっていない | 更新情報を記録し、必要時に再評価する |
プランと権限を確認してから試行範囲を決める
原記事では、新機能にProfessional以上やEnterprise限定のものが含まれる場合があると説明しています。個々の機能の対象プランは異なるため、ひとまとめに判断せず、製品更新ページや公式ヘルプに記載された条件を一件ずつ確認します。プラン全体の違いは「HubSpotアップグレードの判断基準｜Starter→Pro→Enterpriseの切り替えタイミング」も参考になります。
小さく試して全体フローへ広げる
最初の試行は、対象者、対象レコード、確認する結果を限定します。例えば、レポートなら既存の取引データで指標を再現できるか、AIなら提案文を担当者が修正せずに使えるかではなく、どの修正が必要かを確認します。
結果が業務に合えば、入力ルールや担当者向け手順を整え、関係する部門へ段階的に広げます。期待した結果が出ない場合は、対象データ、機能条件、業務ルールの順で原因を確認し、機能を広げる前に前提を整えます。
アップデート後の運用を仕組みで確認する
更新を試した後は、利用者が機能を使えたかだけでなく、記録や引き継ぎが従来の業務とつながったかを確認します。既存ワークフローやデータに関わる変更は、対象範囲を決めてから検証します。問題がなければ、担当者個人の経験に頼らず運用できるよう、手順と判断基準を共有します。
既存ワークフローへの影響を切り分ける
既存ワークフローに関係する変更では、次の項目を先に書き出します。
- 対象レコード
- 登録条件
- 通知先
- 更新されるプロパティ
テスト用のレコードで条件に合うケースと合わないケースを確認し、想定した分岐と通知が動けば次の確認へ進みます。異なる動きがあれば、変更した機能と既存条件を分けて調べ、原因が特定できるまで本番運用へ広げません。
新しいUIの操作確認だけで既存データやワークフローに影響しない場合は、操作担当を決めて小さく試し、画面と手順の違いを記録します。データ更新や自動処理を伴う場合は、テスト環境やテスト用レコードで結果を確認してから運用範囲を決めます。
確認結果を手順書と担当分担に反映する
更新後は、次の内容を簡潔にまとめます。
- 操作画面の変更
- 利用条件
- 問い合わせ先
- 担当者が確認するポイント
新しい機能を使う人が増える場合は、誰が設定を変更できるか、誰が出力をレビューするか、問題が起きたときにどこへ戻すかを決めます。
この仕組みがあれば、担当者が変わっても同じ基準で記録や確認を進めやすくなります。手順書に反映した後は、実際の業務担当者が記載どおりに操作できるかを確認し、迷った箇所だけ補足します。
機能を残すか戻すかを判断する
試行後には、作業時間や確認漏れ、引き継ぎのしやすさなど、導入前に定めた観点で結果を見ます。業務に合い、担当者が手順どおり運用できる場合は対象を広げます。入力や確認の負担が増えた場合は、条件や対象を狭めるか、既存の手順に戻して前提を見直します。
よくある質問
Spring Spotlightの新機能は自動的に使えるようになりますか？
更新の内容によって異なります。ベータ機能は製品更新ページから参加操作が必要な場合があり、表示されていても契約内容や提供段階によって利用できないことがあります。自社アカウントに表示される利用条件と必要な権限を確認してください。
アップデート内容はどこで確認できますか？
HubSpotアカウントのプロフィールメニューから「製品の最新情報」を開き、各更新の説明と状態を確認します。ベータへの参加を検討する場合は、対象プラン、権限、利用範囲も合わせて見ます。定期的に確認する担当者を決めておくと、チームで情報を共有しやすくなります。
既存のワークフローに影響することはありますか？
変更内容によって影響範囲は異なるため、既存の条件や更新先プロパティに関係するかを確認します。関係がある場合は、テスト用レコードで条件に合うケースと合わないケースを試し、想定した動作なら対象範囲を決めます。想定と違う場合は、本番運用へ広げず、ワークフローの条件と更新内容を切り分けて調べます。
Spring SpotlightとINBOUNDの違いは何ですか？
Spring Spotlightは春のプロダクトアップデートに焦点を当てた発表で、INBOUNDは製品発表に加えてマーケティングや営業のセッションも含む年次カンファレンスです。具体的な日程や開催内容は年によって変わるため、参加を検討するときはHubSpotの公式案内で確認してください。
まとめ
HubSpot Spring Spotlightの情報は、発表された機能をそのまま導入するためではなく、自社の業務課題と照らして改善候補を選ぶために活用できます。手作業の集計や情報の分散が残っている場合は、まず業務のどこで情報が途切れるかを整理し、Breeze、レポート、営業、マーケティング、サポート機能のうち課題に近いものから試します。
まずは「製品の最新情報」ページで自社に関係する更新を一つ選ぶところから始めてください。
- 対象業務、困っている作業、現在の記録場所を書き出します。
- 更新の説明、利用条件、権限を確認し、試行の対象と判断基準を決めます。
- テスト結果を確認して手順書に反映し、業務に合えば対象範囲を広げます。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
