HubSpotチケットの使い方｜問い合わせ管理のステータス設計、SLAの置き方と営業・マーケへの渡し方

チケットは、既存顧客の用件1件を解決まで追うレコードで、取引とは終わり方が違う

HubSpotのチケットとは、顧客からの問い合わせや依頼を1件ずつ記録し、担当者・優先度・ステータスを付けて解決まで追うためのCRMのレコードです。取引が「受注か失注か」で終わるのに対し、チケットは「顧客の用件が片付いたか」で終わります。

チケットは、コンタクト・会社・取引と同じCRMのオブジェクトの一つで、それぞれに関連付けられます。導入後の操作の質問、不具合の報告、請求書の再発行、契約内容の相談といった用件を1件ずつチケットにすると、会社レコードを開いたときに、その会社がいま何件の問い合わせを抱えていて、どれが止まっているかが一覧で見えます。

取引とチケットの違いは次のとおりです。どちらで管理するか迷ったときは、その用件で金額が動くかどうかで分けます。

迷いやすいのは、既存顧客から「利用人数を増やしたい」「上位プランの見積もりがほしい」と連絡が来たときです。サポート担当が受けた時点ではチケットとして記録し、見積もりを出す段階になったら営業が取引を作って、チケットと取引を関連付けます。チケットのまま金額を追い始めると、売上の集計にも問い合わせの集計にも入らない案件が生まれます。取引側のステージの区切り方は取引パイプラインのステージを買い手側の出来事で区切る考え方に合わせると、チケットから取引に移る境目も同じ基準で決められます。

無料版・Starter・Service Hub Professionalで変わる範囲

チケットの作成とパイプラインでの管理は無料のツールでも使えます。チャネルをつないでチケットを自動で作るヘルプデスク、自動の振り分け、SLAは、Service Hub Professional以上の機能です。

公式の製品カタログとナレッジベースで確認できた範囲を、無料ツール、Service Hub Starter、Service Hub Professionalの3つで並べると次のようになります。料金体系や上限は改定されることがあるため、契約前にHubSpotの公式ページで最新の条件を確認してください。プラン全体の選び方はStarterとProfessionalの違いと選び方と合わせて判断します。

見落としやすいのは、アカウントを作った時期による違いです。公式ナレッジベースでは、2024年4月1日以降に作成されたアカウントは、受信トレイに接続したチャネルからチケットを作成できず、チケットの管理にはヘルプデスクを使うよう案内されています。フォームについても、同じ日付以降のアカウントでは、ヘルプデスクに接続したフォームからしかチケットを自動作成できません。

無料ツールとStarterでチケットを使う場合は、担当者がコンタクトや会社のレコードからチケットを作り、メールのやり取りをそのチケットに関連付けます。問い合わせが週に数件で、受ける人が1〜2人に決まっている会社なら、手動での作成でも漏れは起きにくく、Professionalに上げる前にこの運用で件数とカテゴリーの傾向をつかめます。

チケットのステータスは、問い合わせの種類ではなく「いま誰の番か」で区切る

チケットパイプラインのステータスは、自社が動く番か、顧客の返答を待つ番かが一目で分かるように区切ります。問い合わせの種類はステータスにせず、カテゴリーのプロパティで分けます。

HubSpotのチケットには、既定で「サポートパイプライン」が用意されていて、公式ヘルプによるとステータスは New（新規）、Waiting on contact（コンタクトの返答待ち）、Waiting on us（自社の対応待ち）、Closed（クローズ）の4つです。既定の4つは「誰の番か」で区切られているため、そのまま使い始めても困りません。追加するなら、社内の別部署に確認を回している状態と、回答を送って顧客の確認を待っている状態の2つです。

ステータスを「誰の番か」で区切る理由は、朝いちばんにサポート担当が見る画面が「自社の番のチケット」だけになるからです。「不具合」「質問」「請求」のように種類でステータスを作ると、不具合のチケットが調査中なのか顧客の返事待ちなのかが分からず、結局チケットを1件ずつ開いて確かめることになります。Service Hub ProfessionalのSLAでは、公式ヘルプのとおり、保留中や顧客の返答待ちのステータスでタイマーを一時停止できるため、顧客の番を独立したステータスにしておくと、応答時間の計測も実態に合います。

パイプラインを分けるのは、対応するチームと手順が違うときだけにします。導入直後の立ち上げ支援を別のチームが担当している会社なら、「導入支援」と「通常サポート」でパイプラインを分ける理由があります。一方で、同じ担当者が同じ手順で返すのに問い合わせの種類ごとにパイプラインを作ると、レポートでパイプラインをまたいで合算する手間が増えるだけです。

