Deutsch

MAP- und CRM-Architektur ohne Flickwerk: Ein MOps-Rebuild-Playbook

Sie haben den Feld-Manager geöffnet und 247 benutzerdefinierte Felder gezählt. Die Hälfte gehört Leuten, die 2023 gegangen sind. Der Lead-zu-Contact-Sync ist kaputt, seit der letzte Admin ihn in Q2 „repariert" hat. Zwei der Picklists haben Freitext-Werte, die nicht existieren sollten. Die Lifecycle-Phase wird von Marketo und Salesforce geschrieben, also flattern 14 % der Datensätze in jedem Sync-Zyklus zwischen MQL und Lead hin und her.

Willkommen in MOps.

Wenn Sie diesen Stack gerade geerbt haben oder ihn seit zwei Jahren anstarren und sich versprechen, ihn „nach der nächsten Kampagne" aufzuräumen, ist das das Playbook. Es ist das, das mir vor drei Jobs jemand hätte in die Hand drücken sollen. Das Ziel ist kein hübsches Diagramm. Das Ziel ist eine verlässliche Datenquelle pro Datenpunkt, ein Owner pro Feld und eine Integration, die Sie nicht um 3 Uhr morgens aufweckt.

MAP zu CRM, der Datenfluss: Der eigentliche Vertrag

Die meisten Teams behandeln die MAP-zu-CRM-Integration wie eine Blackbox. Ist sie nicht. Sie ist ein Vertrag, und wenn niemand den Vertrag aufgeschrieben hat, haben Sie Flickwerk.

Der Vertrag hat vier Teile. Wenn Sie diese falsch machen, zählt nichts anderes mehr.

Lead vs. Contact: was übernommen wird, was stirbt

Wenn ein Lead in Salesforce (oder wie auch immer Ihr CRM es nennt) zu einem Contact konvertiert, verlieren Sie Daten, es sei denn, Sie haben sie explizit zugeordnet. Standardverhalten in den meisten CRMs:

  • Standard-Lead-Felder mit passenden Contact-Feldern: werden übernommen
  • Benutzerdefinierte Lead-Felder ohne passendes Contact-Feld: verschwinden
  • Aktivitätshistorie: meist erhalten, manchmal verwaist
  • MAP-seitige Scoring-Felder: hängt ganz davon ab, ob Ihre MAP nur auf das Lead-Objekt schreibt oder auf beide

