Salesforce Entitlements und Milestones: Einrichtung, Aktionen und Limits

Was sind Salesforce Entitlements und Milestones?

Ein Entitlement ist eine Supporteinheit, und ein Milestone ist ein Schritt auf einem Case mit eigener Frist. Salesforces Entitlements-Übersicht beschreibt Entitlements als Einheiten wie "Telefonsupport" oder "Websupport", die meist Vertragsbedingungen abbilden. Man hängt sie an Accounts, Assets, Contacts und Service Contracts, damit ein Mitarbeiter vor dem Öffnen eines Case prüfen kann, ob ein Anrufer abgedeckt ist.

Allein funktionieren Entitlements nur als Ja oder Nein. Die Uhr kommt mit einem Entitlement-Prozess hinzu, den Salesforces Begriffsseite als Zeitachse aus Milestones definiert, jeweils ein Pflichtschritt wie First Response oder Resolution Time. Milestone-Aktionen sind die zeitabhängigen Automatisierungen auf jedem Schritt. Salesforces Hilfe nennt das Produkt weiterhin Service Cloud, während der Name Agentforce Service im neueren Branding auftaucht, also nach beidem suchen.

Vier Objekte, eine Richtung. Das Entitlement sitzt auf dem Case, verweist auf einen Prozess, der Prozess weist Milestones nach Kriterien zu, und jeder Milestone löst Aktionen aus. Hat ein Case kein Entitlement, startet die Kette nie. Diese eine Tatsache erklärt die meisten Beschwerden der Art „Meine SLA funktioniert nicht“.

Welche Salesforce-Editionen enthalten Entitlement Management?

Professional, Enterprise, Performance, Unlimited und Developer Edition mit Service Cloud. Das steht auf Salesforces Seite zu den unterstützten Editionen, die Service-Level Agreements (Entitlement Management) aufführt und ergänzt, dass die Überwachung von Entitlement-Prozessen in Professional nicht verfügbar ist.

Salesforces Service-Preisseite hat in ihrer Vergleichstabelle eine Zeile „Service Contracts and Entitlements“, aber die Häkchen kamen beim Scrapen nicht durch, also kann ich nicht sagen, welche der aktuellen Plannamen das Feature tragen. Die Preisseite nutzt außerdem neuere Namen als die Editionsseite. Fragt euren Account Executive, der den Plan schriftlich bestätigen soll. Mein Beitrag Salesforce Service Cloud Preise verfolgt die Sitzplatzpreise.

Wie aktiviert man Entitlement Management?

In Setup einschalten, dann die Teile in fester Reihenfolge aufbauen. Salesforces Artikel zur Aktivierung nennt den Weg: Entitlement Settings öffnen, Entitlement Management auswählen und speichern. Er ergänzt, dass nur Nutzer mit einem Standard-System-Administrator-Profil es aktivieren können, ein angepasstes Admin-Profil reicht also nicht.

Die Setup-Checkliste listet dann das Anpassen von Feldern und Seitenlayouts, Lookup-Filter auf Cases, Nutzerzugriff, Entitlement-Vorlagen, das automatische Hinzufügen von Entitlements und Reports. Meine Reihenfolge:

1. Entitlements aktivieren und, falls man je einen laufenden Prozess ändern will, jetzt Enable Entitlement Versioning ankreuzen. Salesforce sagt, Versionierung lässt sich später nicht mehr deaktivieren.
2. Nutzerzugriff vergeben und die Entitlement-Felder zu den Case-Layouts hinzufügen.
3. Milestones unter Entitlement Management in Setup anlegen.
4. Den Entitlement-Prozess erstellen, Milestones hinzufügen, Aktionen hinzufügen, dann aktivieren.
5. Den Prozess auf Entitlements anwenden, oder auf eine Entitlement-Vorlage, damit neue Entitlements ihn erben.

Zum Vergleich: Bei Freshdesk und Zendesk sind SLAs eine Policy pro Ticket. Salesforce baut die Uhr aus mehreren verknüpften Objekten, was mehr Kontrolle gibt, aber auch mehr Stellen, an denen es schiefgehen kann.

Wie erstellt man einen Entitlement-Prozess und seine Milestones?

Zuerst die Milestones anlegen, denn Salesforces Artikel zum Prozess sagt, man muss sie haben, bevor man einen Prozess baut. Dann den Schritten auf dieser Seite folgen:

1. Setup, Entitlement Processes, New Entitlement Process.
2. Den Typ wählen, Case oder Work Order. Ein Prozess läuft nur auf Datensätzen seines Typs, und das lässt sich später nicht mehr ändern.
3. Benennen, und Active ausgeschaltet lassen, bis die Milestone-Aktionen drin sind. Salesforce warnt, dass man Milestone-Aktionen nach Aktivierung und Nutzung auf einem Datensatz nicht mehr aktualisieren oder löschen kann.
4. Festlegen, wann Datensätze eintreten (Erstellungsdatum oder ein eigenes Datum-/Zeitfeld) und austreten (geschlossen oder eigene Kriterien).
5. Optional Geschäftszeiten für jedes Milestone Target Date setzen.

Als Nächstes behandelt der Artikel zum Hinzufügen eines Milestones die Milestone-Felder. Die wichtigen:

• Time Trigger (Minutes): wie lange Nutzer Zeit haben, den Milestone abzuschließen. Man kann stattdessen auf eine Apex-Klasse verweisen, die Support.MilestoneTriggerTimeCalculator implementiert, um es pro Case zu berechnen.
• Start: Milestone Criteria berechnet das Target Date, wenn der Milestone auf den Datensatz zutrifft, für wiederkehrende Milestones. Entitlement Process berechnet es ab Prozessstart, was zu First Response und Resolution Time passt.
• Order and criteria: ein Filter oder eine Formel wie Priority equals High entscheidet, welcher Milestone gilt, wenn mehrere passen.

Salesforce definiert außerdem drei Recurrence-Typen. No Recurrence passt zu First Response und Resolution Time, Independent passt zu etwas wie einer Engineering-Übergabe, die wiederkehren kann, und Sequential wiederholt sich in Reihenfolge. Von einem wiederkehrenden Milestone ist immer nur eine Ausprägung aktiv.

Was machen Erfolgs-, Warn- und Verletzungsaktionen?

Sie sind die Automatisierungen auf dem Timer eines Milestones, und dort passiert bei einer SLA etwas. Salesforces Übersicht zu Milestone-Aktionen listet drei Typen: Erfolgsaktionen lösen aus, wenn ein Milestone abgeschlossen wird, Warnaktionen, wenn er kurz vor der Verletzung steht, und Verletzungsaktionen, wenn er verletzt wurde. Erfolgsaktionen lösen auch bei verspätet abgeschlossenen Milestones noch aus.

Jede Aktion kann eine dieser sein:

Die Flow-Option kam mit Winter '25. Salesforces Release Note sagt, sie deckt Professional bis Developer Edition mit Service Cloud ab. Ein Tipp aus dem Artikel zum Hinzufügen einer Aktion: Für eine Verletzungsaktion, die sofort auslösen soll, den Time Trigger auf 0 Minuten setzen.

Drei Verhaltensweisen, die man kennen sollte, bevor man etwas verspricht:

• Aktionen können ein paar Sekunden vor dem Target Date auslösen. Salesforces Limits-Seite sagt, eine Verletzungsaktion mit 0 Minuten kann in der Minute davor laufen.
• Field Updates haben ein 10-Sekunden-Limit für die Verarbeitung, und längere schlagen ohne Fehlermeldung fehl.
• Aktionen nicht so planen, dass sie bei Case-Erstellung oder -Aktualisierung laufen. Salesforce sagt, das kann zu inkonsistenten Ergebnissen führen.

Wie funktionieren Geschäftszeiten für Milestones?

Die spezifischeren Zeiten gewinnen. Salesforces Artikel zu Geschäftszeiten sagt, Milestone-Zeiten überschreiben die des Entitlement-Prozesses, die wiederum die des Case überschreiben.

Salesforces praktischer Rat: Zeiten auf dem Prozess setzen, wenn viele Cases sich einen Prozess teilen, und auf einem Milestone, wenn der Schweregrad den Rhythmus ändert, etwa ein 24/7-Milestone „Update Customer“ innerhalb eines Wochentagsprozesses. Um Zeiten an einem aktiven Prozess zu ändern: eine neue Version erstellen, dort die Zeiten bearbeiten und das Update mit einer neuen Update-Regel zurückspielen.

Hier widersprechen sich die Docs selbst. Die Seite zum Hinzufügen einer Aktion sagt, zeitgesteuerte Aktionen laufen nur innerhalb der Geschäftszeiten der Org. Die Übersicht zu den Aktionen sagt, Warn- und Verletzungsaktionen beachten keine Geschäftszeiten und laufen auf einer 24-Stunden-Uhr. Ihr Beispiel: Eine Warnung, die auf „2 Days Before“ gesetzt ist, wird bei einem 8-Stunden-Geschäftstag zu 2,880 Minuten, sodass sie bei einem Case, der Montag um 9 Uhr mit einem Ziel am Donnerstag eröffnet wird, sofort auslöst. Ich würde einen Testfall bauen, bevor ich mich auf eine der beiden Lesarten verlasse. Wie andere Tools mit Kalendern umgehen, zeigt mein Beitrag Zendesk Geschäftszeiten als nützlichen Kontrast.

