Pipeline-Pflege durch einen KI-Agenten

Montagmorgen, Pipeline-Meeting. Auf der Liste stehen 140 aktive Verkaufschancen, und bei einem guten Drittel stimmt etwas nicht: Das Abschlussdatum liegt im August, obwohl es Ende September ist. Seit sieben Wochen hat niemand mit dem Kunden gesprochen. Oder es gibt schlicht keinen nächsten Schritt. Die Vertriebsleitung fragt jede dieser Chancen einzeln ab, die Verkäufer antworten aus dem Gedächtnis, und nach neunzig Minuten ist die Hälfte besprochen. Der Forecast, der daraus entsteht, ist eine Momentaufnahme mit bekannten Fehlern.

Pipeline-Pflege ist Routinearbeit, die sich gut in zwei Teile zerlegen lässt. Der erste Teil ist mechanisch: Welche Chancen sind überfällig, welche ruhen, welche haben keine Wiedervorlage? Das beantwortet eine Abfrage. Der zweite Teil braucht Urteilsvermögen: Was ist bei dieser Chance los, und was wäre ein sinnvoller nächster Schritt? Hier kann ein Sprachmodell vorarbeiten, indem es die letzten Aktivitäten liest und einen begründeten Vorschlag macht. Die Entscheidung bleibt beim Verkäufer. Diese Seite zeigt, wie ein KI-Agent mit n8n und der REST-API von ameax die Pipeline regelmäßig prüft, und warum er bestimmte Dinge ausdrücklich nicht tun sollte.

Der Ablauf im Überblick

ameax ist das führende System: Verkaufschancen, Aktivitäten und Wiedervorlagen liegen dort, und dort landen auch die Vorschläge des Agenten. n8n ist der Taktgeber, der den Lauf startet, die Daten abfragt und die Regeln anwendet. Das Sprachmodell bearbeitet nur die auffälligen Fälle und liefert eine Einschätzung in festem Format. Der Verkäufer entscheidet, was mit der Chance passiert.

1. Lauf starten. Ein Schedule Trigger in n8n startet den Lauf, zum Beispiel jede Nacht oder jeden Freitagnachmittag.
2. Offene Chancen laden. n8n fragt alle aktiven Verkaufschancen ab, sortiert nach Abschlussdatum oder letzter Aktivität, und blättert durch alle Seiten.
3. Regeln anwenden. Ein Code-Knoten markiert Chancen mit überfälligem Abschlussdatum, langer Inaktivität oder ohne offene Wiedervorlage. Nur diese gehen weiter.
4. Kontext sammeln. Für jede auffällige Chance liest n8n die letzten Aktivitäten des Kunden, seine offenen Wiedervorlagen und verknüpfte Angebote.
5. Einschätzung. Das Sprachmodell bewertet die Lage und schlägt einen nächsten Schritt mit Begründung vor.
6. Vorschlag ablegen. n8n legt beim zuständigen Verkäufer eine Wiedervorlage mit dem Vorschlag an und dokumentiert die Begründung in ameax.
7. Wochenüberblick. Aus denselben Daten entsteht ein Digest für die Vertriebsleitung, den n8n per E-Mail oder in den Team-Chat schickt.

Das Ergebnis ist eine Pipeline, bei der jede auffällige Chance einen konkreten, begründeten nächsten Schritt im Kalender des Verkäufers hat. Das Pipeline-Meeting bespricht dann nicht mehr, welche Chancen veraltet sind, sondern was mit ihnen passieren soll.

Vorbereitung in ameax

Die Prüfregeln sind nur so gut wie die Daten, auf die sie schauen. Einiges wird deshalb einmalig in ameax festgelegt.

Status, Phasen und die Quelle der Wahrscheinlichkeit

Verkaufschancen haben in ameax einen Status und eine Phase. Die Statuswerte sind interne IDs, im Standard 14 aktiv, 15 gewonnen, 16 verloren, 17 passiv, 18 eingestellt und 19 storniert. Die Phasen sind im Standard Identifikation, Gewinnung, Qualifikation, Angebot und Verkauf (IDs 6 bis 10). Prüfen Sie diese Werte in Ihrer Installation, denn die Liste der Phasen ist anpassbar und die REST-API bietet keinen Endpunkt, um sie aufzulisten.

