KI Action Items aus Meeting-Notizen: Der komplette Workflow

KI Action Items aus Meeting-Notizen: Der komplette Workflow

Action Items sind nur dann relevant, wenn sie die 10 Minuten nach dem Meeting überstehen. Meistens tun sie das nicht. Das Meeting endet, alle nicken bei "kümmern wir uns darum", und bis Freitag erinnert sich niemand mehr, wer was zu tun hat. Dieser Guide ist die genaue Command-Kette, um ein Rohtranscript in zugewiesene, terminierte Aufgaben in Notion oder Linear zu verwandeln – ohne eine Zeile neu zu tippen. Das funktioniert mit drei Slash-Befehlen und einem Notizer-Tool deiner Wahl.

Warum Action Items zwischen Meeting und CRM sterben

Niemand verliert Action Items mit Absicht. Sie sterben in der Lücke zwischen "jemand hat es gesagt" und "jemand ist dafür zuständig". Ein Transcript erfasst alle "sollten wir" und "kannst du" aus dem Meeting – aber ein Transcript ist keine Task-Liste. Es sind 4.000 Wörter Dialog mit drei echten Verpflichtungen mittendrin.

Die Lösung ist nicht ein besseres Notizer-Tool. Sie ist ein Command, der das Transcript so liest wie ein Operations-Lead: auf der Suche nach einem Verb, einem Verantwortlichen und einem Termin – und alles als "unklar" markiert, dem eines dieser drei Elemente fehlt, statt es zu erraten. Fellow's Analyse von AI Meeting Agents zeigt das gleiche Problem aus Sicht des Anbieters: Die Tools, die gewinnen, sind nicht die mit dem sauberen Transcript – sondern die, die dir eine Task-Liste geben, die du bestätigen kannst, statt sie neu zu schreiben.

Die meisten Teams haben bereits einen Notizer. Was sie nicht haben, ist die mittlere Schicht: der Schritt zwischen "hier ist eine Zusammenfassung" und "hier ist eine Task in dem System, in dem mein Team arbeitet". Diese mittlere Schicht ist ein Slash-Befehl, keine neue SaaS-Subscription – und genau die baut dieser Guide.

Schritt 1: Wähle den Notizer, der tatsächlich Owner und Deadline extrahiert

Bevor der Slash-Befehl irgendetwas anfasst, brauchst du ein Transcript mit Struktur. Nicht jeder Notizer extrahiert Action Items gleich, und der Unterschied ist wichtiger als die Transkriptions-Accuracy-Quote auf der Landingpage.

Briefing, 30 Sekunden: Wenn ein Bot im Meeting ändern würde, was Leute in einem Deal Review sagen, überspring Bot-basierte Tools und geh Bot-frei. Sonst: Optimiere dafür, wie sauber das Tool Entscheidungen von Action Items trennt.

Fathoms Summary-Struktur ist bereits out-of-the-box nah an dem, was du brauchst: Es trennt Entscheidungen, Action Items und offene Fragen in separate Blöcke statt einer Textwand. Das ist genau das Format, das dein /recap-Command in Schritt 2 parsen wird.

Fireflies ist Sales-Ops-fokussiert: Es pusht Action Items direkt in HubSpot oder Salesforce Felder – nützlich, wenn deine Action Items wirklich "nächste Schritte bei diesem Deal" sind statt interner Aufgaben.

Granola schickt keinen Bot ins Meeting. Es transkribiert lokal und layert deine eigenen notierten Notizen über das Transcript – damit die Action Items, die es extrahiert, an das verankert sind, was du als wichtig markiert hast, nicht nur an das, was die KI für wichtig hielt.

Wähle einen aus. Lauf nicht zwei Notizer im gleichen Meeting, um die Accuracy zu cross-checken. Das verdoppelt die Cleanup-Arbeit, und der /recap-Command unten erwartet ein kanonisches Transcript, nicht zwei widersprüchliche.

Schritt 2: Build den /recap-Command, der das Transcript in eine Task-Liste verwandelt

