Gespräche und Meetings automatisch nachbereiten

Das Gespräch mit dem Einkaufsleiter lief gut. Er hat ein Budget genannt, zwei Bedenken geäußert und um ein überarbeitetes Angebot bis Freitag gebeten. Dann kommt der nächste Termin, danach noch einer, und am Abend steht im CRM ein Eintrag mit dem Betreff „Telefonat" und sonst nichts. Die Zusage für Freitag steht in einem Notizbuch, das Budget im Gedächtnis eines Verkäufers, und die Vertriebsleitung sieht in der Pipeline eine Verkaufschance, deren Abschlussdatum seit drei Wochen nicht mehr stimmt.

Gesprächsnachbereitung ist die Arbeit, die in fast jedem Vertriebsteam zuerst liegen bleibt. Nicht, weil sie unwichtig wäre, sondern weil sie nach dem eigentlichen Termin kommt und niemand dafür Zeit eingeplant hat. Genau diese Arbeit lässt sich gut an einen Workflow übergeben: Das Transkript oder die Notizen liegen ohnehin vor, ein Sprachmodell kann daraus Struktur machen, und ameax ist der Ort, an dem das Ergebnis als Aktivität, Wiedervorlage und aktualisierte Verkaufschance landet. Für den Verkäufer heißt das: Was er nach dem Termin festhält, reicht als Rohmaterial. Was dann im CRM steht, ist vollständiger als der Eintrag, den er abends um sieben noch getippt hätte.

Der Ablauf im Überblick

Die Aufgaben sind klar verteilt. ameax ist das führende System und das Gedächtnis des Vertriebs: Dort liegen Kunde, Ansprechpartner, Historie und Verkaufschance, und dort landet auch das Ergebnis. n8n ist der Taktgeber, der die Schritte in der richtigen Reihenfolge ausführt und die API-Aufrufe macht. Das Sprachmodell bearbeitet nur den Text und liefert ein festgelegtes JSON zurück. Der Mensch gibt frei, wo eine Änderung Folgen für Forecast oder Kundenbeziehung hat.

1. Gesprächsende. Das Meeting- oder Telefonsystem stellt Transkript oder Notizen bereit und schickt sie per Webhook an n8n, oder n8n holt sie zeitgesteuert ab.
2. Zuordnung. n8n sucht die externen Teilnehmer über ihre E-Mail-Adresse in ameax und ermittelt Kunde und Ansprechpartner.
3. Kontext laden. n8n liest die offenen Verkaufschancen des Kunden und die letzten Aktivitäten, damit das Modell weiß, worum es geht.
4. Auswertung. Das Sprachmodell erzeugt aus Transkript und Kontext ein JSON mit Zusammenfassung, nächsten Schritten, Einwänden, Budget, Zeitrahmen, Stimmung und einer Selbsteinschätzung der Sicherheit.
5. Dokumentation. n8n legt in ameax eine Aktivität mit der Zusammenfassung an, verknüpft mit Kunde, Ansprechpartner und Verkaufschance.
6. Nächste Schritte. Für jeden vereinbarten Schritt entsteht eine Wiedervorlage mit Datum, Verantwortlichem und Priorität.
7. Verkaufschance. Eindeutige Änderungen an Phase, Betrag oder Abschlussdatum schreibt der Workflow direkt; unsichere Änderungen legt er dem Verkäufer zur Freigabe vor.

Das Ergebnis ist kein zusätzliches Dokument irgendwo in einem Laufwerk, sondern Daten an genau den Stellen in ameax, an denen das Team ohnehin arbeitet: im Aktivitätsstrom des Kunden, in der Wiedervorlagenliste des Verkäufers und im Forecast der Vertriebsleitung.

Mit oder ohne Workflow: die Sprachnotiz im KI-Assistenzsystem

