Wofür ein Protokoll wirklich da ist
Ein Meeting-Protokoll löst drei Probleme, und keines davon heißt „festhalten, dass das Meeting stattgefunden hat“. Es fixiert Vereinbarungen, damit einen Monat später niemand streitet, worauf man sich geeinigt hatte. Es verteilt Verantwortung: Jede Handlung bekommt einen Namen und ein Datum. Und es trägt Kontext zu denen, die nicht dabei waren, ohne Nacherzählung auf dem Flur.
Daraus folgt das Qualitätskriterium: Ein Protokoll taugt genau so weit, wie jemand, der nicht im Meeting war, danach handeln kann. Wenn diese Person nach dem Lesen immer noch nicht weiß, was entschieden wurde und was jetzt zu tun ist, funktioniert das Dokument nicht — egal, wie viele Seiten es hat.
Einzelgespräche, Brainstormings ohne Entscheidungen, zehnminütige Status-Calls. Ein schlechtes Protokoll ist schlimmer als keines: Es erzeugt den falschen Eindruck, etwas sei vereinbart, und wird später als Quelle der Wahrheit zitiert. Gab es keine Entscheidungen, sind drei Zeilen im gemeinsamen Kanal ehrlicher als ein leeres Dokument.
Die sieben Abschnitte
Die Reihenfolge ist nicht zufällig: Sie geht von dem, was am schnellsten verstanden werden muss, zu dem, was selektiv gelesen wird. Entscheidungen stehen über der Diskussion, weil den Lesenden das Ergebnis interessiert und nicht der Weg dorthin.
- Kopf. Thema, Datum, Beginn und Ende, wer das Meeting geleitet hat. Die Dauer ist keine Formalie: Sie zeigt, was die Frage gekostet hat, wenn ein halbes Jahr später jemand entscheidet, ob man sich wieder zusammensetzt.
- Teilnehmende. Wer da war und wer eingeladen war, aber nicht kam. Der Unterschied zählt: Wer fehlt, ist durch eine Entscheidung nicht automatisch gebunden, muss aber informiert werden. Die explizite Abwesenheitsliste ist die Liste derer, denen das Protokoll persönlich zugeht.
- Kontext. Ein bis zwei Sätze dazu, warum das Meeting überhaupt stattfand. Drei Monate später ist das das Einzige, was den Rest lesbar macht.
- Entscheidungen. Der Kernabschnitt. Was genau beschlossen wurde — als Liste, jeder Punkt einzeln, mit Angabe, wer entschieden hat.
- Aufgaben. Die Handlungen, die sich aus den Entscheidungen ergeben: Formulierung, genau eine verantwortliche Person, Frist.
- Offene Fragen. Was besprochen, aber nicht entschieden wurde. Der Abschnitt, den man am häufigsten streicht — zu Unrecht: Genau er verhindert, dass eine Frage bis zum nächsten Mal verloren geht.
- Materialien. Links zu Dokumenten, Entwürfen und Dashboards, von denen die Rede war.
Entscheidungen: wie man sie formuliert
Der häufigste Fehler hier ist, den Prozess statt des Ergebnisses aufzuschreiben. „Termine besprochen“, „über das Budget geredet“ — das beschreibt, wie die Zeit verging, nicht, wozu man kam. Eine Entscheidung muss sich wie eine Aussage lesen, die man auf Wahrheit prüfen kann.
Die Formel, die trägt: was beschlossen wurde + auf welcher Grundlage + wer entschieden hat. Die Grundlage braucht es, weil Entscheidungen revidiert werden, und in einem Monat lautet die Frage nicht „was haben wir entschieden“, sondern „warum haben wir es so entschieden“.
Verschiebung des Release besprochen. Einig, dass man noch nachdenken und darauf zurückkommen muss.
Das Release verschiebt sich vom 5. auf den 12. August. Grundlage: Die Billing-Migration ist nicht fertig, das Risiko verlorener Zahlungen wiegt schwerer als die Kosten der Verschiebung. Entschieden: Anna, Product Owner.
Die erste Fassung lässt sich nicht prüfen: unklar, ob das Release verschoben ist, wer wann darauf zurückkommt. Formal gibt es einen Eintrag, faktisch keine Vereinbarung. Die zweite beantwortet drei Fragen auf einmal: neues Datum, Grund und die Person, an die ein Einwand geht.
Zur Formulierung „kommen wir nochmal drauf zurück“
Das ist keine Entscheidung, sondern deren Abwesenheit. Ist die Frage wirklich vertagt, braucht die Vertagung eine verantwortliche Person und ein Datum: „Die Preisstaffel ist bis zum 15. September vertagt; Igor nimmt sie mit den August-Zahlen wieder auf.“ So ein Eintrag gehört zu den offenen Fragen, nicht zu den Entscheidungen.
Aufgaben: was sie machbar macht
Eine Aufgabe aus dem Protokoll unterscheidet sich von einer im Tracker in einem Punkt: Niemand kommt und präzisiert sie. Also muss sie für sich stehen — allein aus der Formulierung muss klar sein, was als erledigt gilt.
- Ein Tätigkeitsverb am Anfang. „Schicken“, „abstimmen“, „sammeln“ — nicht „der Kostenvoranschlag“ oder „die Sache mit den Zugängen“.
- Ein Kriterium für „fertig“. Wohin schicken, in welcher Form, wem zeigen. Ohne das schließt die Aufgabe nach dem Gefühl der ausführenden Person.
- Genau eine verantwortliche Person. „Das Entwicklungsteam“ heißt, dass es niemand macht: Verantwortung, die auf mehrere verteilt ist, gehört niemandem.
- Ein Datum, nicht „nächste Woche“. Relative Fristen verfallen in dem Moment, in dem das Protokoll später gelesen wird als gedacht.
Über den Kostenvoranschlag für Phase zwei nachdenken. Verantwortlich: das Team. Frist: nächste Woche.
Den Kostenvoranschlag für Phase zwei in den Kanal #budget schicken, aufgeschlüsselt nach Rollen. Verantwortlich: Igor. Bis: 8. August.
„Nachdenken“ kann man weder abgeben noch prüfen. „Das Team“ nimmt allen gleichzeitig die Verantwortung. „Nächste Woche“ bedeutet nichts mehr, sobald das Protokoll an einem anderen Montag geöffnet wird. In der zweiten Fassung sieht man den Ablageort, die Form des Ergebnisses, einen Namen und ein Kalenderdatum.
Drei Fehler, die das Protokoll entwerten
- Ein Transkript statt eines Protokolls. Die wörtliche Mitschrift ist Ausgangsmaterial, kein Dokument. Niemand wird sie lesen: Das Nützliche steckt zwischen Rückfragen, Scherzen und Rückgriffen auf bereits Geklärtes. Das Transkript ist das, woraus ein Protokoll gewonnen wird — ersetzen kann es es nicht.
- Entscheidungen ohne Verantwortliche. „Einigung, das Recruiting zu beschleunigen“ ohne Namen heißt: Niemand hat angefangen. Die Prüfung ist einfach — wenn Sie zu jedem Punkt die Person nennen können, der Sie morgen schreiben, ist der Abschnitt fertig.
- Das Protokoll zwei Tage später. Die Erinnerung verliert schnell an Genauigkeit, und mit ihr der Wert des Dokuments: Strittige Formulierungen lassen sich nicht mehr rekonstruieren, und die Beteiligten erinnern sich unterschiedlich. Die praktische Frist ist derselbe Tag, solange das Meeting wenigstens beim Verfassenden frisch ist.
Fertige Vorlage
In Markdown — lässt sich ohne Anpassung in jeden Editor, Tracker oder jede Wissensbasis einfügen.
# Protokoll: [Thema des Meetings] **Datum:** [TT.MM.JJJJ], [Beginn]–[Ende] **Leitung:** [Name] **Teilnehmende:** [Namen, durch Komma getrennt] **Abwesend:** [Namen; „keine“, wenn alle da waren] ## Kontext [1–2 Sätze: warum wir zusammengekommen sind] ## Entscheidungen 1. [Was beschlossen wurde]. Grundlage: [warum]. Entschieden: [Name, Rolle]. 2. … ## Aufgaben | Was zu tun ist | Wer | Bis | |---|---|---| | [Verb + Objekt + Kriterium für fertig] | [ein Name] | [TT.MM] | ## Offene Fragen - [Frage]. Wir kommen darauf zurück am [TT.MM], verantwortlich: [Name]. ## Materialien - [Titel](Link)
Protokoll-Generator
Felder ausfüllen, und das Protokoll setzt sich nach der Vorlage oben zusammen. Es wird nichts irgendwohin geschickt: Alles wird im Browser berechnet, und die Seite speichert nichts von dem, was Sie eingeben.
Checkliste vor dem Versand
Acht Prüfungen, jede fängt ihre eigene Klasse von Problemen ab. Haken setzen — der Zähler zeigt den Stand.
Was man nicht von Hand machen muss
Entscheidungen, Aufgaben und offene Fragen lassen sich aus dem Transkript ziehen: Ihre Formulierungen werden fast immer laut ausgesprochen. Whisperer führt das Transkript des Meetings und baut daraus strukturierte Notizen mit Action Items — Ihnen bleibt, die Formulierungen zu prüfen und fehlende Daten zu ergänzen. Von Hand bleibt das, was von Hand bleiben soll: zu entscheiden, was überhaupt als Entscheidung gilt.
Prüfen muss man trotzdem: Das Modell hört eine Vereinbarung gut, weiß aber nicht, welche der beiden Annas im Unternehmen für Billing zuständig ist. Namen und Termine sind das Einzige, was sich immer nachzulesen lohnt.