Salesforce Ticketsystem: Wie Cases 2026 wirklich funktionieren

Was Leute mit einem "Salesforce-Ticketsystem" meinen

Jeder Helpdesk hat ein Substantiv für das, woran ein Mitarbeiter arbeitet. Zendesk hat Tickets, Jira hat Work Items, und Salesforce hat Cases. Die Objektreferenz definiert es in einer Zeile: Das Case-Objekt "repräsentiert einen Case, also ein Kundenproblem oder -anliegen".

Der Name hat sich wieder verschoben. Salesforce Help zeigt jetzt einen Hinweis in der Tabelle der Service-Editionen: "Service Cloud heißt jetzt Agentforce Service", mit dem Zusatz, dass der alte Name überall im Produkt und in der Dokumentation noch auftaucht. Wer Anbietermaterial aus 2025 liest, liest über dasselbe Produkt unter anderem Namen. Unser Service Cloud Überblick bietet die breitere Produkttour.

Der strukturell wichtige Punkt ist, dass ein Case ein erstklassiges Standardobjekt auf der CRM-Plattform ist, kein Anbau. Er unterstützt die volle API-Oberfläche, von create() bis upsert(), weshalb ein Salesforce-Ticket mit einem Account, einer Opportunity und einem Asset verknüpft werden kann, ohne dass jemand einen Sync bauen muss. Das ist der eigentliche Grund, warum Unternehmen bleiben: Das Ticket sitzt auf demselben Datensatz wie das Geld.

Wer noch zwischen Kategorien abwägt: Unser Leitfaden zu Ticketsystem-Software deckt die Alternativen ab, und die Übersicht zu Salesforce-Integrationen zeigt, was sonst noch an denselben Datensatz andockt.

Eine kleine Falle für alle, die Integrationscode schreiben: Weil case in Java ein reserviertes Wort ist, heißt es im Hinweis zu reservierten Wörtern, man müsse seine App möglicherweise "mit _case statt Case" schreiben.

Der Case-Datensatz: die Felder, an denen der ganze Workflow hängt

Fast jede Workflow-Frage im Salesforce-Ticketing landet bei einer Handvoll Standardfelder. Hier sind die, die Gewicht haben, direkt aus der API-Referenz v67.0.

Diese OwnerId-Zeile ist das nützlichste einzelne Detail, um Salesforce-Ticketing zu verstehen. Weil sie entweder auf einen User oder eine Group zeigt, und eine Group ist, wie Salesforce eine Queue modelliert, sind "einer Person zuweisen" und "einem Team-Postfach zuweisen" buchstäblich dieselbe Operation. Es gibt kein separates Queue-Feld, das synchron gehalten werden müsste, was sauberer ist, als es die meisten Helpdesks hinbekommen.

Die mitgelieferten Picklists sind kleiner, als man in Erinnerung hat. Laut Salesforces eigenem Artikel zu Picklist-Standardwerten erhält ein frisches Org Status-Werte von New, On Hold und Escalated; Type-Werte von Problem, Question, Feature Request und Duplicate; und fünf Case-Reason-Werte. Alles darüber hinaus ist Admin-Arbeit.

"Closed" ist interessanter, als es aussieht. Es ist nicht hartkodiert, sondern Daten. Ein separates, schreibgeschütztes CaseStatus-Objekt trägt pro Wert ein IsClosed-Flag, und die CaseStatus-Referenz merkt an, dass "mehrere Case-Status-Werte einen geschlossenen Case darstellen können". Man kann also Closed - Resolved und Closed - No Response als eigenständige Status ausliefern, und jeder Report rechnet trotzdem korrekt. Das ist ein echter Vorteil gegenüber Helpdesks, die nur drei feste Status-Buckets bieten.

Mitarbeiter bearbeiten den Case im Case Feed, den die Case-Feed-Dokumentation so beschreibt, dass er "wichtige Case-Ereignisse in chronologischer Reihenfolge" anzeigt statt einer Wand aus verwandten Listen. Wichtig vor einer Migration: Laut den Hinweisen zu verwandten Listen wurden im Case Feed "private Kommentare durch Case Notes ersetzt, die Chatter-Posts sind", und sie erscheinen nicht mehr in der verwandten Liste Case Comments. Teams, die über interne Notizen Reports fahren, tappen genau hier in die Falle.

