%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
SLA設定は期限の数字を入れる作業ではなく、何を起点に何を止めるかの設計です。目標の分け方・一時停止条件・超過検知の流れと設定画面の場所を整理します。
HubSpotのチケットSLAは、ヘルプデスクの「SLA」画面で、初回返信までの時間・次の返信までの時間・クローズまでの時間という3つの目標を、チケットの条件ごとに設定する機能です。 期限の数字を入れるだけでは運用に乗りません。どのチケットに、どの時計を、いつ止めて動かすかを先に決めておくことで、期限間近と期限超過を早く見つけられるようになります。
問い合わせ対応の期限は、担当者の感覚や口頭の約束で運用されがちです。「できるだけ早く返す」という基準では、遅れたチケットが誰にも見えないまま顧客の不満につながります——SLAを設定すると決めても、優先度ごとの数字や、返信待ちの間の扱いで手が止まる場面も少なくありません。
この記事では、設定画面の操作そのものより、設定の前に決める設計の判断と、超過を検知して動くところまでの流れを整理します。
- 設定の場所と対象プラン：ヘルプデスクの設定に入る道筋と、プランによって変わる範囲
- 3つの目標の使い分け：初回返信・次の返信・クローズまでの時間を、何のために分けるか
- ルールの切り方：すべてのチケット共通にするか、優先度や条件の組み合わせで分けるかの判断表
- 時計を止める条件：顧客の返信待ちなどで、期限の数え方がどう変わるか
- 超過の検知：SLAステータスをワークフローのトリガーにして、通知と一覧で見つける方法
SLA設定に入る前に確認する場所と対象プラン
SLAの設定は、ヘルプデスクの設定の中にあります。設定を始める前に、画面の場所と、自社のプランで使える範囲を確認します。ここを取り違えると、設計した内容が画面に入らないという手戻りが起きます。
公式ナレッジ（ヘルプデスクでSLA目標を設定する（HubSpotナレッジベース））では、次の道筋が示されています。
- 上部ナビゲーションバーの設定アイコンをクリックします
- 「ヘルプデスク受信トレイ」から「ヘルプデスク」を選びます
- 「ヘルプデスクの自動化」セクションの「SLA」をクリックします
- 目標を設定し、保存します。有効にするには「SLA」スイッチをオンにします
| 項目 | 公式ナレッジで確認できる内容 | 設計への影響 |
|---|---|---|
| 対象プラン | Service HubのProfessionalとEnterprise | StarterではSLA画面が使えない前提で計画する |
| 必要な権限 | ヘルプデスクのチケットにSLAを設定するにはスーパー管理者権限 | 設定担当者と承認者を先に決めておく |
| 条件の組み合わせ | チケットプロパティーの組み合わせによる設定はEnterprise | 複数条件の細かい出し分けはEnterpriseが前提になる |
| 警告ラベルの表示 | 返信エディターの期限ラベルはServiceシートを持つユーザーにのみ表示される | ラベルを見せたい担当者にはシートの割り当てが要る |
なお、受信トレイ側のSLA設定は別の記事（受信トレイのSLA設定（HubSpotナレッジベース））にあり、設定の入口が異なります。公式ナレッジでは、2024年4月1日以降に作成されたアカウントではコミュニケーションの受信トレイでSLAを設定できず、チケット管理とSLA目標にはヘルプデスクの利用が推奨されています。新しく運用を設計する場合は、ヘルプデスク側から考えるのが基本です。
チケットやそのプロパティー（優先度など）を後から変更しても、SLAルールは再評価されません。 優先度などの入力ルールは、SLAを有効にする前に決めておくのが安全です。
3つの目標を何のために分けるか
ヘルプデスクのSLAで設定できる目標は、公式ナレッジ上で「初回返信までの時間」「次の返信までの時間」「クローズまでの時間」の3つです。数字を決める前に、それぞれが測っているものの違いを整理しておきます。
| 目標 | 測っているもの | 向いている管理の観点 |
|---|---|---|
| 初回返信までの時間 | 顧客が問い合わせてから、最初の返信までの待ち時間 | 受付の速さ。顧客の第一印象 |
| 次の返信までの時間 | やり取りの途中での返信の間隔 | 対応の停滞。やり取りが続く案件 |
| クローズまでの時間 | チケットを作ってから閉じるまでの時間 | 解決の速さ。長期化の検知 |
ここで注意したいのは、「解決期限」という言葉の扱いです。公式ナレッジに「解決時間」という項目名はなく、対応するのは「クローズまでの時間」です。社内で「解決」と「クローズ」の意味を揃えておかないと、返信は済んだが閉じていないチケットが期限超過として見えてしまいます。
初回返信の目標は、受付の約束として決める
初回返信の目標は、顧客への最初の約束として扱いやすい項目です。問い合わせフォーム、メール、チャットのどこから入ったかで顧客の期待が変わるため、ソース別に目標を分けるかどうかを検討します。まずは全チケット共通で始め、実績を見てから細分化するほうが、運用が崩れにくくなります。
クローズまでの目標は、優先度と組み合わせて決める
クローズまでの時間は、問い合わせの種類によって大きく変わります。操作の質問は即日で閉じられても、不具合の調査は数日かかります。全チケット共通の1つの数字にすると、重い案件は常に期限超過、軽い案件は常に余裕、という状態になり、超過の通知が意味を持たなくなります。優先度などで値を分ける理由はここにあります。
ルールの切り方：共通・1つのプロパティー・組み合わせ
SLA目標をどの単位で適用するかは、公式ナレッジで3つの選択肢が示されています。ルールを増やすほど設定と保守の手間が増えるため、自社の問い合わせの性質に合わせて選びます。
| 適用の方法 | できること | 向いている状況 |
|---|---|---|
| 全てのチケットに適用 | 全チケットに共通のルールを適用する | 問い合わせの種類が少なく、まず運用を始めたい場合 |
| 1つのチケットプロパティーに基づく | 優先度・チーム・ソース・パイプラインなどの値ごとに目標を変える。値ごとに目標を無効にもできる | 優先度や窓口で期限を分けたい場合 |
| プロパティーの組み合わせ（Enterprise） | カスタムプロパティーや、関連付けられた会社のプロパティー（取引総額、ティアなど）を含む複数条件でルールを作る | 顧客の区分によって約束の水準が違う場合 |
組み合わせでルールを作る場合、条件を満たすルールのうちリストの上にあるものが優先され、ドラッグで順序を変えられます。どのルールにも当てはまらないチケットに備えて、予備のSLAルールも設定できます。ルールの順序と予備ルールは、設定後に「想定したチケットが想定したルールに当たっているか」を数件で確かめる価値があります。
優先度を軸にするなら、入力の運用を先に決める
優先度で分ける場合、チケットに優先度の値が入っていなければ、期待したルールが当たりません。HubSpotの既定のチケットプロパティー（HubSpotの既定のチケットプロパティー（HubSpotナレッジベース））には「優先度」があり、定義は「当該チケットに対して必要な注目度」です。誰が、どの時点で、どの基準で優先度を入れるのかを、SLAを有効にする前に決めておきます。
優先度の基準が曖昧なまま数字だけを決めると、担当者ごとに優先度の付け方がぶれ、SLAの集計が実態を表さなくなります。次のような判断表を、運用の取り決めとして先に作っておくと安定します。
| 優先度の考え方 | 判断の例 | 入力する人 |
|---|---|---|
| 高 | 顧客の業務が止まっている | 受付担当が一次判断 |
| 中 | 業務は続けられるが回避策が必要 | 受付担当 |
| 低 | 使い方の質問・要望 | 受付担当 |
ここでの区分と判断例は設計の一例です。企業様（チーム）によって最適な形は異なりますので、自社の問い合わせの実態に合わせて定義してください。
時計を止める条件と、営業時間の考え方
SLAの数字と同じくらい運用に効くのが、「いつ数えるか」と「いつ止めるか」の設計です。顧客の返信を待っている間にも時計が進むと、担当者の責任ではない超過が積み上がります。
スケジュール：常時か、特定の時間帯か
公式ナレッジでは、SLAを適用するスケジュールとして「常時」か「特定の時間帯」を選べます。特定の時間帯を選ぶ場合は、タイムゾーンと時間を指定します。対応窓口が平日の日中だけなら、時間帯を指定したほうが実態に合います。
一方、受信トレイ側の説明（受信トレイのSLA設定（HubSpotナレッジベース））では、業務時間を選ぶ場合に休日は考慮されないと記載されています。ヘルプデスクの「特定の時間帯」で休日がどう扱われるかは、公式ナレッジに記載がありません。運用の開始前に、祝日を含む期間のSLAの動きをテストチケットで確認してください。
一時停止条件：顧客の返信待ちをどう扱うか
ヘルプデスクのSLAでは、パイプラインとチケットステータスを条件にして、SLAタイマーを一時停止できます。たとえば「顧客の返信待ち」や「保留中」のステータスのときに止め、条件を満たさなくなると自動で再開されます。
| 状況 | 時計の扱い（設計の例） | 判断の理由 |
|---|---|---|
| 担当者が調査中 | 動かす | 自社の責任範囲だから |
| 顧客に情報提供を依頼し返信待ち | 止める | 待ちの原因が自社にないから |
| 社内の別部署に確認依頼中 | 動かす | 顧客から見れば自社の対応時間だから |
| 保留（顧客都合で後日対応） | 止める | 顧客と合意した待ちだから |
止める条件はステータス名に依存します。そのため、チケットのパイプラインにあるステータスの設計とセットで考えます。既定のサポートパイプラインには「新規」「先方待ち」「要対応」「クローズ」の4つのステータスがあり、ステータスの追加や名称変更も可能です。ステータスの場所は、設定のデータ管理にある「オブジェクト」からチケットを選び、「パイプライン」タブを開きます（パイプラインの設定（HubSpotナレッジベース））。
一時停止条件に使うステータスは、「待ちの原因が顧客側にある」ものだけにします。 社内の確認待ちまで止めてしまうと、期限が実態より緩く見え、超過がほとんど出ない設定になります。
保存時に選ぶ適用範囲
SLAの保存時には、「新規チケットのみに適用」か「新規チケットおよび既存のオープン中のチケットに適用」かを選びます。既存のオープンチケットに遡って適用すると、期限が未到来のものだけ期日が再計算されます。別のルールに再割り当てされることはなく、すでに満たされているSLAも更新されません。
SLAの変更を重ねる運用では、遡及適用の影響を確かめてから選びます。公式ナレッジには、チケットを統合した場合は一次チケットを基準にSLAが決まるという注意もあります。統合の運用がある場合は、統合後のチケットでSLAの表示が意図と違わないかを事前に確認しておきます。
設定して終わりにしない：期限間近と超過の検知
SLAを設定すると、チケットにSLA関連のプロパティーが追加されます。公式ナレッジでは、次の4つが挙げられています。
- クローズまでに要した時間のSLA期日
- クローズまでの時間のSLAチケットステータス
- 初回対応までの時間のSLA期日
- 最初の対応までに要した時間のSLAステータス
SLAステータスのプロパティーは、期限に対する各チケットの状態を示します。「期限間近としてマーク」の設定で、期限のどのくらい前に「期限間近」へ変わるかを決められます。この値が、検知の早さを決めます。
ワークフローで通知する
公式ナレッジでは、SLAステータスのプロパティーをワークフローの登録トリガーにして、期限間近や期限超過を通知できると説明されています。通知先は、特定のユーザー、チーム、担当者、チャネルで、内部メール、アプリ内通知、Slack通知が使えます。ワークフローはService HubのProfessionalまたはEnterpriseで利用できます（ワークフローを作成する（HubSpotナレッジベース））。
超過検知の通知を設計するときの考え方は、次のとおりです。
- 期限間近になったら、担当者へアプリ内通知を送ります。巻き返しが間に合う段階の合図です
- 期限超過になったら、担当者とチームの責任者へ通知します。誰が見ているかを明確にします
- 超過した原因を記録するプロパティー（例：顧客の返信待ち・調査の長期化・人員不足）を用意し、週次で見直します。プロパティーは設定のデータ管理にある「プロパティー」で、チケットのオブジェクトを選んで作成します
通知を増やしすぎると、通知が日常のノイズになり見られなくなります。最初は「期限超過」だけを通知し、運用が安定してから「期限間近」を足すほうが、定着しやすい進め方です。ワークフローの基本はHubSpotワークフローの設定方法で整理しています。
リストとレポートで傾向を見る
SLAプロパティーを使うと、アクティブリストや静的リストを作れます。超過したチケットの一覧を週次で見れば、個別の遅れではなく構造的な原因に目が向きます。レポートでは、カスタムレポートビルダーでSLA関連プロパティーを使ったレポートを作成でき、レポートライブラリーで「sla」と検索すると既成のSLAレポートも使えます。ヘルプデスクのチケットのデータは、公式ナレッジ上、2025年1月以降が対象です。
レポートの作り方はHubSpotレポート・ダッシュボード完全ガイドで詳しく解説しています。
運用に乗せるための設計手順
SLAの設定は、画面を触る前の設計で成否が決まります。StartLinkでは、HubSpotの支援を「現状の整理・要件定義 → 設計・構築 → データ移行 → テスト・検証 → 定着・運用改善」の工程で進めており、SLAの設計も同じ流れで考えます。
| 工程 | SLAで決めること | 確認の観点 |
|---|---|---|
| 現状の整理・要件定義 | 問い合わせの種類・件数の傾向・現在の返信の実態・顧客との約束の有無 | 約束している内容と実態の差 |
| 設計・構築 | 優先度の定義・目標の分け方・一時停止に使うステータス・通知の宛先 | 設定ごとに「なぜその値か」を説明できるか |
| データ移行 | 既存チケットの優先度・ステータスの揃え方 | 既存オープンチケットへ遡及適用するかどうか |
| テスト・検証 | テスト用チケットで期限間近・超過・一時停止が想定どおりに動くか | 通知の宛先と内容が正しいか |
| 定着・運用改善 | 超過の内訳を見て、目標値や一時停止条件を調整する | 超過の原因が運用か設計かの切り分け |
スモールスタートで進める場合は、全チケット共通の初回返信の目標と、期限超過の通知だけで始めます。運用しながら、優先度別の目標、一時停止条件、期限間近の通知へと広げていきます。最初から細かい分岐を作ると、設定の意図が共有されず、触れる人がいなくなるためです。
SLAの期限や条件は、問い合わせの内容を読んで判断する部分があります。HubSpotではBreezeアシスタントから「SLAを管理」を使って、SLAの説明や推奨事項を確認できます。StartLinkでは、Breezeなど生成AIで問い合わせの分類や優先度の下書き、たとえば「先方待ち」へ切り替える候補の提示を支援し、最終判断は担当者が行う業務設計も組み合わせています。SLAの設計では、期限間近になったチケットの返信待ち・調査中の別を要約して担当者へ示す下書きや、超過原因の記録プロパティーへの入力候補の提示も、同じ考え方で設計します。
関連する設計は、チケット運用全般を扱うHubSpotチケット管理の使い方と設定手順、ヘルプデスクの初期設定を扱うHubSpotヘルプデスク設定ガイド、プロパティーの命名や型の選び方を扱うHubSpotプロパティ設計と命名規則も参照してください。
SLAが適用されないケースと、よくある設計の失敗
SLA設定でつまずく原因の多くは、仕様の前提を知らないことと、運用ルールが決まっていないことのどちらかです。公式ナレッジで確認できる制約と、設計上の失敗を整理します。
次の表のうち、1行目は受信トレイ側のSLAに関する記載です。受信トレイ側の記載が、ヘルプデスクのチケットへそのまま当てはまるかは公式ナレッジで確認できていないため、運用前にテストチケットで確かめてください。
| 場面 | 起きること | 回避の考え方 |
|---|---|---|
| ワークフローで作成したチケット・チケット一覧から手動で作成したチケット | 受信トレイ側のSLAは適用されない（受信トレイのSLA設定の記載） | 顧客対応のチケットは、問い合わせの受け口から作る運用にそろえる |
| 個人の業務メールアドレスやHubSpot外からの返信 | SLAに影響しない | 返信は接続したチームの受信トレイから送るルールにする |
| チケット・関連プロパティーを後から変更 | SLAルールは再評価されない（遡及適用でも別ルールへは再割り当てされない） | 優先度は受付時に入れる運用にする。ルール変更の反映は保存時の遡及適用の選択で決める |
| 目標が全チケット共通の1つだけ | 重い案件が常に超過し、通知が無視される | 優先度などで目標を分ける |
| 一時停止の条件が広すぎる | 超過がほとんど出ず、遅れが見えない | 顧客側の待ちのステータスだけに限定する |
最初の1か月は、「SLAの達成率」より「超過の原因の内訳」を見ることを勧めます。達成率だけを追うと、数字を満たすために期限を緩める方向に設計が動きやすくなります。
よくある質問
Q1. SLAはどのHubSpotのプランで使えますか
公式ナレッジでは、ヘルプデスクのSLA目標の設定はService HubのProfessionalとEnterpriseが対象です。チケットプロパティーの組み合わせによる設定はEnterpriseが必要です。設定にはスーパー管理者権限が求められます。最新の対象プランは公式ナレッジで確認してください。
Q2. 初回返信と解決の期限は、どの数字から決めればよいですか
数字そのものより先に、問い合わせの種類と顧客との約束を整理します。初回返信は全チケット共通で始め、クローズまでの時間は優先度などで分けると運用しやすくなります。企業様（チーム）によって最適な形は異なりますので、実績の件数を見てから調整します。
Q3. 顧客の返信待ちの間は、期限の計測を止められますか
止められます。ヘルプデスクのSLAでは、パイプラインとチケットステータスを条件に、SLAタイマーを一時停止できます。条件を満たさなくなると自動で再開されます。止める対象は、待ちの原因が顧客側にあるステータスに限定するのが基本です。
Q4. 期限超過をSlackで知らせることはできますか
公式ナレッジでは、SLAステータスをワークフローの登録トリガーにして、期限間近や期限超過を通知できると説明されています。通知先には、内部メール、アプリ内通知、Slack通知が挙げられています。
Q5. SLAの設定を変えたら、既存のチケットにも反映されますか
保存時に「新規チケットのみ」か「新規および既存のオープン中のチケット」かを選びます。既存のオープンチケットに適用した場合は、期限が未到来のものだけ期日が再計算されます。すでに満たされたSLAは更新されません。
まとめ：SLAは設計と検知を一組で整える
- 3つの目標を使い分ける。 初回返信は受付の速さ、次の返信はやり取りの停滞、クローズまでの時間は解決の速さを測ります
- ルールは共通から始め、優先度で分ける。 条件の組み合わせはEnterpriseで、必要になってから足します
- 時計を止める条件は、顧客側の待ちだけにする。 社内の確認待ちまで止めると、超過が見えなくなります
- SLAステータスをワークフローのトリガーにする。 通知とリストで、超過を担当者の目に届けます
- 最初は超過の内訳を見る。 達成率だけでなく、原因が運用か設計かを切り分けます
最初の一歩としては、直近のチケットを数十件取り出し、初回返信までにかかった時間と、返信待ちで止まっていた時間を整理することをお勧めします。その実績をもとに目標値を決めれば、現実に合わない数字を入れるリスクが下がります。
自社の状況に当てはめた進め方を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。サービス全体の考え方はHubSpot導入・運用支援のサービスページで紹介しています。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