Wichtig für den Agenten ist außerdem, woher die Abschlusswahrscheinlichkeit kommt. In ameax gibt es drei Wege: aus einem Bewertungsfeld, aus der Verkaufsphase oder als manuellen Wert. Es gibt im Produkt kein KI-Scoring und keine vorhersagende Abschlusswahrscheinlichkeit. Das ist eine bewusste Stärke: Die Wahrscheinlichkeit ist nachvollziehbar, weil sie aus einer Phase, einer Bewertung oder einer Entscheidung eines Menschen stammt. Der Agent sollte diese Wahrscheinlichkeit deshalb nicht überschreiben. Seine eigene Einschätzung gehört an eine andere Stelle.

Ein Zusatzfeld für die Einschätzung des Agenten

Legen Sie an der Verkaufschance zwei Zusatzfelder an: ein Auswahlfeld „Einschätzung Agent" mit Werten wie „auf Kurs", „nachfassen", „Abschlussdatum prüfen" und „gefährdet" sowie ein Datumsfeld „geprüft am". So bleibt die Einschätzung des Agenten sichtbar getrennt von der Wahrscheinlichkeit, die in den Forecast einfließt. Zusatzfelder der Verkaufschance stehen im Report „Verkaufschancen" als Spalte, Filter und Gruppierung zur Verfügung. Mit dem Modul Verkaufschancenbewertung lässt sich das Forecast-Cockpit außerdem nach jedem segmentfähigen Zusatzfeld aufteilen. Die Feldnamen für die API zeigt die OpenAPI-Spezifikation Ihrer Installation unter /api/v2/openapi.json, einschließlich der erlaubten Auswahlwerte.

Aktivitätsart für Einträge des Agenten

Wenn der Agent seine Begründung als Aktivität dokumentiert, sollte er dafür eine eigene Aktivitätsart verwenden, etwa „Pipeline-Prüfung (automatisch)". Das hat zwei Gründe. Erstens zählen Aktivitäten auf Zielvorgaben ein; automatische Einträge sollen die Kennzahlen der Verkäufer nicht aufblähen. Zweitens muss der Agent bei seinem nächsten Lauf seine eigenen Einträge von echten Kundenkontakten unterscheiden können, sonst hält er eine Chance für aktiv, nur weil er selbst sie vor einer Woche geprüft hat.

Technischer Benutzer mit passenden Rechten

Das API-Token erbt die Rechte des Benutzers, an dem es hängt. Der technische Benutzer für den Agenten braucht Lesezugriff auf alle Verkaufschancen, die geprüft werden sollen, das Recht, Aktivitäten und Wiedervorlagen anzulegen, und das Recht, Wiedervorlagen für andere Benutzer anzulegen, weil die Vorschläge beim zuständigen Verkäufer landen. Schreibrechte auf Verkaufschancen braucht er nur für das Zusatzfeld der Einschätzung. Wie das Token in n8n eingebunden wird, beschreibt die Seite n8n anbinden.

Auslöser

ameax meldet keine Ereignisse aktiv an andere Systeme, und für die Pipeline-Pflege wäre das auch nicht nötig. Der Agent arbeitet zeitgesteuert: Ein Schedule Trigger in n8n startet den Lauf. Zwei Rhythmen haben sich bewährt.

• Nächtlicher Lauf für die Verkäufer. Jede Nacht prüft der Agent die Pipeline und legt Vorschläge an, die am nächsten Morgen in den Wiedervorlagen stehen. Damit eine Chance nicht jeden Tag denselben Vorschlag bekommt, merkt sich der Agent über das Zusatzfeld „geprüft am", wann er sie zuletzt bewertet hat, und prüft sie frühestens nach einer Woche wieder.
• Wöchentlicher Lauf für die Leitung. Freitags oder montags früh erzeugt ein zweiter Workflow aus denselben Abfragen den Wochenüberblick. Er schreibt nichts nach ameax, sondern fasst zusammen.