Ein langer Feed ist auch der Ort, an dem Mitarbeiter Zeit verlieren, weshalb Salesforce Case Summaries zu einer prominenten KI-Funktion wurde. Das allgemeine Muster deckt unser Leitfaden zu Ticket-Zusammenfassungen ab.

Wie Tickets in Salesforce landen, und die Limits, die einem niemand vorher nennt

Salesforce dokumentiert genau fünf Kanäle, die Cases erzeugen: Voice, E-Mail, Webformulare, Messaging-Apps sowie Web- oder In-App-Chat. Von dort fließt alles durch Omni-Channel.

Die Trennlinie, die für die Budgetierung zählt, ist simpel. E-Mail und Webformulare sind mit der Edition kostenlos. Jeder Echtzeit-Kanal ist ein bezahltes Add-on.

Der Wert von 5.000 Cases pro 24 Stunden bei Web-to-Case ist die schärfste veröffentlichte Zahl im gesamten System, und ihr Überlaufverhalten lohnt zweimaliges Lesen. Zusätzliche Anfragen landen in einer Pending-Queue, die mit Web-to-Lead geteilt wird, der Default Case Owner bekommt eine E-Mail, und diese Queue selbst deckelt bei 50.000. Darüber hinaus "werden zusätzliche Anfragen abgelehnt und nicht in die Queue aufgenommen", und der Administrator wird nur für die ersten fünf benachrichtigt. Danach ist die Stille nicht von normalem Funktionieren zu unterscheiden.

Zwei weitere Punkte, die mitten im Aufbau zuschlagen. Web-to-Case unterstützt überhaupt keine Anhänge, weshalb jeder Workflow, bei dem Kunden Screenshots oder Logs schicken, das Webformular nicht nutzen kann. Und die tägliche Obergrenze von Email-to-Case skaliert mit der Lizenzanzahl, nicht mit dem Ticketvolumen, und wird mit jedem anderen E-Mail-Dienst im Org geteilt. Ein Team mit 10 Sitzplätzen hat insgesamt 10.000 E-Mails am Tag, was großzügig klingt, bis ein Email-to-Apex-Dienst still dasselbe Budget auffrisst. Händler, die an diese Obergrenzen stoßen, landen meist eher bei KI-Ticket-Routing als bei einer größeren Lizenzanzahl.

Auch die alte, firewallfreundliche Option gibt es nicht mehr. Salesforces Seite zu Email-to-Case-Einstellungen besagt inzwischen, dass die installierte Agentversion "nicht mehr unterstützt wird und der Agent nicht mehr zum Download verfügbar ist". Support-E-Mails innerhalb des eigenen Netzwerks zu halten, ist jetzt ein eigener Build.

Schließlich warnt die Dokumentation ausdrücklich vor dem Multi-Adressen-Setup, zu dem die meisten Teams zuerst greifen. An mehrere Routing-Adressen zu senden "erzeugt doppelte Cases und thread't nur mit dem Case mit der jüngsten E-Mail-Aktivität". Eine Adresse plus Case Teams ist das unterstützte Muster.

Routing: eine aktive Regel, und die Checkbox, die alles entscheidet

Hier ist die Beschränkung, die jede Salesforce-Ticketing-Implementierung prägt, die ich gesehen habe. Dein Org kann genau eine aktive Case-Assignment-Regel haben. Die Richtlinien zu Assignment Rules sagen es unverblümt: "Deine Organisation kann jeweils eine aktive Case-Assignment-Regel haben".

Diese eine Regel ist in sich großzügig. Sie fasst bis zu 3.000 Regeleinträge, von denen 300 formelbasiert sein können, mit 25 Filterkriterien pro Eintrag und 200 Aktionen pro Regel. Die Auswertung folgt dem Prinzip "erster Treffer gewinnt": Das Assignment-Rule-Setup besagt, Salesforce "weist das Item zu und stoppt die Auswertung", sobald ein Eintrag zutrifft. Trifft nichts zu, fällt der Case an den Default Case Owner in den Support Settings, weshalb ein abschließender Catch-all-Eintrag gängige Praxis ist.

