KI & Automation
Meeting-Agent: Protokolle, die man wiederfindet
Gute Meeting-Nacharbeit ist kein Transkript. Es sind Decision Log, Aufgaben mit Owner und Frist, plus eine Prüfung, ob Behauptungen im Transkript überhaupt vorkommen.
Was schiefgeht: Verlauf speichern statt Ergebnis führen
In einem typischen 10-15-Personen-Team verschwindet das Montagsmeeting so:
- drei Notizversionen in unterschiedlichen Docs
- „wir sollten …“ ohne Owner und Datum
- zwei Wochen später: „Was war zu Lieferant X beschlossen?“
- niemand findet die Belegstelle in unter fünf Minuten
Ops- und Meeting-Leitfäden sind hier einig: Notizen sind Outcomes, kein Gesprächsprotokoll. Entscheiden, Aufgaben, offene Punkte. Der Rest ist Ballast.
Zwei Listen, nicht eine
Vermischen Sie Decision Log und Aufgabenliste nicht. Sie beantworten unterschiedliche Fragen.
Decision Log (was gilt ab jetzt?)
| Entscheidung | Begründung kurz | Entscheider | Review |
|---|---|---|---|
| Lieferant X bis Q4 behalten | Preisvergleich unvollständig | Mira (Ops) | 30.09. |
| Hiring Freeze Sales | Pipeline unter Plan | Jonas (GF) | in 2 Wochen |
Regel: Steht kein Entscheider und kein Review-Datum, ist es oft noch eine Meinung, keine Entscheidung.
Aufgabenliste (wer liefert was bis wann?)
| Nr. | Aufgabe | Owner (eine Person) | Frist | Status | Quelle |
|---|---|---|---|---|---|
| 1 | Preisvergleich Lieferant X fertigstellen | Mira | Fr 12:00 | offen | Meeting 16.07. |
| 2 | Hiring-Freeze mit GF klären | Jonas | Mi | offen | Meeting 16.07. |
Regel aus der Praxis: eine namentliche Person, eine konkrete Aufgabe, ein hartes Datum. „Das Team“ ist kein Owner.
Zusätzlich hilft ein Parkplatz: Themen, die aufkamen, aber bewusst verschoben wurden. Sonst werden sie fälschlich als Beschluss notiert.
Betriebsrhythmus
Innerhalb einer Stunde nach dem Meeting: Listen teilen und Owner bestätigen. Nach ca. 48 Stunden: Blocker abfragen. Zu Beginn des nächsten Meetings: offene Punkte aus dem letzten Mal in 2 Minuten reviewen. Steht ein Punkt in drei aufeinanderfolgenden Logs ohne Fortschritt, ist das ein Prozessproblem, kein „zu wenig KI“.
Baseline in fünf Arbeitstagen
Zählen Sie eine Woche lang:
- Minuten Nacharbeit pro Meeting (inkl. Suchen und Nachfragen)
- Anteil Meetings mit Decision Log + Owner-Aufgaben am selben Tag
- Rückfragen „Was war beschlossen?“ innerhalb von sieben Tagen
- Aufgaben ohne Owner oder ohne Frist (sollte gegen null gehen)
Pilotziel: Nacharbeit runter, Owner-Quote hoch, Rückfragen seltener.
Qualität: Treue vor Eloquenz
Bei KI-Zusammenfassungen lohnt es sich, drei Fehlerarten getrennt zu prüfen, statt nur auf einen guten Gesamteindruck zu achten:
| Prüffrage | Was schiefgehen kann |
|---|---|
| Stimmen die Claims? | erfundene Beschlüsse, falsche Zahlen, ungerechtfertigte Sicherheit |
| Fehlt Wichtiges? | echte Entscheidung oder Aufgabe wurde weggelassen |
| Ist Unsicherheit markiert? | widersprüchliches Transkript wird als Klarheit verkauft |
Ein Fehlermuster, das selten in Checklisten steht, aber in der Praxis häufig auftritt: Überlappende Wortbeiträge und Durcheinanderreden verschlechtern die Transkriptqualität ausgerechnet an den Stellen, an denen mehrere Personen gleichzeitig sprechen, oft genau in strittigen Entscheidungsmomenten. Ein guter Meeting-Agent markiert solche Passagen als unsicher, statt sie stillschweigend zu einer glatten, aber falschen Aussage zu verdichten.
Praktischer Spot-Check vor dem Livegang (10-15 Fälle):
- Standardmeeting mit klaren Aufgaben
- Meeting ohne Beschluss → Agent darf nichts erfinden
- sensible Personal-/Kundenthemen → Review oder Stopp
- Widerspruch im Transkript → Unsicherheit markieren
- spätere Wissensfrage nur aus freigegebenen Quellen, mit Quellenhinweis
Wann der Meeting-Agent lohnt
Template oder fester Protokollant reicht, wenn Meetings selten sind und eine Person zuverlässig nachbereitet.
Meeting-Agent lohnt sich, wenn Meetings häufig Entscheidungen erzeugen, Wissen teamübergreifend auffindbar bleiben soll und Reporting aus denselben Quellen kommt.
Dann: ein Meeting-Typ, drei Outputs (Kurzfassung, Decision Log, Aufgaben), eine freigegebene Quellenmenge. Nicht „alles indexieren“.
Anti-Muster
- Transkript als Wissensdatenbank ohne Struktur
- Decision Log und Aufgaben in einem Freitext vermischen
- Owner = „Marketing“ oder „wir“
- Halluzination als Fakt in Statusmails
- Rechte für alle von Tag 1
- fünf Meeting-Typen und drei Tools im ersten Pilot
Mini-Pilot-Brief
Pilot: Meeting-Agent für [Meeting-Typ]
Quellen: [Liste], explizit freigegeben
Outputs: Kurzfassung + Decision Log + Aufgabenliste (+ Parkplatz)
Darf nicht: geheime Quellen, erfundene Beschlüsse, Versand ohne Review
Review: [Name] gibt kritische Entscheidungen frei
Owner: [Name]
Baseline-Woche: Nacharbeit ____ Min | Owner-Quote ____ | Rückfragen ____
Erfolg in 2-4 Wochen: Nacharbeit runter, Owner-Quote hoch,
weniger „Was war beschlossen?“
No-Go: wiederholte Falsch-Beschlüsse oder unklare Quellenlage
Fehlt der Brief: KI-Workshop. Zeitplan: KI-Agent Pilot in 30 Tagen.
Nächster Schritt
Für den Einstieg genügen ein Meeting-Typ, zwei getrennte Listen und eine Baseline-Woche. Danach folgt ein Pilot mit Review. Bei BitAutor werden Prototyp und erste Integration nach Scope angeboten.
Häufige Fragen zum Meeting-Agent
Ersetzt der Agent das Protokollieren komplett?
Nein. Er strukturiert Inhalte und entlastet bei Zusammenfassung und Aufgaben. Kritische Entscheidungen bleiben in menschlicher Freigabe.
Wie vermeide ich falsche Beschlüsse?
Mit Quellenbindung, getrennten Outputs (Decision Log vs. Aufgaben) und Review vor Versand.
Für welche Meetings lohnt sich der Einstieg?
Für wiederkehrende Meetings mit klaren Entscheidungen und hoher Nachbearbeitungslast.
Wie messe ich den Nutzen?
Baseline für Nacharbeit, Owner-Quote und Rückfragen vor Start, dann Vergleich nach 2-4 Wochen Pilot.