Zusätzlich lässt sich der Lauf für einen einzelnen Verkäufer auch manuell anstoßen, etwa über einen Webhook-Knoten in n8n, den ein Button im Team-Chat aufruft. Der Auslöser ist bewusst ein eigener Baustein; die Prüflogik dahinter bleibt gleich.

Umsetzung Schritt für Schritt

Die Beispiele verwenden die Beispiel-Domain https://ihrefirma.ameax.de. Alle IDs sind Beispielwerte. Jeder Aufruf trägt den Header Authorization: Bearer <token>, schreibende Aufrufe zusätzlich Content-Type: application/json.

Sie bauen sieben Schritte. Die ersten sechs laufen in drei Zügen: Der Agent findet zuerst, was auffällig ist (1 und 2), sammelt dann Kontext und lässt das Sprachmodell einschätzen (3 und 4), und gibt zum Schluss den nächsten Schritt an den Zuständigen weiter (5 und 6). Schritt 7 ist ein zweiter Workflow, der einmal pro Woche die Auffälligkeiten an die Vertriebsleitung schickt.

Schritt 1: Aktive Verkaufschancen abfragen

Die Liste der aktiven Chancen holt ein HTTP-Request-Knoten, sortiert nach Abschlussdatum:

GET https://ihrefirma.ameax.de/api/v2/sales?filter[salestatus]=14&sort=close_date&per_page=100&page=1

Die Antwort enthält data, total, page und per_page. Mehr als 100 Einträge je Seite liefert die API nicht; n8n blättert deshalb mit page, bis alle total Einträge geladen sind. Alternativ sortiert sort=last_active_at nach letzter Aktivität, sodass die am längsten ruhenden Chancen zuerst kommen. Jede Chance bringt unter anderem customer_id, user_id (zuständig), name, sellingstatus, probability, amount, close_date und last_active_at mit.

Schritt 2: Regeln im Workflow anwenden

Die API filtert nur auf Gleichheit oder mit * als Platzhalter. Operatoren wie „kleiner als" gibt es nicht. Die Frage „welche Chancen sind überfällig?" beantwortet deshalb ein Code-Knoten in n8n, der das Abschlussdatum mit dem heutigen Datum vergleicht. Drei Regeln bilden einen guten Anfang:

Die Schwelle für Inaktivität sollte von der Phase abhängen. Eine Chance in der Phase Identifikation darf länger ruhen als eine in der Phase Angebot, bei der der Kunde auf eine Rückmeldung wartet.

Für die dritte Regel fragt n8n die offenen Wiedervorlagen des Kunden ab:

GET https://ihrefirma.ameax.de/api/v2/reminds?filter[customer_id]=4711&filter[active]=1

Einen Filter nach Verkaufschance bietet dieser Endpunkt nicht. Der Workflow prüft deshalb in der Antwort, ob eine der Wiedervorlagen die sale_id der Chance trägt. Je nach Arbeitsweise Ihres Teams kann auch jede offene Wiedervorlage am Kunden als „nächster Schritt geplant" gelten.

Schritt 3: Kontext für die Einschätzung sammeln

Für jede auffällige Chance lädt n8n, was ein erfahrener Vertriebsleiter vor einer Rückfrage lesen würde: die letzten Aktivitäten des Kunden und die mit der Chance verknüpften Belege.

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

An dieser Stelle filtert der Workflow die eigenen Einträge des Agenten heraus, erkennbar an der Aktivitätsart aus der Vorbereitung. Welche Vorgänge in Ihrer Installation den Zeitpunkt last_active_at fortschreiben, sollten Sie einmal prüfen. Auch Einträge des Agenten selbst können dazugehören. Deshalb misst der Agent die Inaktivität zusätzlich an den Aktivitäten der Menschen und verlässt sich nicht allein auf dieses Feld.

Schritt 4: Das Sprachmodell einschätzen lassen

Ein KI-Knoten mit strukturierter Ausgabe in n8n, angebunden an ein Sprachmodell Ihrer Wahl, bekommt je Chance den Befund aus den Regeln und den Kontext. Der Prompt legt fest, dass das Modell vorschlägt und nicht entscheidet:

Rolle:
Du unterstützt die Pipeline-Pflege im Vertrieb. Du bewertest eine
Verkaufschance anhand ihrer Daten und der letzten Kundenkontakte und schlägst
EINEN konkreten nächsten Schritt vor. Du entscheidest nichts: Status,
Wahrscheinlichkeit und Betrag änderst du nicht. Wenn die Daten nicht
reichen, sag das.
Eingabe:
- heute: {{ $now.format('yyyy-MM-dd') }}
- chance: {{ $json.sale }}          (name, phase, betrag, wahrscheinlichkeit,
                                     abschlussdatum, letzte_aktivitaet)
- befunde: {{ $json.befunde }}      (z. B. ["abschlussdatum_ueberfaellig"])
- aktivitaeten: {{ $json.actions }} (datum, art, betreff, notiz; neueste zuerst)
- offene_wiedervorlagen: {{ $json.reminds }}
- belege: {{ $json.receipts }}      (typ, status, datum)
Ausgabe (nur dieses JSON):
{
  "einschaetzung": "auf_kurs|nachfassen|abschlussdatum_pruefen|gefaehrdet",
  "vorschlag": "nachfassen|termin_vereinbaren|abschlussdatum_klaeren|
                chance_neu_bewerten|als_verloren_pruefen",
  "betreff_wiedervorlage": "max. 120 Zeichen, konkret, mit Anlass",
  "vorgeschlagenes_datum": "YYYY-MM-DD",
  "prioritaet": 0,
  "begruendung": "3-5 Sätze, nur mit Bezug auf die übergebenen Daten",
  "daten_ausreichend": true
}

Der Vorschlag „als verloren prüfen" ist ausdrücklich ein Vorschlag an den Verkäufer, keine Aktion. Ein Code-Knoten prüft danach, dass einschaetzung und vorschlag nur erlaubte Werte enthalten, das Datum in der Zukunft liegt und die Priorität einer der drei Stufen entspricht: 0 normal, 5 hoch, 10 zeitkritisch.

Schritt 5: Wiedervorlage an den Zuständigen

Der Vorschlag wird eine Wiedervorlage beim zuständigen Verkäufer, verknüpft mit der Chance:

POST https://ihrefirma.ameax.de/api/v2/reminds
{
  "customer_id": 4711,
  "user_id": 12,
  "sale_id": 311,
  "date": "2026-09-30 09:00:00",
  "subject": "Pipeline: Abschluss 31.08. überfällig, seit 6 Wochen kein Kontakt. Entscheidungstermin beim Kunden erfragen",
  "priority": 5
}

Wiedervorlagen haben in ameax kein Textfeld. Die Kurzbegründung gehört deshalb in den Betreff, und zwar so, dass der Verkäufer ohne weiteres Klicken versteht, warum die Wiedervorlage da ist. Die ausführliche Begründung dokumentiert der Workflow zusätzlich, entweder als Aktivität mit der eigenen Aktivitätsart und der sale_id:

POST https://ihrefirma.ameax.de/api/v2/actions
{
  "customer_id": 4711,
  "sale_id": 311,
  "activity_id": 21,
  "date": "2026-09-29 02:15:00",
  "subject": "Pipeline-Prüfung: Abschlussdatum klären",
  "notice": "Befund: Abschlussdatum 31.08.2026 überfällig, letzte Kundenaktivität 12.08.2026.\nEinschätzung: Kunde hatte Budgetfreigabe für Q3 angekündigt, seitdem keine Rückmeldung. Angebot vom 05.08. ist offen.\nVorschlag: Entscheidungstermin erfragen, danach Abschlussdatum und Phase neu bewerten."
}

oder als Notiz am Kunden über POST /api/v2/notices mit customer_id, subject und notice. Die Aktivität hat den Vorteil, dass sie mit der Verkaufschance verknüpft ist. Ohne user_id wird sie dem API-Benutzer zugeordnet, bleibt also als Eintrag des Agenten erkennbar.

Schritt 6: Einschätzung an der Chance festhalten

Zum Schluss schreibt der Workflow die Einschätzung in die Zusatzfelder der Verkaufschance. Die Feldnamen sind Beispiele; die tatsächlichen Namen stehen in der OpenAPI-Spezifikation Ihrer Installation:

PATCH https://ihrefirma.ameax.de/api/v2/sales/311
{
  "einschaetzung_agent": "abschlussdatum_pruefen",
  "geprueft_am": "2026-09-29"
}

Betrag, Wahrscheinlichkeit, Phase und Status bleiben unangetastet. Ändert der Verkäufer nach seiner Rückfrage das Abschlussdatum oder setzt die Chance auf verloren, ist das seine Entscheidung. Jede Änderung an der Verkaufschance schreibt eine Revision, die Wahrscheinlichkeit hat damit eine nachvollziehbare Historie.

Schritt 7: Der Wochenüberblick für die Vertriebsleitung

Der zweite Workflow nutzt dieselben Abfragen aus Schritt 1 und 2, schreibt aber nichts nach ameax. Ein Code-Knoten verdichtet die Daten je Verkäufer: Anzahl aktiver Chancen, Summe der Beträge, Zahl der überfälligen Chancen, Zahl der Chancen ohne nächsten Schritt, und die Liste der Chancen mit der Einschätzung „gefährdet". Ein Sprachmodell formuliert daraus einen kurzen Text mit den drei wichtigsten Auffälligkeiten der Woche, und n8n verschickt ihn per E-Mail oder in den Team-Chat. Die Zahlen rechnet der Code-Knoten, nicht das Modell; das Modell schreibt nur den Begleittext.

Der Digest ersetzt die Auswertungen in ameax nicht, er ergänzt sie. Die Dashboards im Hub zeigen den aktuellen Stand jederzeit; der Digest bringt die Auffälligkeiten einmal pro Woche aktiv zur Leitung, denn Dashboards verschicken sich nicht selbst.

Was in ameax sichtbar wird

In den Wiedervorlagen der Verkäufer

Die Vorschläge des Agenten stehen als offene Wiedervorlagen im Dashboard des zuständigen Verkäufers, mit Datum, Priorität und einem Betreff, der den Anlass nennt. Ist die Benachrichtigung für Wiedervorlagen aktiviert, erfährt er zusätzlich davon. Im Aktivitätsstrom des Kunden steht die ausführliche Begründung, verknüpft mit der Verkaufschance.

Im Forecast

Der Forecast in ameax zeigt die Wirkung der Pflege direkt. Er gewichtet mit Betrag mal Wahrscheinlichkeit, verteilt die Chancen nach Abschlussdatum auf die Perioden und berücksichtigt nur aktive Chancen. Überfällige Chancen fallen dabei nicht heraus, sondern stehen in ihrem tatsächlichen, vergangenen Quartal. Ein Forecast mit vielen Beträgen in vergangenen Quartalen zeigt also sofort, dass Pflege nötig ist, und nach einigen Wochen Agentenbetrieb sollte dieser Block schrumpfen. Im Forecast-Cockpit steht unter dem Diagramm die Liste der Chancen mit ihrer nächsten Wiedervorlage. Mehr dazu auf der Seite Forecast und Pipeline.

Im Hub

In den Hub-Dashboards gibt es für Verkaufschancen den Forecast als Kennzahl, Diagramm, Tabelle oder Matrix je Mitarbeiter, die Statusverteilung mit offenen Chancen, offenem und gewonnenem Volumen sowie verlorenen Chancen und eine Liste der Verkaufschancen. Der Baustein „Wiedervorlagen" zeigt unter anderem erledigte und überfällige Wiedervorlagen. Die Sichtbarkeit folgt denselben Rechten wie die Verkaufschancen-Liste: Ein Verkäufer sieht dieselbe Auswertung wie die Leitung, aber mit seinen Chancen.

Mit Planzahlen

Ist das Modul Planzahlen aktiv, lassen sich im Hub Ziele auf diese Kennzahlen setzen, etwa ein Pipeline-Volumen oder gewichtetes Volumen je Mitarbeiter und Quartal oder eine Obergrenze für überfällige Wiedervorlagen. Die Ist-Werte stammen aus derselben Berechnung wie die Kennzahl selbst. Eine Pipeline, die der Agent sauber hält, macht diese Ziele erst aussagekräftig.