Jetzt der Teil, der Support-Tickets über das Support-Tool erzeugt. Assignment Rules feuern für Web- und E-Mail-Cases automatisch. Bei manueller Erstellung hängt es von einer Checkbox im Page-Layout ab, ob die Regel überhaupt läuft. Erstellt man einen Case über den Cases-Tab mit dieser deaktivierten Checkbox, wird man laut der Dokumentation zur Case-Zuweisung "automatisch als Case-Owner eingetragen". Über die API ist es schlimmer: Man muss beim Create-Call einen AssignmentRuleHeader mitsenden, sonst läuft überhaupt keine Regel, was der klassische Grund ist, warum jeder per API erstellte Case beim Integrationsnutzer landet.

Ein Salesforce-Administrator, der sich selbst als Omni-Channel-Spezialist bezeichnet, brachte die praktische Seite davon auf Reddit auf den Punkt:

"So this is a tricky example of Case Assignment rules and having your page layout or lightning page set to have the run assignment rules checked or not."

u/mayday6971, Reddit

Seine Lösung, für das, was es wert ist, war ein record-triggered Flow, der prüft, ob die Routing-Konfiguration leer ist, bevor er routet. Der deklarative Weg brauchte Code, um verlässlich zu sein, was eine faire Zusammenfassung von Salesforce-Ticketing im Allgemeinen ist. Unser Leitfaden zu Salesforce Case Automation geht tiefer auf dieses Muster ein, und die breitere Übersicht zu Salesforce Automation deckt Flow selbst ab.

Omni-Channel und das Kapazitätsmodell

Sobald ein Case in einer Queue liegt, drängt Omni-Channel ihn zu einem Mitarbeiter, statt Mitarbeiter selbst aussuchen zu lassen. Mitarbeiter haben eine Kapazitätszahl, die Routing-Konfiguration jeder Queue legt fest, wie viel davon ein Case verbraucht, und zwei Modelle entscheiden, wer die Arbeit bekommt: Least Active wählt, wer die geringste Kapazität nutzt, Most Available wählt, wer am meisten frei hat. Die Dokumentation zum Kapazitätsmodell deckelt einen Mitarbeiter bei "maximal 100 gleichzeitig offenen Arbeitsobjekten".

Drei Einschränkungen, mit denen man planen sollte:

• Routing passiert einmal. Laut der Omni-Channel-Dokumentation: "Wenn Feldwerte am Arbeitsobjekt geändert werden, nachdem es geroutet wurde, wird die Routing-Logik nicht erneut angewendet." Eine Case-Priorität neu zu setzen, routet ihn nicht neu.
• Ablehnen hebt die Zuweisung nicht auf. Die Dokumentation zu Routing-Optionen besagt, Omni-Channel "betrachtet Arbeit als zugewiesen, sobald es ein Arbeitsobjekt an einen Mitarbeiter routet, unabhängig davon, ob der Mitarbeiter annimmt oder ablehnt", und ein abgelehntes Objekt bleibt beim Ablehnenden, bis es erneut geroutet wird.
• Standard-Omni-Channel wird abgeschafft, mit dem Summer-'26-Release, und laut dem Omni-Channel-Überblick "upgradet Salesforce dein Org während des Rollouts automatisch auf Enhanced Omni-Channel".

Skill-basiertes Routing ist das schärfere Werkzeug und die schärfere Klinge. Aktiviert man es für eine Queue, gilt laut der Dokumentation zur Routing-Konfiguration: "Die Mitgliedschaft der Queue gilt dann nicht mehr fürs Routing." Hat niemand die erforderliche Skill, wird der Case gar nicht geroutet, sondern bleibt im Skills Backlog liegen. Es ist außerdem eingeschränkt: Skill-basiertes Routing und Omni-Flows gibt es in Professional, Enterprise, Unlimited und Developer with Agentforce Service, wobei die Performance-Edition auffällig ausgeschlossen bleibt.