チケットに持たせるプロパティは、最初は次の4つに絞ります。

• カテゴリー：導入後の操作の質問、不具合、契約・請求の相談、機能の要望、拡張の相談
• 優先度：業務が止まっているか、回避策があるか、急がないか
• 受付経路：メール、フォーム、チャット、電話、営業経由
• 関連付け：コンタクトだけでなく会社にも必ず紐付ける

カテゴリーの選択肢に「拡張の相談」を入れておくのは、後で営業に渡す問い合わせをクローズ時点で拾うためです。項目を増やすときの基準は作りすぎを防ぐプロパティの作成基準に合わせ、「誰がどのレポートで使うか」を答えられない項目は作りません。

メール・フォーム・チャットからチケットを自動で作るには、窓口を先に一つに寄せる

Service Hub Professionalのヘルプデスクでは、接続したチャネルに届いた問い合わせから既定でチケットが自動作成されます。自動作成の前に、顧客がどの窓口に連絡すればよいかを決めて伝えておかないと、営業の個人メールに届く問い合わせが記録から漏れます。

公式ヘルプによると、ヘルプデスクに接続できるチャネルにはメール、フォーム、チャット、電話などがあり、接続したチャネルに届いた問い合わせは既定でチケットになります。チャネルごとに決めることは次のとおりです。

フォームの作り方や送信後の通知の設定はHubSpotフォームの作り方と送信データの上書きルールと共通です。サポート用のフォームは、見込み客向けの資料請求フォームとは分けて作ります。1つのフォームで両方を受けると、既存顧客の不具合報告がマーケティングのリードとして数えられ、商談化率の分母が膨らみます。

チャットは、見込み客向けのサイトと既存顧客向けの画面で役割が違います。営業時間外の受け方や担当者への通知はチャットボットの営業時間外の受け方と振り分けの設定をそのまま使い、既存顧客からの会話はヘルプデスク側で受けるように分けておくと、営業担当の受信トレイにサポートの会話が混ざりません。

窓口を寄せるときにいちばん残りやすいのは、営業担当に直接届くメールです。長く付き合っている顧客ほど、サポート窓口ではなく担当営業に「ちょっと聞きたいんですが」と連絡してきます。営業がそのメールをサポートのアドレスに転送するのか、自分でチケットを作ってサポート担当に割り当てるのかを決めておかないと、営業の受信箱で止まった問い合わせは、どのレポートにも出てきません。同じ用件で複数のチケットができた場合は、ヘルプデスクのマージ機能で1件にまとめられます。

担当の割り当ては、会社ごとの担当者に寄せるか、受け付けた順に配るかを先に決める

既存顧客の問い合わせは、見込み客のリードと違い、すでにその会社を知っている担当者がいます。会社ごとに担当者を固定するか、サポートチームで受け付けた順に配るかを決めてから、ヘルプデスクの振り分けを設定します。

Service Hub Professional以上のヘルプデスクでは、接続したチャネルごとに振り分けのルールを設定できます。公式ヘルプで確認できる振り分けの方法は、未解決のチケットが少ない人に配る負荷分散、順番に配るラウンドロビン、ランダムの3つで、割り当て先には特定のユーザーやチーム、コンタクトの担当者、割り当て用のワークフローなどを選べます。チケットを受け取るユーザーには、Serviceシートの割り当てとヘルプデスクでチケットにアクセスする権限が必要です。

BtoBで判断が分かれるのは、コンタクトの担当者に割り当てるかどうかです。カスタマーサクセスが1社ずつ担当を持っている会社なら、担当者に割り当てたほうが、経緯を説明し直す手間がなくなります。一方で、担当者が休暇中や商談中だと、その間チケットは誰にも見られません。担当者に割り当てる場合でも、一定時間返信がなければチームの共有の担当に戻すルールをセットで決めます。割り当てた後に動かないときの移し先の考え方は放置されたときの再割り当てのルールと同じで、時間制限と移し先を決めておきます。

サポートの人数が2〜3人で、全員がどの問い合わせにも答えられる会社なら、担当者を固定せず、チームに割り当てて受け付けた順に取るほうが返信は早くなります（人数は判断のための例です）。不具合の調査に製品の知識が必要で、答えられる人が限られているなら、カテゴリーが「不具合」のチケットだけをその人に寄せます。

