HubSpotを使いこなせない3つの原因|90日で立て直す手順

HubSpotを使いこなせない3つの原因|90日で立て直す手順

HubSpotを契約したものの、「機能が多すぎてどこから触ればいいか分からない」「入れたはずのデータが使いものにならない」「結局スプレッドシートに戻ってしまった」という状態は、BtoBマーケティングの現場で頻繁に起きています。多くの担当者はこれを自分のスキル不足だと考えますが、実際にはそうではないケースが大半です。

使いこなせない状態の正体は、「操作を覚えていないこと」ではなく、契約プランの制約・データの汚れ・入力ルールの不在という3つの構造的な原因のいずれかにあります。原因の種類が違えば、打ち手も順番もまったく変わります。

この記事は、すでにHubSpotを導入していて、運用が止まっている・成果が見えない状態にある担当者と意思決定者に向けたものです。自社がどの状態にあるかを判別し、90日で立て直すまでの具体的な手順を扱います。これから導入する段階の方は、導入プロセス側の失敗要因をまとめた記事のほうが適しています。

HubSpotを「使いこなせていない」とは、具体的にどの状態か

使いこなせていない状態は、機能未使用型・データ形骸化型・運用断絶型の3つに分類できます。どれに当てはまるかで、最初に手をつけるべき場所が変わります。

「使いこなせていない」という言葉は感覚的で、そのままでは改善に着手できません。まず自社の状態を分類することが出発点になります。実務で遭遇するパターンは、おおむね次の3つに整理できます。

使いこなせていない状態の3類型 機能未使用型 症状:契約プランの機能の一部しか触れず ワークフローもレポートもほぼ空のまま 最初の一手 プラン内の未使用機能を棚卸しする データ形骸化型 症状:データはあるが重複と表記揺れが多く セグメントもレポートも信用できない 最初の一手 重複とプロパティの整理を最優先する 運用断絶型 症状:マーケだけが使い、営業は別ツール もしくは商談の記録がまったく残らない 最初の一手 入力必須項目を3つまで絞り直す
図1:使いこなせていない状態の3類型。同じ「使えていない」でも、原因と最初に着手すべき場所は異なります。

複数の型が同時に起きているときの優先順位

実際には、3つの型が重なっているケースが少なくありません。その場合の優先順位は明確で、データ形骸化型の解消が常に最優先です。データが信用できない状態で機能を増やしても、増えた機能がすべて誤った数値を出力するだけだからです。

順序としては、①データ形骸化型の解消 → ②運用断絶型の解消(入力ルールの整備)→ ③機能未使用型の解消(機能の拡張)となります。多くの企業は逆の順番、つまり「まず機能を使いこなそう」から入って挫折しています。

立て直しの起点は、いま何が繋がっていないのかを俯瞰することです。HubSpotの運用設計の全体像を基準に、自社の欠けている工程を特定してください。

なぜHubSpotは「使いにくい」と感じるのか|ツール固有のクセ5つ

HubSpotの「使いにくさ」の大半は、操作の難しさではなく仕様の理解不足から生じます。誤解されやすい5つのポイントを押さえるだけで、体感は大きく変わります。

HubSpotのUI自体は、同カテゴリのツールのなかでは平易な部類に入ります。それでも使いにくいと感じるのは、日本の商習慣とは異なる前提で設計された概念がいくつか組み込まれているためです。ここを理解しないまま触ると、「思った通りに動かないツール」に見えてしまいます。

① そもそもプラン上、その機能が存在しない

最も多い誤解がこれです。「ワークフローが作れない」「カスタムレポートが出せない」という状態は、操作を知らないのではなく、契約プランに機能が含まれていないだけというケースが頻繁にあります。HubSpotのナレッジベースによれば、ワークフロー機能の対象はMarketing Hub・Sales Hub・Service Hubなど各HubのProfessionalおよびEnterpriseであり、無料版やStarterでは本格的な自動化は利用できません。

「使いこなせていない」と悩む前に、自社の契約プランで何が使えるのかを確認してください。プラン別の機能差についてはHubSpot無料版と有料版の違い、およびHubSpotの料金プラン比較で整理しています。

操作方法を調べる前に、契約プランで対象機能が提供されているかを確認してください。この一点の確認だけで、解決不能に見えていた問題の相当数が「プラン変更の意思決定」に置き換わります。

② ライフサイクルステージは前進を前提に設計されている

ライフサイクルステージは、HubSpotがマーケティングと営業のプロセスを表現するための中核プロパティです。HubSpotのナレッジベースでは、設定やワークフロー、チャットフローなどを使ってステージを自動更新できると説明されており、取引の作成時に関連するコンタクトや会社のステージを自動設定したり、会社とコンタクトのステージを同期させたりする設定も用意されています。

