Salesforce Data Cloud, heute Data 360, wird 2026 in vielen Customer-360- und Agentforce-Initiativen neu bewertet. Gleichzeitig ist die Budgetierung anspruchsvoller geworden. Unternehmen müssen heute nicht mehr nur klassische User-Lizenzen einordnen, sondern auch Flex Credits, profilbasierte Modelle, Agentforce-Nutzung, Implementierungsaufwand und laufenden Betrieb. Genau deshalb greifen ältere Preisvergleiche oft zu kurz. Wer 2026 realistisch budgetieren will, muss Pricing nicht als einzelne Lizenzzahl verstehen, sondern als Zusammenspiel aus Nutzung, Architektur und Betriebsmodell.
Zusätzliche Unschärfe entsteht durch die Umbenennung von Data Cloud zu Data 360. Wer noch mit älteren Artikeln, Angebotslogiken oder internen Vergleichswerten arbeitet, spricht oft nicht mehr über dieselbe Struktur wie in aktuellen Vertriebs- und Architekturgesprächen. Für Budgetdiskussionen ist das relevant, weil sich nicht nur der Name geändert hat, sondern auch die Art, wie Unternehmen über Verbrauch, Speicherung und Zusatzfunktionen nachdenken müssen.
Dieser Beitrag soll keinen Hochglanz-Business-Case liefern. Er soll ein realistischer Rahmen für österreichische Unternehmen sein, die ein Data-360-, Customer-360- oder Agentforce-Vorhaben sauber budgetieren wollen.
Warum Data 360 beim Pricing trotzdem unübersichtlich bleibt
Data 360 wirkt auf den ersten Blick klarer als frühere Data-Cloud-Modelle. Trotzdem bleibt Pricing erklärungsbedürftig, weil mehrere Logiken gleichzeitig greifen. Nicht jede Kostenposition entsteht dort, wo Teams sie am Anfang vermuten. Das Missverständnis beginnt oft schon bei der Annahme, dass vor allem das Einspielen von Daten teuer sei. In der Praxis entsteht der eigentliche Hebel meist erst dann, wenn Daten im Betrieb verarbeitet, vereinheitlicht, segmentiert, abgefragt oder in agentischen Prozessen genutzt werden.
Für Budgetgespräche ist deshalb weniger entscheidend, wie günstig die Plattform im Einstieg wirkt. Wichtiger ist, welche Nutzung später tatsächlich entsteht. Genau dort kippen viele Kalkulationen.
Die wichtigsten Kostenblöcke sollte man früh getrennt betrachten:
- aktive Nutzung: etwa Datenverarbeitung, Queries, Segmentierung, Scoring oder Agentforce-Verbrauch
- gespeichertes Volumen: also Storage und dauerhaft gehaltene Datenbestände
- Zusatzfunktionen: etwa Identity Resolution, erweiterte KI-Funktionen oder agentennahe Features
Wer diese drei Ebenen in der Kalkulation vermischt, bekommt zwar schnell eine Gesamtzahl, aber selten ein belastbares Budgetmodell.
Was sich gegenüber älteren Data-Cloud-Artikeln geändert hat
Viele ältere Beiträge erklären Data Cloud noch über Unified Profiles, Activations und mehrere parallele Zähler. Das ist für Bestandskunden nicht automatisch falsch, für neue Budgetgespräche aber oft zu grob. Heute wird das Modell stärker als Zusammenspiel aus Credits, Storage, Profilen und Add-ons verstanden. Für Unternehmen heißt das vor allem: Nicht jedes Setup sollte nach derselben Logik kalkuliert werden.
Der praktische Unterschied liegt weniger in der Theorie als in der Frage, welches Modell zum eigenen Vorhaben passt. Ein profilbasiertes Setup kann sinnvoll sein, wenn das gesamte Projekt stark um einheitliche Kundenprofile gebaut ist. Ein stärker verbrauchsorientiertes Modell passt oft besser, wenn Nutzungsmuster schwanken, mehrere Use Cases parallel laufen oder AI-Workloads erst im Aufbau sind.
Warum Agentforce ein eigener Kostenblock ist
Agentforce sollte man 2026 nicht einfach als kleinen KI-Zuschlag auf Salesforce behandeln. Dafür ist das Modell zu eigenständig. In vielen frühen Gesprächen läuft Agentforce gedanklich unter einem allgemeinen AI-Budget mit. Genau das führt später oft zu Überraschungen.
Denn ein Agent wird nicht einfach freigeschaltet und läuft dann unbegrenzt. Stattdessen greifen mehrere Nutzungslogiken ineinander. Je nach Setup spielen Conversations, Actions, zusätzliche Datenzugriffe und weitere Plattformverbräuche zusammen. Dazu kommt ein entscheidender Punkt: Sobald Agentforce auf Data-360-Kontexte zugreift, also etwa auf vereinheitlichte Kundenprofile, Kaufhistorien oder angereicherte Datensichten, wirkt sich das nicht nur auf den Agenten selbst aus, sondern auch auf die zugrunde liegende Datennutzung.
Praktisch heißt das: Der Agent ist kein isolierter Kostenpunkt. Er hängt direkt an der Daten- und Integrationslogik. Genau deshalb ist Agentforce nicht nur ein Funktionsthema, sondern auch ein Budget- und Architekturthema.
Typische Budgetkorridore, die wir in DACH-Projekten sehen
Obwohl es heute mehr öffentliche Preisindikationen gibt als noch vor einiger Zeit, hängt der tatsächliche Vertragspreis weiterhin stark von Volumen, Laufzeit, Bundling und Verhandlung ab. Die folgenden Größenordnungen sind deshalb keine offiziellen Listenpreise, sondern Orientierungswerte aus typischen Projektkonstellationen.
Im Mittelstand mit rund 50 Sales-Usern, einer überschaubaren Data-360-Einführung und einem ersten Agentforce-Use-Case im Service sehen wir häufig jährliche Lizenz- und Plattformkosten im Korridor von etwa 120.000 bis 180.000 Euro. Sobald Marketing-Komponenten, zusätzliche Integrationen oder komplexere Datenanforderungen dazukommen, verschiebt sich dieser Rahmen schnell nach oben.
Im Enterprise-Kontext wird das Bild deutlich breiter. Wenn Service Cloud, größere Datenvolumina, Customer-360-Anforderungen, Contact-Center-Szenarien und ein Integration Layer mit MuleSoft zusammenlaufen, bewegen sich Plattform- und Lizenzkosten schnell in einem Bereich von mehreren hunderttausend Euro pro Jahr. Die größere Herausforderung ist dann aber oft nicht die Einstiegssumme, sondern die Frage, ob die zugrunde liegende Nutzungsannahme realistisch war.
Was in vielen Budgetplänen zu spät auftaucht
In vielen Salesforce-Projekten ist die Lizenz nicht das eigentliche Problem. Das eigentliche Problem ist, dass rund um die Lizenz mehrere Kostenblöcke mitlaufen, die am Anfang nur unvollständig berücksichtigt werden.
Besonders häufig werden diese Punkte zu spät sauber bewertet:
- Implementierung: Datenmodellierung, Mapping, Quellanschlüsse, Testing und Architekturentscheidungen
- Datenqualität: Dubletten, inkonsistente Formate und fehlende Pflichtfelder werden schnell zum eigenen Projekt
- Adoption und Training: ein technisch funktionierender Agent erzeugt noch keinen operativen Nutzen
- laufender Betrieb: Monitoring, Releases, Governance, Regressionstests und Weiterentwicklung
Gerade diese Kosten machen später oft den Unterschied zwischen einem Projekt, das im Kick-off plausibel wirkt, und einem Setup, das wirtschaftlich wirklich tragfähig ist.
Warum der Dreijahresblick ehrlicher ist als der Jahrespreis
Salesforce wird in Budgetgesprächen noch erstaunlich oft wie ein klassischer Jahreskauf betrachtet: Vertrag unterschreiben, Projekt starten, Budget abhaken. Für Data 360 und Agentforce ist das fast immer zu kurz gedacht.
Sinnvoller ist ein Dreijahresblick. Dann wird sichtbar, dass Jahr eins typischerweise von Setup, Implementierung und organisatorischem Umbau geprägt ist. Jahr zwei verschiebt sich stärker in Richtung Stabilisierung, Nutzungsmessung und erste Skalierung. Jahr drei ist häufig der Punkt, an dem echter Nutzen sichtbar wird oder nachgeschärft werden muss, weil die ursprünglichen Annahmen zu grob waren.
Aus Projektsicht ist genau das der realistischere TCO-Rahmen: nicht nur Lizenz plus Implementierung, sondern Lizenz, Nutzung, Betrieb, Weiterentwicklung und Adoption über mehrere Jahre. In vielen Fällen ist dieser Blick deutlich ehrlicher als jede Diskussion über den isolierten Year-1-Preis.
Wann sich die Investition wirtschaftlich rechnen kann
Die gute Nachricht ist: Ein sauber aufgesetztes Data-360- oder Agentforce-Vorhaben kann wirtschaftlich sehr sinnvoll sein. Aber der Nutzen entsteht selten aus dem Produktnamen selbst. Er entsteht dort, wo konkrete Prozesse messbar besser werden.
Im Service ist das meist schnell nachvollziehbar. Wenn Standardanfragen schneller gelöst, besser vorqualifiziert oder teilweise automatisiert werden, sinken Bearbeitungszeiten und Übergaben. Im Vertrieb kann ein konsistenteres Kundenbild helfen, Angebote schneller zu erstellen, Chancen sauberer zu priorisieren und Cross-Sell-Potenziale gezielter zu identifizieren. Im Marketing entsteht Wert eher durch bessere Segmentierung, sauberere Aktivierung und weniger Streuverlust.
Wirtschaftlich belastbar wird der Business Case aber erst, wenn diese Effekte an konkrete Volumina und Prozesskosten gebunden werden. Genau deshalb wirken viele frühe ROI-Rechnungen zu optimistisch: Sie rechnen mit der Plattform, aber noch nicht mit dem echten Verhalten im Betrieb.
Was bei Verhandlungen oft unterschätzt wird
Es gibt inzwischen mehr öffentliche Preissignale als früher. Gleichzeitig bleibt Salesforce eine Plattform, bei der Vertragslogik, Laufzeit und Bundling erheblichen Einfluss auf die reale Kostenstruktur haben. Wer verhandelt, sollte deshalb nicht nur Produktnamen vergleichen, sondern die eigene Nutzungslogik sauber kennen.
Bei Data 360 ist vor allem relevant, ob das Unternehmen eher ein profilgetriebenes Setup mit planbarer Kundenbasis braucht oder ob ein verbrauchsorientiertes Modell besser zur erwarteten Nutzung passt. Bei Agentforce ist entscheidend, ob Conversations, User-Lizenzen oder actionbasierte Nutzung das ehrlichere Modell abbilden. Und auf Gesamtarchitektur-Ebene macht es einen erheblichen Unterschied, ob Sales Cloud, Service Cloud, Data 360, Agentforce und Integration gemeinsam betrachtet werden oder nacheinander eingekauft werden.
Je klarer diese Logik vor dem Gespräch ist, desto sauberer wird die Verhandlung. Der größte Fehler ist selten ein schlechter Preis. Der größere Fehler ist ein Vertrag, der nicht zum späteren Nutzungsverhalten passt.
Was wir unseren Kunden meistens empfehlen
Unsere Empfehlung ist selten spektakulär. Sie beginnt fast immer mit einem klar abgegrenzten Use Case statt mit einer abstrakten Plattformvision. Erst wenn sichtbar ist, welche Daten tatsächlich gebraucht werden, wie hoch die operative Nutzung ist und welcher Prozess wirtschaftlich verbessert werden soll, wird Pricing belastbar.
Danach geht es um Messen statt Schätzen. Data 360 und Agentforce sind stark genug, um in vielen Szenarien echten Mehrwert zu liefern. Genau deshalb sollte Nutzung nicht nur grob geplant, sondern im Betrieb früh beobachtet werden. Wer diese Transparenz von Anfang an aufbaut, plant sauberer und skaliert kontrollierter.
Das führt meist zu einer pragmatischen Reihenfolge: erst ein klarer Use Case, dann echte Nutzungsdaten, danach datenbasierte Skalierung. Nicht um das Projekt kleiner zu rechnen, sondern um die Investition in eine Größenordnung zu bringen, die zum Unternehmen passt.
FAQ
Hat Salesforce Data Cloud 2026 einfach nur umbenannt oder auch die Preislogik geändert?
Für viele Unternehmen spielt beides eine Rolle. Der Namenswechsel zu Data 360 verändert zwar nicht automatisch jeden bestehenden Vertrag, aber die aktuelle Produkt- und Gesprächslogik ist heute klarer auf Credits, Profile, Zusatzfunktionen und operative Nutzung ausgerichtet. Wer mit alten Vergleichswerten arbeitet, vergleicht daher oft nicht mehr sauber.
Kann man Agentforce ohne Data 360 planen?
Für frühe Diskussionen ja, für viele produktive Szenarien aber nur eingeschränkt. Der eigentliche Mehrwert von Agentforce entsteht häufig erst dann, wenn Agenten auf konsolidierte, vertrauenswürdige und gut kontextualisierte Daten zugreifen können.
Was ist 2026 der häufigste Kalkulationsfehler?
Nicht ein zu hoher Listenpreis, sondern eine zu grobe Nutzungsannahme. Teams unterschätzen oft, wie stark sich Data-Nutzung, Agent-Nutzung, Implementierung, Datenqualität und laufender Betrieb gegenseitig beeinflussen.
Fazit
Wer 2026 über Salesforce Data Cloud, heute Data 360, spricht, sollte nicht mehr nur auf eine Lizenzzahl schauen. Die relevante Frage ist, wie Credits, Profile, Agentforce-Nutzung, Datenqualität, Implementierung und Betrieb zusammenwirken. Genau dort entscheidet sich, ob ein Budget belastbar ist oder nur auf dem Papier plausibel wirkt.
Für Unternehmen im DACH-Raum ist das keine rein technische Detailfrage. Es ist eine Architektur- und Investitionsfrage. Je früher Pricing, Nutzung und Betriebsmodell gemeinsam gedacht werden, desto realistischer wird die Entscheidung. Und genau dort liegt meist der Unterschied zwischen einem Projekt, das im Kick-off gut aussieht, und einem Setup, das in der Praxis wirklich trägt.