Nicht jedes Team braucht sofort einen n8n-Workflow. Wer vor allem die Dokumentation beschleunigen will, findet eine einfachere Lösung direkt im Produkt. Im KI-Assistenzsystem von ameax nimmt der Verkäufer an der Aktivität eine Sprachnotiz auf. Sie wird transkribiert, und auf Wunsch baut ein Sprachmodell daraus einen Betreff und einen bereinigten Text ohne Füllwörter, die direkt in die Aktivität geschrieben werden. Zusätzlich lässt sich in Textfelder diktieren, und der Textassistent hilft beim Formulieren von Aktivitätsnotizen.

Der Unterschied zum Workflow: Die Sprachnotiz macht aus dem Gesagten eine gute Aktivität, aber sie legt keine Wiedervorlagen an und ändert keine Verkaufschance. Viele Teams beginnen deshalb mit der Sprachnotiz, gewöhnen sich an vollständige Einträge und bauen den Workflow, sobald aufgezeichnete Meetings der Regelfall sind. Die KI-Funktionen des Produkts sind nicht über die REST-API aufrufbar; ein Workflow arbeitet immer mit einem eigenen Sprachmodell.

Vorbereitung in ameax

Bevor der erste Workflow läuft, wird in ameax einmal festgelegt, wohin die Ergebnisse gehören. Das dauert selten länger als eine Stunde und entscheidet darüber, ob die automatisch angelegten Einträge später auswertbar sind oder nur Text.

Aktivitätsarten und Ergebnisse

Legen Sie fest, mit welcher Aktivitätsart die Nachbereitung gespeichert wird, zum Beispiel „Kundentermin" und „Telefonat", oder eine eigene Art „Gesprächsnotiz (automatisch)". Eine eigene Art hat den Vorteil, dass Sie automatisch erzeugte Einträge von handgeschriebenen unterscheiden können. Dasselbe gilt für Ergebnisse: Ein Gespräch, das mit einer konkreten Vereinbarung endet, ist ein anderes Ergebnis als eines ohne. Die REST-API bietet keinen Endpunkt zum Auflisten von Aktivitätsarten, Ergebnissen oder Verkaufsphasen. Die IDs sehen Sie einmalig in den Einstellungen nach und hinterlegen sie im Workflow, etwa in einem Set-Knoten am Anfang. Wie Aktivitäten, Ergebnisse und Zielvorgaben zusammenhängen, beschreibt die Seite Aktivitäten und Ziele.

Verkaufsphasen und Wahrscheinlichkeit

Die Standard-Verkaufsphasen in ameax sind Identifikation, Gewinnung, Qualifikation, Angebot und Verkauf (IDs 6 bis 10 im Standard, in Ihrer Installation eventuell angepasst). Klären Sie vorab, woher bei Ihnen die Abschlusswahrscheinlichkeit kommt: aus der Phase, aus einem Bewertungsfeld oder als manueller Wert. Wird sie aus der Phase abgeleitet, sollte der Workflow nur die Phase ändern und die Wahrscheinlichkeit nicht zusätzlich überschreiben. Details dazu stehen auf der Seite Forecast und Pipeline.

Zusatzfelder für strukturierte Werte

Einwände, Stimmung oder ein genannter Wettbewerber sind Werte, die man später filtern möchte. Im Fließtext einer Aktivität sind sie verloren. Aktivitäten und Verkaufschancen können über Zusatzfelder erweitert werden, etwa ein Auswahlfeld „Gesprächsstimmung" mit den Werten positiv, neutral und kritisch an der Aktivität. Die mandantenspezifische OpenAPI-Spezifikation unter /api/v2/openapi.json enthält diese Zusatzfelder mit Bezeichnung und Auswahlwerten. Der Workflow und auch das Sprachmodell können sie daher direkt als Beschreibung der erlaubten Werte verwenden.

Technischer Benutzer und Token

