So fügst du KI zu Salesforce Service Cloud hinzu

Erstmal ein Geständnis, warum native Unterstützung zählt

Ich fange mit etwas an, das wir auf die harte Tour gelernt haben. Eine Zeit lang hatte eesel keinen nativen Salesforce-Service-Cloud-Connector, und wir haben Deals deswegen verloren. Ein Mid-Market-Team mit rund 900 Tickets im Monat ist abgesprungen, weil unsere KI noch nicht nativ in ihre Service Cloud eingebunden werden konnte. Das hat genug gestochen, dass wir es richtig gebaut haben. Wenn ich also sage, dass der gewählte Connector mehr zählt als das Modell dahinter, ist das kein Marketing, das ist eine Narbe.

Der Grund, warum es zählt: KI zu Service Cloud hinzuzufügen dreht sich eigentlich nicht um die KI. Es geht darum, wie sauber die KI deine Fälle, dein Wissen und dein Routing liest, und wie viel Arbeit es dich kostet, dorthin zu kommen. Das ist die Linse für alles Folgende.

Die zwei Wege, KI zu Service Cloud hinzuzufügen

Bevor du Setup öffnest, hilft es zu wissen, auf welchem der beiden Wege du bist, denn sie kosten unterschiedlich viel Zeit und Geld.

Nativ bauen. Du nutzt Salesforces eigene Tools, Einstein Bots und Agentforce, um die KI innerhalb von Service Cloud zu konstruieren. Maximale Kontrolle, alles auf einem Kundendatensatz, und gemessene KI-Preise, die du sorgfältig modellieren solltest.

Einen KI-Kollegen darüberlegen. Du verbindest einen zweckgebauten KI-Helpdesk-Agenten mit Service Cloud. Er lernt aus deinen gelösten Fällen und deinem Hilfecenter, entwirft oder sendet Antworten innerhalb deines bestehenden Workflows und übergibt an Menschen, wo er sich nicht sicher ist. Weniger Kontrolle über die Innereien, deutlich weniger Einrichtungsaufwand, und dieselbe Idee gilt, wenn du Agentforce gegen Zendesk AI abwägst.

Die meisten Teams landen bei einer Mischung aus beidem. Gehen wir zuerst den nativen Weg durch, denn du solltest ihn verstehen, bevor du entscheidest, ob du ihn selbst baust.

Option 1: der native Weg (Einstein Bots zu Agentforce)

Salesforce liefert hier zwei sich überschneidende Produkte. Einstein Bots ist der ältere Intent-und-Dialog-Chatbot-Baukasten. Agentforce Service Agent ist der neuere generative, autonome Agent. Der aktuell empfohlene Weg ist, einen Einstein Bot auf deinen Service-Cloud-Kanälen zu bauen und ihn dann optional zu einem Agentforce-Agenten hochzustufen.

Die Pflichtaufgaben, bevor du botten kannst

Salesforce ist erfrischend direkt dabei: "Bevor wir mit Einstein Bots Spaß haben können, müssen wir ein paar Pflichtaufgaben erledigen." Diese Pflichtaufgaben sind echte Voraussetzungen:

• Eine Service-Lizenz und eine Chat- oder Messaging-Lizenz. Der Bot muss auf einem lebenden Konversationskanal reiten; er kann nicht eigenständig existieren.
• Ein Konversationsbudget. Jede Org bekommt 25 Einstein-Bots-Konversationen pro Monat pro aktivem Nutzer, mit einem kostenpflichtigen Add-on für 100 weitere pro Monat. Sie rollen nicht über.
• Kanal-Verkabelung. Lightning Experience aktiviert, die geführte Chat-Einrichtung durchlaufen, Salesforce Knowledge eingeschaltet, eine Experience-Cloud-Site veröffentlicht und ein Embedded-Service-Deployment für das Widget, in das der Bot gerendert wird.

Eine Falle, die es wert ist erwähnt zu werden: Orgs, die seit Summer '23 erstellt wurden, haben standardmäßig erweitertes Omni-Channel-Routing aktiviert, das keine Standard-Bots unterstützt. Ist das bei dir der Fall, baust du Enhanced Bots und routest Konversationen mit Omni-Channel-Flows.

Der Aufbau, Schritt für Schritt

