Meine Rechnungen liegen bei der DATEV, meine Verträge im internen Projektmanagement-Tool und in einer Controlling Software, beide von deutschen Anbieter:innen. Das CRM ist für mich ein Hebel für Struktur und Umsatz, aber es ist für unser Agenturgeschäft nicht geschäftskritisch. Fällt HubSpot morgen aus, stehen zuerst die Prozesse still, die auf Automation laufen: Follow-up-Sequenzen, Formulare, Workflows, die Bewertung eingehender Anfragen. Das tut weh, weil in diesen Prozessen Monate Arbeit stecken. Aber die Interessent:innen da draußen hören nicht auf, sich mit uns zu beschäftigen, nur weil wir kein System mehr haben. Viele würden sich sich von allein wieder melden. Und mit den Bestandsdaten, die bei uns liegen, baue ich mit anderen Werkzeugen in kurzer Zeit wieder ein CRM auf. Das ist keine Wertung gegen HubSpot. Ein Tool ist eben ein Hebel, aber kein Tresor.

Was ich als Kronjuwelen bezeichne, hat mit Kund:innendaten wenig zu tun. Es sind unsere Basiskonzepte, Ausbildungsdokumente, Prozesse und Datenmodelle: Wie denken wir einen Newsletter, eine Website, einen Double-Opt-in-Prozess, ein Datenmodell für Kaufabsichtssignale? Das alles liegt als Markdown-Dateien in einem Obsidian Vault (einem lokalen Wissensspeicher aus reinen Textdateien), versioniert über eine Open-Source-Versionskontrolle, die wir selbst auf einem Hetzner-Server betreiben. Richtig schön langweilig.

Der Auslöser für dieses Projekt liegt gut zwei Jahre zurück. Mir war klar, dass ich mein Unternehmen nicht auf KI ausrichten, sondern dazu befähigen muss, KI so zu nutzen, dass sich das Ergebnis anfühlt wie ein echtes sixclicks-Ergebnis. Dafür braucht ein Sprachmodell unser Wissen in einem Format, das es lesen kann. Markdown ist so ein Format. Word-Dokumente in unstrukturierten Ordnern auf verteilten Rechnern sind es nicht.

Die Einführung war unspektakulär. Bei unserem Quartalstreffen haben wir einen Tag lang über nichts anderes gesprochen: Welche Inhalte werden am meisten gebraucht, was bleibt intern, was darf zu Kund:innen? Daraus sind zehn Regeln entstanden, wie Wissen bei uns gespeichert wird. Die erste lautet: lieber eine schlechte Dokumentation als gar keine. Drei Monate später haben wir in einer Retrospektive rund 2.500 Dokumente sortiert und zusammengeführt. Seitdem gibt es eine neue Rolle im Team, die diesen Speicher nahezu in Vollzeit pflegen wird.

Jede Drittintegration ist eine Datenübertragung, die du einmal eingerichtet hast und dann nie wieder anschaust. Erweiterte Conversions an Google, Kontaktdaten an LinkedIn für die Kampagnenmessung, das Meeting-Transkript, das über Teams ohnehin in der Microsoft Cloud liegt, das Backup, das bei AWS landet. Die Frage ist also nicht, ob Daten das Haus verlassen, sondern welche und wohin.

Meine Erfahrung aus Kund:innenprojekten: Die Sensibilität ist überall hoch, die Umsetzung liegt bei nahezu null. Ein Beratungsunternehmen für IT-Sicherheit hat uns ein Strategiedokument mit über 1.000 Seiten übergeben, das laut eigener Aussage niemand außerhalb sehen darf. Wir hatten vorher gefragt, wie wir es sicher zu uns übertragen. Die Antwort: „Liegt im SharePoint, ist ja hinterm Login.“ Die größten Risiken entstehen dort, wo die Integration bequem ist und niemand mehr weiß, welche Daten fließen: bei Werbeplattformen, die Kontaktdaten zur Attribution bekommen, bei Kollaborations-Tools, die alles mitschneiden, und bei Backups, deren Speicherort nie jemand geprüft hat.

„Your digital future is made in Europe“:
Europas Plan gegen Tech-Abhängigkeit

Wenn wir Datenanalysen für unsere Kund:innen machen, exportieren wir echte Daten aus HubSpot. Die kippen wir dann nicht einfach in Claude oder ChatGPT. Wir anonymisieren sie vorher mit einem einfachen Mechanismus in Excel: Eine Tabelle enthält die echten Kontakte, eine zweite ersetzt jeden Namen durch eine ID. Nur die zweite geht ins Modell. Die Analyse kommt mit IDs zurück, wir legen sie über die erste Tabelle und haben das Ergebnis mit Klarnamen. Das kostet eine Stunde Schulung und kein sechsstelliges Projekt. Mir reicht dafür die Kohorte. Mir ist egal, ob Peter der Nächste ist, den ich anrufen muss; mich interessiert, welche Gruppe als Nächstes dran ist.

Ich kenne Unternehmen, die ihr komplettes CRM in ein Sprachmodell laden und fragen, wen sie als Nächstes anrufen sollen. Wir würden das nie tun. Ich bin gelernter IT-Systemkaufmann. Für mich gehört dazu, die Rechte der Menschen im eigenen Interesse zu nutzen, aber nicht zu überschreiten. Und überall, wo personenbezogene Daten unserer Kund:innen im Spiel sind, regelt ein Auftragsverarbeitungsvertrag, wie wir damit umgehen.