Öffne CommanderGPT, geh ins Workflow Builder und erstelle einen neuen Command namens /recap. Der Prompt macht drei Dinge, in dieser Reihenfolge:

1. Hol dir das Transcript (paste es, oder zeig den Command auf den Export-Link des Notizers, falls dein Plan API-Export unterstützt)

2. Extrahiere jeden Satz, der ein Commitment-Muster erfüllt: "ich werde", "wir sollten", "kannst du", "lass uns"

3. Gib für jeden Match drei Felder aus: Task, Owner, Deadline. Falls Owner oder Deadline fehlt, gib "unklar" aus statt zu erraten

Diese dritte Regel überspring die meisten Teams – und es ist die, die zählt. Eine KI, die einen Owner errät wenn das Transcript keinen nennt, verschiebt die Mehrdeutigkeit nur nach hinten; du merkst drei Tage später, dass "das Team" es nicht gemacht hat, weil niemand im Team dachte, dass es sein Job ist.

Hier ist der genaue Command-Body, den ein RevOps Lead auf Deal-Review Calls laufen lässt:

/recap [paste transcript]
→ Extract action items as: - [ ] Task | Owner | Due date
→ Flag "unclear" if owner or date is missing, do not infer
→ Ignore decisions and FYIs, only output actionable commitments

Lauf ihn einmal auf einem echten Transcript, bevor du ihm bei einem echten Deal Review traust. Der erste Pass auf einem 45-Minuten-Call mit sechs Sprechern braucht normalerweise eine Korrektur-Runde: jemand wird "schau dir die Pricing an" sagen ohne einen "du" zu nennen, und der Command sollte es flaggen, nicht stillschweigend dem zuletzt Sprechenden zuweisen.

Schritt 3: Rout Action Items in Notion oder Linear – ohne Copy-Paste

Wenn /recap eine saubere Liste ausspuckt, nimmt der zweite Command in der Kette, /sync, diese Liste und erstellt die echten Tasks. Das ist der Schritt, den die meisten Teams manuell machen – und der kostet am meisten Zeit: sechs Zeilen aus einer Summary-Email in sechs separate Notion-Reihen kopieren.

Falls dein Team bereits in Notion lebt, mappt /sync jede extrahierte Reihe zu einem Database-Eintrag: Task-Name, Owner (gematcht gegen deine Teamliste), Due Date, Link zur Meeting-Recording. Für Engineering-nahe Operations-Teams auf Linear erstellt der gleiche Command ein Issue statt einer Database-Reihe, getaggt mit dem Meeting-Datum damit es später nachverfolgbar ist.

Das Mapping ist beim ersten Mal nicht automatisch. /sync muss wissen, welche Notion-Property den Owner-Namen hält und welche den Deadline-Termin – und Linear braucht ein Default-Team und Issue-Template, bevor es einen neuen Issue von einem Command akzeptiert statt von einem Menschen, der "New Issue" klickt. Skip diesen Setup und der Command schlägt entweder still fehl, oder noch schlimmer, erstellt Issues im falschen Team-Backlog.

Der Setup-Aufwand ist real: Rechne mit 20 bis 30 Minuten, um deine Notion-Database-Felder oder Linear-Issue-Templates beim ersten Mal zu mappen. Danach: null manuelle Eingabe pro Meeting. Ein CS-Ops-Team, das wir gekannt haben, lief das auf einem wöchentlichen QBR-Prep-Call – schnitt eine 25-Minuten-Post-Meeting-Cleanup auf einen 90-Sekunden-Review-and-Approve-Schritt herunter. Das ist keine universelle Zahl; deine Cleanup-Zeit hängt davon ab, wie viele Action Items ein typischer Call bei dir produziert – aber das ist die Form des Gewinns: Minuten Review statt Minuten Neu-tippen.

Kette /recap → /sync → /notify: Der Workflow, der selbst läuft

Die komplette Kette sind drei Commands, nicht zwei. Der dritte, /notify, sendet einen Slack DM an jeden Owner mit seinen spezifischen Action Items und dem Deadline – direkt nachdem /sync fertig ins Notion oder Linear geschrieben hat.

