%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のカスタマーポータルとは、顧客がログインし、自分に関係するサポートチケットの確認・作成・返信を行えるセルフサービス基盤です。重要なのは、ポータル単体を作ることではなく、問い合わせ受付から回答、解決、履歴活用までをCRM上でつなぐことです。
本記事は「HubSpot購入グループ（Buying Groups）活用ガイド｜ABM戦略を加速する設計」シリーズの一部です。
本記事はStartLinkの「HubSpot完全ガイド」関連記事です。
この記事でわかること
HubSpotで顧客向けセルフサービスを検討している方が、設定前の設計から公開後の運用までを整理できる内容です。画面操作だけでなく、どの情報を顧客に見せるかという判断軸も解説します。
- カスタマーポータルの位置づけ — FAQページとの違いと、CRM全体の中で担う役割を整理します。
- 構築前に決める設計項目 — チケットステージ、表示項目、アクセス権限をどの順番で決めるかがわかります。
- 設定から公開までの手順 — ドメイン、受付先、フォーム、権限、外観、テストの流れを解説します。
- ナレッジベースとの連携方法 — 自己解決から有人対応へつなぐ導線と、問い合わせ履歴の残し方を整理します。
- 運用上の限界と改善方法 — ポータルが向く範囲と、別の運用を組み合わせる判断基準を示します。
HubSpotカスタマーポータルの概要とCRMでの位置づけ
カスタマーポータルは、顧客向けの画面を追加するだけの機能ではありません。社内で管理するチケット情報の一部を、認証された顧客にわかりやすく見せる仕組みです。そのため、画面デザインより先に、チケットと顧客データの関係を整えることがポイントになってきます。
更新版のサポートポータルとの関係
サポートポータルはログインで保護された領域で、顧客が自分のサポートチケットへアクセスして管理できる機能です。利用できるのはService Hub ProfessionalまたはEnterpriseです。（出典：サポートポータルを設定する）
FAQページではなく顧客ごとの窓口
一般的なFAQページは、多くの顧客に共通する回答を掲載する場所です。一方、カスタマーポータルでは、ログインした顧客と関連付けられたチケットや、権限設定に応じた会社のチケットを扱います。
つまり、2つの役割は次のように分かれます。
- ナレッジベース ── 「共通情報を探す場所」
- カスタマーポータル ── 「自分の問い合わせを確認する場所」
この役割を分けると、共通質問はナレッジベース、個別対応はチケットという導線を作れます。
顧客化後の情報をCRMにつなぐ役割
HubSpotでは、コンタクトと会社を起点に、取引、顧客化後のチケット、必要に応じた請求情報へ業務をつなげて考えられます。カスタマーポータルは、この一気通貫の流れのうち、顧客化後のサポート情報を顧客と共有する位置にあります。
問い合わせ履歴がコンタクトや会社と紐づけば、サポート担当者だけでなく、営業やカスタマーサクセスも過去の経緯を確認しやすくなります。CRMを単なる問い合わせ台帳ではなく、部門間で顧客理解を共有する基盤として扱える点が重要です。
カスタマーポータルが必要になる業務課題
ポータルの導入判断は、顧客数だけで決めるものではありません。問い合わせの受付、進捗共有、履歴確認にどれだけ手作業が残っているかを見ます。メールとスプレッドシートを行き来する回数が増えているなら、まず情報の流れを整理する段階です。
メールとスプレッドシートで履歴が分かれる
メールだけで対応すると、担当者の受信箱にやり取りが残り、チーム全体で経緯を追いにくくなります。スプレッドシートを併用しても、メールの内容と対応状況を手動で転記するため、更新のずれが起こるケースがあります。
HubSpotのチケットへ問い合わせを集約すると、受付内容、担当、ステータス、会話を一つのレコードで追えます。さらにポータルを組み合わせれば、社内の管理と顧客への進捗共有を同じチケットを起点に設計できます。
| 観点 | メール・スプレッドシート中心 | チケット・ポータル中心 |
|---|---|---|
| 問い合わせ履歴 | 受信箱や表に分散しやすい | チケットを起点に確認する |
| 対応状況 | 顧客が担当者へ確認する | 顧客がポータルで確認する |
| 引き継ぎ | 担当者の説明に依存しやすい | ステージと履歴を参照する |
| 共通質問 | 同じ回答を個別に送る | ナレッジベースへ案内する |
| 顧客情報 | 問い合わせ台帳として独立しやすい | コンタクトや会社と関連付ける |
対応の遅れより進捗が見えないことが問題になる
顧客の不安は、回答までの時間だけでなく、問い合わせが受け付けられたのか、誰が対応しているのか、解決したのかが見えないことからも生まれます。ポータルで「受付済み」「対応中」「回答済み」「解決済み」のように状態を示せば、顧客が自分で状況を確かめられます。
ただし、社内の細かな作業段階をそのまま公開すると、表示が複雑になります。顧客向けの表示は理解しやすい段階にまとめ、社内では担当部署や確認先を別の情報として管理する設計が適しています。
同じ質問への個別回答を減らしたい
操作方法や設定手順など、共通する質問へ毎回メールで回答している場合は、ナレッジベースへ整理する余地があります。顧客が記事を探し、それでも解決しない場合にチケットを作成できる流れにすると、問い合わせ前の自己解決と個別対応を分けられます。
ここで大切なのは、問い合わせを受け付けない仕組みにすることではありません。自己解決できる内容は記事へ案内し、契約内容や個別状況に関わる内容は担当者がチケットで扱うように、役割を分けます。
構築前に決めるチケットとアクセス権限の設計
HubSpot カスタマーポータル 構築の成否は、設定画面を開く前の設計で決まります。先に決めたいのは、チケットが進む段階、顧客に表示する情報、閲覧できる人の範囲です。この三つが曖昧なまま公開すると、担当者ごとに更新方法が変わり、顧客側の表示もわかりにくくなります。
チケットパイプラインの段階を定義する
カスタマーポータルの土台はチケットパイプラインです。ステージ名だけを並べるのではなく、どの状態になったら次へ進むのか、誰が更新するのか、顧客には何と表示するのかをセットで決めます。
| 社内ステージ | 社内での定義 | 顧客向け表示 | 次へ進める条件 |
|---|---|---|---|
| 新規 | 問い合わせを受け付けた状態 | 受付済み | 担当者が決まり、内容を確認した |
| 対応中 | 担当者が調査または回答準備をしている状態 | 対応中 | 顧客へ回答を送った |
| 回答済み | 顧客へ回答し、確認を待っている状態 | 回答済み | 解決の確認が取れた |
| クローズ | 対応が完了した状態 | 解決済み | 対応履歴の記録がそろった |
企業様によってステージ構成は異なりますが、顧客に見せる状態は簡潔にするのがおすすめです。社内で「開発確認中」「担当部署へ連携済み」などを管理したい場合は、顧客向けステータスと社内管理用の情報を分けます。
顧客に見せる項目を最小限にする
顧客が知りたいのは、自分が何を問い合わせ、現在どの状態で、次に誰の対応を待っているかです。項目を増やすほど親切になるとは限らないため、チケット名、ステータス、作成日、担当表示など、判断に使う項目から始めます。
一方、原因調査のメモ、社内の相談、エスカレーション先などは顧客向け項目と分けます。項目を最小限にすることは、表示を整えるだけでなく、新しい担当者でも同じ基準で更新できる仕組みづくりにつながります。
個人単位と会社単位の閲覧範囲を選ぶ
公式設定では、自分に関連付けられたチケットだけを見せる方法、主な会社に関連付けられたチケットも見せる方法、条件に合う顧客だけ会社のチケットを見せる方法を選べます。（出典：サポートポータル設定を管理する）
個別相談の内容を他の担当者に見せたくない場合は個人単位が合います。契約窓口や管理者が社内の問い合わせ全体を把握する運用なら会社単位が候補になり、一部の管理者だけ全体を見せたい場合は条件で対象を絞ります。どれを選ぶ場合も、テスト用のコンタクトで見えるチケットを確認し、想定外の会社情報が表示されない状態になってから公開へ進みます。
HubSpotカスタマーポータルを構築する手順
構築は、チケットの土台を整えた後にポータル設定へ進む順番がわかりやすいです。先に外観を作ると、後から受付先や権限を変えたときにテストをやり直す範囲が広がります。以下では、各段階で何ができていれば次へ進めるかも示します。
手順1：チケットパイプラインと受付先を整える
最初に、問い合わせを受け取る受信トレイまたはヘルプデスクと、チケットパイプラインを決めます。問い合わせフォームから作成されたチケットがどこへ届き、どのステージから始まるかをそろえます。
以下の画面は、HubSpotのチケット一覧で、チケット名、パイプライン、チケットステータス、作成日、優先度を確認できる状態です。
この一覧で、担当者が新規チケットと対応中のチケットを区別でき、ステータスを同じ基準で更新できれば、ポータル設定へ進めます。担当者によってステージの使い方が違う場合は、先にステージ定義をそろえます。
手順2：ポータル名、ドメイン、フォームを設定する
HubSpotの「サービス」から「カスタマーポータル」へ進み、ポータル名と利用するドメインを設定します。続いて、顧客が新しい問い合わせを送るためのサポートフォームと、作成されたチケットの受付先を選びます。
この段階の完了条件は、テスト用コンタクトでフォームを送信し、想定した受信トレイまたはヘルプデスクにチケットが作成されることです。フォーム送信はできてもチケットが作成されない場合は、フォームと受付先の接続を見直します。
手順3：チケット権限とログイン対象を設定する
次に、顧客が閲覧できるチケットの範囲と、ポータルへログインできる対象を設定します。アクセスグループで対象を限定する方法と、顧客自身の登録を許可する方法があるため、契約顧客だけに見せるなら前者、広く登録を受け付けるなら後者を検討します。
設定後は、個人閲覧用、会社閲覧用、アクセス対象外のテストコンタクトを用意し、それぞれの表示を比べます。対象外のコンタクトがログインできず、対象者には想定したチケットだけが表示されれば、外観設定へ進めます。
手順4：外観と導線を整えて公開前テストを行う
ロゴやブランド設定、ナビゲーション、ナレッジベースへの導線を整えます。見た目を作り込む前に、顧客が「過去の問い合わせを見る」「新しく問い合わせる」「共通質問を調べる」という行動へ迷わず進める構成を優先します。
公開前テストでは、ログイン、チケット一覧、チケット詳細、返信、フォーム送信、ログアウトまでを顧客の順番で操作します。社内担当者側では、作成されたチケットが適切な受付先に入り、返信が履歴へ残り、クローズ後の表示が想定どおりかを確認します。顧客側と社内側の両方で一連の動きがつながれば、公開判断へ進めます。
ナレッジベースとチケットを一気通貫で連携する
どちらか一方だけだと、次の点が足りません。
- カスタマーポータルだけの場合 ── 共通質問への回答を蓄積する場所が不足します
- ナレッジベースだけの場合 ── 顧客ごとの問い合わせ状況を共有できません
二つを役割分担させ、解決しなかった質問だけをチケットへつなぐ設計が実務では使いやすいです。
問い合わせ前にナレッジベースへ案内する
顧客がポータルへ入ったとき、操作方法や設定手順を探せるナレッジベースへのリンクをわかりやすく配置します。記事タイトルは顧客が使う言葉に合わせ、製品内部の用語だけで分類しない方が探しやすくなります。
ナレッジベースの役割は、担当者の代わりにすべてを回答することではありません。共通化できる内容を記事へ移し、個別判断が必要な内容はフォームからチケットへ送れる状態にします。
解決しない質問をチケットへつなぐ
ナレッジ記事で解決しない場合は、顧客が同じ場所からサポートフォームへ進める導線を作ります。フォームの項目は、担当者が受付後の行動を決めるために使う情報へ絞ります。
フォーム送信後にチケットが作成され、顧客がポータルで進捗を確認できれば、受付から解決までがつながります。なお、更新版のサポートポータルに表示されるのはチケットであり、チケットに関連付いていない会話は表示されません。（出典：サポートポータルを設定する）
解決履歴を次の改善へ戻す
クローズしたチケットは、単に保管するのではなく、どの質問が繰り返されているかを見直す材料になります。同じ内容が続く場合はナレッジ記事へ反映し、案内がわかりにくい場合は記事タイトルや導線を見直します。
この循環によって、ナレッジベースで自己解決できる範囲と、担当者が対応する範囲が少しずつ整理されます。問い合わせを減らすことだけを目標にせず、顧客が必要な情報へ早く到達できる状態を目指します。
公開後の運用を仕組み化する方法
ポータルは公開して終わりではなく、チケットが同じ基準で更新され続けて初めて機能します。担当者の記憶や経験だけに頼ると、表示の更新が止まり、顧客から再確認の問い合わせが発生します。運用ルールを少なく明確にし、引き継げる形へ落とし込みます。
更新担当とステージ移行条件を決める
各ステージについて、誰が更新し、何が起きたら次へ進めるかを決めます。例えば、回答を送っただけで「解決済み」にせず、顧客の確認を待つなら「回答済み」に置くというように、言葉と行動を対応させます。
ルールは担当者名ではなく役割名で残すのがおすすめです。担当交代があっても、新しい担当者が同じステージ定義を見て運用できるため、個人の力量ではなく仕組みで対応品質をそろえやすくなります。
最初は対象を絞って始める
初回公開で、すべての顧客、すべての問い合わせ種別、細かなデザイン変更まで広げる必要はありません。まずはチケット確認と新規問い合わせの導線を整え、対象となる顧客を絞って運用します。
試行中は、顧客がログインできたか、目的のチケットが見えたか、フォームから問い合わせを作れたかを確認します。この基本動作が安定した後に、ナレッジ記事、会社単位の閲覧、外観調整へ段階的に広げる方法をStartLinkではおすすめします。
利用されない理由を行動別に分ける
利用が進まないときは、顧客へ案内メールを増やす前に、どの段階で止まっているかを分けます。
- 招待を受け取っていない ── アクセス対象を見直します
- ログインできない ── 認証を見直します
- ログイン後に迷う ── ナビゲーションを見直します
- 問い合わせだけメールへ戻る ── フォーム導線を見直します
判断する場所を分けると、原因に合う修正を選べます。ポータルの存在を知らせるだけでなく、初回ログインの案内、利用方法の記事、問い合わせ時の案内文を同じ導線として整えます。
導入前に理解したい限界と向かないケース
カスタマーポータルは、すべてのサポート業務を置き換えるものではありません。HubSpotの強みは、コンタクト、会社、取引、チケットを一元的に扱えることですが、個別要件によっては専用の仕組みが合う場合もあります。利点だけでなく、表示範囲と運用負荷を先に見ておくことが大切です。
チケットになっていない会話は表示されない
更新版のサポートポータルで顧客に見せる単位はチケットです。
ただし、これは受付経路ごとに確認方法を変える理由にはなりません。フォーム、メール、ヘルプデスクから入った問い合わせがチケットになる流れを整理し、表示させたい問い合わせだけがチケットとして残る状態を作ります。
社内情報と顧客向け情報を分ける必要がある
チケットの会話に含まれる内容は、権限を持つ顧客から見える可能性があります。社内の検討や担当者同士の相談は、顧客へ送る返信と混ぜず、内部用のメモやコメントとして扱います。
公開前には、顧客用アカウントでチケット詳細を開き、件名、本文、添付、担当表示、ステータスを順に確認します。社内だけで扱う情報が見えた場合は、その情報の記録場所を変えてから再テストします。
高度な専用要件には別の選択肢もある
- サポート専業ツール ── 複雑な承認、独自の画面、細かな権限制御などを中心にする場合は、要件に合うことがあります
- HubSpot ── 営業前のコンタクト情報から取引、顧客化後のチケットまでを同じCRMで追いたい場合は、HubSpot内でつながる利点があります
選定では、画面の機能数だけでなく、問い合わせ履歴をどの部門が使うかを確認します。サポート部門だけで完結するなら専用性を、営業やカスタマーサクセスも履歴を使うならCRMとの一元管理を重視すると判断しやすくなります。
よくある質問
ここでは、HubSpot カスタマーポータル 構築を検討するときに確認したいプラン、デザイン、権限、ナレッジベースの疑問を整理します。
カスタマーポータルはどのプランで利用できますか？
更新版のサポートポータルは、公式手順ではService Hub ProfessionalまたはEnterpriseが対象です。従来版のカスタマーポータルからの移行も含め、契約中の機能と顧客への公開範囲を確認してから見積もり・設定へ進めます。（出典：サポートポータルを設定する）
自社ブランドに合わせて外観を変えられますか？
ロゴやブランド設定、テーマ、ナビゲーションを調整できます。最初はブランドの基本要素と主要な導線を整え、顧客がチケット確認と新規問い合わせへ迷わず進める状態を優先するのがおすすめです。
顧客ごとに表示するチケットを制限できますか？
自分に関連付けられたチケットだけを見せる方法、会社に関連付けられたチケットも見せる方法、条件に合う顧客だけ会社のチケットを見せる方法があります。個別相談を扱うなら個人単位、契約窓口が全体を管理するなら会社単位というように、情報共有の範囲で選びます。
ナレッジベースがなくても利用できますか？
チケットの確認や作成を中心にポータルを構成できます。ただし、共通質問が多い場合は、ナレッジベースへ案内し、解決しない内容だけチケットへつなぐ方が、顧客と担当者の双方にとってわかりやすい導線になります。
まとめ
HubSpot カスタマーポータル 構築では、ポータル画面より先にチケットの流れと公開範囲を設計することが重要です。顧客向けのセルフサービスと社内の問い合わせ管理を同じチケットでつなぐと、対応履歴をCRMの顧客情報として活用できます。
- カスタマーポータルは、顧客がチケットを確認・作成・返信するためのログイン領域です。
- チケットステージは、社内の定義、顧客向け表示、次へ進む条件をセットで決めます。
- 権限は、個人単位、会社単位、条件付きの会社閲覧から契約と情報共有の範囲に合わせて選びます。
- ナレッジベースで共通質問を扱い、解決しない内容をチケットへつなげます。
- 最初は対象を絞り、基本動作を確かめてから機能と対象範囲を広げます。
まずは現在の問い合わせ対応を、受付、対応中、回答済み、解決済みの流れに並べるところから始めます。そのうえで、次の順番で構築を進めてください。
- 現在使っているメールとスプレッドシートから、問い合わせの受付経路と対応段階を書き出します。
- 顧客に見せるステータス、項目、閲覧範囲を決め、HubSpotのチケットパイプラインへ反映します。
- テスト用コンタクトでログインからチケット作成、返信、クローズまでを通し、社内側の履歴と照合します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
カスタマーポータルや顧客対応に関連するテーマは、次の記事もあわせて確認できます。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