Wenn es funktioniert, mögen es die Leute. Ein G2-Rezensent brachte auf den Punkt, warum:

"Omni-Channel routing is another feature I didn't realize I'd rely on so heavily. It's not perfect, but the fact that it distributes load across agents based on capacity rather than just round-robin has made a real difference in team morale—nobody feels like they're getting buried while someone else is coasting."

Mahesh D., Small-Business, G2

SLAs laufen über Entitlements, nicht über das Ticket

Das ist der Abschnitt, den ich zweimal lesen würde, bevor ich einem Kunden eine Reaktionszeit verspreche. Escalation Rules in Salesforce sind ein Timer plus eine E-Mail. Die eigentliche SLA-Engine ist Entitlement Management, eine Kette aus vier Objekten: Ein Entitlement sagt, wem Support zusteht, ein Entitlement-Prozess ist die Zeitachse, und Milestones sind die einzelnen Uhren, die auf dem Case landen.

Das Setup ist leistungsfähig. Man bekommt 1.000 Entitlement-Prozesse pro Org mit je 10 Milestones, Milestone-Status Compliant, Open Violation und Closed Violation, sowie reportfähige Felder wie TimeRemainingInMins und IsViolated, die SLA-Dashboards unkompliziert machen.

Dann kommen die Einschränkungen, die Salesforce offen dokumentiert und die meiner Ansicht nach in den meisten Kaufentscheidungen unterschätzt werden:

• Laut den Entitlement-Limits: "Entitlements werden nicht automatisch auf Cases angewendet, die mit Web-to-Case oder Email-to-Case erstellt wurden." Genau die beiden kostenlosen Intake-Kanäle sind es, die die SLA-Engine überspringen, sofern man kein Apex schreibt.
• Laut den Hinweisen zur Milestone-Fertigstellung: "Milestones werden nicht automatisch als abgeschlossen markiert." Automatische Fertigstellung ist ein Apex-Trigger.
• Laut den Regeln zur Prozessaktivierung: "Nachdem ein Entitlement-Prozess aktiviert wurde, kann man seine Milestones nicht löschen oder Milestone-Aktionen erstellen." Man versioniert den Prozess stattdessen.
• Laut der Einschränkung bei Listenansichten: "Das Feld Case Milestone Status ist in Listenansichten in Lightning Experience nicht verfügbar."

Das Timer-Verhalten hat eine eigene Logik, die man verinnerlichen sollte. Milestone-Uhren pausieren außerhalb der Geschäftszeiten, sodass ein 60-minütiger Erstantwort-Milestone, der um 16:30 Uhr bei einer Geschäftszeit von 9 bis 17 Uhr startet, erst am nächsten Tag um 9:30 Uhr endet. Und einen Milestone zu pausieren, nachdem er bereits verletzt wurde, ändert nichts: Das Timer-Verhalten der Milestones besagt, dass Timer "die gesamte verstrichene Zeit nach der Verletzung des Milestones zählen, unabhängig davon, ob der Timer gestoppt wurde".

Escalation Rules unterliegen derselben Ein-aktive-Regel-Beschränkung wie Assignment, sind auf fünf Aktionen pro Eintrag gedeckelt und setzen voraus, dass Geschäftszeiten zuerst konfiguriert sind. Die tückischste Option in der ganzen Funktion ist die Escalation-Start-Einstellung "wenn der Case erstellt wird, und deaktivieren, sobald der Case zum ersten Mal geändert wird", die die Eskalation dauerhaft abbricht, sobald irgendein Mitarbeiter den Case anfasst. Salesforces eigenes Beispiel: ein um 9 Uhr erstellter Case mit fünfstündiger Eskalation, um 10 Uhr bearbeitet, eskaliert nie.

Teams umgehen das auf zwei Wegen: mit einem Apex-Trigger oder mit einer Schicht, die die Queue unabhängig überwacht. Unser SLA-Management-Leitfaden deckt den ersten Weg ab, und KI-Eskalationsmanagement den zweiten.

