In den Anwender-Communities rund um Enterprise-KI-Plattformen häufte sich diese Woche derselbe Befund: Workflows, die Meeting-Transkripte automatisch weiterverarbeiten, liefern seit Wochen keine Ergebnisse mehr. Kein Fehler, keine Warnung, kein rotes Lämpchen. Die Automation läuft formal weiter, sie hat nur nichts mehr zu tun.

Das ist die gefährlichste Art, wie eine Automation kaputtgehen kann. Eine Fehlermeldung erzeugt ein Ticket. Ein leeres Ergebnis erzeugt: nichts. Bis jemandem auffällt, dass die wöchentliche Zusammenfassung seit einem Monat leer ist.

Was passiert ist: das Ereignis hat sich geändert, nicht euer Workflow

Die Ursache in diesem Fall: Der Auslöser, der bei neuen Meeting-Transkripten feuert, reagiert nur noch, wenn der Nutzer das Meeting selbst organisiert hat. Vorher feuerte er für jedes Meeting, an dem der Nutzer teilnahm. Eine stille Änderung im Plattformverhalten, nirgends prominent dokumentiert, von den Betroffenen als Regression erlebt.

Besonders hart trifft es einen Fall, den viele Vertriebs- und Beratungsteams täglich haben: extern gebuchte Termine über geteilte Microsoft-365-Buchungsseiten. Dort erzeugt Microsoft automatisch ein Pseudo-Postfach als Meeting-Organisator. Hinter dieser Adresse steht kein Konto, also kann sich dort auch keine Integration anmelden. Diese Klasse von Meetings ist für organisatorgebundene Trigger nicht erreichbar. Nicht schwierig, nicht umständlich: strukturell unmöglich.

Wer seine Transkript-Pipeline auf diesem Trigger gebaut hat, hat also kein Konfigurationsproblem. Er hat auf ein Ereignis gewettet, das ihm nicht gehört.

Schritt 1: Inventur der Ereignis-Abhängigkeiten

Bevor irgendetwas umgebaut wird, braucht es eine Liste: Welche eurer Automationen hängen an einem Plattform-Ereignis, welche am Artefakt selbst?

Die Unterscheidung ist einfach. "Wenn ein Meeting endet" ist ein Ereignis. "Wenn eine Transkript-Datei im Ordner liegt" ist ein Artefakt. Ereignisse gehören der Plattform, die sie auslöst, und können sich jederzeit ändern. Artefakte liegen in eurer Infrastruktur und sind beobachtbar, egal wer sie erzeugt hat.

Geht die Liste durch und markiert jede Automation, die stirbt, wenn der Anbieter morgen die Auslöse-Logik ändert. Das Ergebnis ist meistens ernüchternd, und genau deshalb wertvoll.

Schritt 2: den Ablageort überwachen statt des Ereignisses

Der Konsens der erfahrensten Anwender in den Communities ist eindeutig: Robuste Transkript-Workflows beobachten den Ort, an dem das Transkript landet, nicht das Meeting-Ereignis. Der Umbau hat eine Feinheit, die man kennen muss: Der Ablageort ist nicht einheitlich. Bei Microsoft 365 landen Transkripte persönlicher Meetings im OneDrive des Organisators, Channel-Meetings schreiben nach SharePoint. Wer nur einen der beiden Orte beobachtet, verliert die Hälfte.

Der Umbau lohnt trotzdem: Eine Ablageort-Überwachung feuert auch für Meetings, die andere organisiert haben, auch für extern gebuchte Termine, sobald die Datei einmal da ist. Das Ereignis kann sich ändern, die Datei bleibt eine Datei.

Schritt 3: einen Fallback bauen, denn auch Ablageorte sind nicht heilig

Dieselbe Woche lieferte den Beleg, dass auch die robuste Variante einen Plan B braucht: Mindestens ein Team berichtet, dass in seinem Umfeld keine Transkript-Dateien mehr im OneDrive ankommen, nur noch die Videoaufzeichnung. Vermutlich eine anbieterseitige Änderung, Reichweite unklar.

Der funktionierende Fallback aus der Community: den Kalender als Quelle der Wahrheit nehmen. Erst die Meetings des Tages aus dem Kalender lesen, dann pro Meeting das Transkript über die Meeting-URL abholen. Mehr Schritte, aber jede Stufe ist beobachtbar, und wenn eine bricht, sieht man wo.

Die allgemeine Regel dahinter: Jede Automation braucht neben dem Hauptpfad eine Antwort auf die Frage "und woran merken wir, dass er nicht mehr funktioniert?". Ein leeres Ergebnis muss ein Signal sein, kein Schweigen.

Take

Automationen sterben selten laut. Sie sterben, wenn sich ein Ereignis ändert, das ihnen nie gehört hat. Wer seine Workflows am Artefakt festmacht statt am Ereignis, den Ablageort kennt und einen beobachtbaren Fallback hat, baut Automationen, die Plattform-Änderungen überleben. Wer das nicht tut, erfährt von der Änderung aus dem leeren Wochenbericht.

Enablement-Gespräch buchen (30 Min mit Sarah)