Schap

Autor: Florian

  • Das Lab: warum Marketing seine eigenen Tools bauen sollte

    Das Lab: warum Marketing seine eigenen Tools bauen sollte

    Den größten Teil meines Berufslebens lief ein neues Tool im Marketing so ab: Lastenheft schreiben, auf einen Slot in der IT warten, auf Budget warten, sechs Monate später etwas bekommen, das fast macht, was du gebraucht hättest. Oder ein SaaS-Produkt kaufen, das 80 % davon kann und die restlichen 20 % unmöglich macht.

    Vor einem Monat haben wir etwas anderes probiert. Wir haben das gestartet, was wir das Lab nennen: ein internes Portal, in dem Marketing- und Vertriebsteams mit KI-Coding-Agenten ihre eigenen Tools bauen. Niemand von uns ist Entwickler. Ich kann ein bisschen HTML und CSS, meine Kolleginnen und Kollegen ungefähr gleich viel.

    Nach vier Wochen gibt es im Lab einen täglichen Chat-Qualitätsreport, einen Finder für Dokumentationslücken, eine Seite mit Marktkennzahlen, eine Beobachtungsliste für Kundentickets, bei denen es still geworden ist, einen Social-Media-Analyser und ein Coaching-Tool für unsere Seminarlocation. Für die meisten davon hat es ein oder zwei Tage bis zur ersten brauchbaren Version gedauert.

    In diesem Beitrag geht es darum, wie das funktioniert, und warum die wichtigste Zutat nicht das KI-Modell ist.

    Der Agent ist der einfache Teil

    Moderne Coding-Agenten schreiben sehr guten Code. Das ist nicht mehr der Engpass. Der Engpass ist, dass der Agent nichts über dein Geschäft weiß. Er weiß nicht, was ein „qualifizierter Lead“ in deinem Unternehmen bedeutet, in welchem CRM-Feld die Partnerstufe steht, warum die Instagram-Zahlen vom letzten Quartal seltsam aussehen oder dass dein Support-Team Tickets auf eine bestimmte Art schließt.

    Gib einem Agenten eine vage Aufgabe und keinen Kontext, und du bekommst ein generisches Dashboard, das toll aussieht und die falsche Frage beantwortet. Gib ihm den richtigen Kontext, und er baut etwas, das sich anfühlt, als hätte es jemand gemacht, der seit Jahren mit dir zusammenarbeitet.

    Die eigentliche Arbeit im Lab ist also nicht das Prompten. Es ist der Aufbau von Kontext.

    Drei Arten von Kontext

    1. Was wir wissen: einfache Markdown-Dateien. Alles, was die Agenten verstehen müssen, liegt als Textdatei vor. Mein eigenes Wissen halte ich in einem Obsidian-Vault fest: wer wir sind, wie wir über unsere Produkte sprechen, Markenrichtlinien, die für KI-Agenten statt für Designer geschrieben sind, Definitionen unserer Kennzahlen. Zusammenfassungen von Meetings landen jeden Abend automatisch im Vault.

    Jedes Projekt-Repository hat eine Einstiegsdatei, AGENTS.md, die jeder Agent zuerst liest, egal ob Claude Code, Codex oder etwas anderes. Daneben liegt ein docs/-Ordner mit Entscheidungen und Erkenntnissen, jeweils mit Datum und Begründung. Wenn ein Agent oder ein Mensch etwas Nicht-Offensichtliches lernt, wird es dort aufgeschrieben. Nicht in einem Chat. Nicht im Gedächtnis eines einzelnen Tools. Im Repo, wo der nächste Agent es findet.

    Eine Regel hat sich als sehr wichtig herausgestellt: Jede Definition steht an genau einem Ort. Als ich im August meinen Vault aufgeräumt habe, waren unsere Markenfarben an sechs Stellen definiert und ein Prozess an neun Stellen beschrieben. Agenten nehmen fröhlich die Version, die sie zuerst finden.

    2. Was gerade passiert: Live-Verbindungen zu unseren Systemen. Kontext heißt auch Daten. Über MCP-Server (die „USB-Anschlüsse“, über die KI-Agenten mit anderer Software sprechen) und APIs können die Agenten unser CRM, unseren Helpdesk, unseren Live-Chat, unsere Social-Media-Analytics und unsere Produktdatenbank lesen. Ein Tool, das „aktive Partner pro Markt“ anzeigt, verwendet keinen Export vom letzten Monat. Es fragt das CRM ab, wenn es läuft.

    So ist auch eine unserer nützlichsten Seiten entstanden. Dieselbe Kennzahl war in Präsentationen mit drei verschiedenen Definitionen unterwegs. Jetzt gibt es eine Definition, einmal aufgeschrieben, und das Tool berechnet sie live. Die Diskussion hat sich von „Wessen Zahl stimmt?“ zu „Was machen wir jetzt damit?“ verschoben.

    3. Was schiefgegangen ist: Erkenntnisse direkt in den Tools. Jeder Skill und jedes Tool hat seine eigene Liste an Fallen. Zum Beispiel: „Lass nie einen KI-Sub-Agenten Tickets aus dem Helpdesk holen, dabei gehen die Filter verloren und du bekommst eine Million Ergebnisse statt ein paar Hundert.“ Diese Notizen sehen langweilig aus. Sie sind der Grund, warum der zweite Durchlauf eines Tools besser ist als der erste.

    Was wir tatsächlich gebaut haben

    Ein paar Beispiele, damit es konkret wird:

    • Chat-Reports. Jeder Live-Chat vom Vortag wird von einer KI gelesen und bewertet: Wurde er angenommen, wie lange hat der Kunde gewartet, wurde eine Verkaufschance verpasst, wurde der Kunde zu früh weggeschickt. Das vollständige Protokoll steht neben der Bewertung, damit jeder nachprüfen kann.
    • Dokumentationslücken. Abgeschlossene Support-Tickets werden mit unserer öffentlichen Wissensdatenbank abgeglichen. Was der Support schriftlich erklären musste, fehlt wahrscheinlich in der Dokumentation. Das Tool schlägt den Text vor, der ergänzt werden sollte.
    • Social-Analyser. KPIs über unsere Marken-Accounts hinweg, das Sentiment jedes Kommentars und jeder DM, eine Liste der Leute, die noch auf eine Antwort warten, und Content-Ideen, die auf die echten Posts und Kommentare verlinken, aus denen sie stammen. Den Großteil davon hat eine Marketing-Kollegin gebaut, nicht ich.
    • Ticket-Beobachtung. Offene Tickets, bei denen ein Kunde wartet und seit Tagen niemand geantwortet hat.
    • Location-Coaching. Anfragen für unsere Seminarlocation, aus denen keine Buchung wurde, warum nicht, und was sie wert gewesen wären.

    Nichts davon ist ausgefeilte Software. Die Tools sind klein, konkret und von den Leuten gebaut, die sie auch nutzen. Genau darum geht es.

    Chat-Report: von der KI bewertete Chats, das Transkript direkt neben der Note
    Nachgestellte Ansicht mit erfundenen Daten: So sieht das echte Tool aus, aber alle Namen und Zahlen hier sind ausgedacht.

    Wie Teams unabhängig bleiben (von der IT und voneinander)

    Jedes Team bekommt im Portal seinen eigenen Bereich: seine eigene kleine App, seinen eigenen Pfad, seinen eigenen Deploy. Wenn Marketing etwas kaputtmacht, geht der Bereich von Marketing kaputt, nicht das ganze Portal. Wer neu dazukommt, bekommt eine Einladung und einen „Prompt kopieren“-Button. Der Prompt weist den eigenen KI-Agenten an, das Projekt zu klonen, AGENTS.md zu lesen und die Onboarding-Checkliste abzuarbeiten. Das Wissen bleibt im Repo, der Prompt zeigt nur dorthin.

    Alles läuft auf Cloudflare mit einem Login davor. Nichts ist öffentlich, und niemand musste ein Login-System bauen. Wer etwas ansehen will, braucht nur eine Firmen-E-Mail-Adresse.

    Wir haben uns die Alternativen angeschaut. Ein BI-Tool mit Preis pro Nutzer und ohne Möglichkeit, Daten einzugeben. Ein Plattformprodukt für mandantenfähige Apps, das für drei Teams mehr gekostet hätte, als es wert war. Getrennte Repositories pro Team. Am Ende haben wir die einfachste Variante gewählt, die funktioniert: ein Repository, mehrere Bereiche, Absprache statt Zwang.

    Ist das eine Bedrohung für die IT?

    Nein. Die IT betreibt weiterhin die zentralen Systeme, kümmert sich um Sicherheit und um alles, was grundsolide sein muss. Was sich ändert, ist der Long Tail: die Hunderten kleinen Reports, Prüfungen und Helfer, die nie wichtig genug für ein IT-Projekt waren, aber die Woche eines Marketingteams spürbar verändern.

    Dafür lautete die Antwort bisher „Lebt ohne“ oder „Baut es in Excel“. Die neue Antwort ist: Bau es selbst, und gib deinem Agenten den Kontext, den er braucht.

    Wo du anfangen kannst

    Wenn du das in deinem Team ausprobieren willst:

    1. Schreib auf, was du weißt. Fang mit einer Markdown-Datei an: wer ihr seid, was eure Kennzahlen bedeuten, wie eure Tonalität ist. Halte jede Definition an einem einzigen Ort.
    2. Verbinde ein System. Nimm das, auf das du am häufigsten schaust (CRM, Helpdesk, Social-Media-Analytics), und verbinde es über einen MCP-Server oder eine API.
    3. Bau ein kleines Tool für eine echte Frage. Kein Dashboard. Eine Frage, etwa „Welche Kunden warten gerade auf eine Antwort?“
    4. Schreib auf, was schiefgegangen ist, mit Datum. Diese Datei wird dein wertvollstes Asset.

    Die Tools sind der sichtbare Teil. Was du wirklich aufbaust, ist der Kontext.

    Community-Ansicht: wer noch auf eine echte Antwort wartet, mit Antwortentwurf
    Nachgestellte Ansicht mit erfundenen Daten: So sieht das echte Tool aus, aber alle Namen und Zahlen hier sind ausgedacht.
  • LLMs lesen deine Kommentarspalte

    LLMs lesen deine Kommentarspalte

    Anfang des Jahres hatte ich ein Gespräch mit Leuten aus einem großen Softwareunternehmen, das mir im Kopf geblieben ist. Ihre Beobachtung: Wenn du einen KI-Assistenten nach einer Marke fragst, stützt sich die Antwort erstaunlich stark auf die öffentliche Stimmung. Forenbeiträge, Bewertungsportale, die Kommentare unter Social-Media-Posts. Nicht die sorgfältig formulierten Produktseiten. Nicht die Pressemitteilungen.

    Denk kurz darüber nach, was das bedeutet. Jahrelang war ein kritischer Kommentar unter einem Instagram-Post ein kleines Kundenservice-Thema. Jemand ist verärgert, vielleicht antwortest du, vielleicht nicht, und eine Woche später erinnert sich niemand mehr daran.

    Heute ist dieser Kommentar Trainingsmaterial dafür, wie Maschinen dich beschreiben.

    Das öffentliche Bild ist schief

    Jetzt kommt der unangenehme Teil. Die meisten Marken mit einer treuen Community haben einen ziemlich einseitigen öffentlichen Fußabdruck:

    • Die zufriedenen Kunden reden an geschlossenen Orten. Partnerportale, private Gruppen, interne Foren, direkte Gespräche mit ihrer Ansprechperson. Viel Wohlwollen, aber fast nichts davon ist für einen Crawler sichtbar.
    • Die unzufriedenen Kunden reden öffentlich. Ein Bewertungsportal, ein Kommentar unter deinem neuesten Video, ein Thread in einem offenen Forum. Dorthin gehen Leute, wenn sie das Gefühl haben, nirgendwo sonst gehört zu werden.

    Das öffentliche Bild ist also oft schlechter als die Wirklichkeit. Und genau dieses öffentliche Bild sehen KI-Assistenten.

    Mit mehr Werbung oder einer besseren Über-uns-Seite löst du das nicht. Du löst es dort, wo es passiert: in den Kommentaren.

    Aus Social Listening wird Arbeit an der eigenen Geschichte

    Social Listening war früher ein Reporting-Job. Erwähnungen zählen, Stimmung messen, ein Diagramm ins Monatsdeck. Nützlich, aber passiv.

    Im KI-Zeitalter wird daraus Arbeit an der eigenen Geschichte. Die Frage ist nicht mehr nur „Wie denken die Leute über uns?“, sondern „Welche Geschichte erzählt das Öffentliche über uns, und kommen wir darin überhaupt vor?“

    Das verändert, wie eine gute Antwort aussieht.

    Die Standardantwort macht es schlimmer. „Das tut uns leid, bitte wende dich an unser Support-Team.“ Diese Antwort hat jeder schon hundertmal gesehen. Sie sagt den Lesern, und jeder Maschine, die mitliest, dass das Problem immer noch ungelöst ist und sich die Marke nicht damit beschäftigt hat.

    Die konkrete Antwort verändert das Bild. Geh auf das eigentliche Problem ein, öffentlich, in ein paar Sätzen. Ist es ein bekanntes Problem, sag, wie es sich lösen lässt. Braucht es ein Gespräch, sag, wer anruft und wann. Die nächste Person mit demselben Problem findet die Antwort genau dort, und die KI auch.

    Dann schließ den Kreis. Wenn das Problem von jemandem wirklich gelöst ist, darfst du ruhig fragen, ob die Person ihre Bewertung aktualisiert oder einen Kommentar ergänzt. Viele machen das, weil sie nie auf die Marke wütend waren, sondern darauf, ignoriert zu werden.

    Wo KI-Agenten helfen

    Das ist viel Arbeit, wenn du es von Hand über mehrere Accounts und Plattformen machst. Und genau bei dieser Art von Arbeit glänzen Agenten, solange ein Mensch das Sagen behält.

    So sieht das Setup aus, das ich in den letzten Monaten aufgebaut habe:

    1. Eine wöchentliche Sentiment-Auswertung. Ein Agent holt Kommentare und Nachrichten von allen Marken-Accounts, bewertet die Stimmung jedes einzelnen und gruppiert sie nach Thema.
    2. Eine „Wartet noch“-Liste. Alle, die eine Frage gestellt oder sich beschwert haben und noch keine echte Antwort bekommen haben. Kein Diagramm. Eine Liste von Menschen. Eine Erkenntnis dabei: Die meisten „beantworteten“ Nachrichten in unseren Analytics waren in Wahrheit automatische Antworten innerhalb von Sekunden. Die behandeln wir jetzt als unbeantwortet.
    3. Antwortentwürfe. Für jeden offenen Punkt entwirft der Agent eine Antwort nach unseren eigenen Richtlinien: Tonalität, was wir zu bekannten Problemen sagen, wann wir an den Support übergeben. Die Entwürfe sind Ausgangspunkte, kein Autopilot.
    4. Ein Mensch prüft und postet. Immer. Der Agent hat nicht den Kontext, um zu wissen, ob dieser Kunde gestern schon mit jemandem gesprochen hat, und er soll nicht allein für die Marke sprechen.
    5. Aktiv gute Bewertungen sammeln. Jede Woche ein paar neue Bewertungen von Kunden, die ganz offensichtlich zufrieden sind, damit das öffentliche Bild nicht nur von den lautesten wenigen bestimmt wird.

    Nichts davon ist ausgefeilte Technologie. Es ist eine Routine, und der Agent macht diese Routine so günstig, dass man sie auch wirklich durchhält.

    Community-Ansicht: wer noch auf eine echte Antwort wartet, mit Antwortentwurf
    Nachgestellte Ansicht mit erfundenen Daten: So sieht das echte Tool aus, aber alle Namen und Zahlen hier sind ausgedacht.

    Was du lassen solltest

    Ein paar Dinge würde ich vermeiden:

    • Lass den Agenten nicht allein posten. Eine einzige schlecht eingeschätzte automatische Antwort an einen verärgerten Kunden, öffentlich, macht viel sorgfältige Arbeit zunichte.
    • Diskutiere nicht öffentlich. Ist eine Bewertung unfair, nenn die Fakten einmal, ruhig, und biete ein Gespräch an. Wer vernünftig wirkt, entscheiden die Leser.
    • Fälsch nichts. Gekaufte oder erfundene Bewertungen sind keine Abkürzung. Sie sind ein Risiko, für Menschen wie für Maschinen.
    • Verwechsle Menge nicht mit Abdeckung. Zehn schnelle Antworten auf einfache Fragen wiegen eine unbeantwortete Beschwerde nicht auf, die einen Monat lang dort steht.

    Die Kurzfassung

    KI-Assistenten lernen deine Marke über das kennen, was öffentlich ist. Und das Öffentliche ist oft zugunsten der wenigen Unzufriedenen verzerrt, weil die vielen Zufriedenen woanders reden.

    Behandle also jeden öffentlichen Kommentar als Teil der Geschichte deiner Marke. Geh auf das eigentliche Problem ein, öffentlich, wie ein Mensch. Nutz Agenten, um alles zu finden, was noch wartet, und um die Antworten zu entwerfen. Und lass einen Menschen auf den Senden-Button drücken.

    Jeder Kommentar ist ein Kunde. Und heutzutage ist jeder Kommentar auch eine Quelle.

  • Miss die Antwort, nicht die Frage

    Miss die Antwort, nicht die Frage

    Jedes Unternehmen sitzt auf einem riesigen Stapel ungelesener Marktforschung. Er heißt Support-Postfach. Jeder Live-Chat, jedes Ticket, jede E-Mail ist ein Kunde, der dir in eigenen Worten sagt, was er nicht versteht, was er will und wo dein Produkt oder dein Content ihn im Stich lässt.

    Marketing liest das selten. Nicht, weil es niemanden interessiert, sondern weil niemand Zeit hat, Tausende Gespräche zu lesen. Mit KI gilt diese Ausrede nicht mehr. Ein Agent kann jedes Gespräch von gestern lesen, bevor du deinen ersten Kaffee getrunken hast.

    Wir machen das jetzt seit ein paar Wochen. Das haben wir dabei gelernt.

    Der Trick: Schau, was der Support erklären musste

    Unsere erste Idee war naheliegend: die Kundenfragen nehmen, prüfen, ob unsere Wissensdatenbank sie beantwortet, und die Lücken auflisten. Das hat nicht gut funktioniert. Kunden stellen vage Fragen in ihren eigenen Worten. „Es geht nicht mehr“ passt zu keinem Artikel.

    Der Durchbruch kam, als wir es umgedreht haben. Miss nicht die Frage. Miss die Antwort. Schau dir an, was die Person im Support schreiben musste, um den Fall zu lösen. Wenn der Support etwas ausführlich und schriftlich erklären musste, ist genau diese Erklärung das, was in der Dokumentation fehlt.

    Mit dieser Änderung wurde die Lückenanalyse über Nacht brauchbar. Für jedes abgeschlossene Ticket vergleicht das Tool die Antwort aus dem Support mit unserer Wissensdatenbank. Es verwendet eine einfache Stichwortsuche über eine lokale Kopie aller Artikel, das ist schnell und braucht überhaupt keine KI. Wo es eine echte Lücke gibt, entwirft es den Text, der ergänzt werden sollte. Das Dokumentationsteam markiert jeden Fund als offen, übernommen oder verworfen.

    Eine Regel hält das Ganze ehrlich: Ein Thema gilt nur dann als „nicht dokumentiert“, wenn die Suche mit mindestens zwei unterschiedlichen Formulierungen nichts gefunden hat.

    Doku-Lücken aus Support-Antworten, mit Textvorschlag
    Nachgestellte Ansicht mit erfundenen Daten: So sieht das echte Tool aus, aber alle Namen und Zahlen hier sind ausgedacht.

    Erkenntnis 1: Das Tempo war nie das Problem

    Als wir angefangen haben, unsere Live-Chats zu bewerten, habe ich langsame Reaktionszeiten erwartet. Alle beschweren sich übers Warten im Chat.

    Falsch. Wenn jemand einen Chat angenommen hat, dann innerhalb von Sekunden. Das Problem war, dass zu viele Chats gar nicht angenommen wurden. Es ging um Abdeckung, nicht um Tempo.

    Das ist ein ganz anderes Problem mit einer ganz anderen Lösung: Schichtplanung statt Schulung. Seit es jeden Morgen sichtbar war, ist der Anteil der angenommenen Chats innerhalb weniger Wochen deutlich gestiegen. Niemandem musste man sagen, dass er sich beeilen soll. Die Zahl musste nur auf dem Tisch liegen.

    Erkenntnis 2: Die Stille nach der ersten Antwort

    Dasselbe Muster haben wir bei den Support-Tickets gesehen. Wir haben mit einer Zufallsstichprobe von hundert abgeschlossenen Tickets angefangen, um die Realität zu sehen, bevor wir irgendetwas bauen. Die ersten Antworten kamen schnell. Aber ein spürbarer Anteil der Tickets wurde geschlossen, ohne dass der Kunde eine echte Antwort bekommen hatte, und manche lagen mitten im Gespräch fast zwei Wochen still.

    Das Tempo stimmte. Die Stille danach nicht.

    Also haben wir eine kleine Beobachtungsliste gebaut: offene Tickets, bei denen die letzte Nachricht vom Kunden kommt und seit Tagen niemand geantwortet hat. Das ist keine Analyse, das ist eine To-do-Liste. Und es ist eine der meistgenutzten Seiten, die wir haben.

    Ticket-Watch: offene Tickets, in denen der Kunde zuletzt geschrieben hat
    Nachgestellte Ansicht mit erfundenen Daten: So sieht das echte Tool aus, aber alle Namen und Zahlen hier sind ausgedacht.

    Erkenntnis 3: „Beantwortet“ heißt nicht beantwortet

    In unserer Social-Media-Analyse wollten wir wissen, wie gut wir auf Kommentare und Direktnachrichten antworten. Das Analytics-Tool sagte: auf fast alle.

    Als wir genauer hingeschaut haben, waren die meisten dieser „Antworten“ automatische Nachrichten, die innerhalb einer Minute verschickt wurden. Ein Mensch hatte sie nie gesehen. Heute behandeln wir jede Antwort der Marke innerhalb von sechzig Sekunden als Auto-Reply und listen die Leute auf, die noch auf eine echte Antwort warten.

    Die Lektion lässt sich verallgemeinern: Wann immer dir ein Tool eine verdächtig gute Zahl liefert, prüf, wie sie gezählt wurde.

    Warum das Aufgabe des Marketings ist

    Man könnte sagen, das ist alles Kundenservice. Es ist aber nicht nur das. Was Kunden im Support fragen, ist das, wonach sie vor dem Kauf suchen werden. Was der Support erklären muss, ist das, was deine Website, deine Produktseiten und dein Content nicht erklären. Wo Kunden hängen bleiben, macht deine Kommunikation ein Versprechen, das das Produkterlebnis nicht hält.

    Es ist außerdem das beste Content-Briefing, das du je bekommen wirst. Jede Erklärung, die der Support immer wieder schreibt, ist ein Blogbeitrag, ein Video oder ein Hilfeartikel, der darauf wartet, geschrieben zu werden, und zwar gleich mit dem genauen Wortlaut der Kunden.

    So fängst du an

    1. Lies zuerst selbst eine Stichprobe. Nimm hundert zufällige Gespräche und lies sie. Danach weißt du, was du messen willst, und du erkennst, wenn die KI danebenliegt.
    2. Stell das vollständige Gespräch neben jedes KI-Urteil. Die Leute müssen nachprüfen können.
    3. Miss die Antwort, nicht die Frage, wenn du Lücken im Content suchst.
    4. Mach aus Erkenntnissen Listen, keine Diagramme. „Diese zwölf Kunden warten“ ist nützlicher als eine Trendlinie.
    5. Sei misstrauisch bei guten Zahlen. Prüf, wie sie gezählt werden.

    Deine Kunden sagen dir längst, was du reparieren und was du schreiben sollst. Neu ist nur, dass du es dir endlich leisten kannst, allen zuzuhören.

  • Warum Chatbots verrotten

    Warum Chatbots verrotten

    Vor ein paar Jahren hatten wir einen Support-Chatbot. Er war teuer, ein spezialisierter Anbieter hatte ihn gebaut, und am Launch-Tag hat er gut funktioniert. Ein Jahr später haben die Leute einen Bogen um ihn gemacht.

    Technisch war nichts kaputt. Der Bot hat weiterhin jede Frage beantwortet, schnell und höflich. Das Problem war, dass immer mehr Antworten falsch waren. Die Produkte hatten sich verändert, die Prozesse hatten sich verändert, die Dokumentation war weitergezogen. Der Bot nicht.

    Diese Erfahrung ist der Maßstab für jeden Chatbot, den wir seitdem gebaut haben. Und sie hat mir das Wichtigste beigebracht, was ich über Chatbots weiß: Ein Chatbot ist kein Technologieprojekt. Er ist ein Content-Pflegeproblem, das sich als Technologieprojekt verkleidet.

    Wie Bots verrotten

    Klassische Chatbots bestehen aus vorgeschriebenen Antworten. Jemand schreibt eine Liste mit Fragen und den passenden Antworten, der Anbieter trainiert ein Modell darauf, die Fragen zu erkennen, und los geht’s.

    Ab diesem Tag erzeugt jede Veränderung in deinem Unternehmen eine kleine Lücke. Eine neue Produktversion. Ein neuer Rückgabeprozess. Eine Preisänderung. Eine Funktion, die umbenannt wurde. Jede Lücke ist winzig. Niemand ist dafür zuständig, sie zu schließen, denn der Bot war ein Projekt, und das Projekt ist abgeschlossen.

    Sechs Monate später erzählt der Bot Kunden selbstbewusst Dinge, die im letzten Frühjahr gestimmt haben. Die Kunden merken es vor dir.

    Was sich mit LLMs ändert und was nicht

    Moderne Sprachmodelle verändern eine Sache grundlegend: Du musst keine Antworten mehr vorschreiben. Du kannst den Bot auf deine Dokumentation ansetzen, und er antwortet von dort. Ändert sich die Dokumentation, ändern sich auch die Antworten.

    Klingt, als wäre das Problem mit dem Verrotten gelöst. Es hat sich nur verschoben.

    Der Bot ist jetzt genau so gut wie die Dokumentation, die er liest. Ist die Doku veraltet, lückenhaft oder in Worten geschrieben, die deine Kunden nicht verwenden, ist es der Bot auch, nur eloquenter. Wie aktuell deine Wissensdatenbank ist, wird zur eigentlichen KPI deines Chatbots.

    Was wir diesmal anders machen

    Als wir dieses Jahr den alten Anbieter-Bot durch einen Assistenten auf Basis eines Sprachmodells ersetzt haben, haben wir uns ein paar Regeln gegeben.

    Mensch zuerst. Ist jemand aus dem Team online, bekommt der Kunde einen Menschen. Der Bot antwortet nur, wenn niemand verfügbar ist, etwa nachts oder am Wochenende. Er ist ein Sicherheitsnetz, kein Türsteher. Einen Support-Kanal haben wir sogar bewusst ganz ohne KI gestartet, weil die Leute, die ihn nutzen, eher einen Menschen brauchten als eine sofortige Antwort.

    Ein Bot, eine Aufgabe. Ein Bot, der Leuten hilft, das Produkt kennenzulernen, und ein Bot, der Fragen vor dem Kauf beantwortet, brauchen unterschiedliche Quellen, eine unterschiedliche Tonalität und unterschiedliche Grenzen. Wir halten sie getrennt und geben jedem einen eigenen Namen, damit Kunden und Team wissen, mit welchem sie gerade sprechen.

    Ablehnen statt raten. Vor dem Go-live haben wir den Dokumentations-Bot mit 200 echten Support-Fragen getestet. Die meisten Antworten waren teilweise richtig, ein paar waren falsch, und eine war eine echte Halluzination. Deshalb hat der Bot jetzt eine Konfidenzschwelle: Deckt die Dokumentation eine Frage nicht eindeutig ab, sagt er das und übergibt. Mehr dazu habe ich in Mach deine KI widersprechbar geschrieben.

    Der Doku-Bot antwortet mit Quelle und übergibt, wenn er unsicher ist
    Nachgestellte Ansicht mit erfundenen Daten: So sieht das echte Tool aus, aber alle Namen und Zahlen hier sind ausgedacht.

    Sprich die Sprache der Kunden. Kunden beschreiben Symptome, Dokumentation beschreibt Funktionen. Als wir jeder Suche das Vokabular der Dokumentation selbst hinzugefügt haben, hat sich die Zahl der Kundenformulierungen, die der Bot beantworten konnte, in unseren Tests ungefähr verdoppelt. Das ist keine Verbesserung am Modell. Es ist eine Verbesserung am Content.

    Jede Antwort kann bewertet werden. Daumen hoch, Daumen runter, mit Begründung. Die Bewertungen verbessern nicht nur den Bot, sie zeigen auch auf die Artikel, die Arbeit brauchen.

    Der Fehler, mit dem niemand rechnet

    Noch eine Geschichte, weil man so etwas nur lernt, wenn man einen Bot im Echtbetrieb laufen lässt.

    An einem seiner ersten Tage hat unser Bot plötzlich innerhalb von Sekunden Hunderte Anfragen an das Chat-System geschickt. Die Ursache war ein einziges Konfigurationsdetail: Die Antwort „Da kann ich nicht helfen, ich leite dich weiter“ saß an einer Stelle, an der das Chat-System sie als neue Frage behandelte. Der Bot hat auf seine eigene Weiterleitungsnachricht geantwortet, was eine weitere Weiterleitungsnachricht ausgelöst hat, und so weiter.

    Für die Kunden ist nichts Schlimmes passiert, und die Lösung war eine Zeile. Aber es ist eine gute Erinnerung: Ein Bot ist ein System, das mit anderen Systemen spricht, und diese Systeme haben ihre eigene Logik. Schau in den ersten Wochen genau hin.

    Wem gehört der Bot?

    Das ist die Frage, die entscheidet, ob ein Bot verrottet.

    Die falsche Antwort lautet: „Der Person, die ihn gebaut hat.“ Diese Person wechselt zum nächsten Projekt, und der Bot wird zum Waisenkind.

    Die richtige Antwort lautet: „Dem Team, dessen Wissen er weitergibt.“ Bei uns sind das die Leute, die die Dokumentation schreiben und pflegen, gemeinsam mit dem Support. Sie sehen die Daumen runter. Sie sehen, welche Fragen der Bot abgelehnt hat. Sie verbessern die Artikel, und der Bot wird besser, ohne dass jemand den Bot selbst anfasst.

    Eine Checkliste, bevor du einen Bot startest

    1. Wer hält das Wissen aktuell? Nenn ein Team, keine Person.
    2. Mensch zuerst oder Bot zuerst? Entscheide das bewusst, pro Kanal.
    3. Eine Aufgabe pro Bot. Getrennte Bots für getrennte Zwecke.
    4. Eine Konfidenzschwelle. Ablehnen statt raten.
    5. Bewertungen mit Begründung, weitergeleitet an die Leute, denen der Content gehört.
    6. Schau in den ersten Wochen genau hin. Bots, die mit Systemen sprechen, machen überraschende Dinge.

    Ein Chatbot verrottet nicht, weil die Technologie schlechter wird. Er verrottet, weil sich niemand dafür verantwortlich fühlt, was er weiß. Löst du das, ist die Technologie der einfache Teil.

  • Ich kann nicht programmieren. Trotzdem läuft bei mir alles auf Cloudflare.

    Ich kann nicht programmieren. Trotzdem läuft bei mir alles auf Cloudflare.

    Zuerst ein Geständnis: Ich bin kein Entwickler. Ich kann einfaches HTML schreiben, mit CSS eine Seite ganz ordentlich aussehen lassen, und ich weiß ungefähr, was eine Datenbank ist. Das war’s.

    Trotzdem betreibe ich seit dieser Woche sechs Websites und kleine Apps auf meinen eigenen Domains. Da ist ein privates Finanz-Dashboard mit Datenbank hinter einem Login. Da ist ein Tool, das die Ladevorgänge der Wallbox einer Familie sammelt und daraus monatliche Belege erstellt. Dazu zwei Websites für Vereine aus der Gegend, eine persönliche Landingpage und der Blog, den du gerade liest. Alles läuft auf einem einzigen Cloudflare-Konto.

    Den Code habe nicht ich geschrieben. Das haben KI-Coding-Agenten gemacht, vor allem Claude Code und Codex. Meine Aufgabe war, zu entscheiden, was ich will, zu prüfen, was zurückkommt, und ein Hosting-Setup zu wählen, das jemand wie ich tatsächlich versteht und am Laufen halten kann. Um diesen letzten Punkt geht es hier, weil er wichtiger ist, als viele glauben.

    Das eigentliche Problem ist nicht das Programmieren

    Wer als Marketer mit KI-Agenten experimentiert, merkt schnell: Code schreiben zu lassen ist nicht mehr das Schwierige. Du beschreibst, was du willst, und ein paar Minuten später läuft etwas auf deinem Laptop.

    Schwierig wird es danach. Wo läuft das Ganze? Wer spielt die Updates am Server ein? Was passiert, wenn um 23 Uhr etwas kaputtgeht? Wie verhindere ich, dass das ganze Internet meine Finanzdaten sieht? Klassisches Webhosting beantwortet diese Fragen mit Dingen, die ich nicht kann: per SSH auf Server zugreifen, Nginx konfigurieren, Zertifikate erneuern, PHP aktualisieren, Datenbank-Backups verwalten.

    Ich brauchte ein Setup, bei dem der Agent die Arbeit macht und ich trotzdem noch verstehe, was passiert.

    Was ich tatsächlich verwende

    Alles folgt demselben einfachen Muster:

    • Workers mit statischen Assets. Jede Website ist ein Ordner mit einfachem HTML, CSS und ein bisschen JavaScript, dazu ein kleines Skript (ein „Worker“), das im Netzwerk von Cloudflare läuft. Kein Server, um den ich mich kümmern muss.
    • D1 für die Datenbanken. Unter der Haube steckt SQLite. Die Daten sind also eine einzige Datei, die ich herunterladen und selbst öffnen könnte, wenn ich wollte.
    • R2 für Dateien, etwa die Foto-Uploads auf einer Vereinsseite oder die Bilder auf diesem Blog.
    • Cloudflare Access, um alles Private hinter einen Login zu stellen. Meine Finanz-App ist nur erreichbar, nachdem ein Code an meine eigene E-Mail-Adresse gegangen ist. Ein eigenes Login-System musste ich dafür nicht bauen.
    • DNS am selben Ort. Die Domains liegen ohnehin bei Cloudflare. Eine neue Subdomain mit einem Worker zu verbinden, ist eine Zeile in einer Konfigurationsdatei.

    Und das Wichtigste: Alles ist in Dateien im Projekt beschrieben. Pro Projekt gibt es eine Konfigurationsdatei, in der steht, welche Datenbank, welcher Speicher-Bucket und welche Domain verwendet werden. Ein Deploy ist ein einziger Befehl. Kein Herumklicken in Dashboards, an das sich eine Woche später niemand mehr erinnert.

    Warum das so gut zu Nicht-Entwicklern passt

    Ein Ort, eine Rechnung, großteils gratis. Meine Websites haben keine Millionen Besucher. Das kostenlose Kontingent deckt fast alles ab, und falls ich es je überschreite, startet der bezahlte Workers-Plan bei fünf Dollar im Monat. Ich habe nicht fünf Hosting-Anbieter mit fünf Logins und fünf Rechnungen.

    Nichts zu patchen. Unter meinen Websites liegt kein Betriebssystem, für das ich verantwortlich bin. Allein das beseitigt die unangenehmste Art von Problemen für jemanden wie mich.

    Agenten verstehen es. Das hat mich überrascht. Weil das ganze Setup aus Dateien besteht (eine Konfiguration, ein Datenbankschema, ein Ordner mit Seiten), kann ein KI-Agent es lesen, ändern und deployen. Wenn ich sage: „Füge eine Seite hinzu, die die Ladevorgänge vom letzten Monat zeigt“, weiß der Agent, wo die Datenbank ist, wie sie aufgebaut ist und wie er die Änderung live bringt. Ein Hosting-Setup, das in einem Web-Dashboard lebt, ist für den Agenten unsichtbar. Ein Setup in Dateien ist etwas, womit er arbeiten kann.

    Zurückrollen ist eingebaut. Jeder Deploy ist eine Version. Wenn etwas kaputtgeht, ist der Weg zurück ein einziger Befehl. Bei zwei Vereinswebsites habe ich das alte Hosting sogar parallel weiterlaufen lassen: Der Worker sitzt einfach davor. Entferne ich eine Route, ist die alte Seite wieder live. Genau so ein Sicherheitsnetz willst du, wenn du nicht ganz sicher bist, ob du weißt, was du tust.

    Sicherheit, die ich nicht selbst bauen musste. Access vor eine App zu stellen, war ein einziger Einrichtungsschritt. Einen sicheren Login selbst zu bauen (oder besser gesagt: darauf zu vertrauen, dass ein Agent ihn richtig baut) wäre ein viel größeres Risiko gewesen.

    Was schiefgegangen ist (damit du es nicht wiederholen musst)

    Zauberei ist es nicht. Ein paar Dinge haben mich erwischt, und alle stehen jetzt in den Projekten, damit weder ich noch der nächste Agent wieder darauf hereinfallen:

    • Zwei Konten, ein Fehler. Ich habe ein berufliches und ein privates Cloudflare-Konto auf demselben Laptop. Ein Agent hat einmal eine Datenbank im falschen Konto angelegt, weil das Tool, das er verwendet hat, mit dem beruflichen Konto verbunden war. Jetzt steht in jedem privaten Projekt die ID des privaten Kontos in der Konfiguration. Ein Deploy ins falsche Konto schlägt damit einfach fehl.
    • „Auto-Deploy“ hat nicht deployed. Eine Website sollte sich bei jedem Push auf GitHub neu deployen. Irgendwann hat sie damit einfach aufgehört, ohne jede Meldung. Die Lösung war nicht technisch, sondern eine Gewohnheit: Nach einer Änderung prüfen, welche Version live ist.
    • Ein Login, der keiner war. Bei einer App hat Cloudflare die HTML-Dateien direkt ausgeliefert, noch bevor meine Login-Prüfung überhaupt lief. Die Daten dahinter waren geschützt, die Seite selbst nicht. Eine einzige Einstellung („Worker zuerst ausführen“) hat es behoben. So etwas findest du nur, wenn du wie ein Außenstehender testest.
    • Fehlermeldungen lügen manchmal. Einmal behauptete das Deploy-Tool, ich sei nicht eingeloggt. Ich war es. Ein Plugin hatte einen Ordner angelegt, der es durcheinandergebracht hat. Ein Agent hat das in Minuten gefunden. Ich hätte Tage gebraucht.

    Worum es eigentlich geht

    Jahrzehntelang hieß „Ich bin nicht technisch“ so viel wie „Dafür brauche ich jemanden aus der IT oder eine Agentur“. Mit KI-Agenten ändert sich das, aber nur, wenn die Plattform darunter einfach genug ist, dass du den Überblick behältst. Für mich ist diese Plattform Cloudflare. Für dich ist es vielleicht eine andere.

    Meine Faustregel: Wähle eine Plattform, auf der sich dein ganzes Setup in einfachen Dateien aufschreiben lässt. Dann können sowohl du als auch deine Agenten es lesen. Genau das macht aus „Der Agent hat mir ein bisschen Code geschrieben“ ein „Ich betreibe das selbst“.

    Dieser Blog ist übrigens mein neuestes Experiment. Er läuft auf EmDash, einem neuen Open-Source-CMS, das auf Cloudflare läuft, und ich teste es als Alternative zu WordPress. Mehr dazu, wenn ich eine Weile damit gelebt habe.

  • Mach deine KI widersprechbar

    Mach deine KI widersprechbar

    Vor ein paar Wochen hatten unsere KI-bewerteten Chat-Reports ein Problem. Jeden Morgen markierte der Report eine Handvoll „verpasster Verkaufschancen“ in unseren Live-Chats. Und jeden Morgen schaute sich unser Vertriebsteam die Fälle an und sagte: Nein, das war keine Chance. Dieser Kunde hatte schon einen Partner. Diese Frage war rein technisch.

    Die KI war nicht dumm. Sie lag jeden Tag auf dieselbe Weise selbstbewusst falsch, weil ihr niemand etwas anderes gesagt hat.

    In dem Moment habe ich die wichtigste Designregel für KI-Reports im Marketing verstanden: Eine Analyse, der niemand widersprechen kann, wiederholt ihre Fehler jeden Tag.

    Daumen runter, mit Begründung

    Die Lösung war fast peinlich einfach. Jede KI-Bewertung in unseren Reports hat jetzt einen Daumen hoch und einen Daumen runter. Für den Daumen runter gibt es eine Bedingung: Du musst eine Begründung schreiben. Ein Satz reicht. „Kunde arbeitet schon mit einem Partner.“ „Das war eine Support-Frage, kein Sales-Lead.“

    Der Durchlauf am nächsten Tag liest diese Begründungen, bevor er irgendetwas bewertet. Die Fehler verschwinden nicht über Nacht, aber sie wiederholen sich nicht mehr. Und genauso wichtig: Das Vertriebsteam hat aufgehört, den Report zu ignorieren, weil es jetzt eine Möglichkeit hatte, ihn mitzugestalten.

    Zwei Dinge habe ich dabei gelernt:

    Chat-Report: von der KI bewertete Chats, das Transkript direkt neben der Note
    Nachgestellte Ansicht mit erfundenen Daten: So sieht das echte Tool aus, aber alle Namen und Zahlen hier sind ausgedacht.
    • Die Begründung zählt mehr als die Stimme. Ein Daumen runter allein sagt der KI, dass sie falschlag, aber nicht warum. Ohne das Warum wird sie einfach überall vorsichtiger.
    • Feedback ist auch ein Vertrauenssignal. Einem Report, mit dem die Leute streiten können, vertrauen sie viel mehr als einem polierten, bei dem das nicht geht.

    Lass die KI keine Kategorien erfinden

    Die zweite Lektion kam von den Themen-Labels. Wir ordnen jeden Chat und jedes Ticket einem Thema zu, damit wir sehen, wonach Kunden am häufigsten fragen. Für einen Durchlauf habe ich den KI-Sub-Agenten eine Liste mit Beispielthemen mitgegeben, als kleine Hilfe.

    Sie haben sie als Inspiration verstanden. Zurück kamen fünfzehn neue, erfundene Labels, alle leicht unterschiedlich, die ich dann von Hand wieder unseren echten Kategorien zuordnen musste. Ein Trenddiagramm auf Basis von Labels, die sich von Durchlauf zu Durchlauf ändern, ist wertlos.

    Die Regel lautet jetzt: Die Labels sind eine geschlossene Liste. Passt ein Gespräch nicht dazu, antwortet der Sub-Agent mit „Sonstiges“ und ergänzt einen Vorschlag. Am Ende des Durchlaufs schaut sich die Hauptsession alle Vorschläge auf einmal an und entscheidet, ob sich ein neues Label lohnt. Von den ersten acht Vorschlägen wurden drei zu echten Labels. Die anderen fünf waren Varianten bestehender.

    Wenn du Zahlen über die Zeit vergleichen willst, gilt: Die KI darf Kategorien befüllen, aber nicht festlegen.

    Ablehnen statt raten

    Wir haben außerdem einen Dokumentations-Bot gebaut, der Produktfragen aus unserer Wissensdatenbank beantwortet. Bevor wir ihn auf Kunden losgelassen haben, haben wir ihn mit 200 echten Fragen aus Support-Tickets getestet und die Antworten von einem anderen Modell beurteilen lassen.

    Das Ergebnis war ernüchternd und nützlich. Nur ein kleiner Teil der Antworten war vollständig richtig. Die meisten waren teilweise richtig: hilfreich, um jemanden zum passenden Artikel zu schicken, aber unvollständig. Ein paar Prozent waren falsch, und eine war eine echte Halluzination: ein Befehl, den es gar nicht gibt.

    Wir haben den Bot nicht aufgegeben. Wir haben seine Aufgabe geändert. Er ist jetzt ein Wegweiser durch die Dokumentation, kein Ersatz für den Support. Und wir haben eine Konfidenzschwelle eingebaut: Deckt die gefundene Dokumentation die Frage nicht eindeutig ab, sagt der Bot, dass er es nicht weiß, und übergibt. Ein ehrliches „Weiß ich nicht“ ist mehr wert als eine flüssige falsche Antwort.

    Der Doku-Bot antwortet mit Quelle und übergibt, wenn er unsicher ist
    Nachgestellte Ansicht mit erfundenen Daten: So sieht das echte Tool aus, aber alle Namen und Zahlen hier sind ausgedacht.

    Dasselbe Prinzip gilt für unsere Analyse-Tools. Eine unserer Regeln für den Report zu Dokumentationslücken: Behaupte nie, etwas sei „nicht dokumentiert“, ohne mit mindestens zwei unterschiedlichen Formulierungen danach gesucht zu haben. Kunden und die Leute, die Dokumentation schreiben, verwenden selten dieselben Wörter.

    Abbrechen, nicht erfinden

    Viele unserer Reports laufen jeden Morgen automatisch, ohne dass jemand zuschaut. Deshalb ist eine Regel nicht verhandelbar: Fehlen Daten oder bricht eine Verbindung ab, stoppt der Durchlauf und sagt das auch. Er füllt die Lücken nicht mit plausiblen Zahlen.

    Klingt selbstverständlich. Ist es nicht. Der Instinkt eines Sprachmodells ist, hilfreich zu sein, und „hilfreich“ heißt bei fehlenden Daten: etwas erfinden. Du musst ihm ausdrücklich und schriftlich sagen, dass ein abgebrochener Report besser ist als ein erfundener.

    Den Beleg direkt neben das Urteil

    Das letzte Muster ist das einfachste. Jede Bewertung, jedes markierte Ticket, jede Content-Idee in unseren Tools verlinkt zurück auf die Quelle: das vollständige Chat-Protokoll, das tatsächliche Ticket, die echten Instagram-Kommentare, auf denen eine Idee beruht. Jeder kann durchklicken und nachprüfen.

    Das bewirkt zweierlei. Fehler werden schnell sichtbar. Und die Menschen behalten die Gewohnheit, sich die echten Gespräche anzuschauen, wo die eigentlichen Erkenntnisse ohnehin liegen.

    Eine Checkliste für deine eigenen KI-Reports

    Wenn du KI-gestützte Reports im Marketing baust, würde ich das hier vom ersten Tag an einbauen:

    1. Ein Daumen runter, der eine Begründung verlangt, und ein nächster Durchlauf, der sie liest.
    2. Geschlossene Listen für alles, was du über die Zeit zählen willst. „Sonstiges plus Vorschlag“ statt erfundener Labels.
    3. Eine Konfidenzschwelle. Ablehnen statt raten.
    4. Abbruch bei fehlenden Daten. In den Anweisungen festgeschrieben, nicht vorausgesetzt.
    5. Ein Beleg neben jedem Urteil. Ein Link zur Quelle, immer.

    Bei alldem geht es nicht um bessere Modelle. Es geht darum, die Arbeit der KI zu etwas zu machen, das Menschen prüfen, anzweifeln und verbessern können. Genau das macht aus einer beeindruckenden Demo ein Tool, auf das sich ein Team wirklich verlässt.

  • Dein erfolgreichster Post lügt dich an

    Dein erfolgreichster Post lügt dich an

    „Welche unserer Posts funktionieren am besten, und wovon sollten wir mehr machen?“

    Das ist die naheliegendste Frage, die du einer KI zu deinen Social-Media-Kanälen stellen kannst. Es ist aber auch eine Frage, bei der die KI komplett und selbstbewusst danebenliegen kann und dir Empfehlungen gibt, die genau in die falsche Richtung zeigen.

    Uns ist genau das passiert. Hier ist, wie es dazu kam, und welche Regeln wir seitdem befolgen.

    Das Quartal, das keines war

    Als ich zum ersten Mal einen Agenten unsere Performance auf YouTube und Instagram analysieren ließ, sahen die Ergebnisse großartig aus. Ein Quartal stach mit Abstand als unser stärkstes heraus, mit durchschnittlich um ein Vielfaches mehr Aufrufen pro Video als in jedem anderen Quartal. Die Empfehlung der KI: mehr von dem machen, was wir damals gemacht haben.

    Das Problem: In diesem Quartal liefen zwei große Kampagnenfilme mit ordentlich Mediabudget dahinter. Die haben nicht „performt“. Für ihre Sichtbarkeit wurde bezahlt. Als wir sie herausgenommen haben, fiel der Durchschnitt für dieses Quartal ungefähr auf ein Zehntel, und es stellte sich heraus, dass es unser schwächstes Quartal war, nicht unser bestes.

    Jede Empfehlung auf Basis der ersten Version wäre falsch gewesen. Und sie hätte vollkommen plausibel ausgesehen, mit Diagrammen und allem Drum und Dran.

    Regel 1: Trenn bezahlt von organisch, bevor du irgendetwas rankst. Nicht als Fußnote, nicht als Filter, den man optional setzen kann. Als ersten Schritt, jedes Mal. Wir nennen das inzwischen unsere eiserne Regel, und sie steht in den Analyse-Anweisungen, damit kein Agent sie überspringen kann.

    Ein Ausreißer lässt alles andere schlecht aussehen

    Selbst nachdem wir die Kampagnen entfernt hatten, stießen wir auf ein zweites Problem. Ein beworbenes Video hatte so viele Aufrufe, dass daneben jedes normale Video winzig wirkte. In einem Ranking nach Durchschnittswerten sah ein ganz normales gutes Video mehr als hundertmal schlechter aus als der Spitzenreiter. Das ist keine Erkenntnis, das ist Rauschen.

    Wir sind auf Mediane umgestiegen. Der Median zeigt dir, was ein typischer Post leistet. Den einen Post, der viral gegangen ist oder beworben wurde, ignoriert er. Plötzlich wurden die Unterschiede zwischen Formaten und Themen wieder sichtbar: welche Arten von Posts verlässlich etwas besser laufen und welche verlässlich etwas schlechter.

    Regel 2: Nimm den Median für „typisch“, und schau dir Ausreißer getrennt an. Ausreißer sind interessant. Sie sollten nur nicht deine Basislinie bestimmen.

    „Engagement“ ist nicht gleich Engagement

    Unterschiedliche Plattformen zählen unterschiedliche Dinge. Auf einem Netzwerk enthielt das „Engagement“ im Analytics-Tool auch Link-Klicks, auf einem anderen nicht. Legst du sie nebeneinander, wirkt eine Plattform aus rein technischen Gründen viel ansprechender als die anderen.

    Regel 3: Vergleich innerhalb einer Plattform, nicht plattformübergreifend, außer du hast geprüft, dass die Zahlen dasselbe bedeuten.

    Eine Kennzahl, drei Definitionen

    Dasselbe Problem gibt es auch in Unternehmen. Für eine unserer zentralen Geschäftskennzahlen haben wir drei verschiedene Definitionen gefunden, die im Umlauf waren, in drei verschiedenen Präsentationen. Jede war vertretbar. Zusammen führten sie dazu, dass jedes Meeting mit einer Debatte darüber begann, wessen Zahl stimmt.

    Gelöst haben wir es, indem wir die Definition einmal aufgeschrieben haben, an einem einzigen Ort, und ein kleines Tool gebaut haben, das sie live aus dem CRM berechnet. Niemand muss der Definition für immer zustimmen. Aber alle verwenden dieselbe, bis sie geändert wird, an genau diesem einen Ort.

    Regel 4: Jede Kennzahl hat genau eine schriftliche Definition. Vor allem, wenn eine KI rechnet. Sie nimmt die Definition, die sie zuerst findet.

    Achte aufs Kleingedruckte

    Ein paar weitere Fallen, in die wir getappt sind:

    • Währungen. Als wir den Partnerumsatz über Länder hinweg mit einem einzigen Schwellenwert verglichen haben, wirkten Partner in Ländern mit einer anderen Währung um ein Vielfaches größer, als sie waren. Rechne immer um, bevor du vergleichst.
    • Auto-Replies. „95 % der Nachrichten beantwortet“ kann heißen: „95 % der Leute haben eine automatische Nachricht bekommen.“ Schau dir an, wie schnell die Antworten kamen.
    • Datenschutz in den Daten. Manche Analytics-Exporte enthalten Links zu Profilbildern mit Zugriffstokens darin. Entferne die, bevor irgendetwas gespeichert oder angezeigt wird.

    Lass die KI zählen, nicht denken

    Das alles heißt nicht, dass KI schlecht in Analytics ist. Bei den mühsamen Teilen ist sie hervorragend: Daten aus APIs holen, sie bereinigen, das Sentiment Tausender Kommentare bewerten, Content-Ideen entwerfen, die auf die echten Posts und Kommentare verlinken, aus denen sie stammen.

    Aber sie hat keine Ahnung, dass für einen Post bezahlt wurde, dass eine Plattform anders zählt oder dass dein Unternehmen eine Kennzahl auf eine bestimmte Weise verwendet. Sie liefert so oder so einen schönen, selbstbewussten Report.

    Die Checkliste ist also kurz:

    1. Bezahltes zuerst raus. Immer.
    2. Mediane für die Basislinie, Ausreißer extra.
    3. Vergleich Gleiches mit Gleichem.
    4. Eine Definition pro Kennzahl, einmal aufgeschrieben.
    5. Lies ein paar der Top-Posts selbst, bevor du dem Ranking glaubst.

    Dein erfolgreichster Post ist vielleicht wirklich dein bester. Stell nur sicher, dass er es sich verdient hat.