Der ROI entsteht nicht durch die Aktivierung eines Agenten. Er entsteht, wenn ein klar abgegrenzter Use Case besser, schneller oder günstiger bearbeitet wird als vorher. Dafür braucht es eine belastbare Ausgangslage: aktuelle Prozessdaten, eine realistische Kostenbetrachtung, klare Erfolgskriterien und die Bereitschaft, nach dem Go-live gegen die Baseline zu messen.
Was Agentforce grundsätzlich ist und welche Funktionen, Grenzen und Alternativen relevant sind, wurde bereits im Beitrag Salesforce Agentforce erklärt eingeordnet. Dieser Artikel setzt dieses Grundverständnis voraus und betrachtet die nächste Frage: Wie bewertet man, ob sich Agentforce wirtschaftlich lohnt?
Warum ROI bei Agentforce schwer greifbar ist
Der Nutzen von Agentforce liegt selten in einem einzelnen Feature. Er entsteht im Zusammenspiel aus Use Case, Datenbasis, Integration, Prozessdesign und Adoption. Ein Agent kann theoretisch Antworten vorbereiten, Leads priorisieren oder Servicefälle bearbeiten. Ob daraus ein messbarer Business Case wird, hängt davon ab, wie oft der Use Case auftritt, wie stabil er ist und wie gut er sich in bestehende Arbeitsabläufe einfügt.
Genau deshalb ist eine pauschale ROI-Aussage schwierig. Ein Agent im Kundenservice kann sehr schnell Nutzen bringen, wenn er wiederkehrende Anfragen zuverlässig vorqualifiziert oder einfache Fälle sauber deflektiert. Derselbe Agent kann kaum Wirkung zeigen, wenn die Fälle selten, komplex oder stark manuell geprägt sind. Im Vertrieb kann ein Agent Reaktionszeiten verbessern und Lead-Qualifizierung unterstützen. Wenn das Sales-Team die Vorschläge aber nicht nutzt oder die Datenbasis schlecht gepflegt ist, bleibt der Effekt begrenzt.
Agentforce ist kein reiner Technologieentscheid. Es ist eine Business-Case-Frage: Welcher konkrete Prozess soll verbessert werden, welche Kennzahl verändert sich dadurch und wie belastbar ist diese Veränderung messbar?
Werthebel nach Use Case unterscheiden
Ein guter Business Case beginnt nicht mit einer allgemeinen Automatisierungsquote. Er beginnt mit dem Werthebel des konkreten Bereichs. Im Service sind andere Kennzahlen relevant als im Sales oder in Operations.
Kundenservice
Im Kundenservice geht es häufig um Deflection-Rate, Average Handle Time, Erstlösungsquote, Eskalationsquote und Nachbearbeitungszeit. Ein Agent kann Nutzen erzeugen, wenn einfache Anfragen ohne menschliche Bearbeitung gelöst werden, wenn Mitarbeitende schneller zum richtigen Kontext kommen oder wenn Fälle besser vorbereitet eskaliert werden.
Sales
Im Sales liegt der Wert eher bei Reaktionszeit, Lead-Qualifizierung, Conversion und Pipeline-Velocity. Ein Agent kann helfen, eingehende Leads schneller zu bewerten, nächste Schritte vorzubereiten oder Account-Kontext zusammenzufassen. Der wirtschaftliche Effekt entsteht aber erst, wenn dadurch mehr relevante Gespräche stattfinden, Opportunities schneller vorankommen oder weniger Zeit in manuelle Recherche fließt.
Operations
In Operations geht es um automatisierte Zwischenschritte, Durchlaufzeit, Fehlerquote und Rückfragen. Ein Agent kann zum Beispiel Informationen aus mehreren Systemen zusammenführen, Statusänderungen vorbereiten oder Routineprüfungen unterstützen. Der ROI liegt dann nicht unbedingt in weniger Personalaufwand, sondern in kürzeren Durchlaufzeiten, weniger Rework oder stabileren Prozessen.
Mitarbeiterproduktivität
Bei Mitarbeiterproduktivität wird es besonders wichtig, sauber zu messen. Eingesparte Routinezeit klingt plausibel, wird aber häufig überschätzt. Entscheidend ist, ob die gewonnene Zeit wirklich in wertvollere Arbeit fließt oder nur als gefühlte Entlastung sichtbar wird.
Ohne Baseline kein belastbarer ROI
Der häufigste Fehler in Agentforce-Business-Cases ist eine fehlende Baseline. Wenn vor dem Go-live nicht gemessen wird, wie der Prozess heute funktioniert, lässt sich später kaum seriös sagen, ob der Agent wirklich verbessert hat.
Eine Baseline muss nicht kompliziert sein. Sie sollte aber die wichtigsten Ausgangswerte festhalten: Fallvolumen, Bearbeitungszeit, Eskalationsquote, Erstlösungsquote, Nacharbeitsaufwand, Fehlerquote, Reaktionszeit oder Conversion. Welche Kennzahlen relevant sind, hängt vom Use Case ab. Wichtig ist nur, dass sie vor dem Einsatz erhoben und später vergleichbar gemessen werden.
Für einen Service-Agenten könnte die Baseline zeigen, dass pro Monat 2.000 wiederkehrende Anfragen eingehen, die durchschnittlich sechs Minuten manuelle Bearbeitung benötigen und in 20 Prozent der Fälle eskaliert werden. Für einen Sales-Agenten könnte sie zeigen, wie lange die erste Reaktion auf neue Leads dauert, wie viele Leads qualifiziert werden und wie viel manuelle Recherche pro Opportunity anfällt.
Ohne diese Ausgangswerte bleibt der ROI eine Erzählung. Mit Baseline wird er prüfbar.
Total Cost of Ownership statt Lizenzblick
Die Kostenseite sollte nicht auf Lizenz- oder Verbrauchskosten reduziert werden. Diese Kosten sind wichtig, aber sie sind nur ein Teil des Business Case. Eine detaillierte Preisbetrachtung gehört in den Beitrag zu Salesforce Data Cloud Pricing 2026. Für die ROI-Bewertung zählt der größere Blick auf Total Cost of Ownership.
Dazu gehören Lizenz- oder Verbrauchskosten, mögliche Data-Cloud- oder Plattformkosten, Implementierung, Integration, Testing, Datenvorbereitung, laufender Betrieb, Monitoring, Governance, Change Management und Adoption. Manche dieser Kosten fallen einmalig an, andere bleiben dauerhaft. Gerade die laufenden Aufwände werden in frühen Business Cases oft unterschätzt.
Ein realistischer TCO-Blick verhindert zwei Fehler. Erstens wirkt ein Use Case nicht künstlich profitabel, nur weil Integrations- und Betriebsaufwand ausgeblendet werden. Zweitens werden gute Use Cases nicht vorschnell abgelehnt, nur weil die direkten Lizenzkosten sichtbar sind, während der operative Nutzen noch nicht sauber quantifiziert wurde.
Die Business-Case-Logik
Ein tragfähiger Agentforce-Business-Case besteht aus drei Teilen: Nutzen, Kosten und Zeit. Der Nutzen beschreibt, welche Kennzahl sich verbessern soll und welchen wirtschaftlichen Effekt das hat. Die Kosten beschreiben, welche Aufwände für Aufbau und Betrieb entstehen. Der Zeithorizont zeigt, wann sich die Investition voraussichtlich amortisiert.
Wichtig ist, nicht nur ein Szenario zu rechnen. Ein konservatives Szenario zeigt, was passiert, wenn Adoption langsamer ist, Deflection niedriger ausfällt oder mehr menschliche Kontrolle nötig bleibt. Ein optimistisches Szenario zeigt, welches Potenzial entsteht, wenn der Use Case gut angenommen wird und die Datenbasis stabil ist. Dazwischen liegt ein realistischer Zielwert, gegen den nach 60 bis 90 Tagen gemessen werden kann.
Besonders hilfreich ist eine Sensitivitätsbetrachtung: Was passiert, wenn nur 30 Prozent der Nutzer den Agenten verwenden statt 60 Prozent? Was passiert, wenn die Bearbeitungszeit nur um 10 Prozent sinkt statt um 25 Prozent? Was passiert, wenn zusätzlicher Monitoring-Aufwand entsteht? Diese Fragen machen den Business Case robuster, weil sie nicht nur den besten Fall betrachten.
Ein DACH-Beispiel für einen Service-Use-Case
Ein mittelständisches Unternehmen im DACH-Raum möchte Agentforce für wiederkehrende Serviceanfragen einsetzen. Es geht nicht um komplexe Sonderfälle, sondern um Statusanfragen, Standardinformationen und einfache Vorqualifizierung.
Vor dem Go-live misst das Team die Baseline: 1.500 relevante Anfragen pro Monat, durchschnittlich fünf Minuten manuelle Bearbeitung, 15 Prozent Eskalationen und eine hohe Wiederholungsquote ähnlicher Fragen.
Der Business Case nimmt konservativ an, dass der Agent nach der Einführungsphase 30 Prozent dieser Fälle vollständig deflektiert und bei weiteren 20 Prozent die manuelle Bearbeitung um zwei Minuten reduziert. Gleichzeitig werden Implementierung, Integration, interne Tests, Training, Monitoring und laufende Anpassung als Kostenblock berücksichtigt. Lizenz- und Verbrauchskosten werden nicht isoliert betrachtet, sondern als Teil des TCO.
Die Rechnung ist nüchtern. Im ersten Monat ist kein positiver ROI zu erwarten, weil Setup, Datenprüfung und Adoption Zeit brauchen. Nach 60 bis 90 Tagen lässt sich aber prüfen, ob die Deflection, Bearbeitungszeit und Eskalationsquote in die richtige Richtung gehen. Wenn der Agent nur wenige Fälle tatsächlich entlastet oder das Team weiterhin alles manuell kontrolliert, wird der Business Case angepasst oder der Use Case enger geschnitten. Wenn die Baseline klar übertroffen wird, kann das Unternehmen entscheiden, ob der nächste Service-Use-Case auf derselben Grundlage aufgebaut wird.
Der Punkt ist nicht, eine Wunderzahl zu versprechen. Der Punkt ist, die Investition an messbare Prozessverbesserungen zu koppeln.
Was den ROI vorab gefährdet
Drei Faktoren gefährden Agentforce-ROI besonders häufig: schwache Datenbasis, unklare Integration und geringe Adoption.
Ohne belastbare Datenbasis kann ein Agent kaum zuverlässig arbeiten. Wenn Kundendaten, Knowledge-Artikel oder Prozessinformationen unvollständig oder widersprüchlich sind, sinkt der Nutzen schnell. Wie Kundendaten für Agentforce aktiviert werden können, wurde im Beitrag Salesforce Data Cloud und KI behandelt.
Auch Integration beeinflusst den ROI. Ein Agent, der ständig auf manuelle Zwischenschritte angewiesen ist, spart weniger Zeit als erwartet. Gleichzeitig kann zu viel Integration den TCO erhöhen. Der Business Case muss deshalb prüfen, welche Systeme für den ersten Use Case wirklich notwendig sind.
Adoption ist der dritte Faktor. Wenn Teams dem Agenten nicht vertrauen, ihn nicht in ihre Abläufe integrieren oder seine Ergebnisse doppelt prüfen, bleibt der Nutzen niedrig. Adoption ist nicht nur Kommunikation. Sie hängt davon ab, ob der Agent reale Arbeit erleichtert und ob Mitarbeitende verstehen, wann sie ihm vertrauen können.
Häufige Fehler in Agentforce-Business-Cases
Viele Business Cases wirken auf dem Papier besser, als sie im Betrieb werden. Ein häufiger Grund sind Vanity-Metriken. Die Anzahl der Agenten, generierten Antworten oder automatisierten Interaktionen sagt wenig aus, wenn nicht klar ist, ob dadurch Bearbeitungszeit, Qualität, Conversion oder Durchlaufzeit verbessert wurden.
Ein zweiter Fehler ist die fehlende Baseline. Ohne Ausgangswert wird jede Verbesserung schwer belegbar. Ein dritter Fehler ist die Hochrechnung eines erfolgreichen Piloten auf den Gesamtbetrieb. Ein Pilot läuft oft mit enger Betreuung, motivierten Nutzern und ausgewählten Fällen. Der produktive Betrieb ist breiter, heterogener und weniger kontrolliert.
Auch Anbieter-Customer-Stories sollten nicht als eigene Erwartung übernommen werden. Sie können zeigen, was möglich ist, aber sie ersetzen keine eigene Rechnung. Entscheidend ist, ob der eigene Use Case, die eigene Datenbasis und die eigene Organisation vergleichbare Voraussetzungen haben.
Pragmatischer Einstieg
Der beste Einstieg ist ein kleiner, messbarer Use Case. Nicht der größte Prozess, nicht der politisch sichtbarste Bereich und nicht der Use Case mit den meisten hypothetischen Einsparungen. Besser ist ein Prozess mit hohem Volumen, klaren Regeln, vorhandenen Daten und messbarer Baseline.
Vor dem Go-live sollte festgelegt werden, welche Kennzahlen verbessert werden sollen und ab wann der Use Case als erfolgreich gilt. Nach 60 bis 90 Tagen sollte gegen diese Baseline gemessen werden. Dabei geht es nicht darum, den Agenten sofort als Erfolg oder Misserfolg zu bewerten. Es geht darum, zu erkennen, welche Annahmen stimmen und welche angepasst werden müssen.
Ein guter erster Agentforce-Business-Case ist deshalb weniger ein großer Forecast als ein kontrolliertes Lernmodell. Er zeigt, ob das Unternehmen Use Cases sauber auswählt, Nutzen messbar macht und die Kosten im Blick behält.
Die eigentliche Lehre für den Agentforce-ROI
Agentforce kann messbaren Wert erzeugen, aber nicht durch Aktivierung allein. Der ROI entsteht erst dort, wo ein konkreter Use Case mit sauberer Baseline, realistischen Kosten und klarer Adoption verbunden wird.
Für Entscheider bedeutet das: Nicht die Feature-Liste sollte die Investition treiben, sondern die Frage, welcher Prozess messbar besser wird. Welche Kennzahl verändert sich? Welche Kosten entstehen wirklich? Welche Annahmen sind konservativ genug? Und wann wird gegen die Baseline geprüft?