Ein API-Token hängt immer an einem Benutzer und erbt dessen Rechte; eigene Rechte-Scopes je Token gibt es nicht. Legen Sie deshalb einen technischen Benutzer an, der genau das darf, was der Workflow braucht: Kunden und Ansprechpartner lesen, Aktivitäten und Wiedervorlagen anlegen, Verkaufschancen bearbeiten. Weil die Wiedervorlagen dem jeweiligen Verkäufer zugewiesen werden, braucht der technische Benutzer das Recht, Wiedervorlagen für andere Benutzer anzulegen. Das Token erzeugen Sie unter /c/apitoken, je Token lassen sich Ablaufdatum und IP-Liste festlegen. Wie n8n das Token im HTTP-Request-Knoten verwendet, zeigt die Seite n8n anbinden.

Auslöser

ameax meldet Ereignisse nicht aktiv an andere Systeme. Der Workflow startet deshalb dort, wo das Gespräch stattfindet, oder zeitgesteuert.

• Webhook des Meeting- oder Telefonsystems an n8n. Viele Konferenz-, Transkriptions- und Telefonsysteme können nach Gesprächsende einen Webhook mit dem Transkript oder einem Link darauf verschicken. In n8n nimmt ein Webhook-Knoten diesen Aufruf an. Das ist der direkteste Weg, weil die Nachbereitung wenige Minuten nach dem Termin fertig ist.
• Zeitgesteuerte Abfrage. Bietet das System keinen Webhook, fragt ein Schedule Trigger in n8n zum Beispiel stündlich die Schnittstelle des Meeting-Systems nach neuen Aufzeichnungen ab und merkt sich, welche bereits verarbeitet wurden.
• Manueller Anstoß. Für Gespräche ohne Aufzeichnung kann der Verkäufer seine Stichpunkte über ein einfaches Formular oder eine Mail an eine eigene Adresse schicken, die n8n abholt. Der weitere Ablauf ist derselbe.

Der Auslöser ist bewusst als eigener Baustein gedacht. Wechselt Ihr Meeting-System, tauschen Sie nur den ersten Knoten aus; Zuordnung, Auswertung und das Schreiben nach ameax bleiben unverändert.

Umsetzung Schritt für Schritt

Die folgenden Beispiele verwenden die Beispiel-Domain https://ihrefirma.ameax.de. Alle IDs (Kunde, Ansprechpartner, Aktivitätsart, Benutzer, Verkaufschance) sind Beispielwerte und müssen durch die Werte Ihrer Installation ersetzt werden. Jeder Aufruf trägt den Header Authorization: Bearer <token>, schreibende Aufrufe zusätzlich Content-Type: application/json.

Sie bauen sieben Schritte, und sie laufen in drei Zügen. Der Workflow klärt zuerst, mit wem gesprochen wurde, holt den Kontext und lässt das Sprachmodell auswerten (1 bis 3). Das Ergebnis schreibt er als Aktivität, Wiedervorlage und aktualisierte Verkaufschance nach ameax (4 bis 6). Schritt 7 fängt Fehler ab und sorgt dafür, dass ein zweiter Lauf nichts doppelt anlegt.

Schritt 1: Teilnehmer dem Kunden zuordnen

Meeting-Systeme liefern in der Regel die E-Mail-Adressen der Teilnehmer. Interne Adressen filtert der Workflow heraus, für jede externe Adresse sucht er den Ansprechpartner:

GET https://ihrefirma.ameax.de/api/v2/persons?filter[email]=anna.beispiel@kunde-beispiel.de

Die Antwort ist eine Liste im Format {"data":[…],"total":N,"page":1,"per_page":25}. Ein Treffer liefert mit id und customer_id alles, was die weiteren Schritte brauchen. Findet sich kein Ansprechpartner, sucht der Workflow den Kunden über die Domain, denn der Filter erlaubt * als Platzhalter:

GET https://ihrefirma.ameax.de/api/v2/customers?filter[email]=*@kunde-beispiel.de

Bleibt auch das ohne eindeutiges Ergebnis, bricht der Workflow nicht ab, sondern schickt die Nachbereitung als Entwurf an den Verkäufer, der sie selbst zuordnet. Bei Telefonaten gilt eine Besonderheit: Die REST-API bietet keine Suche nach Telefonnummer. Ist Ihre Telefonanlage an ameax angebunden, erzeugen Anrufereignisse ohnehin automatisch eine Aktivität mit Dauer (siehe Telefonie und CTI). Der Workflow kann dann diese Aktivität des Tages suchen und ergänzen, statt eine zweite anzulegen:

GET https://ihrefirma.ameax.de/api/v2/actions?filter[customer_id]=4711&filter[date]=2026-09-28*

Schritt 2: Kontext laden

Damit das Sprachmodell eine Aussage wie „wir gehen dann mit Variante B weiter" richtig einordnet, braucht es den Stand vor dem Gespräch. Zwei Abfragen genügen meist: die aktiven Verkaufschancen des Kunden und seine letzten Aktivitäten.

GET https://ihrefirma.ameax.de/api/v2/sales?filter[customer_id]=4711&filter[salestatus]=14
GET https://ihrefirma.ameax.de/api/v2/actions?filter[customer_id]=4711&sort=-date&per_page=10

Der Status 14 steht im Standard für „aktiv". Hat der Kunde mehrere aktive Verkaufschancen, übergibt der Workflow sie mit ID, Name, Phase und Betrag an das Modell und lässt es die passende auswählen. Ist die Zuordnung nicht eindeutig, entscheidet der Verkäufer.

Schritt 3: Das Sprachmodell auswerten lassen

In n8n übernimmt ein KI-Knoten mit strukturierter Ausgabe die Auswertung, angebunden an ein Sprachmodell Ihrer Wahl. Entscheidend ist der Prompt: Er legt die Rolle fest, beschreibt die Eingabe und schreibt das Ausgabeformat exakt vor. Ein erprobter Aufbau:

Rolle:
Du bereitest Vertriebsgespräche für das CRM nach. Du erfindest nichts.
Was im Transkript nicht vorkommt, bleibt null. Datumsangaben rechnest du
relativ zum Gesprächsdatum aus ("bis Freitag" -> konkretes Datum).
Eingabe:
- gespraechsdatum: {{ $json.datum }}
- teilnehmer_intern: {{ $json.intern }}   (Name, E-Mail, ameax-Benutzer-ID)
- teilnehmer_extern: {{ $json.extern }}
- offene_verkaufschancen: {{ $json.sales }} (id, name, phase, betrag, abschlussdatum)
- letzte_aktivitaeten: {{ $json.actions }}
- transkript: {{ $json.transkript }}
Ausgabe (nur dieses JSON, keine Erläuterung):
{
  "betreff": "max. 80 Zeichen",
  "zusammenfassung": "5-10 Sätze, sachlich, ohne Füllwörter",
  "naechste_schritte": [
    {"was": "…", "faellig_am": "YYYY-MM-DD", "uhrzeit": "HH:MM oder null",
     "verantwortlich_benutzer_id": 12, "prioritaet": "normal|hoch|zeitkritisch"}
  ],
  "einwaende": ["…"],
  "budget": {"betrag": 25000, "waehrung": "EUR", "zitat": "…"} ,
  "zeitrahmen": {"entscheidung_bis": "YYYY-MM-DD", "zitat": "…"},
  "stimmung": "positiv|neutral|kritisch",
  "verkaufschance_id": 311,
  "vorschlag_verkaufschance": {
    "phase_id": 9, "betrag": 25000, "abschlussdatum": "YYYY-MM-DD",
    "begruendung": "…"
  },
  "sicherheit": {"zuordnung": "hoch|mittel|niedrig",
                 "vorschlag_verkaufschance": "hoch|mittel|niedrig"}
}

Zwei Details im Prompt zahlen sich aus. Das Feld zitat bei Budget und Zeitrahmen zwingt das Modell, die Stelle im Transkript zu nennen, auf die es sich stützt; ohne Zitat übernimmt der Workflow den Wert nicht. Und die Selbsteinschätzung unter sicherheit ist die Weiche für die Freigabe in Schritt 6. Ein Sprachmodell kann seine eigene Sicherheit nicht zuverlässig messen, aber zusammen mit harten Regeln im Workflow ergibt sie eine brauchbare Vorsortierung.