Das schmutzige Geheimnis ist, dass 80 % der MOps-Teams demografische und verhaltensbezogene Scores nur auf das Lead-Objekt schreiben und dann überrascht tun, wenn ein SDR einen Lead konvertiert und der Score verschwindet. Wenn Ihre MAP Marketo oder Pardot ist, sollten Sie Scoring-Felder auf Lead und Contact schreiben, ODER Leads bei der Erstellung in Contacts konvertieren (das „alles Contacts, keine Leads"-Modell, das HubSpot standardmäßig nutzt).

Wählen Sie eines. Dokumentieren Sie es. Stoppen Sie die Blutung.

Lifecycle-Phase: MAP schreibt, CRM liest. Nie beide.

Das ist die wichtigste Regel im ganzen Playbook. Wenn beide Systeme in die Lifecycle-Phase schreiben können, werden Sie Race Conditions haben. Sie werden Datensätze haben, die flattern. Sie werden einen SDR haben, der einen Deal auf einem Contact abschließt, den die MAP gerade zurück auf MQL degradiert hat, wegen eines Abmelde-Webhooks, der drei Minuten nach dem Closed-Won-Update feuerte.

Wählen Sie einen Schreiber. Die MAP ist meist korrekt, weil sie die Verhaltenssignale zuerst sieht. Das CRM liest die Lifecycle-Phase; es kämpft nicht darum. Wenn der Vertrieb überschreiben muss (z. B. jemanden manuell als SAL markieren), bauen Sie ein separates Feld (sales_stage_override__c) und lassen eine Automatisierung in der MAP diese Überschreibung respektieren. Lassen Sie nicht zwei Systeme über dieselbe Spalte streiten.

Sync-Timing: Echtzeit ist nicht immer besser

Der Standardimpuls ist „mach es Echtzeit". Das ist etwa die Hälfte der Zeit falsch.

Echtzeit-Syncs ergeben Sinn für:

  • Formular-Ausfüllungen (der Lead muss im CRM landen, bevor die SDR-Queue aktualisiert wird)
  • Lifecycle-Phasen-Übergänge, die das Routing treiben
  • Closed-Won-Status (Umsatzattribution kann nicht warten)

Batch-Syncs (15 Min., stündlich, nächtlich) ergeben Sinn für:

  • Massen-Score-Neuberechnungen
  • Listen-Mitgliedschafts-Wechsel
  • Aktivitätshistorie-Nachfüllungen
  • Alles, was mehr als 1.000 Datensatz-Updates pro Stunde feuert

Warum zählt das? Weil „alle 10 Minuten" die schlechtestmögliche Einstellung für den Scoring-Sync ist. Sie ist langsam genug, dass SDRs ihr nicht trauen können, schnell genug, um Ihre API-Limits während eines Kampagnen-Versands zu sprengen, und gerade häufig genug, um Race Conditions unsichtbar zu machen, bis Ihre monatliche Abstimmungsabfrage sie erwischt.

Wenn Sie sich nur eines merken: Echtzeit für die Übergabe, Batch für die Hygiene.

Die MQL-Übergabe: ein Feld, ein Owner, eine Definition

Halt. Öffnen Sie Ihr Salesforce. Suchen Sie nach jedem Feld mit „MQL" im Namen. Ich wette mit Ihnen um einen Kaffee, dass Sie mindestens drei haben:

  • MQL_Date__c (gesetzt von Marketo)
  • Marketing_Qualified__c (gesetzt von einer Workflow-Regel aus 2022)
  • Lifecycle_Stage = „MQL" (gesetzt von HubSpot)

Wählen Sie eines. Löschen Sie die anderen zwei. Die MQL-Übergabe ist ein Feld, ein Owner (MOps), eine Definition (aufgeschrieben in einem Confluence-Dokument, das ein Datum trägt). Wenn der Vertrieb dem Feld nicht traut, ist das ein Definitionsproblem, kein Feldproblem. Ein viertes Feld hinzuzufügen löst nie ein Definitionsproblem.

Das Problem des Feld-Wildwuchses

Feld-Wildwuchs ist, wie MAP+CRM-Stacks sterben. Kein einzelner dramatischer Ausfall. Eine langsame Anhäufung von Feldern, die niemand verantwortet, genutzt von einem Bericht, den niemand öffnet, gesetzt von einem Workflow, den niemand dokumentiert hat.

Wie Sie zu 247 benutzerdefinierten Feldern kamen

Jedes Feld hat eine Entstehungsgeschichte. Ungefähr:

  • 30 % sind echt, genutzt, verantwortet. Die sind in Ordnung.
  • 25 % wurden 2022 für eine Kampagne erstellt, werden immer noch beschrieben und von nichts gelesen.
  • 20 % wurden von einer Vertriebsführungskraft erstellt, die gegangen ist, einem Dashboard zugeordnet, das eingestellt wurde, aber das Feld ist immer noch auf jedem Seitenlayout.
  • 15 % sind Dubletten mit leicht unterschiedlichen Namen (Industry__c, industry_v2__c, Account_Industry__c).
  • 10 % sind Integrations-„Geisterfelder", die automatisch von einer Integration erstellt wurden, die vor 18 Monaten getrennt wurde, aber das Feld blieb.

Niemand löscht Felder, weil sich Löschungen riskant anfühlen. Genau deshalb brauchen Sie einen Prozess.

Das 90-Tage-Feld-Audit-Framework

Führen Sie das jedes Quartal durch. Blocken Sie vier Stunden an einem Freitag. Es ist die hebelstärkste Aufräumarbeit in MOps.

Schritt 1: Ziehen Sie einen Nutzungsbericht. Für jedes benutzerdefinierte Feld zählen Sie:

  • Wie viele Datensätze einen Nicht-Null-Wert haben (letzte 90 Tage an Schreibvorgängen)
  • Wie viele Berichte das Feld referenzieren
  • Wie viele Workflows/Automatisierungen das Feld referenzieren
  • Wie viele Integrationen darauf schreiben

Wenn alle vier null sind, ist das Feld tot. Markieren Sie es.

Schritt 2: Finden Sie den Owner. Jedes Feld braucht einen Namen daran. Ziehen Sie das „Created By" und prüfen Sie, ob diese Person noch im Unternehmen ist. Wenn nicht, gehen Sie das Feld durch das Team. Beansprucht es jemand? Wenn es innerhalb von sieben Tagen niemand beansprucht, ist es eine Waise.

Schritt 3: Bauen Sie die Kill-Liste. Drei Buckets:

  • Hartes Löschen: Null Nutzung UND kein Owner. Im nächsten Sprint löschen.
  • Deprecate: Hat etwas Nutzung, aber der Owner stimmt zu, dass es redundant ist. In der Beschreibung als veraltet markieren, aus Layouts ausblenden, Löschung in 90 Tagen einplanen.
  • Dokumentieren: Aktiv, verantwortet, keine weitere Aktion. Schreiben Sie die Beschreibung, wenn sie leer ist.

Schritt 4: Machen Sie es dauerhaft. Fügen Sie eine Feld-Erstellungsrichtlinie hinzu: Jedes neue benutzerdefinierte Feld erfordert eine Beschreibung, einen Owner und ein „Review by"-Datum. Keine Beschreibung = kein Feld. Bringen Sie den CRM-Admin dazu, es durchzusetzen. Wenn er nicht will, holen Sie sich für diesen einen Workflow Admin-Rechte.

Sie werden nicht auf 50 Felder kommen. Sie können wahrscheinlich auf 100 kommen. Das ist das Ziel.

Namenskonventionen, die Personalwechsel überstehen

Wenn der nächste Admin, der Ihren Stack erbt, in fünf Sekunden nicht erraten kann, was ein Feld tut, ist der Name falsch. Benennen Sie ihn um.

Die Namenskonvention, die ich nutze und die drei Jobwechsel überstanden hat:

  • mkt_*: geschrieben von der MAP. Marketing verantwortet.
  • sfdc_*: natives Salesforce-Feld oder vertriebs-verantwortetes benutzerdefiniertes Feld.
  • ext_*: geschrieben von einer externen Integration (Clearbit, ZoomInfo, 6sense usw.). Schreibgeschützt für alle anderen.
  • ops_*: operative/berechnete Felder (Region, Segment, Account-Tier).
  • Kein Präfix: Standardfelder, die Sie nicht erstellt haben.

Picklist-Disziplin zählt mehr, als Sie denken. Freitext-Länderfelder, in denen Sie „USA", „U.S.A.", „United States", „US" und „America" alle im selben Datensatz haben, werden Ihr Reporting zerstören. Sperren Sie Picklists. Wenn der Vertrieb diskutiert, zeigen Sie ihm den Segment-Bericht, in dem der USA-Umsatz über fünf Buckets verteilt ist.

Die Fünf-Sekunden-Regel: Wenn ein neuer Admin den Feld-Manager öffnet und in fünf Sekunden nicht erraten kann, was cust_dt_2_v3__c tut, ist dieses Feld falsch benannt. Benennen Sie es um. Ja, es wird zwei Berichte kaputt machen. Reparieren Sie die Berichte. Ihr zukünftiges Ich wird Ihnen eine Dankesnotiz schicken.

MAP-Auswahl: Marketo vs. HubSpot vs. Pardot vs. Rework

Die Hälfte des MAP-Integrationsschmerzes kommt daher, die falsche MAP für das Unternehmen zu wählen. So denke ich darüber.

Marketo (jetzt Adobe)

Wählen Sie Marketo, wenn:

  • Sie einen dedizierten MAP-Admin haben (nicht einen „Marketing-Manager, der auch Marketo macht")
  • Ihre Kampagnenprogramme wirklich komplex sind (Multi-Touch-Nurtures, account-basierte Plays, Dutzende von Segmenten)
  • Sie Enterprise sind (über 1.000 Mitarbeiter) oder Demand Gen im Enterprise-Stil betreiben
  • Sie den Preis und die Lernkurve verkraften können

Wählen Sie Marketo nicht, wenn Sie ein 50-Personen-Startup sind. Sie werden 8 % der Plattform nutzen, 100 % des Preises zahlen, und die Integration zu Salesforce wird einen FTE auffressen.

HubSpot

Wählen Sie HubSpot, wenn:

  • Marketing die GTM-Motion anführt
  • Ihr Team in der UI lebt (nicht in API-Aufrufen und SQL)
  • Sie Mid-Market sind (50 bis 500 Mitarbeiter)
  • Sie CRM und MAP vom selben Anbieter wollen und Sie mit HubSpots CRM einverstanden sind (das für SMB in Ordnung ist und bei Enterprise dünn wird)

HubSpots Stärke ist, dass CRM und MAP ein System sind, sodass das Flickwerk-Problem teilweise verschwindet. Die Schwäche ist, dass Sie, wenn Sie HubSpot CRM entwachsen und Salesforce dranschrauben, das Integrationsproblem mit zusätzlichen Schritten neu erschaffen haben.

Pardot (Marketing Cloud Account Engagement)

Wählen Sie Pardot, wenn:

  • Sie ein Salesforce-natives Haus sind und der Salesforce-Admin auch die Marketing-Automatisierung verantwortet
  • Sie keine ausgefeilte Programmlogik brauchen
  • Sie Lifecycle-Phase und Scoring eng an SFDC-Objekte gekoppelt haben wollen

Pardots Stärke ist, dass die SFDC-Integration nativ ist (sie lebt innerhalb von SFDC). Die Schwäche ist, dass die MAP selbst veraltet ist; wenn Ihr Team moderne UX braucht, werden sie mit Ihnen kämpfen.

Rework

Wählen Sie Rework, wenn:

  • Sie ein kleines oder mittelgroßes B2B sind (20 bis 500 Mitarbeiter)
  • Vertrieb und Marketing sich eine Pipeline teilen und Sie nicht wollen, dass zwei Tools darum kämpfen
  • Sie keinen dedizierten MAP-Admin haben und auch keinen wollen
  • Sie lieber ein CRM mit eingebautem Lead-Capture, Scoring und Routing hätten, als eine separate MAP+CRM-Integration zu pflegen

Reworks Argument zu diesem speziellen Problem: Es gibt keine MAP-zu-CRM-Integration zu pflegen, weil es keine separate MAP gibt. Lead-Capture, Scoring, Lifecycle-Phase und Pipeline leben in einem System. Sie geben einen Teil von Marketos Enterprise-Programmkomplexität auf. Im Gegenzug geben Sie das Flickwerk auf.

Für ein 30-Personen-B2B-SaaS-Team mit einem MOps-Generalisten kostet der Marketo+SFDC-Stack vielleicht 80.000 Dollar/Jahr an Lizenzen plus einen halben FTE zur Pflege. Derselbe Workflow auf Rework läuft für 12 Dollar/Nutzer/Monat auf der CRM-Stufe (etwa 10.000 Dollar/Jahr für ein Team von 30), und die MAP-Integration geht von „pflegen" zu „existiert nicht".

Das ist nicht für jeden die richtige Antwort. Es ist die richtige Antwort für mehr Teams, als es zugeben.

Die Entscheidung zum Neuaufbau von Grund auf

Irgendwann kostet das Flicken mehr als der Neuaufbau. Der schwierige Teil ist zu wissen, wann.

Die 40-%-Regel: Wenn mehr als 40 % der Zeit Ihres MOps-Teams für Integrationsreparaturen, Geisterfelder und Abstimmungsabfragen draufgeht, und das seit zwei aufeinanderfolgenden Quartalen, sind Sie über den Flick-Punkt hinaus. Bauen Sie neu.

Andere Signale:

  • Drei oder mehr „vertrauenswürdige" Lifecycle-Felder existieren und Leute streiten darüber, welches korrekt ist
  • Sync-Fehler laufen bei mehr als 0,5 % der Datensätze pro Tag
  • Eine neue MOps-Einstellung braucht mehr als 90 Tage, um ihre erste nicht-triviale Änderung auszuliefern
  • Der Audit-Trail bei kritischen Feldern lautet „frag Sandra, sie erinnert sich"
  • Die MAP-CRM-Integration hat mehr als zwei eigene Middleware-Komponenten (Workato-Recipes, Zapier-Zaps, eigener Apex)

Neuaufbauten sind keine „alles in die Luft jagen"-Operation. Sie sind ein Parallelaufbau. Sie stellen eine neue Instanz auf (oder ein sauberes Schema in der bestehenden Instanz), migrieren eine Kampagne nach der anderen, validieren, dann depreziieren Sie die alte. Es dauert 90 bis 180 Tage. Es ist schneller als die nächsten 18 Monate Flickwerk.

Sagen Sie Ihrem Chef, es ist eine Investition, kein Projekt. Investitionen verzinsen sich. Flickwerk nicht.

Überwachung der Integrationsgesundheit

Eine gesunde MAP-CRM-Integration hat Telemetrie. Wenn Sie es nicht sehen können, können Sie es nicht reparieren.

Die drei Alarme, die jeder MOps-Lead laufen haben sollte:

1. Sync-Fehlerraten-Alarm. Feuert, wenn Sync-Fehler 0,5 % der versuchten Datensätze in einem 1-Stunden-Fenster überschreiten. Das fängt API-Limit-Probleme, Validierungsregel-Konflikte und Middleware-Ausfälle ab, bevor der Vertrieb es bemerkt.

2. Lifecycle-Flatter-Alarm. Feuert, wenn sich die Lifecycle-Phase eines Datensatzes mehr als dreimal in 24 Stunden ändert. Das fängt die Race Conditions ab, in denen zwei Systeme um dasselbe Feld kämpfen.

3. Formular-zu-CRM-Latenz-Alarm. Feuert, wenn eine Formular-Einsendung mehr als 90 Sekunden braucht, um im CRM zu landen. SDRs vertrauen dem System basierend auf dieser Kennzahl mehr als auf jeder anderen.

Eine tägliche Abstimmungsabfrage sollte außerdem jeden Morgen um 6 Uhr laufen und Ihnen (und nur Ihnen, bis Sie ihr vertrauen) eine E-Mail schicken. Die Abfrage, die ich auf Salesforce + Marketo laufen lasse:

-- Datensätze in der MAP ohne CRM-Gegenstück, letzte 7 Tage
SELECT email, lifecycle_stage, last_modified
FROM map_leads
WHERE crm_id IS NULL
  AND created > DATEADD(day, -7, CURRENT_DATE)
  AND lifecycle_stage IN ('MQL', 'SAL');

Alles in diesem Ergebnis-Set ist ein Lead, der es zu einem Vertriebsmitarbeiter hätte schaffen sollen, es aber nicht tat. Wenn die Abfrage an einem Tag mehr als 5 Zeilen zurückgibt, haben Sie ein Integrationsproblem, von dem Sie noch nichts wissen.

Die Dashboard-Variante: eine wöchentliche Ansicht der Sync-Fehleranzahl nach Fehlertyp, der MQL-Übergabe-Latenz P50/P95 und der Gesamtzahl der Datensätze unter jeder Lifecycle-Phase. Machen Sie sie zur Startseite Ihres MOps-Confluence-Bereichs. Wenn ein VP fragt „ist das System gesund?", zeigen Sie auf das Dashboard und sagen „ja" oder „nein" mit Daten.

Eine verlässliche Datenquelle, eine MQL-Definition, ein Owner

Wenn dieses Playbook eine einzige Kernaussage hätte, wäre es diese: Jeder Datenpunkt in Ihrem MAP+CRM-Stack hat genau eine verlässliche Datenquelle, einen Owner und eine Definition. Alles andere ist Flickwerk.

Wenn ein Vertriebsmitarbeiter argumentiert, ein MQL „sei eigentlich kein MQL", ist das kein Feldproblem. Das ist ein Definitionsproblem. Reparieren Sie die Definition. Dokumentieren Sie sie. Bringen Sie die Vertriebsführung dazu, schriftlich abzunicken. Dann wird das Feld irrelevant, weil sich alle einig sind, was es bedeutet.

Wenn zwei Systeme in dasselbe Feld schreiben, wählen Sie eines. Das andere wird schreibgeschützt oder bekommt ein separates Überschreibungsfeld. Race Conditions werden mit mehr Workflows nicht besser.

Wenn ein benutzerdefiniertes Feld keinen Owner hat, töten Sie es. Wenn in drei Monaten jemand bemerkt, dass es fehlt, finden Sie heraus, wer es tatsächlich genutzt hat. Meistens bemerkt es niemand, und Sie haben das System für den nächsten Admin, der es erbt, einfacher gemacht.

Das Flickwerk verzinst sich. Jede Abkürzung, die Sie dieses Quartal nehmen, ist ein Problem, das Ihr Nachfolger nächstes Jahr erbt. Manchmal ist die richtige Antwort, neu zu bauen. Manchmal ist sie, auf einen Stack umzusteigen, der die Integration von vornherein nicht erfordert. Fast immer ist sie, mehr zu löschen, als Sie hinzufügen.

Das ist der Job.

Mehr erfahren