Salesforceのentitlementsは誰がサポートを受けられるかを示し、entitlement processesはそれをクロックに変える。First ResponseやResolution Timeのようなmilestonesがあり、それぞれに成功・警告・違反アクションが付く。これを動かすにはEntitlement Managementを有効にし、milestonesを作り、プロセスを作成して適用し、すべてのケースにentitlementが付いていることを確認する必要がある。entitlementなしでは何も始まらないからだ。milestonesは自動では完了しないので、トリガーを用意するかMark Completedをクリックする習慣をつけておく。このクロックは、初回返信を下書きしてくれるeeselのようなチームメイトと組み合わせたい。
私はeeselでエージェント機能を作っていて、Salesforceについてよく聞かれる質問はAIではなくタイマーについてのものだ。2026年初頭のあるデモレビューで、月間およそ900件のチケットを扱うミッドマーケットのサポートチームが、Salesforceのネイティブ連携がないことをdealbreakerだと言ったため、私はSalesforceのentitlementドキュメントを最初から最後まで読んだ。Service Cloudのキューを処理するAIエージェントは、管理者がすでに構築したSLAクロックの内側で動かなければならない。eesel CLIを使えば、コーディングエージェントが承認済みのFirst Responseポリシーをナレッジとしてアップロードし、本番公開前にテストの質問を投げることができる。ただし、接続の承認は依然としてSalesforce管理者が行う必要がある。
Salesforceのentitlementsとmilestonesとは何か?
entitlementはサポートの単位であり、milestoneはケース上の期限付きステップだ。Salesforceのentitlements overviewでは、entitlementsは「電話サポート」や「Webサポート」のような単位として説明されており、通常はサービス契約の条件をモデル化している。アカウント、アセット、コンタクト、サービス契約に紐づけることで、担当者はケースを開く前に発信者がカバーされているかを確認できる。
entitlementsだけでは単なる是非の判定にすぎない。クロックはentitlement processとともに現れる。Salesforceのterms pageはこれを、First ResponseやResolution Timeのような必須ステップであるmilestonesのタイムラインと定義している。milestoneアクションは各ステップ上の時間依存の自動化だ。Salesforceのヘルプはいまも製品をService Cloudと呼んでいるが、より新しいブランディングではAgentforce Serviceという名前が登場するので、両方で検索するとよい。
4つのオブジェクトが一方向に流れる。entitlementはケース上にあり、プロセスを指し、プロセスは条件に応じてmilestonesを割り当て、各milestoneがアクションを発火させる。ケースにentitlementがなければ、この連鎖は決して始まらない。この一点が「SLAが機能していない」という苦情の大半を説明している。
Entitlement Managementを含むSalesforceのエディションはどれか?
Service Cloudを使うProfessional、Enterprise、Performance、Unlimited、Developerの各エディションだ。これはSalesforceのサポートエディション一覧に書かれており、Service-Level Agreements(Entitlement Management)が挙げられ、entitlement processの監視はProfessionalでは利用できないと付け加えられている。
Salesforceのサービス料金ページには比較表に「Service Contracts and Entitlements」という行があるが、スクレイピングしたときにチェックマークが取得できなかったため、現行プランのどれがこの機能を含むかは断言できない。料金ページはエディションページよりも新しい名前を使っている点も注意だ。プランは書面でアカウントエグゼクティブに確認してもらうとよい。座席単価はSalesforce Service Cloudの料金の記事で追っている。
Entitlement Managementを有効にするにはどうするか?
Setupで有効にしたうえで、決まった順序でパーツを組み立てる。Salesforceの有効化に関する記事は手順を示している。Entitlement Settingsを開き、Entitlement Managementを選択し、保存する。標準のSystem Administratorプロファイルを持つユーザーのみが有効化できるとも付け加えられており、カスタムの管理者プロファイルでは不十分だ。
設定チェックリストでは続けて、フィールドとページレイアウトのカスタマイズ、ケース上のlookupフィルタ、ユーザーアクセス、entitlementテンプレート、entitlementsの自動追加、レポートが挙げられている。私の順序はこうだ。
- entitlementsを有効にし、将来本番運用中のプロセスを変更する可能性があるなら、今のうちにEnable Entitlement Versioningにチェックを入れる。Salesforceによれば、バージョニングは後から無効化できない。
- ユーザーにアクセス権を与え、ケースのページレイアウトにentitlementフィールドを追加する。
- Setup内のEntitlement Managementでmilestonesを作成する。
- entitlement processを作成し、milestonesを追加し、アクションを追加してから有効化する。
- プロセスをentitlementsに適用するか、entitlementテンプレートに適用して新しいentitlementsに継承させる。
他のツールと比較すると、FreshdeskやZendeskのSLAはチケットごとのポリシーだ。Salesforceは複数の連結したオブジェクトからクロックを組み立てており、より多くの制御と、より多くの間違えやすいポイントの両方をもたらしている。
entitlement processとそのmilestonesはどう作るか?
先にmilestonesを作っておく。Salesforceのプロセスに関する記事は、プロセスを作る前にmilestonesを用意しておく必要があると述べている。そのページの手順は次のとおりだ。
- Setup、Entitlement Processes、New Entitlement Process。
- タイプを選ぶ。CaseかWork Orderのどちらかで、プロセスはそのタイプのレコードにしか動作せず、後から変更できない。
- 名前を付け、milestoneアクションが揃うまでActiveをオフにしておく。Salesforceは、有効化してレコードで使用した後はmilestoneアクションを更新も削除もできないと警告している。
- レコードがいつ入り(作成日、またはカスタムの日付/時刻フィールド)、いつ出るか(クローズ、またはカスタム条件)を選ぶ。
- 任意で、各milestoneのTarget Dateに営業時間を設定する。
次に、milestoneの追加に関する記事がmilestoneのフィールドを扱っている。重要なものは次のとおりだ。
- Time Trigger (Minutes): ユーザーがmilestoneを完了させるまでの時間。代わりに
Support.MilestoneTriggerTimeCalculatorを実装したApexクラスを指定して、ケースごとに計算することもできる。 - Start: Milestone Criteriaは、繰り返しのmilestoneについて、milestoneがレコードに適用された時点でTarget Dateを計算する。Entitlement Processはプロセス開始時点から計算するため、First ResponseやResolution Timeに向いている。
- Order and criteria:
Priority equals Highのようなフィルタや式が、複数一致したときにどのmilestoneを適用するかを決める。
Salesforceはさらに3つのrecurrenceタイプを定義している。No RecurrenceはFirst ResponseやResolution Timeに向いており、Independentは繰り返す可能性のあるエンジニアリングの引き継ぎのようなものに向いており、Sequentialは順番に繰り返す。繰り返しのmilestoneは一度に1つのオカレンスだけがアクティブになる。
成功・警告・違反アクションは何をするか?
これらはmilestoneのタイマー上の自動化であり、SLAが実際に何かをする場所だ。Salesforceのmilestoneアクションの概要は3つのタイプを挙げている。成功アクションはmilestoneが完了したときに発火し、警告アクションは違反に近づいたときに、違反アクションは違反したときに発火する。成功アクションは、遅れて完了したmilestoneでもやはり発火する。
各アクションは次のいずれかになる。
| ワークフローアクション | 内容 | Salesforceの例 |
|---|---|---|
| New Task | タスクを作成する | First Responseが違反したときに顧客に電話する |
| New Email | メールアラートを送る | 違反に近づいたときにケースのownerに通知する |
| New Field Update | フィールドを更新する | 違反に近づいたときにPriorityをHighにする |
| New Flow | autolaunchedなflowを起動する | 違反に近づいたときにSlack通知を送る |
| New Outbound Message | 外部システムにデータを送る | 完了後にパーツデータを送る |
| Select Existing Action | 既存のアクションを再利用する | メールアラートを再利用する |
Flowオプションは Winter '25 で追加された。Salesforceのリリースノートによれば、Service CloudのProfessionalからDeveloperまでのエディションをカバーしている。アクション追加に関する記事からの一つのコツとして、即座に発火させたい違反アクションにはtime triggerを0分に設定する。
何かを約束する前に知っておくべき3つの挙動がある。
- アクションはTarget Dateの数秒前に発火することがある。Salesforceの上限ページによれば、0分の違反アクションはその1分前に実行されることがある。
- フィールド更新の処理には10秒の上限があり、それより長くかかるものはエラーなしで失敗する。
- アクションをケースの作成時や更新時に実行するよう設定してはいけない。Salesforceによれば、これは一貫しない結果につながる可能性がある。
milestoneの営業時間はどう機能するか?
より具体的な時間が優先される。Salesforceの営業時間に関する記事は、milestoneの時間がentitlement processの時間を上書きし、それがさらにケースの時間を上書きすると述べている。
Salesforceの実践的なアドバイスはこうだ。多くのケースが1つのプロセスを共有するときはプロセスに時間を設定し、重大度によってリズムが変わるとき、例えば平日プロセスの中にある24時間365日の「Update Customer」milestoneのような場合はmilestoneに時間を設定する。有効なプロセスの時間を変更するには、新しいバージョンを作成し、そこで時間を編集し、新しい更新ルールで更新を反映させる。
ここではドキュメント自体が矛盾している。アクション追加のページでは、時間トリガーのアクションは組織の営業時間内にしか発生しないとされている。一方でアクションの概要では、警告アクションと違反アクションは営業時間を考慮せず24時間クロックで動くとされている。例として、8時間の営業日に対して「2 Days Before」に設定された警告は2,880分になるため、月曜の午前9時に開かれ木曜が目標のケースでは即座に発火する。どちらの説明に頼るにせよ、実際にテストケースを作ってみることをお勧めする。他のツールがカレンダーをどう扱うかについては、Zendeskの営業時間の記事が有用な比較になる。
担当者はケース上のクロックをどう見るか?
ケースに追加するmilestoneトラッカーを通じてだ。Salesforceのトラッカーに関する記事は、進行中のmilestoneは縮んでいく緑の円として表示され、期限を過ぎると赤に変わると述べている。
Lightningでは、App BuilderでMilestonesコンポーネントを追加する。トラッカーはデフォルトで実時間を表示するが、Entitlement Settingsで営業時間に切り替えられる。レコード全体のmilestoneステータスは次の3つの値のいずれかだ。
| ステータス | 意味 |
|---|---|
| Compliant | 完了している、または違反していない |
| Open Violation | milestoneが違反し、そのステップがまだ未完了 |
| Closed Violation | milestoneが違反したが、そのステップは後で完了した |
レポートについては、Case Milestonesレポートタイプで違反を追跡できる。どの数値をそれと並べるべきかはAIによるカスタマーサービス指標の記事で、同じ作業を別のツールで行う様子はHubSpotのSLA目標のガイドで扱っている。
管理者が計画しておくべき上限と落とし穴は何か?
ケースにはentitlementが必要で、プロセスはレコードと一致する必要があり、誰もmilestonesを代わりに完了してはくれない。Salesforceの上限ページは短く、全文を読む価値がある。数字は次のとおりだ。
- 組織あたり
1,000のentitlement processes、プロセスあたり10のmilestones - milestone上のアクションタイプごとに
10のアクションと10のtime trigger - 1時間あたり
50,000のentitlementキューエントリ
実務で痛手になる落とし穴は次のとおりだ。
- entitlementsはメールやWebのケースには追加されない。 Salesforceの自動追加に関する記事は、Web-to-Case、Email-to-Case、experienceのケースには自動では付かないとし、追加するためのApexのサンプルを示している。コンタクトもアカウントのentitlementsを継承しない。
- milestonesは自動完了しない。 自動完了に関する記事はApexトリガーを示している。ケースがクローズしたときのResolution Time、コンタクトにメールが送られたときのFirst Response、または公開コメントがされたときなどだ。担当者はMark Completedを使える。このドキュメント内にFlowベースのレシピは見つからなかった。
- レコードタイプごとに1つのプロセス。 Case用のプロセスはwork orderでは動作しないので、別々のentitlementsに分けておく。
- 有効化するとアクションが凍結される。 有効化後はmilestonesの削除もアクションの作成もできない。バージョニングを使えば、使用中のバージョンでmilestonesを追加できるが、既存のものは編集できない。
- 精度は分単位。 milestonesは分と秒で計測されるが、開始・終了時刻は分単位でしか正確ではないため、24時間365日の時間帯以外では一部の秒が失われる。
- キューの違反メールはメンバーに届かない。 キューにメールアドレスがある場合、違反はそこに送られ、Salesforceによればキューのメンバーはそれを受け取らない。
- モバイルとLightningのギャップ。 トラッカーはSalesforceのモバイルアプリには表示されず、Case Milestoneには誰が完了させたかを示すフィールドがない。
ZendeskやHelp Scoutを使っている人には、これらはどれも馴染みのないものに見えるだろう。Salesforceのモデルは柔軟だが、その分、管理者が丁寧に配線することを求めてくる。
First Responseのクロックが動いている間、AIはどこに関わるか?
AIチームメイトは初回応答を短縮できるが、プロセスそのものの代わりにはならない。はっきり言っておこう。eeselはentitlement processesの代わりにはならない。entitlements、milestones、アクションはそのまま動き続ける。eeselが変えるのは、返信が準備できるまでに担当者がかける時間だ。
eeselのSalesforce連携はService Cloudにエージェントとして加わり、ケースを読み取って返信を下書きまたは送信し、社内ノートを追加し、フィールドを更新する。これにはコンタクトとアカウントのコンテキストをドキュメントから使う。そのページによれば、既存のentitlementsや自動化と並行して動作するとされている。milestoneオブジェクトの読み取りについてのeeselのドキュメントは見つからなかったので、完了トリガーが返信をどうカウントするかは、頼る前に確認した方がよい。
その確認は重要だ。文書化されたFirst Responseのトリガーは、コンタクトに送られたメールか公開コメントで完了する。社内ノートとして保存された下書きはどちらも満たさないため、下書き設定が役立つのは、誰かがその下書きをすぐに送る場合だけだ。送信設定であれば、トリガーの定義どおりにmilestoneを完了させる。
私の一番近い証拠はSalesforceのものではなく、それは正直に言っておく。SamCartはFreshdeskのチケットに1つのeeselエージェントを、自社サイトのチャットにもう1つのエージェントを動かしており、280件のヘルプセンター記事から回答し、チケット側のエージェントはチームメイトが未アサインの間だけ返信する。これは初回応答目標が求める形だ。smavaはもう一方の極端な例で、月間およそ27,000件のZendeskチケットを処理し、約15,300件の下書き返信を人が承認できるよう準備している。
買い手から一番よく聞くパターンは、まず下書きモードで始め、回答の精度が保てるようになってから自動返信にするというものだ。eeselは本番公開前に過去の自社ケースでシミュレーションを行う。AIによる初回応答とSalesforceのAIエスカレーションの記事ではこうした引き継ぎを扱っている。選択肢については、Service Cloud向けベストAIのまとめ、ChatGPT for Service CloudとClaude for Service Cloudの記事、Salesforce Service Cloud向けAIのガイドを参照してほしい。
自分の組織でこれをどう使うか?
管理者に渡すとしたら、短いバージョンはこうなる。
- まず2つのmilestoneから始める。 First ResponseとResolution Time、No Recurrence、1つのプロセス。データを信頼できるようになってから繰り返し型を追加する。
- 先にentitlementの抜け漏れを直す。 メールとWebのケースが常にentitlementを得られるようApexを追加する。さもないとクロックはキューの一部しかカバーしない。
- 本番公開前に完了トリガーを書いておく。 初回応答としてカウントするのがメールか、公開コメントか、その両方かを決める。
- 早すぎる有効化はしない。 すべての警告・違反アクションを追加してから有効化する。後からはアクションを追加できないからだ。
- バージョニングを今すぐ有効にする。 それなしで本番運用中のプロセスを変更するのは苦痛だ。
- 営業時間の挙動をテストする。 テスト用のケースを作り、ドキュメントの2通りの解釈に対して警告がどう発火するかを観察する。
- 違反についてレポートする。 Case Milestonesレポートを作り、Open Violationsを毎週確認する。
キューこそが本当のボトルネックなら、AIによるチケット優先度付け、チケット分類、チケット要約についての記事が、クロックが動き出す前にAIがどこで時間を節約できるかを示している。エスカレーション管理とSLAのベストプラクティスの記事は目標設定に役立ち、Frontは同じ発想の軽量版を提供している。
Salesforce Service Cloud向けeeselを試す
初回応答の取りこぼしがキューサイズの問題であるなら、Salesforce向けeeselはService Cloudの新しいチームメイトのように動作する。ナレッジ記事や過去のケースから学び、アカウントのコンテキストとともに新しいケースを読み取り、返信を下書きまたは送信するので、担当者は作業が済んだ状態から始められる。entitlementsやmilestonesを変更することはなく、それらの内側で動き続ける。
まず1つのキューで下書きモードを使い、過去の自社ケースと比較し、回答の精度が保てるようになったら自動返信を有効にしよう。AIヘルプデスクエージェントがキューに加わる様子や、エンタープライズ向けAIヘルプデスクの比較を見てから、eeselを試す。