Nach dem KI-Knoten prüft ein Code-Knoten das JSON: Sind alle Pflichtfelder vorhanden? Liegen die Daten in der Zukunft? Ist die verkaufschance_id eine der übergebenen IDs? Stammt die verantwortlich_benutzer_id aus der Liste der internen Teilnehmer? Ein Modell, das eine ID erfindet, fällt hier auf, bevor etwas nach ameax geschrieben wird.

Schritt 4: Aktivität mit Zusammenfassung anlegen

Die Zusammenfassung wird eine Aktivität am Kunden. Pflicht sind customer_id, subject (höchstens 250 Zeichen) und date; der Rest verknüpft die Aktivität mit Ansprechpartner, Aktivitätsart, Ergebnis und Verkaufschance:

POST https://ihrefirma.ameax.de/api/v2/actions
{
  "customer_id": 4711,
  "person_id": 802,
  "user_id": 12,
  "sale_id": 311,
  "activity_id": 3,
  "finding_id": 7,
  "date": "2026-09-28 14:30:00",
  "subject": "Kundentermin: überarbeitetes Angebot bis Freitag vereinbart",
  "notice": "Zusammenfassung:\n…\n\nEinwände:\n- Lieferzeit im Dezember\n- Schulungsaufwand\n\nBudget: ca. 25.000 EUR (\"Wir haben rund fünfundzwanzig eingeplant\")\nEntscheidung bis: 2026-10-31"
}

Ohne user_id gilt der API-Benutzer als Bearbeiter. Setzen Sie hier den Verkäufer, der das Gespräch geführt hat, damit die Aktivität in seinen Auswertungen und Zielvorgaben erscheint. Soll erkennbar bleiben, dass der Eintrag automatisch entstand, verwenden Sie dafür die eigene Aktivitätsart aus der Vorbereitung. Existiert bereits eine Aktivität aus der Telefonanlage, ergänzt ein PATCH /api/v2/actions/{id} mit notice und subject diese Aktivität, statt eine zweite anzulegen. Ein Zusatzfeld wie „Gesprächsstimmung" wird im selben Aufruf mitgeschickt, unter dem Feldnamen, den die OpenAPI-Spezifikation Ihrer Installation nennt.

Schritt 5: Je nächstem Schritt eine Wiedervorlage

Jeder vereinbarte Schritt wird eine eigene Wiedervorlage. Pflicht sind customer_id, date und subject; über user_id geht sie an den Verantwortlichen, über sale_id hängt sie an der Verkaufschance. Die Priorität kennt in ameax drei Stufen: 0 normal, 5 hoch, 10 zeitkritisch.

POST https://ihrefirma.ameax.de/api/v2/reminds
{
  "customer_id": 4711,
  "person_id": 802,
  "user_id": 12,
  "sale_id": 311,
  "activity_id": 4,
  "date": "2026-10-02 09:00:00",
  "subject": "Überarbeitetes Angebot (Variante B, Lieferung Januar) an Frau Beispiel senden",
  "priority": 5
}

Wiedervorlagen haben kein eigenes Textfeld. Der Betreff muss deshalb für sich allein verständlich sein: nicht „Angebot", sondern was, für wen, mit welcher Besonderheit. Den ausführlichen Zusammenhang findet der Verkäufer in der Aktivität aus Schritt 4. Wie Zuständigkeit, Teams und Benachrichtigung bei Wiedervorlagen funktionieren, beschreibt die Seite Wiedervorlagen. Zusagen, die der Kunde gemacht hat („wir melden uns bis Mitte Oktober"), werden ebenfalls Wiedervorlagen, und zwar mit dem Datum, an dem Sie nachhaken, falls die Meldung ausbleibt.

Schritt 6: Verkaufschance aktualisieren, mit Freigabe bei Unsicherheit

Die Aktualisierung der Verkaufschance ist der Schritt mit den größten Folgen, denn sie verändert den Forecast. Ein PATCH ändert nur die mitgeschickten Felder:

PATCH https://ihrefirma.ameax.de/api/v2/sales/311
{
  "sellingstatus": 9,
  "amount": 25000,
  "close_date": "2026-10-31"
}

Ob der Workflow diesen Aufruf direkt ausführt oder vorher fragt, entscheidet eine Regel im Workflow, nicht das Modell allein. Bewährt hat sich folgende Aufteilung:

Die Freigabe selbst lässt sich in n8n auf zwei Arten bauen. Die einfache Variante: Der Workflow legt eine Wiedervorlage „Vorschlag prüfen: Phase Angebot, Abschluss 31.10., Betrag 25.000 EUR" an und überlässt die Änderung dem Verkäufer in ameax. Die komfortablere Variante: n8n schickt dem Verkäufer eine Nachricht mit dem Vorschlag und zwei Links, und ein Warteschritt im Workflow führt den PATCH erst aus, wenn der Verkäufer bestätigt. In beiden Fällen bleibt die Entscheidung beim Menschen, der das Gespräch geführt hat.

Schritt 7: Fehler und Wiederholungen abfangen

Die API antwortet bei Fehlern im Format application/problem+json mit einer Liste errors, die Feld, Code und Meldung nennt, und jede Antwort trägt eine X-Request-Id. Protokollieren Sie beides im Workflow. Die API kennt keine Idempotenz-Schlüssel; läuft ein Workflow nach einem Abbruch erneut, muss er selbst verhindern, dass dieselbe Aktivität zweimal entsteht. Praktisch heißt das: Vor dem Anlegen prüfen, ob es für diesen Kunden und dieses Datum bereits eine Aktivität mit demselben Betreff gibt (filter[customer_id] und filter[date]), oder die Kennung der Aufzeichnung in n8n speichern und bereits verarbeitete überspringen.

Was in ameax sichtbar wird

Der Nutzen der Nachbereitung entsteht nicht im Workflow, sondern dort, wo Team und Führung mit dem Ergebnis arbeiten.

Für den Verkäufer

Im Aktivitätsstrom des Kunden steht nach jedem Gespräch ein vollständiger Eintrag mit Zusammenfassung, Einwänden, Budget und Zeitrahmen, verknüpft mit Ansprechpartner und Verkaufschance. Die nächsten Schritte erscheinen als offene Wiedervorlagen im Dashboard, mit Datum, Uhrzeit und Priorität. Ist die Benachrichtigung für Wiedervorlagen eingeschaltet, wird der Zuständige zusätzlich benachrichtigt. Wer die Wiedervorlage erledigt, dokumentiert das nächste Gespräch, und der Kreislauf beginnt von vorn.

Für die Vertriebsleitung

Weil Phase, Betrag und Abschlussdatum nach jedem Gespräch nachgezogen werden, spiegelt der Forecast den tatsächlichen Stand. Der gewichtete Forecast in ameax rechnet mit Betrag mal Wahrscheinlichkeit und verteilt die Chancen nach Abschlussdatum auf die Perioden; überfällige Chancen fallen dabei nicht heraus, sondern bleiben in ihrem tatsächlichen Quartal sichtbar. Im Forecast-Cockpit steht unter dem Diagramm die Liste der Chancen mit ihrer nächsten Wiedervorlage, sodass auf einen Blick erkennbar ist, bei welcher Chance kein nächster Schritt geplant ist.

Einzeln ist eine Nachbereitung Dokumentation. In der Summe wird sie zur Grundlage: Weil Einwände und Stimmung als Auswahlwerte an der Aktivität hängen, lassen sie sich filtern und zählen. Fällt in dreißig Gesprächen immer derselbe Einwand, ist das keine Frage mehr an den Verkäufer, sondern an das Angebot.

Im Hub

In den Hub-Dashboards zeigen die Bausteine „Aktivitäten" und „Wiedervorlagen" Menge und Verteilung der Einträge je Mitarbeiter und Periode, der Verkaufschancen-Forecast das gewichtete Volumen. Die Aktivitäten zählen außerdem auf Zielvorgaben ein, etwa eine Mindestzahl an Kundenterminen je Mitarbeiter im rollierenden Zeitraum.