Im Workflow Builder geketten zusammen sieht die Sequenz so aus: Transcript rein, /recap extrahiert, /sync erstellt die Tasks, /notify pingt die Owners. Kein Dashboard zum Checken, keine Digest-Email zum Skippen. Der Owner der Task kriegt die Nachricht, dass er Owner ist, innerhalb einer Minute nachdem das Meeting endet – während der Kontext noch frisch genug ist, dass er das ganze Transcript nicht nochmal lesen muss, um zu verstehen warum.

Hier ist wo die "3 Commands, 1 Workflow, 0 Reibung" Idee verdient wird: Jeder Command macht einen Job, und du kannst jeden von ihnen tauschen (einen anderen Notizer, ein anderes Ziel, ein anderer Notification-Channel) ohne die Kette neu zu bauen.

Wo das bricht: Recurring Meetings, leise Sprecher, vage Verben

Drei Fehler-Modi, die es wert sind, sie zu kennen, bevor du das auf ein ganzes Team loosest – nicht danach.

Recurring Meetings duplizieren Tasks, wenn /sync nicht vor dem Erstellen eines neuen Items gegen vorhandene offene Items mit dem gleichen Task-Namen checkt. Füg einen Dedupe-Check gegen offene Tasks der letzten 14 Tage ein, oder du endest mit einer Notion-Database voller "folge up mit Legal" Reihen von sechs verschiedenen Wochen.

Leise Sprecher werden übersprungen. Wenn jemand sich zu etwas in einem Side-Comment oder einer Chat-Message während des Calls verpflichtet statt es laut zu sagen – das Transcript sieht es nie und /recap auch nicht. Das ist eine echte Lücke, keine Tuning-Frage: Der Command extrahiert was gesagt wurde, nicht was gemeint war.

Vage Verben produzieren vage Tasks. "Lass uns über Pricing nachdenken" ist kein Action Item, es ist ein Diskussions-Topic – und ein gut eingestellter /recap sollte es als unklar flaggen statt für es einen fake Owner und Date zu fabrizieren. Wenn dein Command suspekt komplette Task-Listen aus vagen Meetings generiert – errätst du, nicht extrahierst du – und das lohnt sich zu auditen.

Was man nach 30 Tagen misst

Vertrau nicht dem Workflow-Wort, dass er funktioniert. Zwei Zahlen zum Tracken über 30 Tage nach dem Deployment: Completion Rate (von den Action Items, die /recap extrahiert hat, wie viele wurden tatsächlich bis zum Deadline fertig) und Manual Correction Rate (wie oft musstest du einen Owner oder Date fixen, den der Command falsch machte).

Wenn die Completion Rate flach bleibt gegen deine Pre-Automation-Baseline – der Engpass ist nicht Extraction, sondern Follow-Through – und kein Slash-Command-Chaining fixet ein Accountability-Problem. Wenn die Manual Correction Rate über eins von fünf extrahierten Items liegt nach den ersten zwei Wochen – dein /recap-Prompt braucht Verschärfung, nicht dein Notizer getauscht.

Wir haben dir kein Network-weites Benchmark zum Mitnehmen. Miss deine eigene Baseline in Woche eins, dann vergleich.

Dein nächster Command zum Setup

Start mit /recap allein. Lauf ihn auf deinem nächsten Deal Review oder QBR Prep Call – kopier den Output manuell einmal in Notion – und schau wie viel Korrektur er braucht bevor du /sync drähtest. Alle drei Commands am Tag eins zu kettten, bevor du der Extraction traust, heißt nur, dass du die falsche Task-Liste schneller automatisierst.

Wenn /recap saubere Owner-und-Date-Paare auf drei aufeinanderfolgenden Calls mit unter 20% Korrektur ausspuckt – füg /sync hinzu. Füg /notify zuletzt ein, wenn das Ziel richtig ist. Recon komplett bevor du die ganze Kette zu einem 10-Personen-Team shippst.