Die Entscheidung für Agentforce fällt meistens in einem Raum, in dem niemand in die Org geschaut hat. Budget steht, Termin steht, und der erste Blick in die Knowledge Base kommt im Projekt. Dann zeigt sich, dass der Agent nichts zu antworten hat.
Agentforce ist selten ein KI-Problem. Der Agent beantwortet genau das, was Ihre Knowledge Base hergibt, schreibt genau die Felder, die er schreiben darf, und eskaliert nur dorthin, wo ein Ziel definiert ist. Alles drei steht heute schon in Ihrer Org oder eben nicht.
Dieser Artikel beschreibt, welcher Zustand einer Service-Cloud-Org einen Piloten trägt. Ob Agentforce für Sie überhaupt die richtige Investition ist, ist eine andere Frage, und die beantwortet Wann Sie kein Agentforce brauchen.
Vier Stellen in Ihrer Org entscheiden über den Piloten, nicht das Sprachmodell
Das Modell ist bei allen gleich. Unterschiedlich ist, was es vorfindet. Diese vier Punkte bestimmen, ob ein Pilot trägt:
- Knowledge-Artikel: Was der Agent nicht als veröffentlichten Text findet, kann er nicht beantworten.
- Case-Datenqualität: Nicht nur die Historie. Vor allem die Regeln, die beim Speichern greifen.
- Record Types: Sie bestimmen, welchen Prozess der Agent überhaupt bedienen darf.
- Eskalationswege: Ein Agent ohne definiertes Ziel für die Übergabe hat keine Notbremse.
Quer dazu liegt ein fünfter Punkt, den die meisten Projekte unterschätzen: Der Agent arbeitet unter einem eigenen Benutzer und sieht nur, was dieser Benutzer sehen darf. Dazu unten mehr.
Ein KI-Agent ist ein zusätzlicher Benutzer ohne Gedächtnis, mit vollem Zugriff auf Ihre Unordnung.
Der Agent liest nur veröffentlichte Knowledge-Artikel, nicht Ihre Entwürfe
Agentforce holt sich Fachwissen über eine Agentforce Data Library. Die indiziert Ihre Knowledge-Artikel und Anhänge und liefert dem Modell zur Laufzeit die passenden Ausschnitte. Zwei Voraussetzungen stehen dabei in der Dokumentation, und beide werden in Budgets gerne übersehen:
- Data 360 muss aktiv sein. Ohne aktiviertes Data 360, früher Data Cloud, gibt es keine Data Library. Der Betrieb verbraucht Data-360-Credits.
- Nur veröffentlichte Artikel zählen. Entwürfe sind für den Agenten nicht vorhanden. Wenn Sie den Agenten zusätzlich auf öffentliche Artikel beschränken, zählt nur, was im Public-Knowledge-Base-Kanal sichtbar ist.
Dazu kommt die Feinsteuerung: Sie können das Grounding auf Datenkategorien filtern, und Sie bestimmen in den Knowledge Field Settings, welche Felder als identifizierende Felder in den Index gehen. Titel und Zusammenfassung tragen damit die Auffindbarkeit. Ein Artikel mit dem Titel „Vorgehen 2019 final" ist für den Agenten so gut wie unsichtbar, auch wenn im Fließtext die richtige Antwort steht.
Der Zustand Ihrer Knowledge Base lässt sich in zwei Minuten messen. Diese Abfrage in der Developer Console zeigt, wie viel von Ihrem Wissen überhaupt indizierbar ist:
SELECT PublishStatus, Language, COUNT(Id)
FROM Knowledge__kav
WHERE IsLatestVersion = true
GROUP BY PublishStatus, LanguageEin häufiges Ergebnis in DACH-Orgs: viele Artikel im Status Draft, eine gewachsene Mischung aus deutscher und englischer Sprachversion, und ein Teil der veröffentlichten Artikel ohne Datenkategorie. Jede dieser drei Zahlen ist ein Befund, bevor irgendjemand über Prompts spricht.
Was das kostet: Artikel neu zu schreiben ist Redaktionsarbeit, nicht Administratorarbeit. Rechnen Sie pro Artikel eine halbe bis eine Stunde einer Person, die das Thema wirklich kennt. Was es bricht: Wenn Sie Artikel zusammenlegen, ändern sich die URL-Namen. Bestehende Verlinkungen aus Cases, E-Mail-Vorlagen und dem Help Center laufen ins Leere. Legen Sie vorher fest, welche Artikel bestehen bleiben und welche nur noch weiterleiten. Wie eine Knowledge-Struktur aussieht, die im Alltag benutzt wird, habe ich am Beispiel Field Service in Knowledge Base optimal nutzen beschrieben.
Ihre Validierungsregeln entscheiden, ob der Agent einen Case speichern darf
Über Case-Datenqualität wird fast immer rückwärts gesprochen: Wie sauber ist die Historie, reicht sie als Trainingsmaterial. Das ist die halbe Frage. Die andere Hälfte ist der Schreibweg: Der Agent legt Cases an und aktualisiert sie, und dabei gelten für ihn dieselben Regeln wie für jeden anderen Benutzer.
Ein konkretes Beispiel, das in vielen gewachsenen Service-Orgs so oder ähnlich steht. Auf dem Case liegt eine aktive Validierungsregel dieser Art:
AND(
ISPICKVAL(Type, "Technical"),
ISBLANK(TEXT(Product_Line__c))
)Ein Mensch im Service liest die Fehlermeldung, ruft beim Kunden zurück und trägt die Produktlinie nach. Der Agent kann das nicht. Er klassifiziert das Anliegen als technisch, hat die Produktlinie aber nirgends im Gespräch, und der Speichervorgang scheitert. Nach außen sieht das aus wie ein abgebrochener Chat. Im Debug Log steht eine Validierungsregel aus dem Jahr 2021.
Die Prüfung dafür ist unspektakulär und dauert eine Stunde: Setup, Object Manager, Case, Validation Rules. Gehen Sie jede aktive Regel durch und beantworten Sie eine einzige Frage: Woher nimmt der Agent diesen Wert? Dieselbe Frage gilt für Pflichtfelder auf Feldebene und für Flows, die beim Speichern greifen.
Was das kostet: pro Regel wenige Minuten Analyse, die Korrektur meist unter einer Stunde. Was es bricht: Eine Regel einfach zu deaktivieren gibt Ihrem Team die Freiheit zurück, das Feld leer zu lassen. Reports und Auswertungen, die auf diesem Feld stehen, werden dann unvollständig, und niemand merkt es sofort. Der saubere Weg ist, die Regel auf den Record Type oder die Benutzergruppe einzuschränken, für die sie gedacht war, statt sie zu löschen.
Welcher Use-Case sich als erster Pilot eignet und wie Sie ihn zuschneiden, steht in Agentforce in der Fallannahme.
Record Types bestimmen, welchen Prozess der Agent bedienen darf
Jeder Case Record Type hängt an einem Support Process, und der Support Process legt fest, welche Status-Werte zur Auswahl stehen. Für den Agenten heißt das: Der Record Type entscheidet, welchen Prozess er überhaupt durchlaufen kann.
Zwei Dinge müssen deshalb vor dem Piloten geklärt sein. Erstens: Auf welche Record Types hat der Benutzer des Agenten Zugriff, und welcher ist sein Standard? Ohne diese Festlegung landet jeder vom Agenten erzeugte Case auf dem Standard dieses Benutzers, nicht auf dem fachlich richtigen. Zweitens: Wie viele Record Types sind fachlich wirklich verschieden? Orgs mit zwölf oder vierzehn aktiven Case Record Types haben oft drei echte Prozesse und elf historische Varianten.
Was das kostet: Record Types zusammenzulegen ist eine Datenmigration und kein Klick. Rechnen Sie mit Tagen, nicht Stunden. Was es bricht: Bestehende Cases behalten ihren Record Type, Berichte filtern darauf, Berechtigungen und Layouts hängen daran, und Automatisierungen prüfen Record-Type-Namen im Klartext. Für einen Piloten ist die Aufräumaktion deshalb der falsche Startpunkt. Nehmen Sie einen Record Type, machen Sie den sauber, und lassen Sie den Rest vorerst stehen.
Ohne definiertes Ziel bricht die Eskalation ab, statt weiterzugehen
Die Übergabe an einen Menschen ist kein Nebeneffekt, sondern eine eigene Konfiguration. Auf den Messaging-Kanälen übergibt ein Agentforce Service Agent über einen ausgehenden Omni-Channel-Flow. Der Flow bestimmt das Ziel und gibt es zurück: entweder eine Benutzer-ID oder eine Queue-ID. Ohne diesen Flow gibt es kein Ziel, und ohne Ziel bricht das Gespräch ab.
Daran hängt ein Detail mit unangenehmen Folgen für den Test. Die Eskalation setzt eine Messaging Session voraus. Im Agentforce Builder gibt es keine. Wer den Agenten nur dort durchspielt, hält ihn für fertig, obwohl sein wichtigster Weg nie gelaufen ist. Die Eskalation müssen Sie auf dem Kanal testen, auf dem sie später läuft.
Und eine Queue allein ist noch kein Eskalationsweg. Eine Queue ohne Mitglieder oder ohne anwesende Mitarbeiter ist eine Warteschlange, in der Vorgänge liegen bleiben. Legen Sie pro Thema fest, wohin eskaliert wird, und was passiert, wenn dort gerade niemand verfügbar ist.
Was das kostet: pro Eskalationspfad ein Flow, eine Queue und eine benannte Zuständigkeit, in Summe wenige Tage für die ersten drei Pfade. Was es bricht: Wenn Sie Eskalationen in bestehende Queues legen, ändern Sie die Last dieser Teams. Ohne Ankündigung und ohne Verabredung über Reaktionszeiten ist das der schnellste Weg, die Akzeptanz im Service zu verlieren, bevor der Agent seinen ersten Nutzen zeigt.
Der Agent sieht genau so viel wie sein eigener Benutzer
Ein Agentforce Service Agent arbeitet unter einem eigenen Benutzerdatensatz. Salesforce liefert dafür die Permission Set Group AgentforceServiceAgentUserPsg mit den Berechtigungssätzen für den Service Agent, Data Cloud und Prompt Templates. Der Zuschnitt ist bewusst minimal gehalten: Der Agent startet mit sehr wenig und bekommt nur dazu, was er nachweislich braucht.
Für Objekte und Felder gelten Permission Sets, für einzelne Datensätze gilt Ihr Sharing-Modell. Was dieser Benutzer nicht sehen darf, kann der Agent nicht beantworten. Und er sagt das nicht. Er antwortet einfach ohne die Information, die ihm fehlt. Genau deshalb sind Testantworten, die plausibel klingen und trotzdem falsch sind, im Zweifel ein Rechteproblem und kein Modellproblem.
Was das kostet: Ein Aufbau nach dem Prinzip der geringsten Rechte braucht Iterationen. Jede fehlende Antwort im Test ist zuerst eine Frage nach der Berechtigung. Was es bricht: Die Abkürzung, ein vorhandenes Profil zu kopieren, liefert in fünf Minuten einen Agenten mit Admin-Nähe. Das funktioniert im Test hervorragend und fällt Ihnen bei der ersten Datenschutzprüfung auf die Füße, weil sich dann nicht mehr sagen lässt, auf welche personenbezogenen Felder der Agent zugreifen konnte.
Eine Stunde, fünf Prüfungen: so erheben Sie den Zustand selbst
Diese fünf Schritte kann ein Administrator mit Systemzugriff an einem Vormittag erledigen. Das Ergebnis ist kein Gutachten, aber es reicht für eine ehrliche Antwort auf die Frage, ob ein Pilot trägt.
- Knowledge zählen: die Abfrage oben, aufgeteilt nach Publikationsstatus und Sprache.
- Abdeckung prüfen: die 20 häufigsten Anliegen der letzten sechs Monate gegen die veröffentlichten Artikel halten.
- Case-Typen zählen: wie viele unterschiedliche Kombinationen aus Typ und Grund es gibt und wie groß der größte Sammelposten ist.
- Validierungsregeln durchgehen: je aktive Regel auf dem Case die Frage, woher der Agent diesen Wert nehmen soll.
- Eskalationsziele benennen: welche Queue für welches Thema, mit wie vielen Mitgliedern und mit welcher Reaktionszeit.
Für Schritt drei reicht diese Abfrage:
SELECT Type, Reason, COUNT(Id)
FROM Case
WHERE IsClosed = true AND ClosedDate = LAST_N_MONTHS:6
GROUP BY Type, Reason
ORDER BY COUNT(Id) DESCWenn eine dieser fünf Prüfungen daran scheitert, dass niemand im Haus weiß, wo die Werte herkommen oder wer für eine Queue zuständig ist, dann ist genau das der Befund. Er ist wertvoller als jedes Ergebnis, das Sie sich wünschen.
Diese Vorarbeit rechnet sich auch dann, wenn Agentforce nicht kommt
Das ist das ehrliche Argument, und es ist auch das bequemste. Kein einziger Punkt auf dieser Liste ist eine Investition in KI. Jeder zahlt heute auf den Service ein:
- Veröffentlichte, auffindbare Knowledge-Artikel verkürzen die Bearbeitungszeit Ihres Teams, bevor irgendein Agent sie liest.
- Validierungsregeln, deren Zweck jemand erklären kann, sind der Unterschied zwischen Datenqualität und Verwaltungsaufwand.
- Weniger Record Types senken den Pflegeaufwand bei jeder künftigen Änderung.
- Definierte Eskalationswege sind das, was Ihre Kunden ohnehin erwarten, mit oder ohne KI.
Deshalb ist die Reihenfolge belastbar: erst der Zustand, dann die Entscheidung. Fällt die Entscheidung am Ende gegen Agentforce, haben Sie trotzdem eine bessere Service Cloud und ein paar Zehntausend Euro Lizenzkosten gespart. Fällt sie dafür, starten Sie mit einem Agenten, der etwas zu sagen hat und weiß, wohin er abgeben kann.
Häufige Fragen
Brauchen wir Data Cloud für Agentforce?
Für das Grounding auf Knowledge über eine Agentforce Data Library setzt Salesforce ein aktiviertes Data 360, früher Data Cloud, voraus. Der Betrieb der Data Library verbraucht Data-360-Credits. Rechnen Sie das in die Kostenschätzung ein, bevor Sie einen Piloten zusagen.
Reichen interne Knowledge-Artikel, oder müssen sie öffentlich sein?
Interne Artikel reichen, solange sie veröffentlicht sind. Entwürfe zählen nicht. Kritisch wird es erst, wenn Sie den Agenten zusätzlich auf öffentliche Artikel beschränken: Dann zählt nur noch, was im Public-Knowledge-Base-Kanal sichtbar ist, und ein Großteil Ihres Wissens fällt aus dem Index.
Wie viele Knowledge-Artikel braucht ein Pilot?
Es gibt keine Mindestzahl. Entscheidend ist die Abdeckung im gewählten Themenausschnitt. Nehmen Sie die 20 häufigsten Anliegen der letzten sechs Monate und prüfen Sie, zu wie vielen es einen veröffentlichten Artikel gibt. Unter der Hälfte ist ein Pilot verfrüht.
Können wir die Eskalation im Agentforce Builder testen?
Nein. Im Builder existiert keine Messaging Session, und ohne Messaging Session kann der Agent nicht eskalieren. Testen Sie jeden Eskalationspfad auf dem Kanal, auf dem er später produktiv läuft.
Wie lange dauert diese Vorarbeit realistisch?
Die Erhebung dauert einen Vormittag. Die Arbeit danach hängt am Befund: Knowledge-Artikel überarbeiten ist Redaktionsarbeit über Wochen, Validierungsregeln und Eskalationspfade sind meist wenige Tage. Record Types zusammenzulegen ist der einzige Punkt, den Sie für einen Piloten aufschieben sollten.
Wenn Sie diesen Zustand nicht selbst erheben wollen: Die Agentforce-for-Service Readiness prüft genau diese Punkte in Ihrer Org – Knowledge, Case-Daten, Record Types, Eskalationswege und den Zuschnitt des Agent-Benutzers – und liefert eine Liste mit Aufwand je Punkt sowie eine Empfehlung für den ersten Piloten. Ab 6.000 Euro netto zum Festpreis. Beauftragen Sie innerhalb von drei Monaten eine Umsetzung ab 20 Tagen, wird die Gebühr voll angerechnet. Davor steht immer ein kostenloses Erstgespräch von 30 Minuten.