Wie sehen Mitarbeiter die Uhr auf einem Case?

Über den Milestone Tracker, den man dem Case hinzufügt. Salesforces Artikel zum Tracker sagt, ein laufender Milestone zeigt sich als grüner Kreis, der herunterläuft, und wird rot, sobald er überfällig ist.

In Lightning fügt man die Milestones-Komponente im App Builder hinzu. Der Tracker zeigt standardmäßig reale Stunden; man kann in den Entitlement Settings auf Geschäftszeiten umstellen. Der Milestone-Status eines Datensatzes insgesamt ist einer von drei Werten:

Für Reports erlaubt der Case-Milestones-Reporttyp, Verletzungen zu verfolgen. Mein Beitrag KI-Kennzahlen im Kundenservice behandelt, welche Zahlen man daneben stellt, und der Leitfaden HubSpot SLA-Ziele zeigt dieselbe Aufgabe in einem anderen Tool.

Welche Limits und Fallstricke sollten Admins einplanen?

Der Case braucht ein Entitlement, der Prozess muss zum Datensatz passen, und niemand schließt Milestones für einen ab. Salesforces Limits-Seite ist kurz und lohnt sich komplett zu lesen. Die Zahlen:

• 1,000 Entitlement-Prozesse pro Org, und 10 Milestones pro Prozess
• 10 Aktionen und 10 Time Trigger pro Aktionstyp auf einem Milestone
• 50,000 Entitlement-Queue-Einträge pro Stunde

Die Fallstricke, die in der Praxis wehtun:

1. Entitlements werden nicht zu per E-Mail oder Web eingegangenen Cases hinzugefügt. Salesforces Artikel zum automatischen Hinzufügen sagt, Web-to-Case-, Email-to-Case- und Experience-Cases bekommen keins automatisch, und liefert Beispiel-Apex, um es hinzuzufügen. Contacts erben außerdem nicht die Entitlements des Accounts.
2. Milestones werden nicht automatisch abgeschlossen. Der Artikel zum automatischen Abschluss liefert Apex-Trigger: Resolution Time, wenn ein Case geschlossen wird, First Response, wenn eine E-Mail an den Contact geht, oder wenn ein öffentlicher Kommentar erstellt wird. Mitarbeiter können Mark Completed nutzen. Ich habe in diesen Docs kein Flow-basiertes Rezept gefunden.
3. Ein Prozess pro Datensatztyp. Ein Case-Prozess läuft nicht auf Work Orders, also auf getrennten Entitlements halten.
4. Aktivierung friert Aktionen ein. Nach der Aktivierung kann man keine Milestones löschen oder Aktionen anlegen. Versionierung nutzen: Auf einer genutzten Version kann man Milestones hinzufügen, aber bestehende nicht bearbeiten.
5. Die Präzision liegt bei der Minute. Milestones werden in Minuten und Sekunden gemessen, aber Start- und Endzeiten sind nur minutengenau, also gehen außerhalb von 24/7-Zeiten manche Sekunden verloren.
6. Queue-Verletzungsmails erreichen keine Mitglieder. Hat eine Queue eine E-Mail-Adresse, geht die Verletzung dorthin, und Salesforce sagt, Queue-Mitglieder erhalten sie nicht.
7. Lücken bei Mobile und Lightning. Der Tracker erscheint nicht in der Salesforce-Mobile-App, und Case Milestone hat keine Felder, die zeigen, wer es abgeschlossen hat.

Wer auch Zendesk oder Help Scout betreibt, dem wird nichts davon vertraut vorkommen. Salesforces Modell ist flexibel, und es verlangt vom Admin, es sorgfältig zu verdrahten.

Wo passt KI hin, während die First-Response-Uhr läuft?

Ein KI-Teammate kann die erste Antwort verkürzen, ersetzt aber nicht den Prozess. Ich sage das klar: eesel ersetzt keine Entitlement-Prozesse. Eure Entitlements, Milestones und Aktionen laufen weiter. Was eesel ändert, ist, wie lange ein Mitarbeiter braucht, bevor die Antwort fertig ist.