問題は、この自動更新が基本的に前進方向を想定している点です。失注した商談のコンタクトを前の段階に戻す、いわゆるリサイクルの動きは自動では起きません。設計時にこれを想定していないと、失注したリードがSQLのまま滞留し、ファネルの数値が実態から乖離していきます。

③ リストとビューは別物である

「リストを作ったのに一覧に出てこない」という混乱は、リストとビューの区別がついていないことから生じます。リストは条件に合致するレコードの集合で、メール配信やワークフローの対象として使うもの、ビューはレコード一覧の表示条件を保存したものです。用途がまったく異なります。

さらにリストにはアクティブリスト(条件に合致するレコードが自動で出入りする)と静的リスト(作成時点のメンバーが固定される)があり、この違いを意識せずに配信対象へ指定すると、意図しない相手にメールが届く事故につながります。

④ プロパティの自由度が高すぎる

HubSpotはカスタムプロパティを自由に追加できます。この柔軟性は利点ですが、ルールを決めずに運用すると、担当者ごとに似た意味のプロパティが乱立します。「業種」「業界」「顧客カテゴリ」が別々に存在し、それぞれ半分ずつ埋まっている、というのは典型的な劣化パターンです。

⑤ レポートはデータの質を超えられない

レポート機能が使いこなせないという相談の多くは、レポートの作り方ではなくデータ側の問題です。商談の記録が入っていなければ商談化率は出せませんし、リードソースが記録されていなければチャネル別の評価はできません。レポート設計の考え方はHubSpotレポート設計で扱っていますが、前提としてデータが揃っている必要があります。

「使いにくい」の訴え実際の原因対処
自動化が組めないプランに機能が含まれていない契約プランを確認し投資判断に切り替える
ファネルの数字が合わないステージが前進しかしない設計失注時の戻しルールを設計する
対象者が絞り込めないリストとビューを混同している用途で使い分け、リスト種別を確認する
入力項目が探せない類似プロパティが乱立しているプロパティを棚卸しし統廃合する
レポートが作れない元データが記録されていない記録ルールを先に決める

使いこなせない状態からの立て直し手順(0〜90日)

立て直しは棚卸し・復旧・定着の3フェーズで進めます。機能を増やすのは最後で、最初にやるべきは現状の数値化です。

すでに動いているポータルを止めずに改善するには、順序が重要です。以下は実務で使える90日のロードマップです。

立て直しの90日ロードマップ 1 0〜14日/現状の棚卸し ・重複コンタクト数を実数で数える ・稼働中のワークフローを一覧化 ・契約プランで使える機能を確認 ・活動記録がある商談の割合を算出 2 15〜45日/復旧と絞り込み ・重複を統合し表記揺れを正規化 ・使うプロパティを決め残りは非表示 ・止めるワークフローを決めて停止 ・当面使う機能を3つに絞る 3 46〜90日/定着と計測 ・入力必須項目を3項目までに固定 ・週次会議でダッシュボードを開く ・記録率とデータ品質を再計測 ・改善が確認できたら機能を拡張
図2:立て直しの90日ロードマップ。機能の拡張は最終フェーズに置き、先にデータと運用ルールを整えます。

このロードマップで重要なのは、第1フェーズを必ず数値で終えることです。「データが汚い気がする」ではなく「重複コンタクトが1,240件、活動記録のある商談は38%」という形にしておかないと、90日後に改善したかどうかを判定できません。

初期設定そのものに不備がある場合は、HubSpot初期設定チェックリストを使って設定項目を洗い直すのが確実です。運用中のポータルでも、チェックリストと突き合わせることで欠落箇所を特定できます。

データ品質を復旧する:重複・プロパティ乱立・表記揺れ

データ復旧は重複統合・プロパティ統廃合・値の正規化の3工程で進めます。着手前のバックアップと影響範囲の確認が前提です。

データ形骸化型の症状は、放置すると加速度的に悪化します。汚れたデータの上に新しい施策を重ねるほど、汚れの量も増えるためです。復旧の工程は次の通りです。

  1. 影響範囲の確認とエクスポート:現在のコンタクト・会社・取引を全件エクスポートして保管します。統合や削除は取り消せない操作が含まれるためです。
  2. 重複の統合:メールアドレス・会社ドメインを軸に重複を特定し、統合します。件数が多い場合は、直近の活動があるレコードから優先的に処理します。
  3. プロパティの統廃合:入力率が極端に低いプロパティ、意味が重複しているプロパティを一覧化し、残すものを決めます。使わないものは削除ではなく非表示にして、まず入力画面から外します。
  4. 値の正規化:業種や役職などの自由入力欄が表記揺れの温床になります。ドロップダウン選択式に変更し、既存の値を寄せ直します。
  5. 再発防止の設定:フォームの入力項目とプロパティの対応を見直し、新規レコードが正規化された状態で入るようにします。