Hier die ehrliche Zusammenfassung: Salesforce-Ticketing gibt einem eine SLA-Engine, die fast alles ausdrücken kann, und erwartet, dass man einen Admin und einen Entwickler mitbringt, um sie zum Laufen zu bringen. Ob sich dieser Deal lohnt, hängt größtenteils davon ab, wie viele Leute man hat.

Was ein Salesforce-Ticketsystem 2026 tatsächlich kostet

Die Listenpreise sind öffentlich und übersichtlich. Was man tatsächlich zahlt, ist es nicht.

Alle fünf stammen direkt von der Service-Cloud-Preisseite. Jetzt die Add-ons aus der Funktionsvergleichstabelle auf derselben Seite:

Lies die erste Zeile noch einmal. Bei Enterprise listet die Preisseite Knowledge Management als "Nur Lesen. Lesen/Schreiben käuflich erhältlich." Ein Ticketsystem, in dem Mitarbeiter ohne einen $75-Aufpreis keinen Knowledge-Artikel schreiben können, ist eine ungewöhnliche Definition von "enthalten", und das prägt still, wie Teams an KI-gestützte Wissenserstellung herangehen.

Unsere Aufschlüsselung der Add-on-Preise und der Leitfaden zu Plattform-Lizenzpreisen haben die vollständigen Matrizen.

Die KI-Schicht wird separat abgerechnet

Agentforce, die KI, die Cases beantwortet, ist nicht im Sitzplatzpreis enthalten, außer man ist in der $550-Edition. Es gibt drei Verbrauchseinstiegspunkte: Salesforce Foundations bei $0, Flex Credits bei $500 pro 100.000 Credits, und Conversations bei $2 pro Konversation. Die letzten beiden lassen sich nicht mischen, da "Flex Credits und Conversations nicht im selben Org unterstützt werden".

Salesforce veröffentlicht eigene Rechenbeispiele, und sie sind das nützlichste Preismaterial, das das Unternehmen liefert:

Die mittlere Spalte lohnt den Blick, denn sie ist ein Support-Ticket. Eine Case-Management-Konversation durchläuft drei Aktionen (Kunde identifizieren, dessen Cases abrufen, einen Kommentar hinzufügen), was 60 Flex Credits entspricht, also $0,30 im Credit-Modell gegenüber $2,00 im Conversation-Modell. Dieselbe Arbeit, fast das 7-Fache am Preis, allein abhängig davon, welchen Vertrag man unterschrieben hat. Unser Flex-Credits-Leitfaden rechnet die Credit-Mathematik vor, und Agentforce-Preise deckt die Lizenzseite ab.

Etwas veröffentlicht Salesforce nicht: was als "Konversation" zählt. Die Preisseite setzt kein Limit für Turns, Sitzungsdauer oder Lösungsvoraussetzung für die $2-Einheit. Sie veröffentlicht auch nicht den vertraglichen Überschreitungssatz, nur dass es laut den Agentforce-Preisbedingungen "keine Überschreitungsstrafe" gibt und man rückwirkend zum vertraglichen Satz abgerechnet wird. Und ungenutzte Flex Credits "werden nicht in nachfolgende Abo-Zeiträume übertragen".

Trag deine eigenen Zahlen ein

Wer die Ausgabe mit Salesforces eigenen Zahlen abgleichen möchte: Unser Preisrechner-Leitfaden und der Beitrag zu Salesforce-KI-Preisen rechnen dieselbe Mathematik aus der anderen Richtung durch.

Wo Teams tatsächlich hängen bleiben

Salesforce Service Cloud hält auf G2 4,4 von 5 Punkten über 7.357 Bewertungen, davon 63 % mit fünf Sternen. Das ist kein schlechtes Produkt. Die Beschwerden bündeln sich an drei konkreten Stellen.

Die Lizenz-Leiter. Ein Rezensent aus dem Small-Business-Segment beschrieb die Verlängerungserfahrung treffend:

"Pricing is where it gets a little frustrating. It starts feeling reasonable until you realize the features you actually need day to day are sitting behind another add on or a higher tier. Storage, advanced reporting, extra automation capabilities — it all adds up quietly until your renewal conversation becomes a bit of a shock."

Mahesh D., Small-Business, G2

