Service Hub のすべての機能はチケットオブジェクトを中心に動く。SLA もヘルススコアも AI も、最終的には「チケットが正しく設計されているか」に依存する。チケットの構造を正しく設計しないまま運用を始めると、後から修正するコストが雪だるま式に増える。プロパティの設計・パイプラインのステージ定義・チャネル統合・優先度と カテゴリの設定・CRM との関連付け——これら5つの基礎を丁寧に積み上げることが、スケーラブルなサポート組織の出発点だ。
HubSpot のチケットオブジェクトは、顧客からの1件の問い合わせ・サポートリクエストを表す記録の単位だ。コンタクト・会社・商談と同じ CRM の第一級オブジェクトとして扱われるため、レポート・ワークフロー・AI 分析のすべてでチケットデータが活用できる。まずチケットレコードが持つ構造を理解し、その上でプロパティを設計することが重要だ。
最初から多くのカスタムプロパティを作ると、エージェントの入力負荷が増え、データ品質が下がる。「このデータを使って何を判断するか」が答えられないプロパティは作らない。まず「チケットカテゴリ・影響範囲・クローズ理由」の3つのカスタムプロパティから始め、運用の中で必要なものを追加していくアプローチを推奨する。
チケットパイプラインは「チケットが解決されるまでの工程を可視化する仕組み」だ。Sales Hub の商談パイプラインと同じ構造を持つが、設計の視点はまったく逆——商談は「営業担当者の行動」を基準にするが、チケットパイプラインは「解決プロセスの状態」を基準に設計する。ステージは「担当者が何をすべきか」ではなく「チケットが今どの状態にあるか」を表す名前にすることが重要だ。
| パイプライン名 | 用途 | ステージ構成の特徴 | 推奨する組織 |
|---|---|---|---|
| 一般サポート | メール・チャットからの一般問い合わせ | 新着→担当中→顧客待ち→解決→クローズ | すべての組織に推奨（デフォルト） |
| 技術サポート / バグ | 開発チームが関与する技術不具合・バグ対応 | 受付→調査→開発確認中→修正待ち→テスト→解決 | SaaS・テック系プロダクト企業 |
| オンボーディング | 新規顧客の初期設定・導入支援のプロセス管理 | キックオフ→設定支援→トレーニング→検収→完了 | CS チームがオンボーディングを担う組織 |
| 返品・返金処理 | EC・SaaS の返品・返金・解約申請の処理 | 申請受付→確認中→承認→処理完了 | EC・サブスクリプションビジネス |
「顧客回答待ち」ステージがないと、返信を待っている間も SLA のカウントが進み続け、SLA 違反が続出する。このステージに移動した時点で SLA を一時停止する設定（Professional 以上で可能）と組み合わせることで、エージェントの対応速度を正確に測定できる。「顧客が遅い」のか「エージェントが遅い」のかを区別するためにも、このステージの設置は必須だ。
顧客がサポートに連絡する手段は1つではない。メール・ライブチャット・電話・フォーム・SNS——すべてのチャネルからの問い合わせを HubSpot の受信トレイに集約し、自動でチケットを生成することが「取りこぼし防止」と「データの一元管理」の出発点だ。
受信トレイに接続したチャネルで「自動的にチケットを作成する」設定が OFF になっていると、エージェントが手動でチケットを作成するまで追跡ができない。設定場所：サービス → 受信トレイ → チャネルを選択 → チケット作成 → 「常にチケットを作成する」を ON。これはすべてのチャネルで確認すべき最初の設定だ。
チケットが届いてから「誰が・どの順番で・どう対応するか」を決める仕組みが優先度・カテゴリ・タグだ。これらが曖昧だとルーティングが機能せず、SLA 管理もレポートも精度が落ちる。設計は「入力するエージェントが迷わない」ことを最優先に、選択肢を絞り込むことが重要だ。
| 優先度 | 定義・適用条件 | SLA 目安（初回応答） | SLA 目安（解決） |
|---|---|---|---|
| Urgent | 本番環境の障害・売上損失・セキュリティインシデント・全顧客影響。経営陣・CS マネージャーへ即時エスカレーション必須 | 30分以内 | 4時間以内 |
| High | 主要機能の不具合・一部顧客への影響・期日のある業務処理ができない状態 | 2時間以内 | 8時間（営業時間内） |
| Medium | 機能の一部が使えない・手動での回避策がある状態・非重要機能の不具合 | 4時間以内 | 24時間（営業時間内） |
| Low | 使い方の質問・機能要望・ドキュメントの誤り・業務に支障のない改善提案 | 8時間以内 | 72時間（営業時間内） |
カテゴリは「問い合わせの種類を分類する」ための軸だ。レポートで「どのカテゴリが最も多いか」「どのカテゴリが解決に時間がかかるか」を分析するために使う。カテゴリは多すぎると入力が曖昧になるため、最初は7〜10項目以内に収めることを推奨する。
| カテゴリ名 | 対象となる問い合わせ例 | 主な担当チーム |
|---|---|---|
| 技術不具合 | エラー・バグ・API 不具合・動作異常 | 技術サポートチーム |
| 使い方・How-to | 機能の使い方・設定方法・操作手順の質問 | 一般サポートチーム |
| 請求・契約 | 請求書の確認・契約変更・プランのアップグレード | アカウント担当・CS |
| オンボーディング | 導入初期の設定支援・初回トレーニング依頼 | CS チーム |
| データ・連携 | データエクスポート・インポート・外部ツール連携 | 技術サポートチーム |
| 機能要望 | 新機能の要望・改善提案（Product へフィードバック） | CS / Product チーム |
| セキュリティ・権限 | アクセス権限・セキュリティインシデント・ログイン問題 | 技術サポート（即時エスカレーション） |
チケットを CRM の他オブジェクトと関連付けることで、Service Hub は「チケット管理ツール」から「顧客理解のプラットフォーム」に変わる。エージェントがチケット画面を開いた時、その顧客の全体像——商談・過去のチケット・ヘルススコア・NPS——が同一画面で参照できる状態が理想だ。
| 自動関連付けの方法 | 動作の仕組み | 設定場所 |
|---|---|---|
| メールアドレスによる自動マッチング | メールから作成されたチケットは、差出人のメールアドレスで既存のコンタクト・会社を自動検索して関連付ける | 自動（設定不要） |
| フォームのフィールドマッピング | サポートフォームの「会社名」「メール」フィールドをコンタクト・会社プロパティにマッピングすることで、作成時に自動で関連付ける | フォーム設定 → フィールドのマッピング |
| ワークフローによる関連付け | 「チケット作成時 → コンタクトの会社を取得 → チケットに関連付ける」ワークフローで、コンタクトの会社を自動でチケットに紐づける | ワークフロー → チケットベース → 関連付けアクション |
| 更新商談との手動関連付け | CS が更新商談の担当者の場合、チケットレコードの「関連付けを追加」から更新商談を選択して紐づける。一覧ビューから一括操作も可能 | チケットレコード → 右パネル → 関連付けを追加 |
HubSpot のデフォルト動作では、メールから作成されたチケットはコンタクトに関連付けられるが、会社への関連付けは自動では行われない。会社単位のチケット集計・ヘルススコアの精度を保つために、「チケット作成時にコンタクトの会社を取得してチケットに関連付けるワークフロー」を必ず設定しよう。これを怠ると、後から会社ビューでチケット履歴が見えない問題が発生する。
最初から多くのカスタムプロパティを作ると入力負荷が増えデータ品質が下がる。チケットカテゴリ・影響範囲・クローズ理由の3つから始め、「使って判断するデータ」だけを追加する原則を守る。
「担当者が何をすべきか」ではなく「チケットが今どの状態か」を表すステージ名にする。「顧客回答待ち」ステージは必ず設け、SLA を一時停止する設定と組み合わせる。
メール・チャット・フォーム・WhatsApp のすべてで受信トレイに接続し、自動チケット生成を有効化することが取りこぼし防止の第一歩。2025年3月以降 Urgent 優先度が追加されたため優先度定義も4段階で整備する。
Urgent（本番障害・即時エスカレーション）・High（主要機能不具合）・Medium（回避策あり）・Low（質問・要望）の定義を全員が共有することで、SLA 管理とルーティングの精度が上がる。
デフォルトではコンタクトには関連付けられるが会社には自動で関連付けられない。「チケット作成 → コンタクトの会社を取得 → チケットに関連付け」ワークフローを設定しないと、会社単位のヘルススコア・レポートが不正確になる。
更新商談とチケットを紐づけることで、「この顧客の更新前に何件のサポートコストが発生しているか」が見える。CS がサポートコストを根拠に更新交渉や料金改定の判断材料にできる。