Stefan Kummerlöw · Probeaufgabe · Automation Manager

Post Closer Call: Workflow Konzeption

Die Probeaufgabe verlangt einen Workflow, der nach jedem relevanten Closer Call automatisch einen personalisierten Gmail-Entwurf erstellt, auf Basis des vorgegebenen Toolsets Fireflies, Close und Gmail.

Mein Ansatz: Trigger und Lead-Matching laufen deterministisch über Metadaten, ein einziger LLM-Aufruf wertet das Transkript aus. Der Draft füllt eine feste Vorlage, kein Freitext, keine stillen Fehler, volle Kontrolle beim Closer.

Fireflies.ai · Recording & Transkript
Close · Lead-Matching & Daten
Gmail · Drafts & Versand

Kontext & Ziel

Situation heute

  • Vertriebscalls werden mit Fireflies aufgezeichnet & transkribiert
  • Leads und Gesprächshistorie sind in Close CRM gepflegt
  • Follow-up-Mails werden aktuell vollständig manuell verfasst
  • Bestehende E-Mail-Vorlage: statischer Rahmen + dynamische Felder
  • Prozess ist zeitaufwendig und fehleranfällig
  • Kein automatisches Versenden — Nutzer prüft und versendet selbst

Automatisierungsziel

  • Relevante Closer Calls automatisch erkennen
  • Transkript-Daten aus Fireflies extrahieren
  • Meeting dem richtigen Lead in Close zuordnen
  • Gmail-Draft auf Basis der Vorlage befüllen
  • Nutzer per Notification mit direktem Draft-Link informieren
  • Robuste Fallbacks für jede Fehlersituation
Kernprinzip: Human-in-the-Loop Der Entwurf wird nicht automatisch versendet. Der Nutzer behält volle Kontrolle und prüft vor dem Senden.

Die 8 Schritte im Detail