In den Auswertungen

Die Zusatzfelder „Einschätzung Agent" und „geprüft am" stehen im Report „Verkaufschancen" als Spalte, Filter und Gruppierung zur Verfügung. So lässt sich zum Beispiel auswerten, wie viel Volumen der Agent als „gefährdet" eingestuft hat, und ob diese Chancen später gewonnen oder verloren wurden.

Best Practices und Stolperstellen

• Nichts automatisch auf verloren setzen. Eine Chance, die sieben Wochen ruht, kann verloren sein oder kurz vor der Unterschrift stehen, weil der Entscheider im Urlaub war. Das weiß nur der Verkäufer. Der Agent schlägt „als verloren prüfen" vor; den Status setzt ein Mensch. Das hält auch die Historie sauber, denn jede Änderung an der Verkaufschance wird als Revision festgehalten, und diese Revision soll eine Entscheidung des Verkäufers sein.
• Die Wahrscheinlichkeit nicht überschreiben. Der Forecast in ameax rechnet mit Betrag mal Wahrscheinlichkeit. Kommt die Wahrscheinlichkeit aus Phase oder Bewertungsfeld, ist sie nachvollziehbar. Schreibt der Agent eine eigene Zahl hinein, weiß niemand mehr, woher sie stammt. Die Einschätzung des Agenten gehört ins Zusatzfeld.
• Vorschläge nicht wiederholen. Ein Agent, der jede Nacht dieselbe Wiedervorlage anlegt, wird nach drei Tagen ignoriert. Das Feld „geprüft am" und eine Mindestpause von einer Woche verhindern das. Zusätzlich prüft der Workflow vor dem Anlegen, ob zur Chance schon eine offene Wiedervorlage des Agenten existiert.
• Zahlen im Code rechnen, nicht im Modell. Summen, Tage seit der letzten Aktivität und Überfälligkeit rechnet der Code-Knoten. Das Sprachmodell bekommt fertige Werte und formuliert. So stimmt der Digest mit den Zahlen in ameax überein.
• Eigene Einträge erkennen. Der Agent muss seine Aktivitäten von Kundenkontakten unterscheiden können, sonst zählt er sich selbst als Aktivität. Eine eigene Aktivitätsart und die Zuordnung zum API-Benutzer lösen das.
• Mit wenigen Regeln beginnen. Drei klare Regeln mit guten Schwellenwerten sind besser als zehn, die jede zweite Chance markieren. Beobachten Sie in den ersten Wochen, welche Vorschläge die Verkäufer umsetzen, und passen Sie die Schwellen an.
• Die Rechte des technischen Benutzers bewusst setzen. Das Token erbt die Rechte seines Benutzers. Ein Agent, der alle Chancen lesen soll, braucht die entsprechende Sichtbarkeit; ein Agent, der nur ein Team prüft, sollte nur dieses sehen. Eigene Rechte je Token gibt es nicht, also steuern Sie das über den Benutzer.
• Die Last im Blick behalten. Die API liefert keine Rate-Limit-Header. Bei großen Pipelines arbeitet der Workflow die Chancen in Paketen ab und wartet zwischen den Aufrufen kurz, statt hunderte Anfragen gleichzeitig zu schicken.

Fazit

Ein KI-Agent für die Pipeline-Pflege nimmt der Vertriebsleitung die mühsame Frage ab, welche Chancen veraltet sind, und dem Verkäufer das Nachdenken darüber, wo er anfangen soll. Die Regeln finden die auffälligen Chancen, das Sprachmodell liest den Verlauf und schlägt einen begründeten nächsten Schritt vor, und ameax hält Vorschlag und Begründung dort fest, wo der Verkäufer ohnehin arbeitet. Status und Wahrscheinlichkeit bleiben in der Hand der Menschen. Damit bleibt der Forecast nachvollziehbar, und er wird trotzdem aktueller. Aktuelle Pipelinedaten entstehen am besten schon nach jedem Gespräch; wie das geht, zeigt die Seite Gespräche und Meetings automatisch nachbereiten. Den technischen Unterbau beschreibt n8n anbinden.