Die Admin-Steuer. Salesforce-Ticketing lässt sich auf so ziemlich alles konfigurieren, und irgendjemand muss diese Konfiguration erledigen. Ein Tech Lead, der einen Rollout mit über 600 Sitzplätzen über fünf Clouds hinweg geleitet hat, brachte es auf Hacker News auf den Punkt:

"I entered the move skeptical of Salesforce's value; I left impressed with the flexibility of the platform but aghast at the costs and development effort required to do much of anything."

billbrown, Hacker News

Der ungedeckelte KI-Zähler. Das ist der neueste Punkt und der, den ich in einem Sales-Call am härtesten hinterfragen würde. Ein Thread vom Juli 2026 dokumentierte, dass Agentforce und Digital Wallet keinen automatischen Stopp haben:

"There are currently no native hard caps, circuit breakers, or real-time consumption alerts to automatically halt credit drain. The system prioritizes operational continuity for their servers, leaving the customer exposed to un-capped financial liability."

Agentforce & Digital Wallet lack hard caps for async loops, Reddit

Das ist nicht theoretisch. Ein anderer Administrator beschrieb die Rechnung:

"We got $40k bill cuz our retriever jobs hit the fan when an intern ran web crawler once, failed and Salesforce support created two new for testing, so we have to also pay for the negligence of sf support staff."

u/Simple-Art-2338, Reddit

Es gibt ein viertes Thema, das wichtiger ist als das Geld: was die KI tut, wenn sie falsch liegt. Ein Team berichtete, dass ein Agentforce-Agent einem Kunden einen intern-only Knowledge-Artikel inklusive Kündigungsanleitung zeigte, statt zu eskalieren. Salesforce Premier Support führte das schließlich auf eine Prompt-Vorlage zurück, die den Standard-Retriever mit Zugriff auf jeden Knowledge-Artikel verwendete.

Wir haben darüber geschrieben, warum dieses Fehlermuster so verbreitet ist, in KI-Halluzinationen im Support, und wie gute KI-Handoff-Praxis aussieht.

Unser Beitrag zu Service-Cloud-KI-Einschränkungen deckt den Rest ab, und Salesforce-KI-Governance behandelt die Kontrollen, die man drumherum einrichten kann.

Solltest du deinen Support auf Salesforce betreiben?

Hier ist meine ehrliche Einschätzung, nachdem ich mich durch diese Dokumentation gearbeitet habe.

Bleib beim Salesforce-Ticketing, wenn deine Cases wirklich CRM-Kontext brauchen, um beantwortet zu werden, und du einen Admin hast. Wenn die Antwort auf "wo ist diese Bestellung, was hat der Kunde bezahlt, wie sieht sein Vertrag aus" in Salesforce lebt, dann bedeutet das Ticket woanders zu platzieren, einen Sync zu bauen, den man für immer pflegt. Nichts in der Kategorie schlägt einen Case, der nativ am Account-Datensatz hängt. Unser Vergleich Salesforce Service Cloud vs. Zendesk behandelt diesen Trade-off im Detail.

Schau dich anderswo um, wenn du ein kleines Support-Team ohne dedizierte Admin-Kapazität bist. Die Funktionen, für die man Salesforce kaufen würde, Entitlements, Skill-basiertes Routing und Knowledge read-write, sind allesamt hinter Edition-Stufen, Apex oder beidem verriegelt. Ein Fünf-Personen-Team zahlt Enterprise-Komplexität zu Enterprise-Preisen und bekommt weder das Entitlement-Monitoring noch den Admin, der es betreibt.

Unsere Listen der besten Ticketsysteme für kleine Teams und kostenlosen Ticketsysteme sind bessere Ausgangspunkte.

Der Leitfaden KI-Ticketsystem deckt ab, was zuerst automatisiert werden sollte, sobald man sich für eines entschieden hat. Wenn das eigentliche Problem das Volumen ist, beginn mit Ticket-Reduktion statt mit einer Migration.

Der interessante Mittelfall, den ich am häufigsten sehe, sind Teams, die bei Salesforce bleiben und einfach die KI obendrauf nicht kaufen wollen. Das ist eine echte Option und es lohnt sich, sie auszubuchstabieren.

