Der schnellste Weg, ein Customer-Insights-Projekt zu gegen die Wand zu fahren (und die Checkliste, die das verhindert)

Der schnellste Weg, ein Customer-Insights-Projekt scheitern zu lassen, ist, es wie ein Tool-Rollout zu behandeln und Marketing erst einzuladen, „wenn es fertig ist“.

Dieser Ansatz führt zu einem ziemlich vorhersehbaren Ergebnis: ein technisch korrektes Setup, das nicht dazu passt, wie Marketing wirklich arbeitet. Dann „haben die Leute keine Zeit“, es zu nutzen, bauen Workarounds oder schieben alles zurück zu Agenturen und Excel. Adoption wird zum Trainingsproblem, das Projekt wird zum Schuldzuweisungsspiel – und du verteidigst am Ende eine Plattform, die niemand will.

Es geht auch anders. Ohne Magie. Ich habe vor einer Weile versucht, dafür eine komplette Checkliste zu schreiben. Sie wurde absurd lang. Und natürlich muss ich als Consultant sagen: it depends, weil kein Customer-Insights-Projekt wie das andere ist. Also habe ich sie ein bisschen komprimiert und nur die Teile behalten, die aus meiner Erfahrung den größten Unterschied machen.

Du kannst sie hier herunterladen und weiterlesen, wenn du meine Gedanken hinter den Schritten verstehen willst.

Mindset-Shift: Hör auf, Requirements zu sammeln und fang an, gemeinsame Realität zu schaffen

Die meisten Projekte laufen nach einem bekannten Muster: Requirements, Design, Build, Test, Training, Go-live.

Marketing-Automation-Projekte verhalten sich aber nicht zwingend so, weil Marketingarbeit nicht statisch ist. Es gibt Kampagnenzyklen, Freigaben, Content-Engpässe, Last-Minute-Änderungen, „wir brauchen das bis morgen“ – und hundert kleine Entscheidungen, die nie in einem Requirements-Dokument landen.

Das Ziel in den ersten Wochen ist deshalb nicht ein perfektes Design, sondern zu verstehen:

• was Marketing im Alltag wirklich macht
• welche Daten wirklich verfügbar (und nutzbar) sind
• welche Integrationen real sind – nicht angenommen
• welche Reibungspunkte dir das Momentum killen, wenn du sie ignorierst

Und noch eins, weil es wirklich alle unterschätzen: wie Arbeit durch die Organisation fließt. Wer schreibt Content? Wer gibt frei? Wie lange braucht Legal? Was passiert, wenn jemand im Urlaub ist?

Schritt 1: Hol Marketing an Tag eins dazu

„Tag eins“ heißt nicht: formaler Requirements-Workshop, in dem alle freundlich nicken und sich am Ende nichts ändert.

Eine Struktur, die in der Praxis gut funktioniert: Starte mit einer Working Session, die sich darauf fokussiert, wie Marketing Arbeit erledigt, wo Zeit verloren geht, und wie „gut“ unter Druck aussieht. Du sammelst nicht jeden Wunsch. Du identifizierst die wenigen Kampagnentypen, die wirklich zählen – und die Constraints, die du nicht ignorieren kannst (Freigabeketten, Content-Vorlauf, Compliance, Segmentierungsgewohnheiten, Channel-Limits).

Ein kleiner Schritt mit großer Wirkung: Such dir eine Marketing-Person bzw. einen Key User als Design-Partner:in. Nicht jemand, der nur im Steering Committee sitzt. Sondern ein echter User, der mit dir baut, Annahmen challengt – und dir sagt, wenn etwas verwirrend ist.

Schritt 2: Baue zuerst eine kleine Journey – mit echtem Content und echten Daten

Hier fangen viele Projekte an zu wackeln, weil alle zuerst das „richtige Setup“ bauen wollen: Datenmodell, alle Integrationen, eine komplette Segment-Strategie, eine Asset-Library, und dann direkt große Kampagnen.

In der Praxis lernst du mehr, wenn du das Gegenteil machst: Baue so früh wie möglich eine kleine Journey einmal Ende-zu-Ende. Nicht zwanzig Segmente. Kein „Template-Framework“. Eine Journey, die echten Content und echte Daten nutzt – und wirklich laufen kann.

Du suchst eine Journey, die simpel genug ist, um sie schnell fertig zu bekommen, aber realistisch genug, um die Realität sichtbar zu machen. Zum Beispiel: Follow-up nach einer Formularübermittlung, eine Event-Registrierungsstrecke, ein Welcome-Flow.

Wenn du das früh machst, wird das Projekt nicht mehr theoretisch. Und dann tauchen die nützlichen Probleme auf:

• Content-Freigaben dauern länger als der Projektplan
• Consent-Logik ist unklar
• Identity Matching verhält sich anders als erwartet
• User bauen Segmente für alles, weil Trigger sich riskant anfühlen
• Naming wird ab Tag drei chaotisch
• „kleine Änderungen“ brauchen drei Systeme und zwei Teams

Genau diese Probleme willst du finden, solange du noch Luft zum Anpassen hast.

Schritt 2.1: Bevor du eine „Segment-Strategie“ baust: Erstell Regeln, die Chaos verhindern

Die meisten Teams bauen nicht zu viele Segmente, weil sie Segmente so lieben. Sie tun es, weil Segmente sich nach Kontrolle anfühlen.

Trigger machen Angst („was, wenn es falsch feuert?“), Segmente fühlen sich sicher an („wenigstens kann ich es mir anschauen“). Also bauen Leute Segmente für alles. Und nach ein paar Monaten hast du einen Segment-Friedhof, den niemand anfassen will.

Deshalb setze ich gern früh eine einfache Regel: Segmente sind Produkte, keine Projekt-Artefakte. Jedes Segment braucht eine:n Owner und einen Grund, zu existieren.

Schritt 3: Mach Shadow Sessions – und mach aus dem Gelernten kleine Templates

Sobald die Pilot-Journey steht, mach das, was Adoption schneller verändert als jeder Trainingsplan: Shadow Sessions.

Setz dich mit Marketing-Usern hin, während sie bauen und ausführen. „Zeig mir, wie du das machst.“

Menschen over-engineeren, weil sie unsicher sind. Sie duplizieren Assets, weil sie sie nicht finden. Sie bauen Segmente für jede Mini-Kampagne, weil es sich „richtig“ anfühlt. Sie vermeiden Features, weil eine verwirrende Erfahrung Vertrauen zerstört hat.

Nach Shadow Sessions solltest du nicht mit einem riesigen Governance-Dokument reagieren. Erstell lieber eine Handvoll wiederverwendbarer Bausteine.

Hier sind die drei „Templates“, die du erstellen kannst:

1. Ein Naming-Cheat-Sheet, das auf einen Screen passt: Journeys, E-Mails, Segmente, Trigger.

2. Zwei oder drei Journey-Patterns: Zum Beispiel: Welcome, Event-Follow-up, Re-Engagement. Sie geben einen sicheren Startpunkt.

3. Eine „Definition of Done“-Checkliste für die Journey-Aktivierung Die kleine Reihe an Checks, die Panik verhindert: Consent-Link vorhanden, Suppression angewendet, Testkontakt hat funktioniert, Freigabe dokumentiert, Ziele definiert.

Wenn du standardisierst, halte es praxisnah: vorhersehbares Naming, zwei oder drei Journey-Patterns, die man kopieren kann, ohne groß nachzudenken.

Schritt 4: Enablement, das während des Bauens passiert (nicht ein Trainingstag am Ende)

Training scheitert, wenn es von der echten Arbeit entkoppelt ist. Statt also am Ende „das große Training“ zu planen, mach Micro-Enablement:

• 20 Minuten direkt nachdem ein Feature eingeführt wurde
• eine kurze Aufnahme („so machen wir hier Consent Checks“)
• eine praktische Übung („baue und aktiviere eine Mini-Journey in TEST)

Das Ziel ist Unabhängigkeit: Marketing soll die Basics bauen und betreiben können, ohne dass ständig eine Rettungsmission nötig ist.

Was du messen solltest, wenn du ein System willst, das Menschen wirklich nutzen

Wenn du Erfolg als „Go-live“ definierst, verfehlst du den Punkt. Die echte Frage ist: Kann Marketing alleine arbeiten?

Achte auf Zeichen von Sicherheit und Vertrauen:

• User können eine Basic-Journey bauen, ohne dauernd gerettet zu werden zu müssen
• Assets werden wiederverwendet statt dupliziert
• Die Anzahl der Segmente explodiert nicht endlos „für alle Fälle“
• Menschen vertrauen den Ergebnissen genug, um danach zu handeln

Zusammenfassung

Customer Insights scheitert nicht an fehlenden Features. Es scheitert, wenn es wie ein Tool-Rollout behandelt wird: erst bauen, Marketing später einladen.

Ich finde, die Lösung ist simpel: Co-Build ab Tag eins, früh eine echte Journey shippen, über Shadow Sessions lernen – und die Learnings in ein paar Standards übersetzen, denen Menschen wirklich folgen können.

Ich habe das in eine praktische Checkliste gepackt, die du sofort nutzen kannst. Downloade die Customer Insights Checkliste

Hast du Fragen, Ideen oder Anmerkungen? Meld dich gern.