Das Marketingteam von GitHub in Japan und Südkorea verwandelte wiederkehrende Veranstaltungsprozesse in ausführbare Workflows innerhalb von GitHub, anstatt jeden Schritt manuell zwischen Registrierungsseiten, Links, E-Mail-Kampagnen und Kundendatenbanken zu verwalten. Laut Tomoko Tanaka beginnt der Prozess mit einem einzigen GitHub Issue. Anschließend übernimmt GitHub Actions die Einrichtung der Veranstaltung, die Prüfung der Teilnehmerlisten und die Nachbereitungsarbeiten nach ihrem Ende.
Der Beitrag stellt keineswegs ein neues Produkt vor, sondern beschreibt eine von Tanaka entwickelte operative Praxis, die auf bereits vorhandenen GitHub-Tools basiert und GitHub Copilot nutzt, um interne Verfahrensleitfäden in Automatisierungen umzuwandeln. Die Bedeutung des Versuchs liegt darin, Marketingmanagement mit Konzepten zu verbinden, die Softwareteams vertraut sind, etwa Review, Änderungsverlauf, Trigger und wiederholbare Workflows.
Das Problem: Kleine Schritte und aufeinanderfolgende Fehler
Zu den Veranstaltungen des Teams gehören regelmäßige Webinare für Unternehmensentwickler, Community-Treffen in Tokio und geschlossene Sitzungen für Führungskräfte in Seoul. Nach der Genehmigung einer Veranstaltung beginnt eine Reihe wiederkehrender Aufgaben: eine Landingpage kopieren, für jeden Kanal Links mit UTM-Tags erstellen, die Einladungsnachricht vorbereiten, einen Versandauftrag einreichen, die Veranstaltung zu zwei Projektboards hinzufügen und anschließend bis zum Veranstaltungstermin täglich die Teilnehmerliste herunterladen und bereinigen.
Nach dem Ende der Veranstaltung müssen die Anwesenheitsliste exportiert, für den Upload in ein Customer-Relationship-Management-System umformatiert, die entsprechenden Tags zu den Datensätzen hinzugefügt und ein Bericht erstellt werden. Kein einzelner Schritt wirkt schwierig, doch ein Fehler in einem Link, einem Kampagnennamen oder einer täglichen Aktualisierung kann sich auf Berichte und nachgelagerte Prozesse auswirken.
Drei Bausteine zum Aufbau des Workflows
Der Versuch stützte sich auf drei grundlegende Funktionen in GitHub:
- Issue Forms: Sie dienen als strukturierte Antragsformulare anstelle eines leeren Textfelds und erfassen Felder wie Veranstaltungstitel, Datum, Region, Kampagnenname und Zielgruppe. Es gibt unterschiedliche Formulare für Webinare und Präsenzveranstaltungen, die jedoch dieselbe Ausführungslogik speisen.
- Labels: Sie werden nicht nur als beschreibende Tags verwendet, sondern auch als Ausführungsschlüssel. Wird beispielsweise das Label event-setup hinzugefügt, startet der zugehörige Workflow.
- GitHub Actions: Sie führen die Aufgaben aus, lesen die im Anfragetext enthaltenen Felder und verbinden sich mit externen Tools, um die Veranstaltung einzurichten, Teilnehmer zu verfolgen oder die abschließenden Arbeiten durchzuführen.
Durch dieses Design wird das Issue zur Arbeitseinheit, die Planung, Diskussion und Status zusammenführt und einen sichtbaren Verlauf der Entscheidungen sowie einen Link zu jeder Änderung bereitstellt. Auch Änderungen am Workflow können als Softwareänderungen behandelt werden, die vor dem Zusammenführen über einen Pull Request geprüft werden.
Die Rolle von GitHub Copilot bei der Umwandlung von Verfahren in Automatisierungen
Tanaka begann nicht damit, den Code direkt zu schreiben. Stattdessen verfasste sie die betrieblichen Leitfäden des Teams und stellte sie GitHub Copilot zur Verfügung, um die Automatisierung im Dialog weiterzuentwickeln. Sie sagt, dass ihre frühere Erfahrung mit dem Betrieb von Datenbanken auf Linux-Servern ihr half, diese Verfahren als programmierbare Pipeline zu betrachten, auch wenn sie einräumt, dass ihre Programmierkenntnisse nicht mehr dem früheren Stand entsprechen.
Die Planung beginnt mit einem Gespräch, in dem die Idee beschrieben wird, etwa die Organisation eines Webinars über KI-gestützte Entwicklung im November. Anschließend liest Copilot die Datei AGENTS.md im Stammverzeichnis des Repositorys. Dabei handelt es sich um einen in Markdown verfassten Leitfaden, der Regeln für Kampagnenbenennungen, die Zuordnung von Quartalen zu Daten, Zeitzonen und Kriterien für Einladungsnachrichten festlegt. Auf Grundlage dieser Regeln und einer ähnlichen früheren Veranstaltung schlägt Copilot einen Kampagnennamen vor, erstellt zwei Versionen der Einladungsnachricht und stellt die im Verfahrensleitfaden vorgesehenen Fragen.
Was ändert sich in der Praxis?
Dieser Ansatz reduziert wiederkehrende manuelle Arbeiten, ohne die menschliche Entscheidung in der Planungsphase abzuschaffen. Das Gespräch lässt Raum für die individuelle Gestaltung einer bestimmten Veranstaltung, während die Automatisierung nach der Genehmigung die festen Schritte übernimmt. Dem Beitrag zufolge dauerte die manuelle Vorbereitung einer Veranstaltung ungefähr zwei Tage. Nun beginnt der Prozess mit einem einzigen Issue und führt anschließend die Einrichtung, die tägliche Prüfung der Teilnehmerlisten und die Bereinigung nach dem Ende der Veranstaltung aus.
Entscheidend ist nicht GitHub Actions allein, sondern die Programmierbarkeit der anderen Tools. Die Veranstaltungsmanagementplattform verfügt über eine API, während das Customer-Relationship-Management-System eine offizielle CLI verwendet, die die benötigten Aufgaben abdeckt und die Anmeldung über den Browser durchführt. Daher musste Tanaka dafür keinen API-Schlüssel einrichten. Die Schlussfolgerung des Beitrags lautet, dass das Vorhandensein einer API oder CLI ausreicht, um einen Weg für eine programmatische Integration zu eröffnen, unabhängig davon, ob es sich um eine Veranstaltungsplattform, ein CRM-System, einen Formularersteller oder einen Analysedienst handelt.
Der Versuch zeigt außerdem, warum der Aufbau eines maßgeschneiderten Workflows in einer Umgebung mit mehreren Märkten bevorzugt werden kann. Das APAC-Team arbeitet nicht als ein einziger Markt: Dasselbe Webinar kann in Tokio auf Japanisch und in Seoul auf Koreanisch stattfinden, mit unterschiedlichen Zielgruppen, CRM-Feldern und Kriterien für die Definition eines qualifizierten Leads. Tanaka zufolge kann die Anpassung einer fertigen Plattform an diese Unterschiede Budgets für Anpassungen und Beratung sowie das Warten auf die Roadmap des Anbieters erfordern, während ein interner Aufbau die Änderung des Workflows über einen Pull Request und eine Prüfung ermöglicht.
Dies ist kein Rezept dafür, fertige Marketingplattformen abzuschaffen, und auch kein Beleg dafür, dass Automatisierung für jedes Team geeignet ist. Der praktische Wert des beschriebenen Falls liegt darin, die Arbeit zunächst zu dokumentieren und dann Entscheidungen, die menschliche Flexibilität erfordern, von wiederkehrenden Schritten zu trennen, die automatisch ausgeführt werden können. Der Erfolg des Modells hängt außerdem davon ab, dass externe Tools integrierbar sind und die Verfahrensleitfäden präzise bleiben. Sind die Regeln unvollständig oder werden sie geändert, ohne aktualisiert zu werden, können sich die Fehler in den automatisierten Workflow verlagern, anstatt zu verschwinden.