1. Einstein Bots einschalten. Suche in Setup nach Einstein Bots, kippe den Schalter, akzeptiere die Bedingungen. Du brauchst die Berechtigung Customize Application, Modify Metadata oder Manage Bots, um tatsächlich zu bauen. (Get Started with Einstein Bots)
2. Den Bot erstellen. Starte den geführten Einrichtungsablauf. Der schnellste Start ist die Intro-Vorlage, die mit Dialogen für gängige Aufgaben ausgeliefert wird (Willkommen, ein Problem melden, Bestellstatus prüfen). Von Grund auf bekommst du ein Hauptmenü, Systemdialoge und Entitäten zur Eingabeerfassung.
3. Die generative Schicht hinzufügen. Hier wird es zu "KI" statt zu einem Entscheidungsbaum. Schalte Generative Knowledge Answers ein, damit der Bot deine Wissensdatenbank durchsucht und eine konversationelle Antwort schreibt, oder nutze Article Answers, um FAQ-artige Antworten aus deiner Lightning-Knowledge-Basis zu liefern.
4. Dialoge und Intents bauen. Im Bot Builder konstruierst du die Konversation als Baum aus Dialogen, jeder ausgelöst durch eine Menüwahl oder einen aus dem Freitext des Kunden erkannten Intent, wobei Entitäten zum Slot-Filling und Verzweigen genutzt werden.
5. Mit einem Kanal verbinden. Standard-Bots nutzen den Connect-a-Standard-Bot-to-Channels-Ablauf. Enhanced Bots routen zu und von dem Bot mit Omni-Channel-Flows.
6. Die menschliche Übergabe verdrahten. Übergabe ist eine erstklassige Aktion, kein nachträglicher Gedanke. Der Systemdialog Transfer to Agent (Standard) oder der Set-Routing-Type-Schritt (Enhanced) schiebt die live laufende Konversation in Omni-Channel, das sie an einen verfügbaren Menschen in der Service Console routet.

Aufsteigen zu Agentforce

Wenn du bereit für einen autonomen Agenten statt verfasster Dialogbäume bist, erzeugt das Create-Agent-from-Bot-Tool (derzeit Beta) aus deinem bestehenden Bot einen Agentforce Service Agent. Der ursprüngliche Bot bleibt live, sodass du in deinem eigenen Tempo migrierst. Salesforces eigenes empfohlenes Muster: Lass den Einstein-Bot begrüßen, verifizieren und filtern, dann übergib komplexe oder heikle Intents an den Agentforce-Agenten. Willst du den tieferen Vergleich, wir haben Agentforce gegen andere Ansätze separat aufgeschrieben.

Was native KI wirklich kostet

Hier kommt der Teil, der überrascht. Die Editionen pro Sitzplatz enthalten keine unbegrenzte KI-Agenten-Nutzung. KI wird oben drauf gestapelt und gemessen.

Quelle: Salesforce Service Cloud Preise. Jede Zeile liest sich "Startpreis. Transaktionsgebühren fallen an", echte Deals liegen also über diesen Untergrenzen. Es gibt eine begrenzte Agentforce-Gratisstufe, um es auszuprobieren, aber sie trägt keine echte Support-Warteschlange.

Zusätzlich läuft autonomes Agentforce auf einem von zwei Verbrauchsmodellen:

• Konversationsbasiert: 2 USD pro Konversation, pauschal, unabhängig von der Komplexität.
• Flex Credits: 0,10 USD pro Aktion (20 Credits je), in Paketen zu 100.000 Credits für 500 USD.

Nach Salesforces eigener Rechnung ist eine Interaktion unter der Konversationsabrechnung pauschal 2 USD, verbraucht aber 3 bis 6 Aktionen bei Flex Credits, also etwa 0,30 bis 0,60 USD. Der Haken ist die Planbarkeit: Eine gemessene Geldbörse lässt sich schwer prognostizieren, was die lauteste Beschwerde in der Community ist.

"Preisgestaltung und 'Flex-Credit'-Unvorhersehbarkeit... Es ist schwerer zu budgetieren als traditionelle Sitzplatzlizenzen. Wenn ein KI-Agent in einer Schleife hängen bleibt oder einen unerwarteten Feiertagsansturm bewältigt, kann sich deine 'digitale Geldbörse' an Credits schneller leeren als erwartet."

The Evolution of Service, G2

Wenn dich die Kostenfrage hierher gebracht hat, gehen wir in ist Agentforce die Kosten wert tiefer und legen die vollständige Setup-Kosten-Aufschlüsselung dar.

Option 2: einen KI-Kollegen darüberlegen

Wenn sich der native Weg wie ein Projekt liest, für das dir die Zeit fehlt, ist Layering die Alternative. Statt Dialoge zu bauen und Credits zu kaufen, verbindest du einen KI-Helpdesk-Agenten mit Service Cloud und lässt ihn aus dem lernen, was du bereits hast.

Das ist der Ansatz, an dem ich bei eesel arbeite, hier also die ehrliche Version, wie er sich vom nativen Aufbau unterscheidet:

• Er trainiert auf deinen gelösten Fällen, nicht nur auf deinem Hilfecenter. Native Bots antworten aus deiner Wissensdatenbank. Ein KI-Kollege liest auch deine vergangenen Service-Cloud-Tickets, sodass er die Antworten übernimmt, die dein Team tatsächlich gibt, Tonalität inklusive, vom ersten Tag an.
• Die Einrichtung dauert Minuten, kein Sprint. Kein Lizenz-Stapeln, keine Omni-Channel-Flow-Diagramme. Du verbindest Service Cloud, richtest ihn auf deine Wissensquellen aus, und er ist live. Das ist der ganze Grund, warum native Connectors so sehr zählen.
• Erst Co-Pilot, dann Autonomie. Das Muster, das fast alle eigentlich wollen, ist im Entwurfsmodus zu starten, zuzuschauen und dann bei den einfachen Dingen auf voll automatisch umzuschalten, sobald man Vertrauen hat. Konfidenzbasiertes Routing hält Antworten mit geringer Sicherheit als Entwürfe statt als Live-Antworten.

Was ich am meisten hervorheben würde, ist Simulation. Bevor ein KI-Kollege einem einzigen lebenden Kunden antwortet, kannst du ihn gegen deine historischen Service-Cloud-Tickets laufen lassen und genau sehen, was er gesagt und was er gelöst hätte. Das macht aus "wird uns das blamieren?" statt eines Wettens am Launch-Tag eine Zahl, die du vorab prüfst. Es ist die direkte Antwort auf die Datenhygiene-Angst unten und etwas, das der native Ablauf dir nicht sauber liefert.

Häufige Fehler beim Hinzufügen von KI zu Service Cloud

Nachdem ich viele dieser Rollouts beobachtet habe, häufen sich die Fehlschläge in ein paar vorhersehbaren Kategorien.

KI auf unordentliche Daten richten und hoffen. Das ist der große Fehler, und Service-Cloud-Nutzer sagen es unverblümt:

"Agentforce ist nur so klug wie die Daten, die es 'lesen' kann. Wenn deine Salesforce-Org Jahre an technischen Schulden, doppelten Datensätzen, veralteten Wissensartikeln oder schlecht gemappten Feldern hat, wird die KI kämpfen... Wenn deine Content-Version-Dateien seit 2021 nicht aktualisiert wurden, gibt der KI-Agent Kunden selbstbewusst veraltete Informationen."

The Evolution of Service, G2

Die Lösung ist kein besseres Modell, es ist zuerst dein Wissen zu bereinigen und gegen echte Tickets zu simulieren, damit du die selbstbewusst-falschen Antworten fängst, bevor Kunden es tun.

Den Einrichtungsaufwand unterschätzen. Rezensenten sind offen, dass "die meisten Teams am Ende einen dedizierten Admin oder externen Berater brauchen, nur damit es reibungslos läuft." Plane diese Zeit ein, oder wähle den Weg, der sie nicht braucht.

Die gemessenen Kosten nicht durchrechnen. Ein Team auf Reddit brachte es unverblümt auf den Punkt: "Wir haben ein POC gefahren, das kostenmäßig untragbar war." Rechne, bevor du dich festlegst, dein echtes monatliches Ticketvolumen sowohl durch die 2-USD-pro-Konversation- als auch die Flex-Credit-Rechnung, oder nutze einen ROI-Rechner, um es zu prüfen. Passt keines von beidem, ist das dein Signal, dir Alternativen mit flacherer Preisgestaltung anzusehen.

Die Übergabe-Gestaltung überspringen. Eine KI, die einen schwierigen Fall nicht elegant an einen Menschen übergeben kann, frustriert einfach nur Leute. Verdrahte den Eskalationspfad, bevor du live gehst, egal welchen Weg du wählst.

Probiere eesel für Salesforce Service Cloud

Willst du eine KI für Salesforce Service Cloud ohne den mehrwöchigen Aufbau? eesel verbindet sich mit Service Cloud, lernt automatisch aus deinen vergangenen Fällen und Hilfeartikeln und fährt eine vollständige Simulation auf deinen historischen Tickets, damit du die Lösungsrate siehst, bevor es je live antwortet. Du startest im Entwurfsmodus und gibst ihm dann mehr Autonomie, sobald du vertraust, und die Preisgestaltung ist pauschal 0,40 USD pro Ticket ohne Sitzplatzgebühren, sodass es keine Flex-Credit-Geldbörse gibt, die sich leert.

Es ist kostenlos zum Ausprobieren, und weil es zuerst in der Simulation läuft, siehst du als Erstes, was es auf deinen echten Service-Cloud-Tickets getan hätte, nicht eine Demo mit fremden Daten.