SLA（Service Level Agreement）は「顧客との約束」であり、サポートチームのパフォーマンスを測る基準だ。設定が甘すぎると顧客満足が下がり、厳しすぎるとチームが疲弊する。Service Hub の SLA は優先度別・チャネル別・営業時間・タイムゾーン対応が可能で、2025年3月以降はルールごとの稼働時間個別設定が実現した。この章では FRT・TTR・CSAT の3指標の定義・SLA ルール設定・タイムゾーン対応・エスカレーション自動化・達成率レポートを体系的に解説する。
SLA とは「このチケットにはいつまでに応答・解決する」という時間的な約束を定めたルールだ。顧客との契約書に明記される場合もあれば、チームの内部目標として設定される場合もある。HubSpot Service Hub の SLA 機能（Professional 以上）では、チケットの優先度・チャネル・パイプラインに応じた SLA ルールを設定し、期限を自動計算・自動アラートすることができる。
SLA を設計する前に、まず「何を測るか」を明確にしよう。サポートの品質を測る主要指標は3つだ。
土日・祝日・深夜の時間を含めて FRT・TTR を計算すると、営業時間外に届いたチケットが常に「応答が遅い」と評価されてしまう。Service Hub の SLA では「営業時間内のみカウント」する設定が必須だ。例えば金曜18時に届いたチケットへの月曜9時の返信は、カレンダー時間では15時間だが、営業時間ベースでは「即応答」と正確に評価できる。
HubSpot の SLA 設定は「設定 → サービス → SLA」から行う。Professional 以上で利用でき、優先度別・パイプライン別に異なるルールを設定できる。Enterprise では「条件付き SLA」も使え、チケットのプロパティに応じてルールを動的に切り替えることも可能だ。
| 優先度 | FRT 目標（営業時間内） | 解決時間目標（営業時間内） | アラートタイミング |
|---|---|---|---|
| 🔴 Urgent | 30分以内 | 4時間以内 | 期限の15分前 + 超過後に即通知 |
| 🟠 High | 2時間以内 | 8時間以内（営業時間内） | 期限の30分前 + 超過後に通知 |
| 🟡 Medium | 4時間以内 | 24時間以内（営業時間内） | 期限の1時間前 + 超過後に通知 |
| 🟢 Low | 8時間以内 | 72時間以内（営業時間内） | 超過後に通知（1日1回） |
SLA は「営業時間内のみカウント」する設定が重要だ。設定場所：設定 → 一般 → 営業時間。複数の営業時間スケジュールを作成でき（Enterprise）、SLA ルールごとに異なるスケジュールを適用できる（2025年3月以降）。
顧客からの返信を待っている間も SLA のカウントが進み続けると、「エージェントが遅い」と誤って記録されてしまう。設定場所：SLA 設定 → 「特定のステージでタイマーを一時停止する」→ 「顧客回答待ち」ステージを選択。この設定なしで SLA を運用すると、達成率が実態よりも低く見え、エージェントのモチベーション低下につながる。
2025年3月のアップデートで、SLA ルールごとに稼働時間とタイムゾーンを個別に設定できるようになった。それ以前は組織全体で1つの営業時間スケジュールしか適用できなかったが、この変更により日本チームと欧州チームが異なるタイムゾーンで別々に SLA を管理することが現実的になった。
| チームリージョン | 営業時間スケジュール | タイムゾーン | 対象チケット |
|---|---|---|---|
| 日本（APJ） | 月〜金 09:00–18:00 | Asia/Tokyo（UTC+9） | パイプライン = 日本サポート / チーム = Japan |
| 欧州（EMEA） | 月〜金 09:00–17:30 | Europe/London（UTC+0/+1） | パイプライン = EMEA サポート / チーム = EMEA |
| 北米（Americas） | 月〜金 08:00–18:00 | America/New_York（UTC-5/-4） | パイプライン = Americas サポート / チーム = US |
| Urgent（グローバル共通） | 月〜日 24時間 | UTC（協定世界時） | 優先度 = Urgent（全パイプライン共通） |
① 設定 → 一般 → 営業時間 → 「営業時間スケジュールを追加」でリージョンごとのスケジュールを作成する。② 設定 → サービス → SLA → 「SLA ルールを追加」→ 対象のパイプライン・優先度を選択する。③ 「稼働時間」で①で作成したスケジュールを選択し、「タイムゾーン」で該当タイムゾーンを指定する。④ FRT・解決時間の目標値を入力して保存。Enterprise では複数スケジュールの並行運用が可能。Professional では1スケジュールのみ（ただし 2025年3月以降は Pro でも優先度別に個別設定が可能）。
SLA 期限が近づいたとき・超過したときに何も起こらなければ、SLA を設定した意味がない。ワークフローで「SLA 危険 → アラート通知 → 担当者変更 → マネージャー通知」の自動エスカレーションを設計することが必須だ。HubSpot ではチケットベースのワークフローで SLA トリガーを条件として使える。
| ワークフロー名 | トリガー条件 | 主なアクション |
|---|---|---|
| Urgent FRT 15分前アラート | 優先度 = Urgent / SLA FRT 残15分 | エージェントへ Slack 通知 |
| High FRT 30分前アラート | 優先度 = High / SLA FRT 残30分 | エージェントへメール通知 |
| SLA FRT 超過通知 | SLA FRT ステータス = 超過 | マネージャーへ通知 / チケット担当者をマネージャーに変更 |
| 解決 SLA 2時間前アラート | 解決 SLA 残2時間 / ステータス ≠ クローズ | エージェント + チームリードへ通知 / 内部メモに自動記録 |
| 解決 SLA 超過通知 | 解決 SLA ステータス = 超過 | マネージャー + CS ディレクターへ通知 / 週次レポートに記録フラグ |
SLA を設定し・運用するだけでは不十分だ。達成率を定期的に測定・レポートし、改善アクションにつなげる仕組みが必要だ。Service Hub には Help Desk 分析タブ・カスタムレポートビルダーが用意されており、SLA 達成率を多角的に分析できる。
毎日（エージェント）： Workspace の SLA 危険ビューを確認し、期限切れゼロを目標に対応する。毎週（マネージャー）： 週次サマリーダッシュボードで優先度別 FRT 達成率・SLA 超過件数を確認し、超過が多かったカテゴリ・担当者を特定してサポートを入れる。毎月（CS リーダー）： 月次トレンドで施策効果を評価し、翌月の改善テーマを設定する。
FRT は「担当者が受け付けたか」の確認、TTR は「解決の速さ」、CSAT は「対応の質」を測る。3つをセットで設計・追跡することで、速さと質のバランスが取れた SLA 運用になる。
この設定がないと顧客側の遅延がエージェントの SLA 違反として記録される。設定場所：SLA 設定 → 特定ステージでタイマーを一時停止 → 顧客回答待ちを選択。
日本・欧州・米国チームが同一 HubSpot を使っていても、それぞれのリージョンの営業時間・タイムゾーンを SLA ルールに個別設定できる。グローバルチームは必ず設定する。
Urgent の SLA 期限15分前にエージェントへ Slack 通知 → 未対応なら超過後にマネージャーに担当変更——この2段階のエスカレーションが SLA 超過率を大幅に下げる。
解決時間が最も長いカテゴリ = ナレッジベースが最も不足している領域だ。TTR 分析の結果をそのまま「KB 記事を最初に書くべきトピック」として活用する。
FRT・TTR 達成率・CSAT・SLA 超過件数を1画面に集めたダッシュボードを毎週月曜に自動メール配信することで、チームの状況共有コストがゼロになる。