重複統合とプロパティ削除は元に戻せません。必ず全件エクスポートを取り、統合ルールを文書化してから着手してください。

具体的な作業手順はHubSpotのデータクレンジングで詳しく扱っています。データ量が多く自社で処理しきれない場合は、現状のデータ状態を見たうえでの復旧計画についてご相談いただくこともできます。

「営業が入力しない」は教育ではなく仕組みで解く

入力が定着しない原因は意識ではなく設計にあります。必須項目を絞り、入力しないと業務が進まない構造を作ることが最短の解決策です。

運用断絶型の中核にあるのが、営業側の入力が定着しない問題です。ここで「もっと入力してください」と依頼を繰り返しても、状況はほぼ改善しません。入力が面倒であるという事実は変わらないためです。

機能する打ち手は、次の3つに絞られます。

  • 必須項目を3つまでに削る:営業に求める入力を最小化します。多くの企業は必須項目が10以上あり、それが未入力の主因になっています。まず何がなくてもレポートが破綻するのかを見極め、それだけを必須にします。
  • 入力しないと次に進めない構造にする:取引ステージを進める条件として特定プロパティの入力を必須化すれば、依頼ではなく手順として組み込まれます。意識に依存しない設計が要点です。
  • 入力したデータが使われる場を作る:週次の営業会議でHubSpotのダッシュボードを画面共有し、そこに映る数字で議論します。自分が入れたデータが会議で使われる実感が、継続入力の唯一の動機になります。

この3点は、マーケティングと営業の間の合意事項として文書化しておくと定着が早まります。MQLの定義や引き渡し基準を含めた設計はマーケティングと営業の連携、およびHubSpotでのMQL定義の設定で扱っています。営業側の運用機能についてはSales HubのBtoB活用も参考になります。

フェーズ別に「使う機能」と「捨てる機能」を決める

全機能を使おうとする姿勢が、使いこなせない状態を長引かせます。自社のフェーズに合わない機能は、意識的に使わない判断が必要です。

HubSpotの機能は広範ですが、すべてを同時に立ち上げる必要はありません。むしろ、リード数や商談数が少ない段階で高度な自動化を組むと、運用負荷だけが増えます。目安は次の通りです。

フェーズ月間リード数の目安使う機能当面使わない機能
立ち上げ期〜30件コンタクト管理/フォーム/取引パイプラインスコアリング/複雑な分岐ワークフロー
拡大初期30〜100件上記+メール配信/基本ワークフロー/ダッシュボード予測スコアリング/高度なアトリビューション
本格運用期100件〜上記+スコアリング/ナーチャリング/カスタムレポート用途が説明できない機能すべて

リード数が月30件に満たない段階でスコアリングを設計しても、統計的に意味のある閾値は設定できません。HubSpotのリードスコアリング設定ワークフロー設計は、対象となるリード量が確保できてから着手するほうが確実です。

使わない機能を決めることは、後退ではなく設計判断です。機能を絞った期間に運用が定着すれば、拡張のスピードはむしろ上がります。

一人でHubSpotを運用している場合は、絞り込みの重要性がさらに高まります。体制面の考え方は一人マーケ体制でのHubSpot運用、リソース不足への対応は社内リソースが足りないときの対処法にまとめています。

【独自視点】ツールを乗り換えるべきなのは、どんなときか

使いこなせない状態の大半はツール変更で解決しませんが、乗り換えが合理的なケースも実在します。判断基準は「制約が仕様に起因しているかどうか」です。

「HubSpotが合わないので別のMAツールに移行したい」という相談は一定数あります。この判断が正しいこともあれば、問題を先送りしているだけのこともあります。両者を分ける基準を明示します。

乗り換えが合理的なのは、次のいずれかに該当する場合です。

  • 必要な機能が仕様上、実現できない:複雑な承認フロー、特殊な権限分離、既存基幹システムとの密結合など、HubSpotの設計思想と根本的に相容れない要件がある場合です。
  • コスト構造が事業規模と合わない:コンタクト数やシート数の増加によって費用が事業の成長速度を上回るペースで膨らんでいる場合、プラン見直しでも解消しないことがあります。
  • すでに他ツールが業務の主系として定着している:営業が別のSFAを日常的に使っており、そちらを主系にする意思決定が済んでいる場合です。

