Der Headless-CRM-Wandel: Warum Expertise zum wertvollsten Layer wird
Salesforce, HubSpot und Microsoft trennen zunehmend die kontrollierten Geschäftssysteme von den Oberflächen, über die sie bedient werden. Während Agents mehr Implementierungsarbeit übernehmen, gewinnen Kontext, Architektur, Governance und Domänenexpertise an Wert.
Frag die KI, wie das für dich gilt
CRM trennt sich zunehmend von seiner Benutzeroberfläche.
Über weite Teile der Software-as-a-Service-Ära war eine CRM-Plattform gleichzeitig das zugrunde liegende Geschäftssystem und der zentrale Ort, an dem Menschen damit arbeiteten. Die Plattform speicherte Kundendaten, Berechtigungen, Workflows und Geschäftslogik. Ihre Masken, Formulare, Dashboards und Builder waren die Oberfläche, über die Arbeit erledigt wurde.
Diese Kopplung beginnt sich zu lösen.
Salesforce nennt diese Entwicklung Headless 360. HubSpot und Microsoft verwenden andere Begriffe, bewegen sich architektonisch aber in eine ähnliche Richtung: Kontrollierte Geschäftsfunktionen werden zunehmend über APIs, Model Context Protocol Server, Coding Agents und individuell entwickelte Anwendungen zugänglich.
Die Oberfläche des Plattformanbieters ist damit nicht mehr der einzige Ausgangspunkt für Arbeit. Ein Agent, eine Anwendung oder ein spezialisierter Workflow kann mit denselben Daten und derselben Geschäftslogik arbeiten und dabei weiterhin die Regeln und Kontrollen des zugrunde liegenden Systems nutzen.
Das wirkt zunächst wie eine technische Veränderung. Tatsächlich verändert sich damit auch die Ökonomie des Marktes.
Wenn immer mehr Implementierung von Agents generiert oder ausgeführt werden kann, wird Implementierung weniger knapp. Der Wert verschiebt sich zu den Fragen, was gebaut werden sollte, wie die tatsächliche Systemlandschaft funktioniert, welche Guardrails gelten und wie sich überprüfen lässt, ob das Ergebnis für das Unternehmen wirklich korrekt ist.
Genau hier entsteht Raum für einen Expertise-Layer.
Inhaltsverzeichnis
- Implementierung wird weniger knapp
- Bauen wird einfacher. Zu wissen, was gebaut werden sollte, nicht.
- Drei Arten von Wissen
- Ein Beispiel aus der Marketing Cloud
- Kann ein General-Purpose-Modell nicht einfach selbst zum Experten werden?
- Die eigentliche Build-vs.-Buy-Entscheidung
- Ein Markt mit drei Layern entsteht
- Warum sich die CRM-Anbieter in diese Richtung bewegen
- Wo mape positioniert ist
- Expertise wird zu Software
- Quellen und weiterführende Links
Implementierung wird weniger knapp
Salesforce formuliert diese Verschiebung ungewöhnlich deutlich.
In The Future of the Salesforce Developer in the Agentic AI Era argumentiert Salesforce, dass Implementierung nicht länger die wichtigste Quelle für den Wert eines Entwicklers ist. KI kann erste Versionen von Apex, Lightning Web Components, Tests und Integrationsgerüsten innerhalb von Sekunden erzeugen. Salesforce beschreibt Implementierung als zunehmend schnell und günstig, während sich der Engpass in Richtung Systemdesign, Qualitätssicherung und systemübergreifendes Denken verschiebt.
Diese Unterscheidung ist besonders wichtig, weil die meisten Enterprise-CRM-Projekte keine Greenfield-Projekte sind. Sie finden in gewachsenen Umgebungen statt, die durch Jahre an Konfigurationen, Integrationen, Ausnahmen und nicht dokumentierten Entscheidungen geprägt sind. Ein KI-System kann die technische Struktur möglicherweise inspizieren. Die Gründe hinter dieser Struktur stecken jedoch oft in institutionellem Wissen, Geschäftsprozessen und vergangenen Entscheidungen statt in Code oder Metadaten.
Salesforce Headless 360 macht aus dieser These eine Architektur. Salesforce stellt zentrale Plattformfunktionen über APIs, MCP-Tools und Kommandozeilen-Schnittstellen zur Verfügung. Coding Agents können eine Organisation analysieren, Implementierung erzeugen, Tests ausführen und Änderungen über bestehende Pipelines ausrollen. Business Agents können dieselbe Plattform über externe Oberflächen nutzen. Der Browser wird zu einer von mehreren möglichen Oberflächen.
Die Rolle des Menschen verschiebt sich damit: weg davon, jeden Implementierungsschritt selbst auszuführen, hin dazu, Intention zu definieren, Ergebnisse zu bewerten und zu entscheiden, was in das größere System passt.
Die bisherige Wertschöpfungskette sah häufig ungefähr so aus:
Business-Anforderung → Spezifikation → spezialisierte Implementierung → Plattformoberfläche
Das entstehende Modell sieht zunehmend so aus:
Business-Intention → Discovery → Kundenkontext → Architektur und Guardrails → agentengestützte Implementierung → Evaluation → Ausführung
Der teure mittlere Teil wird komprimiert. Die Entscheidungen davor und danach werden wichtiger.
Bauen wird einfacher. Zu wissen, was gebaut werden sollte, nicht.
Die leistungsfähigsten General-Purpose-KI-Produkte können besser im allgemeinen Schlussfolgern sein als jede spezialisierte Domänenanwendung. Moderne Software-Builder können besser darin sein, Anwendungen zu generieren als ein spezialisiertes CRM-Produkt.
Das ist nicht der entscheidende Unterschied.
Der wichtigere Punkt ist:
Sie machen das Bauen einfacher. Ein Expertise-Layer hilft zu bestimmen, was überhaupt gebaut werden sollte.
| Fähigkeit | Was sie zunehmend gut kann | Was weiterhin geklärt werden muss |
|---|---|---|
| General-Purpose-KI | Schlussfolgern, Entwürfe, Analyse und Codegenerierung | Welcher Kontext verlässlich ist, welche Fragen entscheidend sind und wie ein fachlich korrektes Ergebnis aussieht |
| Software-Generation-Plattformen | Eine formulierte Intention oder Spezifikation in funktionierende Software übersetzen | Ob die Spezifikation auf den richtigen Daten, Regeln, Risiken und Betriebsmodellen basiert |
| CRM- und Marketing-Plattformen | Kontrollierte Daten, Berechtigungen, Workflows und transaktionale Ausführung bereitstellen | Welche Änderung das Unternehmen tatsächlich vornehmen sollte und wie sie validiert werden muss |
| Expertise-Layer | Domänenmethoden, Kundenkontext, Schutzmechanismen und Evaluation auf die Arbeit anwenden | Menschliche Freigabe und Verantwortung bei folgenreichen Entscheidungen |
Ein Modell kann schlussfolgern. Ein Builder kann eine Oberfläche erzeugen. Ein CRM kann eine Transaktion ausführen.
Keine dieser Fähigkeiten erzeugt automatisch die operative Methodik, die alles miteinander verbindet.
Drei Arten von Wissen
In der Diskussion darüber, ob ein General-Purpose-Modell selbst zum Experten werden kann, werden häufig drei unterschiedliche Arten von Wissen vermischt.
1. Öffentliches Wissen
Nehmen wir die Frage:
Wie sollte eine Abandoned-Cart-Journey grundsätzlich funktionieren?
Ein Frontier-Modell kann diese Frage sehr gut beantworten. Es kann Timing, Segmentierung, Nachrichtenabfolge, Testansätze und typische Implementierungsmuster erklären. Es kann möglicherweise auch SQL, Skripte, Konfigurationen oder Anwendungscode erzeugen, die zur Umsetzung erforderlich sind.
Öffentlich verfügbares Domänenwissen wird zunehmend reichlich vorhanden.
2. Organisationskontext
Ändern wir die Frage:
Wie funktioniert der Abandoned-Cart-Prozess in diesem Unternehmen tatsächlich?
Die Antwort kann Zugriff auf CRM-Daten, eine Marketing-Automation-Plattform, Commerce-Systeme, Consent-Daten, Dokumentation, Namenskonventionen, bestehende Automationen und frühere Kampagnenentscheidungen erfordern.
Headless-Architekturen und MCP machen immer mehr dieses Kontexts für Modelle zugänglich. Salesforce, HubSpot und Microsoft machen ihre kontrollierten Geschäftssysteme zunehmend durch Agents aufrufbar.
Das ist ein wichtiger Fortschritt. Aber auf Kontext zugreifen zu können ist nicht dasselbe wie zu wissen, welche Teile dieses Kontexts korrekt sind.
3. Expertenurteil
Die dritte Frage ist schwieriger:
Wenn wir alles zusammen betrachten, was sollte dieses Unternehmen verändern, was sollte unangetastet bleiben, was fehlt uns und was muss vor einem Go-live validiert werden?
Ein Kundensystem wird nicht automatisch zur Wahrheit, nur weil ein Agent es auslesen kann.
Felder können veraltet sein. Dokumentation kann der tatsächlichen Implementierung widersprechen. Zwei Systeme können unterschiedliche Antworten zur gleichen Kundin oder zum gleichen Kunden liefern. Eine Namenskonvention kann einen Prozess beschreiben, den das Team seit Jahren nicht mehr verwendet.
Erfahrene Praktiker rufen Kontext deshalb nicht nur ab. Sie hinterfragen ihn.
Und manchmal lautet ihre wertvollste Empfehlung:
Noch nicht bauen.
Ein Beispiel aus der Marketing Cloud
Stellen wir uns vor, ein Kunde sagt:
Baut eine Reaktivierungskampagne für Kundinnen und Kunden, die seit 180 Tagen nichts mehr gekauft haben.
Ein verbundener Agent analysiert die Umgebung und findet Datensätze oder Felder zu Kontakten, Bestellungen, letztem Kaufdatum, E-Mail-Einwilligung und Journey-Historie.
Technisch gesehen verfügt er bereits über eine Menge Kontext.
Eine erfahrene CRM- oder Marketing-Operations-Fachkraft beginnt jedoch mit anderen Fragen:
- Was genau bedeutet hier „Kunde“?
- Zählt eine Bestellung, die vollständig erstattet wurde?
- Welches System ist für die Kaufhistorie maßgeblich?
- Wird das Feld für das letzte Kaufdatum zuverlässig gepflegt?
- Wie werden Gastbestellungen abgebildet?
- Bedeutet das Consent-Feld in jedem Markt dasselbe?
- Enthält die Journey-Historie auch Service-Kommunikation oder ausschließlich Marketing-Kommunikation?
- Läuft bereits ein anderes Win-back-Programm für einen Teil dieser Zielgruppe?
- Wie häufig synchronisiert sich das Commerce-System?
- Was passiert, wenn jemand zwischen Segmentierung und Versand erneut kauft?
- Gibt es Suppression Rules außerhalb der offensichtlichen CRM-Objekte?
- Was hat das Unternehmen aus früheren Reaktivierungskampagnen gelernt?
- Welcher Antwort sollte vertraut werden, wenn Systeme einander widersprechen?
Ein leistungsfähiges Modell kann über jede einzelne dieser Fragen nachdenken.
Die schwierigere Aufgabe besteht darin sicherzustellen, dass die richtigen Fragen überhaupt gestellt werden, festzulegen, welche Evidenz akzeptabel ist, Widersprüche zu behandeln und zu definieren, was erfüllt sein muss, bevor eine Kampagne live gehen darf.
Das ist der Unterschied zwischen verfügbarem Kontext und angewandter Expertise.
Kann ein General-Purpose-Modell nicht einfach selbst zum Experten werden?
Doch – wenn ein Unternehmen das dafür notwendige System darum herum baut.
Ein ausreichend entschlossenes Team kann ein leistungsfähiges Modell mit CRM- und Marketing-Plattformen, Dokumentation, Kampagnenhistorie und weiteren Geschäftssystemen verbinden. Es kann Spezialanweisungen, Workflow-Definitionen, Freigaberegeln, deterministische Prüfungen, Evaluationskriterien und persistenten Kontext hinzufügen.
An diesem Punkt hat das Unternehmen jedoch nicht einfach nur ein Modell eingeführt.
Es hat begonnen, ein eigenes Expertise-System aufzubauen und dauerhaft zu pflegen.
Diese Einordnung ist wichtig, weil sie zu einer glaubwürdigeren Wettbewerbsposition führt. Die Wahl besteht nicht zwischen einem angeblich intelligenten Spezialprodukt und einem unintelligenten General-Purpose-Modell. General-Purpose-Modelle sind außerordentlich leistungsfähig und werden weiter besser werden.
Die eigentliche Wahl lautet:
Ein eigenes CRM- und Marketing-Operations-Expertise-System rund um General-Purpose-KI aufbauen und kontinuierlich pflegen – oder einen bestehenden Expertise-Layer nutzen.
Die eigentliche Build-vs.-Buy-Entscheidung
Software-Generation macht diese Unterscheidung noch klarer.
Bitten wir einen modernen Builder, ein Dashboard für Kundinnen und Kunden mit erhöhtem Churn-Risiko zu erstellen, kann daraus in kurzer Zeit eine beeindruckende Anwendung entstehen.
Bevor diese Anwendung wirklich nützlich ist, muss allerdings jemand festlegen:
- Was bedeutet „Churn-Risiko“ konkret?
- Welches System ist führend für die Kundenidentität?
- Welches Zeitfenster definiert Churn?
- Wie werden Erstattungen und fehlende Daten behandelt?
- Welche Kundinnen und Kunden müssen ausgeschlossen werden?
- Welche Interventionen sind angemessen?
- Welche Berechtigungen gelten?
- Wie wird Marketing Consent berücksichtigt?
- Wie wird Erfolg gemessen?
Sind all diese Entscheidungen bereits bekannt, wird Softwaregenerierung erheblich einfacher.
Aber genau darin steckt der entscheidende Punkt: Die Expertise wurde vor der Generierung der Software bereitgestellt.
Software-Builder reduzieren die Notwendigkeit zu wissen, wie man eine Anwendung baut. Sie eliminieren nicht die Notwendigkeit zu wissen, wie gute CRM- und Marketing-Operations-Arbeit aussieht.
Die Build-vs.-Buy-Frage ist deshalb nicht, ob sich die zugrunde liegende Technologie technisch nachbauen lässt. In vielen Fällen lässt sie sich nachbauen.
Die Frage ist, ob das kontinuierliche Strukturieren, Evaluieren und Pflegen von Domänenexpertise als Software eine Fähigkeit ist, die das Unternehmen selbst besitzen und betreiben möchte.
Ein Markt mit drei Layern entsteht
Die Entwicklung lässt sich als drei miteinander verbundene Layer verstehen.
1. Der System-Layer
Hier bleiben Salesforce, HubSpot, Dynamics, Braze und andere Business-Plattformen unverzichtbar.
Der System-Layer verwaltet Kundendaten, Identitäten, Berechtigungen, Business Objects, transaktionale Ausführung, Audit Trails und kontrollierte Geschäftslogik.
Headless zu werden macht diesen Layer nicht irrelevant. Es macht seine Fähigkeiten über mehr Oberflächen und Anwendungen verfügbar.
Salesforce beschreibt die Plattform als Träger von Identität, Zugriff, Fähigkeiten, Governance und angesammeltem Geschäftskontext. Microsoft positioniert Dynamics-365-MCP-Server ähnlich: als kontrollierten Zugang, über den Agents dieselben Datenmodelle, Berechtigungen, Geschäftsregeln und Audit Trails nutzen können wie andere Nutzer.
2. Der Intelligence-Layer
Dieser Layer wird von General-Purpose-Modellen und Agent-Infrastruktur bereitgestellt.
Er liefert Sprachverständnis, Schlussfolgerung, Generierung, Planung und Tool-Nutzung. Er kann natürliche Sprache in Analysen, Code, Abfragen und Aktionen übersetzen.
Die Modelle in diesem Layer werden weiter besser werden. Ein Expertise-Produkt sollte von dieser Entwicklung profitieren, statt darauf angewiesen zu sein, General-Purpose-Modelle dauerhaft im allgemeinen Schlussfolgern zu übertreffen.
Ein Modell weiß jedoch nicht automatisch, warum das Datenmodell eines Unternehmens auf eine bestimmte Weise aufgebaut wurde. Es weiß nicht von selbst, welchen Feldern vertraut werden kann, welche Ausnahmen wichtig sind, welche Freigabewege zwingend sind oder welche historischen Entscheidungen erhalten bleiben müssen.
Intelligence kann vorschlagen und ausführen. Sie braucht weiterhin Richtung.
3. Der Expertise-Layer
Der Expertise-Layer verbindet Business-Intention mit kontrollierter Ausführung.
Er stellt Fragen wie:
- Was wollen wir tatsächlich erreichen?
- Welche Fragen müssen vor einer Aktion geklärt sein?
- Welchem System oder welcher Evidenz sollten wir vertrauen?
- Wie sieht gute Arbeit in dieser Domäne aus?
- Welche Schutzmechanismen und Freigabepunkte gelten?
- Was muss vor dem Deployment validiert werden?
- Worin unterscheidet sich dieses Unternehmen von generischer Best Practice?
Dieser Layer verbindet Domänenmethodik, interpretierten Kundenkontext, geführte Workflows, Validierung und menschliche Kontrolle.
Eine API beschreibt, was ein System tun kann.
Ein Modell kann darüber nachdenken, was es tun könnte.
Der Expertise-Layer hilft zu bestimmen, was das Unternehmen tun sollte.
Warum sich die CRM-Anbieter in diese Richtung bewegen
Auf den ersten Blick könnten zwei Entwicklungen widersprüchlich wirken.
CRM-Anbieter geben Coding und Business Agents immer mehr Möglichkeiten, Implementierungsarbeit zu übernehmen. Gleichzeitig erklären sie Entwicklern und Partnern, dass Architektur, Domänenverständnis, Systemdesign und Urteilskraft wertvoller werden.
Das ist kein Widerspruch. Beides hängt direkt zusammen.
KI wird besser in der Implementierung
↓
Implementierung wird weniger knapp
↓
Zu wissen, was implementiert werden sollte, wird relativ wertvoller
↓
Expertinnen und Experten bewegen sich Richtung Architektur, Kontext und Validierung
↓
Expertise kann zunehmend in wiederholbare Workflows übersetzt werden
Der Salesforce Consulting Partners Hub formuliert das explizit. Salesforce fordert Partner dazu auf, Domänenexpertise in einen Wettbewerbsvorteil zu verwandeln, und argumentiert, dass Kundinnen und Kunden häufig nicht nur ein Datenproblem, sondern ein Kontextproblem haben. Partner, die diesen vertrauenswürdigen Kontext mitgestalten können, werden wichtiger statt weniger wichtig.
HubSpot öffnet einen ähnlichen architektonischen Raum. UI Extensions ermöglichen Entwicklern, kontextuelle Oberflächen und geführte mehrstufige Workflows auf HubSpot aufzubauen. Der Remote MCP Server ermöglicht kompatiblen KI-Tools den Lese- und Schreibzugriff auf erlaubte CRM-Daten unter Berücksichtigung bestehender Benutzerrechte.
HubSpots State of Partner AI Readiness berichtet, dass 73 % der Partner KI aktiv nutzen, 42 % den Aufbau interner KI-Fähigkeiten und Expertise priorisieren und 30 % bereits eigene Agents entwickeln. HubSpots Botschaft an Partner ist klar: Unternehmen, die ihre eigene Expertise mit KI-Fähigkeiten kombinieren, sind besonders gut positioniert.
Microsoft formuliert die Rolle von Partnern ebenso deutlich. In der Beschreibung von Dynamics 365 als agent-ready Business-Applications-Plattform beschreibt Microsoft den Wandel von Systems of Record hin zu Systems of Action. Agents übernehmen mehr Arbeit, während Menschen die Guardrails festlegen. Partner bringen Branchenwissen, Domänenexpertise und Kundenbeziehungen ein, die Plattformfähigkeiten in reale Geschäftsergebnisse übersetzen.
Die Signale der Plattformanbieter zeigen damit in dieselbe Richtung:
Plattformfähigkeiten werden leichter zugänglich. Angewandte Expertise wird wertvoller.
Wo mape positioniert ist
Genau dieser Layer ist der Bereich, für den mape entwickelt wird.
mape ist Expertise-as-a-Service für CRM und Marketing Operations. mape sitzt auf bestehenden CRM- und Marketing-Automation-Systemen auf und hilft Teams dabei, von einer geschäftlichen Situation zu einer geführten, kontextbezogenen und dokumentierten Ausführung zu gelangen.
Künstliche Intelligenz kann Teil des Motors sein, aber sie ist nicht das Produkt. Das Produkt ist die Domänenexpertise, die bestimmt, was geprüft werden muss, welche Fragen geklärt werden sollten, wie die Arbeit ablaufen soll und was vor der Fertigstellung überprüft werden muss.
Diese Unterscheidung ist auch im Wettbewerb entscheidend.
mape muss nicht behaupten, dass ein General-Purpose-Modell Salesforce nicht verstehen kann. Zunehmend kann es das sehr gut.
mape muss auch nicht behaupten, dass moderne Software-Builder keine beeindruckenden Anwendungen erzeugen können. Auch das können sie zunehmend.
Die Rolle von mape besteht darin, CRM- und Marketing-Operations-Expertise um diese Fähigkeiten herum anzuwenden: Business Discovery, direkter Systemkontext, passende Guardrails, Validierung, Dokumentation und sichtbare menschliche Verantwortung.
Die Kurzfassung lautet:
General-Purpose-KI kann verstehen und schlussfolgern. Software-Builder können generieren. CRM-Plattformen können kontrollieren und ausführen. mape hilft Teams zu bestimmen, was getan werden sollte, warum und unter welchen Bedingungen.
Ausgehend von komplexen CRM- und Marketing-Automation-Umgebungen konzentriert sich mape auf operative Arbeit, die Kampagnenteams regelmäßig verlangsamt: Segmentierung, Kampagnen-Setup, Journey-Logik, E-Mail-Erstellung, Reporting, Qualitätssicherung und Dokumentation.
Die Oberfläche kann sich verändern. Der Bedarf an Kontext, Urteilskraft und verantwortungsvoller Ausführung bleibt.
Expertise wird zu Software
Der Headless-CRM-Wandel macht Domänenexpertinnen und -experten nicht überflüssig.
Er verändert die Ökonomie ihrer Arbeit.
Solange Implementierung große Mengen spezialisierter manueller Arbeit erforderte, floss ein erheblicher Teil des Werts von Expertise direkt in die Erstellung der Implementierung. Wenn Agents mehr davon übernehmen, können Expertinnen und Experten eine Ebene höher arbeiten.
Sie können mehr Zeit darauf verwenden, das Unternehmen zu verstehen, Kontext zu hinterfragen, das richtige Betriebsmodell zu gestalten, Guardrails zu definieren, Ergebnisse zu validieren und die Methodik für zukünftige Ausführung zu verbessern.
Salesforce' VIBEPASS Research zeigt, warum diese Validierung wichtig ist. Plausiblen Code zu generieren wird zunehmend einfach, subtile Fehler zu erkennen und zu beheben bleibt deutlich schwieriger. Dasselbe Prinzip gilt für CRM und Marketing Operations: Ein technisch erfolgreicher Workflow kann fachlich trotzdem falsch sein.
Die stärksten Expertise-Organisationen werden KI deshalb nicht nur einsetzen, um einzelne Spezialistinnen und Spezialisten schneller zu machen. Sie werden professionelles Urteil in Systeme übersetzen, die gute Praxis konsistent anwendbar machen.
CRM-Anbieter stellen das kontrollierte System bereit.
Modellanbieter liefern immer leistungsfähigere Intelligence.
Software-Builder machen Implementierung erheblich einfacher.
Der verbleibende strategische Layer ist derjenige, der versteht, wie all diese Fähigkeiten auf ein konkretes Geschäftsproblem angewendet werden sollten.
Implementierung wird zur Commodity. Expertise wird zum Produkt.
Das ist die Verschiebung hinter Headless CRM.
Und genau dort ist mape positioniert.
Quellen und weiterführende Links
- The Future of the Salesforce Developer in the Agentic AI Era — Salesforce Developers
- What Salesforce Headless 360 Means for Developers — Salesforce Developers
- Salesforce Consulting Partners Hub
- Master the Agentic Development Lifecycle for Agentforce — Salesforce Developers
- VIBEPASS: Can Vibe Coders Really Pass the Vibe Check? — Salesforce AI Research
- Remote HubSpot MCP server is now generally available — HubSpot Developers
- UI extensions overview — HubSpot Developers
- State of Partner AI Readiness — HubSpot
- Microsoft Dynamics 365: An agent-ready business applications platform — Microsoft