チケットに誰がアクセスできるかは、営業にもサポートにも関わります。営業担当に自分の顧客のチケットは見せたいが、編集はさせたくない、といった条件は役割別に閲覧範囲を決める権限設定の中で決めます。

SLAの目安は、契約で約束している時間と、今の実績の両方から置く

SLAの時間は他社の相場ではなく、契約書や利用規約で顧客に約束している応答時間を上限にし、今の実績を測ってから置きます。約束がないなら、まず実績を測る期間を取ってから目標を決めます。

Service Hub Professional以上のヘルプデスクでは、公式ヘルプのとおり、「初回返信までの時間」「次の返信までの時間」「クローズまでの時間」の3種類のSLA目標を設定できます。対象のパイプラインとステータスを選び、営業時間を指定して計測し、顧客の返答待ちなどのステータスではタイマーを止められます。優先度やカテゴリーなど、チケットのプロパティの組み合わせごとに別のSLAを置くにはEnterpriseが必要です。

目安を置く順番は次のとおりです。

1. 契約書・利用規約・サポートページで、顧客に応答時間を約束しているかを確認する。約束していれば、それが守るべき上限になる
2. チケットの運用を始めてから一定期間、初回返信とクローズまでの実際の時間を測る
3. 実績の中央値をもとに、今の人数で守れる時間を目標にする。守れない目標を置くと、SLA超過の通知が毎日鳴り、誰も見なくなる
4. 優先度が高いもの（業務が止まっている不具合）だけ短い目標を別に置く

たとえば、利用規約に「営業日の翌日までに一次回答」と書いてある会社なら、初回返信の目標は営業時間で数えて1営業日以内が上限です。業務が止まっている不具合だけは当日中の初回返信を目標にし、クローズまでの時間は不具合と質問で分けて見る、という置き方になります（時間はすべて説明のための例です）。

無料ツールとStarterではSLAの機能がないため、週に一度、クローズしていないチケットを作成日の古い順に並べ、自社の番のまま止まっているものを確認する運用で代わりにします。件数が少ないうちは、この確認で十分に漏れを拾えます。応答時間を顧客との約束として厳密に管理する必要が出てきた時点が、Professionalを検討する時期です。SLAの設計や窓口の寄せ方を自社の体制に合わせて決めたい場合は、問い合わせ管理の設計について相談することもできます。

チケットの記録を営業とマーケティングに渡すと、アップセル・解約・コンテンツの材料になる

チケットはサポートの作業記録であると同時に、既存顧客が何に困り、何を欲しがっているかの記録です。会社ごとの件数とカテゴリーを月に一度営業とマーケティングが読む場を作ると、拡張の相談、解約の兆候、FAQやコンテンツのネタを拾えます。

渡し先ごとに、チケット上でどう見えるかと、どう渡すかを決めておきます。

拡張の兆候は、問い合わせの文面に出ます。「別の部署でも使いたいがアカウントはどう増やすのか」という質問は、サポート担当にとっては操作の質問ですが、営業にとっては提案の入口です。提案の前に利用状況のどこを見るかは提案の前に見るべき利用状況の見方に沿って確かめ、チケットの記録はその判断材料の一つとして使います。

解約の兆候のうち、チケットに出るものと出ないものがあります。不具合の連続や解決までの長さはチケットの件数と時間で見えますが、問い合わせが急に止まった会社は、チケットの一覧を見ているだけでは気づけません。前の四半期に毎月問い合わせがあった会社で、直近の件数がゼロになっているものを会社別のレポートで拾います。チケット以外に出る兆候も含めた見方は既存顧客マーケティングでの解約の予兆のつかみ方と組み合わせます。

マーケティングにとってのチケットは、顧客が実際に使った言葉の記録です。同じ操作の質問が毎月届くなら、その答えを導入直後のオンボーディングメールやヘルプ記事にし、送った後の月にそのカテゴリーの件数が減ったかを見ます。会社別・カテゴリー別の件数を毎月同じ形で出すレポートは、レポートの指標と可視化の手順に沿って一度作り、営業定例のダッシュボードに置いておきます。

対応の手間や満足度も記録に残すなら、チケットのクローズ時に送るアンケートと送りすぎの防ぎ方を決めておくと、回答がチケットと会社に結び付いて残ります。問い合わせの多い顧客には、再アンケートの間隔を必ず設定します。

HubSpotにチケットを持たないほうがよい場合