Die zweite Kategorie, die nicht in ein öffentliches Modell gehört, ist das eigene Domänenwissen. Ein ehemaliger Performance Marketer hat bei uns die zehn Regeln für die Führung eines Google Ads-Kontos bis 5.000 Euro Budget aufgeschrieben. Solches Wissen geben wir nicht unkontrolliert in öffentliche Modelle ein. Ob und wie Eingaben verarbeitet oder für die Weiterentwicklung eines Modells genutzt werden, hängt von den jeweiligen Anbieter:innen, Produkt und den vereinbarten Einstellungen ab. Also arbeiten wir mit unserem Wissen bei uns. Dass wir einzelne Dokumente heute noch in Cloud-Projekte hochladen, weil unsere eigene Infrastruktur noch nicht so weit ist, ist ein bewusster Kompromiss, kein Prinzip.

Ein Kill-Switch-Plan, also der Plan für den Tag, an dem ein:e Anbieter:in ausfällt oder du ihn verlässt, ist bei uns kein Dokument im Tresor. Er ist die Antwort auf drei Fragen pro System: Welche Daten liegen dort, die wir nirgendwo sonst haben? In welchem Format kommen sie raus? Mit welchem Werkzeug arbeiten wir am Tag danach weiter? Für den Wissensspeicher: alles als Markdown mit Versionshistorie auf eigenem Server, weiterarbeiten mit jedem Editor. Für Rechnungen und Verträge: getrennt vom CRM bei zwei anderen Anbieter:innen, sodass ein Ausfall nie alles trifft. Für HubSpot: Kontakte und Historie als Export, ein anderes CRM innerhalb von Tagen.

Getestet wird das im Alltag und der ehrlichste Test ist die Urlaubsübergabe. Bei uns ist das eine Teams-Nachricht: die letzten drei Ergebnisprotokolle, die zwei akuten Teilprojekte, fertig. Ruft ein:e Kund:in während der Vertretung an, lese ich die Protokolle, frage intern nach, wie zwei Zeilen gemeint sind und gebe am nächsten Tag eine Empfehlung. Das dauert 20 Minuten. Wenn deine Urlaubsübergabe dagegen ein Drei-Stunden-Meeting braucht, hast du den Kill-Switch-Test gerade nicht bestanden, ohne dass ein:e Anbieter:in ausgefallen ist.

Drei Dinge, die du diese Woche prüfen kannst

1. Wo liegen deine Kronjuwelen wirklich?
Rechnungen, Verträge, Konzepte, Prozesswissen. Lautet die Antwort „in Word-Dateien in Kund:innenordnern“, ist dein Problem die Dokumentation. Das löst kein:e Anbieter:in.

2. Was geht bei euch heute in ein Sprachmodell und wer entscheidet das?
Entscheidet niemand, entscheidet die Kollegin mit dem CRM-Export und einer Deadline. Prüfe den Auftragsverarbeitungsvertrag und baue eine Anonymisierungsroutine, die jeder in einer Stunde lernt.

3. Wie lange dauert eure Urlaubsübergabe?
Die Zahl sagt mehr über eure Datensouveränität als jedes Rechenzentrum.

Unser Wissensspeicher liegt bei Hetzner, unsere Buchhaltung bei der DATEV. Trotzdem ist eine europäische Alternative nicht automatisch souveräner. Souverän bist du, wenn du gehen kannst, ohne etwas zurückzulassen. Ein europäisches CRM mit proprietärem Format und schlechtem Export ist ein Lock-in mit EU-Flagge.

Bei KI zeigt sich das am deutlichsten. Wir pilotieren lokale Open-Source-Sprachmodelle über Ollama auf einem Rechner mit 256 Gigabyte Grafikspeicher neben meinem Monitor. Sobald zwei Leute gleichzeitig darauf arbeiten, muss ich die Klimaanlage anschalten. Für 20 Leute reicht das nicht. Der nächste Schritt ist ein europäischer KI-Anbieter:innen; von den beiden, die ich verglichen habe, war der französische deutlich weiter als der deutsche. Die Modelle der Unternehmen habe ich lokal eins zu eins repliziert, damit ich weiß, dass das, was hier läuft, dort genauso läuft. Das ist Souveränität: die Möglichkeit, dasselbe Modell morgen woanders zu betreiben. Gratis ist sie nicht. Ich würde unseren Weg keinem Unternehmen eins zu eins empfehlen. Die Logik dahinter aber schon.

Zurück zur Ausgangsfrage. Fällt HubSpot morgen aus, verliere ich Leads und Komfort und fülle in ein paar Tagen ein neues CRM. Was ich nicht neu bauen könnte, ist die Revenue-Marketing-Logik, die in über 20 Jahren entstanden ist und heute versioniert als Markdown auf einem Server liegt, den wir kontrollieren. Die Frage nach souveräneren Alternativen ist für eine Marketing-Abteilung deshalb die zweite. Die erste lautet: Welche Daten würdest du morgen wirklich vermissen und liegen sie in einem Format, das jede:n Anbieter:in überlebt? Die meisten, die ich das frage, kennen die Antwort. Sie warten darauf, dass morgens jemand reinkommt und das für sie erledigt, am besten ohne Budget, dafür aber mit zehn Jahren Erfahrung und das am liebsten vor Weihnachten. Statt frommer Wünsche an das Christkind, empfehle ich: Fang mit 15 Minuten am Tag an, sichere dein Know-how und mach es in deiner Organisation verfügbar.

Stelle OnlineMarketing.de als bevorzugte Quelle auf Google ein

Wenn du OnlineMarketing.de auf Google als bevorzugte Quelle einstellen möchtest, um auch in den Schlagzeilen auf Google immer aktuelle News und Tipps aus der Welt des Marketing und der Tech-Entwicklungen zu finden, kannst du einfach die Google-Quelleneinstellungen aufrufen und die Seite anwählen. Über das Stern-Icon neben den Top Stories kannst du ebenfalls bevorzugte Quellen für die spätere Suche speichern.