Ein Content-Workflow ist nicht einfach eine Liste aus „offen“, „in Arbeit“ und „fertig“. Er ist ein Vertrag darüber, wann ein Inhalt seinen Zustand wechseln darf, wer dann übernimmt und was bei einer Ausnahme passiert.
Diese Seite hilft dir, diesen Vertrag zu gestalten. Wenn du zunächst herausfinden musst, warum bereits begonnene Inhalte nicht veröffentlicht werden, starte mit der Backlog- und Wartezeitdiagnose. Dort geht es um den bestehenden Stau; hier um den zukünftigen Soll-Prozess.
Definiere Zustände als überprüfbare Ergebnisse
Ein Status sollte eine überprüfbare Aussage über den Inhalt machen. „Bei Redaktion“ beschreibt nur einen Ort. „Briefing vollständig“ oder „fachlich geprüft“ beschreibt ein Ergebnis, auf das sich die nächste Person verlassen kann.
Ein schlanker Redaktionsworkflow könnte so aussehen:
Ausgewählt → Briefing bereit → Entwurf bereit → Review entschieden → Veröffentlichung bereit → veröffentlicht
Die konkrete Zahl der Zustände ist zweitrangig. Jeder zusätzliche Zustand muss eine andere Entscheidung, Verantwortung oder Wartephase sichtbar machen. Wenn niemand anders handelt und kein neues Kriterium gilt, brauchst du wahrscheinlich keinen eigenen Status.
Der Sechs-Felder-Vertrag für jeden Zustand
Beschreibe jeden relevanten Zustand mit denselben sechs Feldern:
- Zustand: Welches überprüfbare Ergebnis liegt vor?
- Verantwortlicher: Genau eine Rolle hält den Ball.
- Eingangsauslöser: Welches Ereignis startet diese Phase?
- Pflichteingaben: Was muss vor Arbeitsbeginn vorhanden sein?
- Ausgangskriterium: Was muss wahr sein, damit es weitergeht?
- Ausnahmeweg: Wohin geht ein blockierter, abgelehnter oder veralteter Inhalt?
Das Prinzip hinter Auslösern und Prüfkriterien findet sich auch in Workflow-Dokumentation: Atlassian trennt etwa Trigger für einen Übergang von Validatoren, die Bedingungen vor dem Abschluss prüfen. Das ist ein nützliches Modell, keine Produktempfehlung.
Beispiel: Der Übergang vom Entwurf ins Review
| Feld | Arbeitsregel |
|---|---|
| Zustand | Entwurf bereit |
| Verantwortlicher | Redakteur bis zur Annahme durch Reviewer |
| Eingangsauslöser | Briefing erfüllt und Entwurf abgelegt |
| Pflichteingaben | Ziel, Kernbotschaft, Quellen, CTA, Format |
| Ausgangskriterium | Reviewer nimmt an oder gibt gebündelt zurück |
| Ausnahmeweg | Fehlende Belege → zurück zu „Briefing bereit“; strategischer Konflikt → Entscheidung nötig |
So wird aus „Bitte einmal anschauen“ eine eindeutige Übergabe. Der Empfänger weiß, welche Prüfung erwartet wird; der Absender weiß, wann die Arbeit wirklich übergeben ist.
Rückwege gehören zum normalen Prozess
Ein Workflow, der nur vorwärts zeigt, versteckt die häufigsten Fälle. Plane mindestens diese Rück- und Seitenwege:
- Überarbeitung: Feedback ist konkret und der Entwurf bleibt aktiv.
- Blockiert: Eine benannte Abhängigkeit fehlt; Eigentümer und Prüftermin sind gesetzt.
- Pausiert: Das Thema ist weiterhin gültig, aber nicht aktuell priorisiert.
- Verworfen: Eine bewusste Entscheidung beendet die Arbeit und hält den Grund fest.
„Blockiert“ darf kein Lagerplatz ohne nächste Prüfung sein. Jeder blockierte Inhalt braucht Ursache, zuständige Person und Termin. Sonst entsteht genau der unsichtbare Rückstau, den der Workflow verhindern sollte.
Eigentum wechselt an der Übergabe
Für jeden aktiven Inhalt muss jederzeit genau eine Rolle die nächste Bewegung verantworten. Beteiligte dürfen mehrere sein; Eigentum sollte nicht geteilt sein. Definiere deshalb für jeden Übergang:
Wer übergibt? Wer nimmt an? Woran erkennt die empfangende Rolle Vollständigkeit? Bis wann reagiert sie?
Die von Atlassian beschriebene Content-Entwicklung mit sichtbaren Phasen und Revisionen illustriert diesen Grundgedanken. Dein eigener Ablauf sollte jedoch nur Zustände enthalten, die dein Team tatsächlich pflegt.
Automatisiere erst stabile Übergangsregeln
Automatisierung eignet sich für eindeutige Folgen: nach angenommener Übergabe eine Aufgabe erzeugen, bei überschrittener Reaktionszeit erinnern oder nach Veröffentlichung die Messung terminieren. Sie kann aber nicht entscheiden, was „reviewbereit“ bedeutet, wenn das Team darüber uneinig ist.
Teste den Workflow zunächst mit drei realen Inhalten. Notiere bei jedem Übergang:
- War das Ausgangskriterium eindeutig?
- Konnte die nächste Rolle ohne Rückfrage starten?
- War bei einer Ausnahme der Rückweg klar?
- Blieb zu jeder Zeit eine Person für die nächste Bewegung verantwortlich?
Erst wenn diese Fragen stabil beantwortet sind, lohnt sich die Abbildung in einem System.
Nächster Schritt im Content-Pfad
Hast du noch keinen klaren Engpass, prüfe zuerst, warum Content liegen bleibt. Ist dein Zustands- und Übergabemodell dagegen definiert, gehe weiter zu Marketing Automation Tools und bewerte Systeme danach, ob sie genau diese Regeln, Ausnahmen und Verantwortlichkeiten abbilden können.