HubSpotカスタマーポータルのチケット表示範囲:誰がどのチケットを見られるか、その制御方法
Rama Adi
Katelin Teen
最終更新 November 5, 2026
HubSpotカスタマーポータルでのチケット表示範囲は、選んだ権限設定と、各チケットが紐づくレコードという2つで決まります。権限設定がルールを決め(自分のチケットだけ、会社全体、選んだ連絡先のみ)、紐づけがそのルールをどのチケットに適用するかを決めます。「違うチケットが表示される」という問題の多くは、実は連絡先の主要会社が間違っていることが原因です。B2Bアカウントなら、私はSelected customers can see company ticketsを選び、公開前に主要会社の紐づけを整理し、社内の会話はノートとコメントに留めます。スレッド内のものはすべてポータルで読めてしまうからです。eeselはHubSpotのチケットに内部コメントとして返信を書くので、チームの誰かが送信するまでポータルには何も届きません。
HubSpotカスタマーポータルのチケット表示はどう決まるのか
カスタマーポータル(HubSpotは更新版をサポートポータルと呼んでいます)は、顧客がチケットを見たり返信したり送信したりできるログインページです。Service Hub ProfessionalまたはEnterpriseが必要です。顧客がそこで何を見るかは、2つの独立した設定で決まります。
- どのチケットを見られるか。 権限設定と、チケットが連絡先・会社に紐づく内容の組み合わせ。
- 各チケット内で何を見られるか。 列として表示するプロパティと、会話スレッド。
私はHubSpot連携を含むeeselの連携を作っていますが、HubSpotの権限設定は、その裏にある紐づけデータの質以上には機能しないと学びました。私たちのHubSpotエージェントは、各チケットをそれに紐づく連絡先・会社・ディールと一緒に読みます(eeselのHubSpotドキュメント)。紐づけが乱れていると、返信がすぐに的外れになって表れます。ポータルも同じ仕組みです。紐づけが示す通りに動くだけで、顧客にはCRMが本人に結びつけたものがそのまま見えます。
始める前に重要な制約が2つあります。
- 表示されるのはチケットのみ。 チケットに紐づいていない会話は表示されません。インボックスやヘルプデスクのチャット、Facebook Messenger、フォーム、チームメールのメッセージが対象です。ただし、チケットが表示されるのに会話は必須ではありません。
- 機密性の高い添付ファイルはHubSpot内に留まります。 Sensitive Dataの設定が有効なら、顧客はポータルでそれらのファイルを開けません。
| プラン | カスタマーポータル | 開始価格 | 初回オンボーディング費 |
|---|---|---|---|
| Free、Starter | なし | $0 / $7（1席・月） | なし |
| Professional | あり、access groupは最大2個(プライベートナレッジベースと共有) | $90（1席・月） | $1,500 |
| Enterprise | あり、access groupは最大100個(プライベートナレッジベースと共有) | $150（1席・月） | $3,500 |
出典:HubSpot Service Hubの料金。HubSpotの料金とHubSpotのレビューの記事では、ポータル以外の部分も扱っています。
どのCustomer Ticket Permissionを選ぶべきか
Service > Customer Portal > TicketsのCustomer Ticket Permissionsセクションには、3つの選択肢があります(HubSpotドキュメント)。
| 選択肢 | 誰がチケットを見られるか | 向いている場合 |
|---|---|---|
| Only tickets they're associated with | そのチケットに紐づく連絡先 | B2C、または同僚同士の依頼を見せたくないアカウント全般 |
| All tickets from their company | そのチケットの主要会社に属するポータル利用者全員 | 全員が同じプロジェクトで働く小規模なB2Bアカウント |
| Selected customers can see company tickets | 連絡先プロパティのフィルタに合致する連絡先が会社のチケットを見られ、それ以外は自分のチケットのみ | 大半のB2Bアカウント:管理者やチャンピオンは全部見え、他のユーザーは自分のものだけ見える |
「紐づく」は「提出した」より広い意味を持ちます。HubSpot自身の説明によれば、顧客は「submitted or been added to」したチケットを見られるので、同僚をチケットの連絡先に追加するだけで、最も厳しい設定でもその人にアクセス権が渡ります。
Selected customersの選択肢はより新しく、チームは何年も前からこれを求めていました。2024年のHubSpot Communityのアイデアがその理由を説明しています。
"For some customers allowing everyone to see all tickets from everyone else would open a hugh data-security issue, e.g., if some projects we work with are confidential."
これはまさにSelected customersが対応するケースです。設定するにはManage contact propertiesをクリックしてフィルタを追加します。私ならJob titleやLifecycle stageを使い回すより、Portal: sees company ticketsのような専用のチェックボックスプロパティを作ります。役職は誰かが昇進すれば変わりますが、チェックボックスはチームの誰かがそう決めた時だけ変わります。ドキュメントにある落とし穴として、フィルタはパネルを閉じた時点で適用されますが、それを維持するにはビューを保存する必要があります。
会社レベルのアクセスが有効な場合、顧客には2つのタブが表示されます。My view(自分の連絡先に紐づくチケット)とOrganization view(主要会社に紐づくチケット)です。「Tickets」を、顧客が使う言葉、たとえばOrdersやCases、Requestsに変更することもできます。
Zendeskから移行してきた方には、これが会社全体でのチケットアクセスに相当するHubSpot版の機能です。Zendesk B2BサポートとFreshdeskカスタマーポータルの設定の記事では、他の2つのツールでの扱い方を紹介しています。
チケットが間違った場所に表示される、または表示されないのはなぜか
ポータルの表示に関する問題のほとんどは、紐づけに起因します。権限設定は紐づけだけを読んで判断するので、間違った会社が紐づいたチケットは間違った人に表示されてしまいます。
これらのルールは、HubSpotのレコードの紐づけと会社の自動紐づけに関するドキュメントによるものです。
- チケットは連絡先の主要会社を継承します。 Associate Ticket to a Contact's Primary Companyを無効にしていない限り、「For tickets, the associated contact's primary company will be automatically associated」します。
- 最初に紐づいた会社がデフォルトで主要会社になります。 最初に紐づけられた会社は、誰かが変更するまで主要会社のままです。
- ポータルで有効なのは主要会社だけです。 Organization viewは顧客の主要会社に紐づくチケットを表示します。主要ではない2番目の会社に紐づくチケットはそこに表示されず、親会社に子会社のチケットを見せる設定もありません。
- 会社はメールのドメインで紐づけられます。 自動紐づけが有効な場合、
sandra@example.comはドメインがexample.comの会社に紐づきます。サブドメインは別の会社を作るため、@example.comと@info.example.comは2つの別レコードになります。 - フリーメールのアドレスは通常会社に紐づきません。 Gmailやhotmailの連絡先は、Website URLプロパティが一致する場合にのみ会社に紐づきます。
- ドメインが重複していると、HubSpotが代わりに会社を選びます。 2つの会社が同じドメインを共有している場合、HubSpotはどちらか一方を選び、「it is not possible to select which company the contacts should be automatically associated with」状態になります。
B2Bチームに最も響く落とし穴がこれです。業務委託先、代理店、リセラーの連絡先は、自分の勤め先を主要会社として持っています。その人が本来の顧客のプロジェクトについてチケットを開くと、そのチケットは代理店を会社として継承するため、代理店のOrganization viewに表示され、本来の顧客のものには表示されません。
この落とし穴には2つ目のパターンもあります。チームによっては、HubSpotがチケットを顧客の会社ではなく自社の会社レコードに紐づけてしまうことに気づきます。HubSpot Communityのスレッドでもそう説明されています。これは大抵、自社のスタッフがチケットの連絡先として登録されている場合に起こります。解決策は、自社のドメインをopted-outドメインのリストに追加すること(HubSpotは最大1,000個の除外ドメインを許可しています)と、自社のスタッフを顧客のチケットの連絡先に加えないことです。
チケットがまったく表示されない場合は、次の順で確認してください。
- 会話がチケットに紐づいているか。 チケットのないチャットやMessengerのスレッドは決して表示されません。
- 正しい連絡先が紐づいているか。 メールのFrom欄ではなく、チケットレコードのサイドバーを確認してください。
- チケット表示フィルタがそれを隠していないか。(詳細は後述)
- 実際の顧客としてテストしているか。 HubSpotにログイン中だと、ポータルはログインをスキップしてチケット一覧を表示してしまいます。実際の連絡先として、プライベートウィンドウでテストしてください。テストチケットが見えなかったHubSpot Communityの投稿では、原因は「was my cache」だったとわかりました。
- ヘルプデスクに移行したばかりか。 あるCommunity Championは、ヘルプデスクへの移行後、ポータルのフォームチケットが正しい連絡先に紐づかず、顧客のビューから消えてしまったと報告しています。解決策は、ポータルのデフォルトインボックスをHelp Deskに設定することでした。
ルーティングや紐づけのルールがより大きな整理作業の一部なら、HubSpotのチケットルーティングとHubSpot CRMデータの整理の記事がさらに詳しく扱っています。
ポータルに表示するチケットをどう絞り込むか
権限設定が決めるのは、顧客が誰のチケットを見られるかです。Ticket visibilityフィルタが決めるのは、どの種類のチケットがそもそも表示されるかです。TicketsタブでSelect ticket propertiesをクリックし、続いてAdd filterをクリックして、任意のチケットプロパティに条件を設定します(HubSpotドキュメント)。
ほとんどのアカウントで私が設定する3つのフィルタです。
- Pipelineはサポート用パイプラインに限定する。 エンジニアリングへのエスカレーション、財務チームが処理する請求トラブル、オンボーディングプロジェクトといった社内向けパイプラインは、顧客の連絡先が紐づいているだけで表示されるべきではありません。
Show in portalプロパティがNoでないこと。 単一のチェックボックスがあれば、エージェントは機密性の高いチケットを別のパイプラインに移さずに隠せます。- システムチケットのカテゴリを除外する。 更新リマインダーのようなワークフロー生成のチケットがあるなら、それらをカテゴリで除外し、顧客が開いたことのないチケットを見せないようにしてください。
このフィルタに頼る前に知っておくべきことがあります。これはポータルに表示される一覧を変えるだけで、CRM内のチケットの紐づけは変えません。あるパイプラインが本当に顧客に届いてはならないなら、顧客の連絡先をそのチケットから外しておいてください。チケットの振り分けの記事では、最初からキューを分けておく方法を紹介しています。
チケット内で顧客は何を見られるか
顧客が見られるのは、表示を選んだチケットプロパティだけです。デフォルトでは6つです(HubSpotドキュメント)。
| デフォルトの列 | 補足 |
|---|---|
| Subject | チケット名。チームやワークフローがここに書いた内容を顧客が読む |
| Requested by | 提出した連絡先 |
| Create date | |
| Ticket owner | デフォルトは名(ファーストネーム)。フルネーム、姓、独自のエイリアスも選べる |
| Last activity date | |
| Status | パイプラインのステージ名なので、顧客に伝わりやすい言葉でステージ名を付ける |
プロパティは最大10個まで表示でき、並べ替えやリネームもできます。モバイルのカードビューでは最初の2つしか表示されません。Priorityのような社内向けの項目はリストから外してください。HubSpot自身の例でも、Priorityを外してTicket nameを表示しています。顧客はExport to CSVもクリックできるため、今表示されているビューの内容がすべて書き出されます。つまり表示している列はすべて、表計算ソフトに出ていく可能性があるものとして扱ってください。
会話スレッドには独自のルールがあります。
- チケットに複数のスレッドが紐づいている場合、HubSpotの設定ガイドによれば表示されるのは元のスレッドのみです。顧客が複数スレッドを見る権限を持っている場合は、チケット上部にタブが表示され、切り替えられます。
- 会話スレッドの内容は、そのチケットを見られる顧客全員に見えます。HubSpotの助言は、社内の会話にはノートとコメントを使い、社内メールがスレッドに混入しないようフィルタルールを設定することです。
- どの会話が表示されるかは、チケットレコードの右サイドバーにあるConversationsカードで確認できます。
注意したいのは「全員に返信」のリークです。エージェントが顧客へのメールにエンジニアリングの同僚をCCで入れ、その同僚が「正直これはこちらのバグで、火曜に修正を出しました」と返信すると、その返信は今やスレッドに残り、顧客はそれをポータルで読めてしまいます。アカウントマネージャーへのメール転送でも同じことが起こります。スレッドに入っていれば、それは公開されたも同然です。
顧客にチケットのクローズや再オープンを許すべきか
チケットに関する2つのアクションは、同じTicketsタブにあります。Allow customers to reply to closed conversationsとAllow customers to close tickets from the portalです。クローズを有効にすると、パイプラインごとにクローズ済みステージを選びます。パイプラインにクローズ済みステージが1つしかない場合は、HubSpotが自動でそれを選びます。
私の考えでは、顧客によるクローズは有効にして、メインのResolvedではなくClosed by customerのような専用ステージに割り当てるべきです。「顧客が諦めた」と「こちらが解決した」を同じものとして数えないことで、ファーストコンタクト解決率や解決時間のレポートが正確になります。クローズ済みの会話への返信許可も、ワークフローがチケットを再オープンするか、返信が来たときに担当者に通知する仕組みがある限り、有効にする価値があります。そうでなければ、顧客は誰も見ていないチケットに書き込むことになり、静かにSLAを破ってしまうかもしれません。
そもそも誰がポータルに入れるのか
チケットの表示範囲は、誰かがログインできるようになって初めて意味を持ちます。Accessタブには、入る方法が2つあります(HubSpotドキュメント)。
- Access group membership required。 access groupを選ぶと、HubSpotがその連絡先に登録用リンクをメールで送ります。Professionalはaccess groupを最大
2個、Enterpriseは最大100個まで許可し、この上限はプライベートナレッジベースと共有されます。 - Self-registration required。 誰でも登録できます。プライベートコンテンツの設定でセルフ登録を有効にする必要があり、データ処理への同意表示も用意すべきです。
セットアップで見落としやすい点が3つあります。
- hs-sitesやhubspotpagebuilderのようなHubSpotのシステムドメイン上のポータルは、access groupへのmembershipメールを送信しません。まず自社ドメインを接続してください。
- 登録メールは連絡先のmember emailプロパティ宛てに送られ、それは必ずしもメインのメールアドレスではありません。
- ポータルはドメインの主要言語で表示され、HubSpotはまだ多言語ポータルに対応していません。多言語サポートの回避策は、HubSpotの翻訳の記事で扱っています。
顧客は通常、HubSpotのナレッジベース経由でポータルに到達するため、両者はaccess groupの上限を共有しています。セルフサービスをより広く見るなら、カスタマーサポートポータルとHubSpotのチケット削減の記事が次のステップです。
公開前の表示範囲チェック(所要約30分)
ポータルを有効にする前、あるいは稼働中のポータルの権限を変更する前に、このチェックリストを確認してください。
- 複数の会社が紐づいている連絡先のリストを出す。 主要会社が、実際に働いている会社であり、代理店や以前の勤め先ではないことを確認します。
- 自社の会社レコードに紐づくチケットを探す。 その紐づけを外し、自社ドメインをopted-outドメインのリストに追加します。
- ドメインを共有している会社を一覧化する。 統合するか、手動で紐づけを修正してください。そうしないとHubSpotが代わりに1つを選んでしまいます。
Portal: sees company ticketsのチェックボックスを作成する。 Selected customersを使う場合は、各アカウントの管理者やチャンピオンに有効化します。- チケット表示フィルタを設定する。 顧客向けのパイプラインだけに絞ります。
- 顧客に悪印象なパイプラインステージ名(
Waiting on dev、Escalated - angryなど)をリネームする。 - 列を絞り込む。 顧客にエクスポートさせてよい内容だけに限定します。
- 同じ会社の実在する連絡先2人でテストする。 チェックボックスの有無それぞれでプライベートウィンドウからテストし、My viewとOrganization viewで見える内容を比較します。
ポータルが初めてなら、最初のaccess groupを招待する前にこのテストをしてください。設定を直すほうが、同僚のチケットを見てしまった顧客からのメールに対応するよりずっと簡単です。
HubSpotユーザーはカスタマーポータルについて何と言っているか
レビューでポータルが言及される頻度はヘルプデスクより少なく、共通する声は、ほとんどのチームにはうまく機能するが、上位層では手狭に感じられるというものです。
"customer portal needs further work to cater for enterprise sized businesses"
HubSpot Communityで最も要望が多い欠落点は、ここまで扱ってきた内容と重なります。会社レベルのアクセスのアイデアは今ではDeliveredとされ、その後に出た選択した連絡先についての要望が、今日のSelected customersオプションの内容を説明しています。他のフォーラムのアイデアには、子会社のチケットや、連絡先のディールに紐づくチケットを求める声もあります。これがあなたのアカウント構成に関わるなら、今はそれを前提に計画してください。HubSpotの代替とHubSpot対Zendeskの記事では、他のヘルプデスクが会社をどうモデル化しているかを比較しています。
顧客がチケットを見られる状況で、AIはどこに関わるのか
顧客がポータルでチケットを読めるようになると、AIツールがそのチケットのどこに書き込むかがより重要になります。HubSpotに接続するどのAIでも、HubSpot自身のBreeze Customer Agentを含めて、確認すべき点が2つあります。
- スレッドに下書きするか、コメントに下書きするか。 スレッドのメッセージとして投稿された下書きは公開されます。内部コメントとして残された下書きは公開されません。
- チケットをリネームするか。 チケット名はポータルのSubject列です。チームのトリアージ用にタイトルを書き換えるAI(「Angry - refund - 3rd time」など)は、顧客に見える内容も同時に書き換えています。
eeselのHubSpotエージェントは、デフォルトで安全な側に倒します。そのAdd internal commentアクションは「a comment the customer can't see」と説明され、ドキュメントもそこから始めることを勧めています。エージェントが下書きし、人が送信するという形です(eeselのHubSpotドキュメント)。チケットのタイトルや説明の更新もできるので、そのアクションを許可するなら、タイトルを顧客に優しい表現に保つよう指示に書いてください。
フランスのオンライン学習プラットフォーム、MentorShowもまさにこの構成で運用しています。サポートチームは完全にHubSpot上で業務を行い、eeselは取り上げた会話とチケットに内部ノートを残します。チーム向けの分析と、続いてメンバーの言語での返信下書きです。下書きの前には、メンバーのHubSpotレコード(サブスクリプションの状態、次回更新日、過去のチケット)を読みます。2026年8月8日から9月8日の間に、約1,200件のHubSpotの項目(インボックス会話648件、チケット586件)を読み、ナレッジベース検索を837回実行し、チームが確認・送信するための下書きを432件書きました。
あなたのHubSpotチケットでeeselを試す
ポータルをきちんと整えたら、次のボトルネックはその裏にあるキューです。eesel for HubSpotは、Service Hub内の新しいチームメイトのように働きます。HubSpotのナレッジベースと過去のチケットから学び、そのソースを有効にすれば各チケットの背後にある連絡先と会社を読み取り、すべての返信を内部コメントとして残すので、チームが送信するまでポータルには何も届きません。日常的な質問で信頼できると分かったら、直接返信させることもできます。まずは単一のパイプラインでeeselを試すか、HubSpot向けの最良のAIの記事で選択肢を比較してみてください。
ターミナルから設定したい場合は、eeselのCLIを使えば、Claude Code、Codex、Cursorがeesel integrations connect hubspotを実行し、ソースを同期し、内部コメントの自動化を有効化した後、テストの質問を投げて、チケットが公開される前に下書きを確認できます。それでも、HubSpotのApp Marketplace Access権限を持つ誰かが、ブラウザで接続を承認する必要があります。