KI zu Salesforce-Cases hinzufügen, ohne den Credit-Zähler

Es gibt zwei Wege, eine Salesforce-Ticketqueue zu automatisieren, und sie haben sehr unterschiedliche Formen.

Der native Weg ist Agentforce. Man kauft eine Edition, die es unterstützt, aktiviert es, baut die Topics und Actions, und behält dann den Zähler im Blick. Es ist tief in die Plattform eingewoben, was ein echter Vorteil ist, wenn die Automatisierung sechs Standardobjekte berühren muss. Unser Beitrag zu Agentforce Customer Service deckt ab, worin es gut ist. Für die Großunternehmens-Version lies Service-Cloud-KI für Enterprise, und für die Mechanik darunter Salesforce-KI in Service Cloud.

Wer das Feld lieber vergleichen möchte, bevor man sich festlegt: Wir haben die Zahlen in bester Salesforce-Chatbot durchgerechnet und den Agent-Assist-Blickwinkel in Helpdesk-Copilot betrachtet.

Der Schicht-Weg lässt die Service-Cloud-Konfiguration exakt so, wie sie ist, und setzt einen KI-Agenten oben auf das Case-Objekt. Das haben wir bei eesel gebaut: Es arbeitet innerhalb der Service-Cloud-Cases und -Feeds, respektiert die Assignment Rules, Escalation Rules und Entitlements, die bereits konfiguriert sind, und verlangt nie, das Routing neu zu bauen.

Der Teil, den ich wirklich hervorheben würde, weil er genau das ist, was diesen Zwischenfall mit dem internen Knowledge-Artikel in unserem Stack unmöglich gemacht hat, ist die Simulation. Man lässt den Agenten gegen die vergangenen Cases laufen, bevor er einen Live-Case anfasst, sieht, wo er stark und wo er dünn ist, und aktiviert ihn erst danach. Der Reddit-Thread über den verlorenen Kunden wegen einer schlechten KI-Antwort erzählt genau die Geschichte, was passiert, wenn man diesen Schritt auslässt.

eesel für deine Salesforce-Cases ausprobieren

Wenn du auf Service Cloud bist und das Agentforce-Angebot dich hat zusammenzucken lassen, ist das die Version, die ich zuerst ausprobieren würde. eesel tritt als KI-Agent innerhalb von Salesforce Service Cloud bei, ohne Chatbot-Widget und ohne separates Postfach. Es entwirft und versendet Antworten, fügt interne Notizen hinzu, routet Cases in Queues und aktualisiert die Felder, die man erwarten würde: Priority, Status, Owner. Es verwaltet auch die SLA-Zeitpläne. Das Ausgangsmaterial sind die eigenen vergangenen Cases, plus Knowledge-Artikel und E-Mail-Vorlagen.

Drei Dinge, die speziell für einen Salesforce-Käufer zählen. Die Einrichtung ist codefrei, und die Seite behauptet unter 30 Minuten, was eine ganz andere Größenordnung als ein Agentforce-Aufbau ist. Man wählt genau aus, welche Cases es anfasst, nach Record Type, Queue, Kanal oder Bedingung, sodass man mit Entwürfen bei Tier 1 starten und erweitern kann, sobald man Vertrauen aufgebaut hat. Und der Preis ist eine Pauschale von 40 Cent pro bearbeitetem Case, ohne Plattformgebühr und ohne Sitzplatzgebühr, sodass die Zahl aus dem Rechner oben dieselbe Zahl bleibt, die auf der Rechnung steht.

Ein Logistiksoftware-Team auf Service Cloud hatte es vollständig integriert in rund einer Stunde über 717 Knowledge-Elemente hinweg. Man bekommt $50 an kostenloser Nutzung, um es zuerst an den eigenen Cases zu testen, ohne Kreditkarte, und das Ganze pausiert automatisch, sobald das gesetzte Ausgabenlimit erreicht ist. Starte mit eesel für Salesforce oder durchstöbere die vollständige Integrationsliste, falls dein Stack breiter aufgestellt ist als ein einzelner Helpdesk.