逆に、乗り換えても解決しないのは、目的が定まっていない・データが汚い・入力ルールがない、という3つの状態です。これらはツールに紐づく問題ではないため、移行先でも同じ症状が再現します。移行作業のコストだけが追加で発生する形になります。

判断が乗り換え側に傾いた場合は、MAツール乗り換えの手順MAツール比較で移行時の論点を確認してください。HubSpotと他ツールの直接比較はHubSpotとMarketoの比較で扱っています。

なお、この記事はすでに導入済みの状態を前提にしています。導入プロジェクトそのものの設計に課題がある場合は、HubSpot導入が失敗する7つの理由のほうが該当します。

まとめ

使いこなせない状態は、原因の分類から始めれば必ず前に進みます。機能習得より先に、データと入力ルールを整えることが順序として正しい進め方です。

この記事で扱った内容を整理します。

  • 使いこなせていない状態は、機能未使用型・データ形骸化型・運用断絶型の3類型に分けられる
  • 複数該当する場合は、データ形骸化型の解消を最優先にする
  • 「使いにくさ」の多くは操作の問題ではなく、プラン制約・ライフサイクルステージ・リストとビュー・プロパティ乱立・データ不足という仕様理解の問題である
  • 立て直しは、棚卸し(0〜14日)→ 復旧と絞り込み(15〜45日)→ 定着と計測(46〜90日)の順で進める
  • 営業の入力は、必須項目の削減と「入力しないと進めない」構造で解決する
  • 乗り換えが合理的なのは、仕様上の制約・コスト構造・他ツールの定着という3条件に限られる

最初の一歩は、重複コンタクト数と活動記録率を実際に数えることです。この2つの数字が出た時点で、自社がどの型に該当し、何から着手すべきかが確定します。現状の診断と優先順位づけから支援が必要な場合は、お気軽にご相談ください。

無料相談

導入済みのHubSpot、立て直しから対応します

データの重複、止まったままのワークフロー、記録が残らない商談。現状のポータルを確認したうえで、90日で何から手をつけるべきかを整理してお渡しします。設定代行のみの依頼にも対応可能です。

よくある質問(FAQ)

HubSpotの無料プランでも使いこなすことはできますか?
コンタクト管理・フォーム・基本的なメール配信・取引管理といった範囲であれば、無料プランでも実用に足ります。ただしHubSpotのナレッジベースが示す通り、ワークフローによる自動化はProfessional以上が対象です。無料プランで「自動化できない」のは使いこなせていないからではなく、機能が含まれていないためです。まず無料の範囲で運用フローを固め、必要な機能が具体化した段階でプランを上げる進め方が合理的です。
使いこなせるようになるまで、どのくらいの期間が必要ですか?
現状の状態によって大きく異なります。データが比較的きれいで入力ルールも存在する場合は、機能の習得だけで済むため1〜2か月程度です。データの重複や表記揺れが大量にある場合は、復旧作業だけで1〜2か月かかり、定着まで含めると90日程度を見込む必要があります。まず重複コンタクト数を数えることで、必要な期間の見当がつきます。
HubSpotの操作を学ぶには何から始めるべきですか?
HubSpot Academyの無料コースが体系的で、コストもかかりません。ただし操作学習の前に、自社のポータルで「何を実現したいか」を1つ決めることを推奨します。目的のない状態で全機能を学ぶと、学んだ内容が業務に接続されずに定着しません。「商談化率を可視化する」といった具体的な目標を設定してから、必要な機能に絞って学ぶほうが効率的です。
社内に詳しい人がいない場合、どうすればよいですか?
まず社内で1名を管理担当として明示的に決めてください。全業務を担う必要はなく、設定変更の窓口が一本化されているだけで、設定の乱れは大幅に減ります。そのうえで、設定作業やデータ復旧など専門性の高い部分を外部に切り出す分業が現実的です。委託範囲の決め方はHubSpot運用の外注、パートナー選定の観点はHubSpotパートナーの選び方で解説しています。
データが汚れすぎている場合、作り直したほうが早いですか?
ポータルの作り直しは、既存の活動履歴やメールのエンゲージメント履歴を失うことになるため、原則として推奨できません。多くのケースでは、重複統合とプロパティの統廃合で実用水準まで回復します。ただし、コンタクト数の半数以上が重複または無効で、かつ活動履歴がほとんど存在しない場合は、必要なデータだけを移行して構築し直す判断が合理的なこともあります。判断には現状の実数確認が前提になります。