専用のヘルプデスクで運用が安定している会社、問い合わせが少なく受ける人が1人の会社、不具合の管理を開発チームの課題管理ツールで完結させている会社は、HubSpotにチケットを持たないか、件数だけを連携するほうが手間が少なく済みます。

すでに別のヘルプデスクを使っていて、サポートチームがその画面で毎日の対応を終えられているなら、チケットをHubSpotに移す理由は「営業とマーケティングが問い合わせの記録を見られないこと」だけです。その場合は、ヘルプデスクごと乗り換えるより、会社ごとの未解決件数や直近の問い合わせ日など、営業が見たい項目だけをHubSpotの会社レコードに同期するほうが、サポートの運用を止めずに済みます。同期の向きとどちらを正のデータにするかは連携方法の選び方と、同期の向き・正のデータの決め方に沿って決めます。

問い合わせが月に数件で、受けるのが社長か担当者1人という会社では、チケットのパイプラインを作っても、ステータスを更新する手間のほうが大きくなります。会社レコードにメモを残し、返信が必要なものだけタスクにする運用で足ります。件数が増えて、2人以上で分担し始めた時点がチケットに移る目安です。

不具合の修正を開発チームが課題管理ツールで管理している場合、チケットの中で修正の進み具合まで追おうとすると、同じ情報を2か所で更新することになります。チケットは「顧客への連絡」を追い、修正の進み具合は開発側のツールの課題番号をチケットのプロパティに残して参照する、と役割を分けます。

まとめ

HubSpotのチケットは、ステータスを「誰の番か」で区切り、会社に関連付け、その記録を営業とマーケティングが月に一度読むところまで決めて初めて、問い合わせの漏れと解約の兆候を拾える記録になります。

• チケットは顧客の用件が片付くまでを追うレコード。金額が動く段階になったら取引を作って関連付ける
• チケットの作成は無料ツールでもできる。チャネルからの自動作成、自動の振り分け、SLAはService Hub Professional以上
• 2024年4月1日以降に作成したアカウントは、受信トレイのチャネルからチケットを作れない。自動作成にはヘルプデスクを使う
• ステータスは自社の番と顧客の番で区切り、問い合わせの種類はカテゴリーのプロパティで分ける
• SLAは契約で約束している時間を上限にし、実績を測ってから置く
• 別のヘルプデスクで運用が安定しているなら、移さずに件数だけを連携する選択肢がある

最初にやることは、いま問い合わせがどの窓口に何件届いているかを、営業の個人メールも含めて書き出すことです。窓口の数と件数が分かれば、手動で作るか、Professionalのヘルプデスクで自動化するか、HubSpotに持たないかを決められます。既存顧客の記録をどこに置き、誰がどう読むかまで含めて整理したい場合は、既存顧客の問い合わせ管理の設計を相談するフォームからご連絡ください。

よくある質問

HubSpotのチケットは無料で使えますか？

チケットの作成と、既定のパイプライン1本での管理は無料ツールでも使えます。メールやフォームなどのチャネルからチケットを自動で作るヘルプデスク、自動の振り分け、SLAはService Hub Professional以上の機能です。

HubSpotのチケットと取引は何が違いますか？

取引は受注に向けた商談を追い、受注か失注で終わります。チケットは顧客の問い合わせや依頼を追い、用件が片付いたらクローズします。既存顧客からの拡張の相談は、受け付けた段階ではチケット、見積もりを出す段階からは取引で管理し、両者を関連付けます。

問い合わせメールから自動でチケットが作られないのはなぜですか？

2024年4月1日以降に作成したアカウントでは、受信トレイに接続したチャネルからチケットを作成できない仕様になっているためです。公式ナレッジベースでは、チケットの管理にヘルプデスク（Service Hub Professional以上）を使うよう案内されています。無料ツールやStarterでは、担当者がレコードから手動でチケットを作る運用になります。

SLAはどのプランで設定できますか？

ヘルプデスクのSLAはService Hub Professional以上で設定でき、初回返信までの時間、次の返信までの時間、クローズまでの時間の3種類を置けます。優先度などチケットのプロパティの組み合わせごとに別のSLAを置くにはEnterpriseが必要です。

チケットのパイプラインは問い合わせの種類ごとに分けるべきですか？

種類ごとには分けず、カテゴリーのプロパティで分けます。パイプラインを分けるのは、導入支援と通常サポートのように、対応するチームや手順が違う場合だけにします。種類ごとに分けると、パイプラインをまたいだ件数の集計に手間がかかります。