eesels Salesforce-Integration tritt Service Cloud als Agent bei, der Cases liest und Antworten entwirft oder sendet, interne Notizen hinzufügt und Felder aktualisiert, mit Contact- und Account-Kontext aus den Docs. Die Seite sagt, es arbeitet neben euren Entitlements und bestehenden Automatisierungen. Ich habe keine eesel-Dokumentation zum Lesen von Milestone-Objekten gefunden, also würde ich prüfen, wie euer Abschlusstrigger eine Antwort zählt, bevor ihr euch darauf verlasst.

Diese Prüfung zählt. Die dokumentierten First-Response-Trigger schließen bei einer an den Contact gesendeten E-Mail oder einem öffentlichen Kommentar ab. Ein als interne Notiz gespeicherter Entwurf erfüllt keines von beidem, also hilft ein Entwurfs-Setup nur, wenn eine Person den Entwurf schnell sendet. Ein Sende-Setup schließt den Milestone so ab, wie euer Trigger es definiert.

Mein nächster Beleg ist nicht Salesforce, das sage ich offen. SamCart betreibt einen eesel-Agenten auf Freshdesk-Tickets und einen weiteren im Website-Chat, der aus 280 Help-Center-Artikeln antwortet, und der Ticket-Agent antwortet nur, solange kein Teammate zugewiesen ist. Das ist die Form, die ein First-Response-Ziel will. smava zeigt das andere Ende: rund 27,000 Zendesk-Tickets, die in einem Monat bearbeitet wurden, mit rund 15,300 Antwortentwürfen, die zur Freigabe vorbereitet wurden.

Das Muster, das ich von Käufern am häufigsten höre: erst Draft-Modus, dann Auto-Reply, sobald die Antworten sich bewähren. eesel simuliert anhand eurer eigenen vergangenen Cases, bevor es live geht, und meine Leitfäden zu KI First Response und Salesforce KI-Eskalation behandeln die Übergaben. Für weitere Optionen siehe meine Übersicht beste KI für Service Cloud, die Beiträge ChatGPT für Service Cloud und Claude für Service Cloud, und meinen Leitfaden KI für Salesforce Service Cloud.

Was würde ich damit in meiner eigenen Org machen?

Hier die Kurzversion, die ich einem Admin geben würde:

1. Mit zwei Milestones anfangen. First Response und Resolution Time, No Recurrence, ein Prozess. Wiederkehrende hinzufügen, sobald man den Daten vertraut.
2. Zuerst die Entitlement-Lücke schließen. Apex hinzufügen, damit per E-Mail und Web eingegangene Cases immer eins bekommen, sonst decken die Uhren nur einen Teil der Queue ab.
3. Abschlusstrigger vor dem Go-Live schreiben. Festlegen, was als erste Antwort zählt: eine E-Mail, ein öffentlicher Kommentar, oder beides.
4. Nicht zu früh aktivieren. Jede Warn- und Verletzungsaktion hinzufügen, dann aktivieren, denn danach kann man keine Aktionen mehr hinzufügen.
5. Versionierung jetzt aktivieren. Einen laufenden Prozess ohne sie zu ändern ist schmerzhaft.
6. Das Geschäftszeiten-Verhalten testen. Einen Testcase anlegen und eine Warnung gegen die zwei Lesarten der Docs beobachten.
7. Über Verletzungen berichten. Den Case-Milestones-Report bauen und wöchentlich Open Violations durchsehen.

Ist die Queue der eigentliche Flaschenhals, zeigen meine Beiträge zu KI-Ticket-Priorisierung, Ticket-Klassifizierung und Ticket-Zusammenfassung, wo KI Zeit spart, bevor eine Uhr startet. Die Beiträge Eskalationsmanagement und SLA Best Practices helfen beim Setzen von Zielen, und Front bietet eine leichtere Version derselben Idee.

eesel für Salesforce Service Cloud ausprobieren

Wenn verpasste erste Antworten ein Problem der Queue-Größe sind, arbeitet eesel für Salesforce wie ein neuer Teammate in Service Cloud. Es lernt aus euren Knowledge-Artikeln und vergangenen Cases, liest jeden neuen Case mit dem Account-Kontext und entwirft oder sendet die Antwort, sodass eure Mitarbeiter mit erledigter Arbeit starten. Es ändert eure Entitlements oder Milestones nicht und arbeitet weiter innerhalb davon.

Im Draft-Modus auf einer Queue starten, mit den eigenen vergangenen Cases vergleichen und Auto-Reply einschalten, sobald die Antworten sich bewähren. Siehe, wie ein KI-Helpdesk-Agent einer Queue beitritt, oder vergleiche KI-Helpdesks für Enterprise, dann eesel ausprobieren.