Best Practices und Stolperstellen

Die folgenden Punkte stammen aus dem, was bei dieser Art von Workflow typischerweise schiefgeht. Jeder lässt sich mit wenig Aufwand vermeiden, wenn man ihn vorher kennt.

• Nichts erfinden lassen. Sprachmodelle ergänzen Lücken gern mit Plausiblem. Ein Budget, das nie genannt wurde, ist im Forecast schlimmer als gar kein Budget. Der Prompt verlangt deshalb null für alles, was nicht im Transkript steht, und der Workflow übernimmt Zahlen und Daten nur mit Zitat.
• Datumsangaben relativ zum Gespräch rechnen. „Nächsten Dienstag" bedeutet etwas anderes, wenn das Transkript erst am Montag darauf verarbeitet wird. Geben Sie dem Modell immer das Gesprächsdatum mit, nicht das Verarbeitungsdatum, und prüfen Sie im Code-Knoten, dass kein Fälligkeitsdatum in der Vergangenheit liegt.
• Verantwortliche nur aus bekannten Personen wählen. Das Modell soll den Verantwortlichen aus der Liste der internen Teilnehmer mit ihrer ameax-Benutzer-ID auswählen, nicht frei benennen. Bleibt ein Schritt ohne klare Zuständigkeit, geht die Wiedervorlage an den Gesprächsleiter.
• Betreffe der Wiedervorlagen ausformulieren. Weil Wiedervorlagen kein Textfeld haben, trägt der Betreff die ganze Information. Ein guter Betreff beantwortet „was, für wen, mit welcher Besonderheit" und passt trotzdem in eine Zeile.
• Keine Kampagnen- oder Statuswechsel als Nebeneffekt. Die Nachbereitung dokumentiert und plant; sie entscheidet nicht, dass eine Verkaufschance verloren ist. Solche Einschätzungen gehören als Wiedervorlage zum Verkäufer.
• Vollständigkeit vor Kürze. Eine Zusammenfassung von zwei Sätzen ist schnell gelesen, hilft aber in sechs Monaten niemandem. Fünf bis zehn Sätze mit Einwänden und Zusagen sind ein guter Richtwert, besonders wenn ein Kollege den Kunden später übernimmt.
• Datenschutz und Aufzeichnung klären. Ob Gespräche aufgezeichnet, transkribiert und an ein Sprachmodell übergeben werden dürfen, hängt unter anderem von der Einwilligung der Teilnehmer und vom gewählten KI-Dienst ab. Das ist eine Frage für Ihren Datenschutzbeauftragten und den Einzelfall; der Workflow sollte nur Gespräche verarbeiten, bei denen das geklärt ist.
• Zuerst im Entwurfsmodus laufen lassen. Lassen Sie den Workflow in den ersten Wochen alles zur Freigabe vorlegen und vergleichen Sie Vorschläge und Entscheidungen. Erst wenn die Vorschläge in einer Kategorie fast immer übernommen werden, schalten Sie diese auf direktes Schreiben um.

Fazit

Gesprächsnachbereitung eignet sich gut für die Automatisierung, weil der Rohstoff schon vorhanden ist und die Zielorte klar sind. Das Sprachmodell macht aus einem Transkript eine Zusammenfassung, nächste Schritte und einen Vorschlag für die Verkaufschance. n8n übernimmt Zuordnung, Prüfung und die Aufrufe an die REST-API. ameax hält das Ergebnis dort fest, wo Vertrieb und Führung ohnehin arbeiten. Solange der Verkäufer bei allem, was den Forecast verändert und unsicher ist, das letzte Wort behält, gewinnt das Team Zeit und bessere Daten zugleich. Weitere Szenarien, etwa die Pipeline-Pflege durch einen KI-Agenten oder Angebote per KI vorbereiten, bauen auf genau diesen Daten auf.