SCHRITT 01
Relevanten Closer Call erkennen
INPUT „Transcription complete"-Webhook von Fireflies nach Meeting-Ende
CHECK Primär über Metadaten: Kalender-Tag oder Deal-Stage in Close (z. B. Stage = „Closing"). Nur wenn Metadaten fehlen: optionaler LLM-Aufruf setzt Flag is_closer_call. Kein LLM-Aufruf für jedes beliebige Meeting: spart Kosten und Latenz.
OUTPUT is_closer_call = true → Workflow läuft weiter; kein Tag / false → Abbruch ohne Aktion
SCHRITT 02
Daten aus Fireflies extrahieren
INPUT Meeting-ID aus dem Fireflies-Webhook-Payload
CHECK API-Aufruf an Fireflies: Metadaten (Datum, Titel, Teilnehmer-E-Mails) und Transkript-Text werden eingesammelt. Datenabholung über die Fireflies GraphQL API.
OUTPUT Datum, Titel, Teilnehmer-E-Mails und Transkript-Text; E-Mails fließen direkt in das Lead-Matching (Schritt 03)
SCHRITT 03
Meeting zu Lead in Close matchen
INPUT Teilnehmer-E-Mails und -Domains aus Schritt 02
CHECK API-Abfrage Close: E-Mail-Domain-Matching (z. B. @acme-corp.de → Firma „Acme Corp"). Bei 0 oder 2+ Matches: Draft wird trotzdem erstellt (generische Anrede) und ein Task mit hoher Priorität in Close angelegt.
OUTPUT Close Lead-ID bei 1 Match. 0 oder 2+ Matches: Draft mit generischer Anrede + Prioritäts-Task in Close zur manuellen Klärung
SCHRITT 04
Relevante CRM-Daten abrufen
INPUT Close Lead-ID aus Schritt 03
CHECK API-Abfrage Close: Kontaktdaten, Deal-Status, historische Aktivitäten & Call-Notizen
OUTPUT Name, E-Mail, Unternehmen, Status, letzte Gesprächsnotizen, offene Punkte
SCHRITT 05
Gesprächsinhalte aus Transkript extrahieren
INPUT Vollständiges Transkript + CRM-Kontext aus den Vorschritten
CHECK Einmaliger LLM-Aufruf mit strukturiertem Prompt. Gibt zurück: is_closer_call (true/false), Pain Points, besprochene Lösung, Next Steps, wichtige Zahlen (Budget, Laufzeit). Formatiert als JSON
OUTPUT false → Workflow endet, kein Draft. true → strukturiertes JSON fließt direkt in die Vorlage (Schritt 06)
SCHRITT 06
Gmail Draft anhand der Vorlage erstellen
INPUT Strukturiertes JSON aus Schritt 05 + CRM-Stammdaten + feste Follow-up-Vorlage
CHECK Template-Engine befüllt vordefinierte Platzhalter per String-Ersetzung: Name, Firma, Datum (aus CRM/Fireflies) sowie 1–3 Textbausteine aus der LLM-Auswertung.
OUTPUT Gmail Draft-ID + direkter Link; Betreff-Schema: [Follow-up] Firma – Datum – Closer Call
SCHRITT 07
Nutzer informieren, Draft auffindbar machen
INPUT Draft-Link + Lead-Name + Firma aus Schritt 06
CHECK Task mit hoher Priorität in Close anlegen: „Neuer Follow-up-Draft erstellt – bitte prüfen und versenden" + direkter Link. Der Draft ist über das konsistente Betreff-Schema in Gmail sofort auffindbar. Slack wäre eine sinnvolle Erweiterung, liegt aber außerhalb des vorgegebenen Toolsets.
OUTPUT Task in Close angelegt, Draft über Gmail-Suche via Betreff-Schema sofort auffindbar
SCHRITT 08
Fehlerfälle & Fallbacks definieren
FEHLER Transkript-Timeout · kein eindeutiger CRM-Match · API-Fehler Close oder Gmail · LLM gibt is_closer_call = false zurück
FALLBACK Fehlerhinweise werden NICHT in den Draft geschrieben (Risiko versehentliches Senden). Alle Probleme landen als Tasks in Close. Bei unsicheren Daten: konservativer, generischerer Draft statt riskanter Platzhaltertext.
ZIEL Keine stillen Fehler — jede Ausnahme wird als Task in Close dokumentiert und dem Nutzer sichtbar gemacht

Workflow-Flowchart

Alle Pfade inklusive Entscheidungsknoten und Fehler-Abzweigungen

Automatisierter Prozessschritt
Entscheidungsknoten
Fehler- / Fallback-Pfad
Start- / Erfolgszustand
          flowchart TD
          %% Start: Transkript ist fertig
          START([Fireflies: Transcription complete]) --> B{Ist der Termin als
Sales-/Abschlussgespräch markiert?} %% 1. Relevanten Closer Call erkennen (ohne LLM) B -->|Ja: Markierung in CRM/Kalender| C[API-Aufruf Fireflies:
Metadaten + Transkript abrufen] B -->|Nein| Z1[Ende: kein Trigger] %% 2. Daten aus Fireflies extrahieren C --> F[Fireflies-Daten nutzen:
Teilnehmer-E-Mails · Titel · Datum · Transkript] %% 3. Meeting zu Lead in Close matchen F --> F1[API-Aufruf Close:
Kontakt- & Domain-Matching] F1 --> G{Match-Ergebnis?} G -->|1 eindeutiger Kontakt| H[CRM-Daten laden
Name · Firma · Stage] G -->|0 oder 2+ Kontakte/Firmen| Z3[Task in Close:
Match klären
Draft mit generischer Anrede] %% 4 + 5. CRM-Infos + Gesprächsinhalte (ein LLM-Call) H --> I[LLM aufrufen:
Transkript + CRM-Kontext →
is_closer_call + Pain Points + Next Steps] Z3 --> I %% Sicherheitscheck: wirklich Closer? I --> J{is_closer_call = true?} J -->|false| Z4[Ende: kein Draft erstellt] J -->|true| L[Template befüllen:
Name + Firma + Datum +
LLM-Textbausteine] %% 6. Gmail-Draft erstellen L --> M{Gmail API:
Draft erstellen} M -->|API-Fehler| Z5[Task in Close:
API-Fehler
max. 3 Retry-Versuche] M -->|Erfolg| N[Task in Close:
Draft-Link für Follow-up von Firma-Datum] %% 7. Nutzer informieren N --> END([Nutzer sieht Task in Close,
prüft Draft und versendet]) classDef error fill:#FEF2F2,stroke:#EF4444,color:#991B1B classDef success fill:#F0FDF4,stroke:#22C55E,color:#166534 classDef process fill:#EFF6FF,stroke:#3B82F6,color:#1E3A8A classDef decision fill:#FFFBEB,stroke:#F59E0B,color:#92400E class Z1,Z3,Z4,Z5 error class START,END success class C,F,F1,H,I,L,N process class B,G,J,M decision
Automatisierter Prozessschritt
Entscheidungsknoten
Fehler- / Fallback-Pfad
Start- / Erfolgszustand

Gmail Draft Mockup (Interaktive Demo)

Simulierte Gmail-Oberfläche mit dem automatisch generierten Entwurf. Die Vorlage ist fest vorgegeben, der Text wird nicht frei generiert, sondern per String-Ersetzung befüllt. Gelb markierte Felder kommen dynamisch aus CRM oder Transkript-Auswertung, alles andere ist statischer Vorlagentext.

{{Feld}} Dynamisch aus Close CRM
{{Feld}} Dynamisch aus Fireflies-Transkript
MK
+
Verfassen
Posteingang 12
Markiert
Gesendet
Entwürfe 1
Alle Mails
Spam
Papierkorb
Hauptordner
Soziale Netzwerke
Werbung
Notion
Weekly digest — Your workspace activity this week...
Mo.
GitHub
PR #142 was merged — New activity in your repository...
Di.
⚡ Automation
Entwurf [Follow-up] Acme Corp – 24.02.2025 – Closer Call — Hallo Max, vielen Dank für unser heutiges Gespräch...
Jetzt
Stripe
Payment processed — Invoice #INV-2024-0089...
Di.
Neuer Entwurf
An max.mustermann@acme-corp.de
Betreff [Follow-up] Acme Corp24.02.2025 – Closer Call

Hallo Max,


vielen Dank für unser heutiges Gespräch. Es war sehr aufschlussreich, mehr über Acme Corp und Ihre aktuellen Herausforderungen zu erfahren.


Ihre zentralen Herausforderungen:

  • Manuelle Reporting-Prozesse kosten ca. 8 Std./Woche
  • Fehlende Integration zwischen CRM und Buchhaltung

Vereinbarte nächste Schritte:

  • Technisches Setup-Gespräch bis 28.02.2025
  • Angebot mit Starter-Paket wird bis Freitag zugesandt

Wie besprochen, erhalten Sie das finale Angebot für das Starter-Paket (3 Monate · €1.200/Monat) in den nächsten Tagen.


Ich freue mich auf Ihre Rückmeldung und stehe für Rückfragen jederzeit zur Verfügung.


Mit freundlichen Grüßen,
Markus Klein
Sales Manager · Company GmbH · +49 151 1234 5678

← Klick mich

Designentscheidungen & Herausforderungen

🔔

Trigger-Logik: Wann startet der Workflow?

Fireflies sendet einen „Transcription complete"-Webhook. Die Erkennung, ob es ein Closer Call ist, stützt sich primär auf Metadaten nicht auf ein Sprachmodell.

  • Primärcheck: Kalender-Tag oder Deal-Stage in Close (z. B. Stage = „Closing") deterministisch und kostenlos
  • Nur wenn Metadaten fehlen oder widersprüchlich sind: optionaler LLM-Aufruf setzt das Flag is_closer_call
  • Vorteil: Kein LLM-Aufruf für jedes beliebige Meeting, was Kosten und Latenz gezielt reduziert
  • Herausforderung: Sales-Kalendereinträge sind diskret benannt (kein „Closer Call" im Titel) → Lösung: CRM-Stage als primäre Quelle
🎯

Matching-Strategie: Lead in Close finden

Das Matching läuft über E-Mail-Domains der Teilnehmer gegen Close-Kontakte und -Unternehmen.

  • Primär: Exakter E‑Mail-Abgleich auf Kontakt-Ebene (z. B. max.mustermann@acme‑corp.de → Kontakt in Close).
  • Fallback: Domain-Abgleich (z. B. @acme‑corp.de → Unternehmen ‚Acme Corp‘ in Close), wenn kein eindeutiger Kontakt gefunden wird.
  • 1 Kontakt-Match → Lead wird direkt zugeordnet, Workflow läuft automatisch weiter.
  • 0 oder 2+ Kontakte/Firmen → Draft wird trotzdem erstellt (generische Anrede) + Task mit hoher Priorität in Close, um den Match manuell zu klären.
  • Warum kein LLM? Matching-Fehler durch ein Sprachmodell wären schwerer zu erkennen und nachzuvollziehen als ein klarer ‚kein eindeutiger Treffer‘.
🧠

Transkript-Auswertung: Einmaliger LLM-Schritt

Wir nutzen ein Sprachmodell genau einmal: um das Transkript auszuwerten und die wichtigsten Gesprächspunkte strukturiert herauszuziehen. Das ist der einzige LLM-Aufruf im gesamten Workflow.

  • Prompt gibt zurück: is_closer_call (true/false), Pain Points, besprochene Lösung, Next Steps, wichtige Zahlen
  • Der Draft-Text wird danach nicht frei generiert. Die LLM-Ausgabe liefert nur 1–3 Textbausteine für die Vorlage
  • Output ist ein definiertes JSON-Schema; die Felder sind vorgegeben, nicht offen formuliert
  • Historische Call-Notizen aus Close können als Prompt-Kontext mitgegeben werden, um Wiederholungen zu vermeiden
🛡️

Fehler-Handling: Keine stillen Fehler

Fehlerhinweise und technische Warnungen gehören nicht in den Kunden-Draft. Das Risiko: interne Markierungen werden versehentlich mitgesendet.

  • Alle Auffälligkeiten (unklarer Match, fehlende Felder, API-Fehler) werden als Tasks in Close dokumentiert, nie im E-Mail-Text
  • Bei Datenlücken: der Draft bleibt bewusst generischer statt mit unsicheren Inhalten befüllt zu werden
  • API-Fehler Close / Gmail → max. 3 automatische Retry-Versuche, danach Task in Close
  • Lieber ein etwas allgemeinerer Draft, den der Nutzer minimal ergänzt, als ein riskant vollautomatischer
🗓️

Diskretion: Meeting-Benennung im Kalender

Sales-Termine werden bewusst nicht immer als „Closer Call" betitelt — das wäre in Kundenmeetings unpassend. Die Call-Erkennung kann sich deshalb nicht allein auf den Kalendertitel stützen.

  • Primäre Erkennung über interne CRM-Stage in Close (z. B. Deal-Stage = „Closing") oder interne Kalender-Tags
  • Sekundär: optionaler LLM-Check des Transkripts, falls Metadaten fehlen oder widersprüchlich sind
  • Grenzfälle (z. B. geplantes Closing-Meeting ohne Transkript) → Task in Close: „Transkript fehlt, bitte prüfen"
  • So bleibt die Erkennung robust, ohne auf eine strikte Titelkonvention angewiesen zu sein
🚦

Menschliche Fehler & Kommunikationsrisiken

Der größte Risikofaktor ist nicht die Technik, sondern die Gefahr, dass ein unfertig geprüfter Draft versehentlich versendet wird oder interne Hinweise an den Kunden gelangen.

  • Interne Warnungen, Fehlermarkierungen oder technische Hinweise werden NIE in den Draft geschrieben
  • Alle Auffälligkeiten landen als Tasks in Close, sichtbar für den Nutzer, aber getrennt vom E-Mail-Text
  • Das System erzeugt lieber einen etwas allgemeineren Draft als einen mit unsicheren oder internen Inhalten
  • Bewusste Designentscheidung: Kontrolle beim Menschen lassen, Automation nur dort, wo sie zuverlässig ist

Next Steps & Ausbaumöglichkeiten

Der nächste Schritt

Gefällt euch, was ihr hier seht?

Die Architektur steht, die Designentscheidungen sind begründet, jetzt fehlt nur noch das Gespräch. Ich freue mich darauf, den Rest des Teams kennenzulernen und offene Fragen direkt zu klären.