「測定できないものは改善できない」——サポートチームが感覚ではなくデータで動くようになると、改善サイクルのスピードが劇的に上がる。どの KPI を追跡し・どのダッシュボードを誰のために作り・どのレポートを定例会議に持ち込むか——この設計を正しく行うことで、サポートの ROI を経営層に示し、チームの優先順位を数値で決め、問題を発生前に検知できるようになる。この章では KPI の階層設計・ダッシュボードモックアップ・標準レポートカタログ・分析ケイデンスを体系的に解説する。
すべての KPI を全員が見る必要はない。経営層が毎日チケット件数を確認する必要はなく、エージェントが NRR（純収益維持率）を追う必要もない。「誰が・何のために・どの指標を見るか」を3層に分けて設計することで、各役割が意思決定に必要なデータだけに集中できる。KPI の洪水は「何も見ない状態」と同じだ。
KPI を詰め込んだダッシュボードは誰も使わなくなる。経営層は「サポートが会社の収益にどう貢献しているか」を知りたいのであり、チケットの平均返信時間には興味がない。各ダッシュボードを設計するとき、最初に「このダッシュボードを見て何を決断するか」を1文で書くことで、不要な指標を自然に除外できる。
KPI を正確に定義しないと、チームによって「解決時間」の意味が違ったり、計測の起点がずれてデータが比較できなくなる。以下に Service Hub で追跡すべきコア KPI の定義・計算式・業界ベンチマークを整理した。
HubSpot のダッシュボードは「レポートを並べるキャンバス」だ。設定場所は レポート → ダッシュボード → 新規作成。各レポートをウィジェットとして追加し、自動更新・定期メール送付が設定できる。マネージャー向けダッシュボードの完成形モックアップを以下に示す。
| 担当者 | 担当件数 | CSAT | FRT 平均 | TTR 平均 | SLA |
|---|---|---|---|---|---|
| 田中 恵子 | 87 | 94% | 1.8h | 14.2h | 達成 |
| 山田 太郎 | 92 | 89% | 2.6h | 19.8h | 達成 |
| 鈴木 さくら | 74 | 76% | 3.9h | 28.4h | 未達 |
| 佐藤 健 | 68 | 91% | 2.1h | 16.7h | 一部未達 |
担当者別の CSAT スコアを公開するときは、「ランキングで競わせるため」ではなく「サポートが必要なメンバーを早期に特定してコーチングするため」という目的を明示する。CSAT が低いエージェントには「Copilot の返信提案を活用しているか」「KB 参照の習慣があるか」を確認し、スキル習得の機会を提供するアプローチが生産的だ。
HubSpot Service Hub には標準レポートが多数用意されているが、どれを使えばいいかわからないという声が多い。以下に「すぐに使える標準8レポート」と、それぞれが答える問いをまとめた。設定場所はすべて レポート → レポート → サービス カテゴリから選択できる。
データを見るだけでは何も変わらない。「誰が・いつ・どのレポートを見て・何を決めるか」のサイクル（ケイデンス）を組織のカレンダーに組み込むことが、分析を改善アクションに変換する唯一の方法だ。
週次レビューで「SLA が91%でした、先週より下がりました」と報告して終わるのではなく、「SLA が低下した原因は何か」→「来週中に何を変えるか」→「誰がオーナーか」まで会議内で決めるアジェンダ構成にする。データの確認と改善アクションの設定を同じ会議で行うことで、分析が「報告」ではなく「意思決定」の道具になる。
経営層は NPS・更新率・NRR、マネージャーは FRT・TTR・SLA・CSAT、エージェントは自分の担当チケットと SLA 残時間だけを追う。「全員に全指標」は誰も使わないダッシュボードを生む。
FRT・TTR・SLA・CSAT・AI 解決率——これら5つの定義と計算式をチーム全員が同じ理解で共有することが分析精度の前提。「解決時間」の意味がメンバーによって違うと比較できないデータが積み上がる。
KPI を詰め込んだダッシュボードは誰も使わない。各ダッシュボードの設計前に「このダッシュボードを見て何を決断するか」を明文化することで、不要な指標が自然に除外できる。
チケット量・FRT/TTR・SLA・CSAT・AI解決率・KB パフォーマンス・担当者別・ヘルス分布——各レポートが答える「問い」を把握することで、会議に持ち込むべきレポートを迷わず選べるようになる。
日次5分・週次30分・月次2時間・四半期エグゼクティブレポートのサイクルを組織のカレンダーに組み込む。「データを見た」で終わらず「誰が・何を・いつまでに変えるか」まで同じ会議で決める。
CSAT が低いエージェントを責めるのではなく、Copilot 活用状況・KB 参照の習慣・スキルギャップを確認してサポートを提供する。データが「恐怖」ではなく「成長の道具」として機能する文化を作ることが長期的なチームの底上げにつながる。