Die teuerste Ressource in Ihrem Unternehmen ist die Synchronität. Dass fünf Experten zur gleichen Zeit im gleichen Zoom-Call sein müssen, um eine Routine-Entscheidung (z. B. eine Tool-Lizenz oder Budgetfreigabe) zu treffen, ist ein logistischer Albtraum.

Wenn einer im Urlaub ist, steht der Prozess still.

Im Decision-OS lösen wir das durch das Prinzip des Passive Consent („Lazy Consensus“). Die Regel lautet: „Der Zug fährt ab, wenn sich keiner auf die Gleise wirft.“ – wer schweigt, stimmt zu.

Damit dieses Prinzip nicht im Chaos endet, verlassen wir uns nicht auf individuelle Disziplin. Wir bauen einen Automaten. Dieser Artikel zeigt, wie Sie den 48-Stunden-Timer in Ihren Toolstack (Jira/Notion + Slack + Zapier/Make) integrieren.

1. Die Logik: Active Approval vs. Passive Consent

Bevor wir automatisieren, müssen wir den Algorithmus verstehen.

Legacy Mode (Active Approval): Ein Antrag bleibt PENDING, bis alle Stakeholder APPROVED geklickt haben.
Problem: Der Langsamste bestimmt das Tempo. Default = Stillstand.
Decision-OS Mode (Passive Consent): Ein Antrag wechselt automatisch auf DECIDED nach Ablauf einer Frist (t = 48h), sofern kein VETO eingeht.
Vorteil: Der Prozess läuft weiter. Default = Fortschritt.

Technisch betrachtet implementieren wir also einen Timeout mit Default-Entscheidung: Wird innerhalb der Frist kein Einspruch registriert, feuert das System die Transition auf DECIDED.

2. Der Trigger: Status „ASYNC REVIEW“

Wir erweitern die State Machine des Decision-Logs um den Status ASYNC REVIEW. Das ist der Startschuss für die Automatisierung.

Der Workflow:

Der DRI (Verantwortliche) bereitet das Ticket vor (Status: DRAFT).
Alle Pflichtfelder (Impact, Rationale, Consulted) sind gefüllt.
Der DRI setzt den Status auf ASYNC REVIEW – und damit den Timer in Gang.

Ab diesem Moment gehört der Prozess dem Bot. Kein manuelles Nachfassen per E-Mail, keine Kalendereinladung – die Automatisierung übernimmt das Monitoring.

3. Die Architektur des Bots (Schritt-für-Schritt)

Im Kern besteht der „48-Stunden-Bot“ aus vier Bausteinen, die Sie in Plattformen wie Zapier oder Make.com abbilden können.

Schritt 1: Der Broadcaster (Slack/Teams Notification)

Niemand schaut alle fünf Minuten ins Decision-Log. Wir müssen die Entscheidung in den Arbeitsstrom pushen.

Action: Sende Nachricht an Channel #decisions-feed.

Die Payload (vereinfacht):

⏳ ASYNC REVIEW GESTARTET
Titel: {{TicketName}}
DRI: {{User}}
Impact: {{ImpactLevel}}
Deadline: {{Now + 48h}}
👉 Wenn du bis zur Deadline kein Veto einlegst, gilt dies als Zustimmung.
[Button: Zum Ticket] [Button: Veto einlegen]

Das explizite Nennen der Konsequenz („Schweigen = Zustimmung“) ist juristisch und kulturell entscheidend. Es macht den Default klar: Fortschritt, nicht Warten.

Schritt 2: Der Timer (The Wait Step)

Action: Delay / Sleep für 48 Stunden (oder zwei Arbeitstage).

Tech-Tipp: Nutzen Sie, wo möglich, eine Business-Hours-Logik, damit eine Entscheidung von Freitagnachmittag nicht am Sonntagabend durchläuft, wenn niemand hinschaut. Viele Automations-Plattformen bieten dafür eigene Module oder Sie rechnen die Deadline selbst.

Schritt 3: Der Check (State Verification)

Nach Ablauf der 48 Stunden „wacht“ der Bot auf. Er darf aber nicht blind entscheiden. Zuerst prüft er, ob jemand manuell eingegriffen hat.

Action: Get Record (aus Jira/Notion).

Condition:

Wenn Status == "ASYNC REVIEW" → Niemand hat ein Veto eingelegt. → Proceed.
Wenn Status != "ASYNC REVIEW" → Jemand hat interveniert (z. B. auf DRAFT oder READY gestellt). → Automation abbrechen.

So stellen Sie sicher, dass manuelle Eskalationen respektiert werden und der Bot nicht „drüberbügeln“ kann.

Schritt 4: The Hammer (Auto-Transition)

Wenn der Status nach 48 Stunden unverändert ASYNC REVIEW ist, fällt der Hammer.

Action: Update Record Status to DECIDED.
Log-Entry: Schreiben Sie einen System-Kommentar ins Ticket: „Automatisch entschieden durch Lazy-Consensus-Protokoll nach 48h ohne Einspruch.“
Notification: Sende Nachricht an DRI: „Glückwunsch. Dein Ticket ist durch. Du kannst exekutieren.“

Damit ist die Entscheidung nicht nur getroffen, sondern auch auditierbar dokumentiert.

4. Exception Handling: Der Veto-Button

Was passiert, wenn jemand nicht einverstanden ist? Wir müssen die Hürde für ein Veto niedrig halten, aber formalisiert.

Bauen Sie einen Veto-Trigger:

Wenn ein Nutzer im Ticket den Status manuell auf DRAFT zurücksetzt oder in Slack den Button „Veto“ klickt:
- Die Automatisierung bricht ab (siehe Schritt 3).
- Das Ticket wandert auf die Agenda des nächsten Weekly Tactical Meetings (Status: READY).
- Der Nutzer wird aufgefordert, im Feld Comments den Grund einzutragen (z. B. neue Fakten oder ein schwerwiegendes Risiko).

Das System sortiert also automatisch:

Routine → geht durch (Auto-Decide).
Konflikt → geht ins Meeting (Human-Decide).

Fazit: Governance als Service

Mit diesem Setup verändern Sie die Rolle der Governance radikal. Sie ist nicht mehr der Verhinderer, der auf Unterschriften wartet. Sie ist der Enabler, der den Weg freiräumt, solange niemand „Stopp“ ruft.

Erfahrungswert aus Decision-OS-Piloten: Rund 80 % der Routine-Entscheidungen laufen lautlos durch, wenn der 48-Stunden-Timer sauber implementiert ist – Entscheidungen, für die früher wertvolle Meeting-Zeit verbrannt wurde.

Und das Beste: Alles ist messbar. Aus den Status-Transitions können Sie später KPIs wie Time-to-Decision, Re-Open-Rate und Async-Anteil direkt in Ihr BI-Dashboard übernehmen.

Automating Consent: Wie Sie den „48-Stunden-Timer“ technisch implementieren