Angebote per KI vorbereiten

Die Anfrage kommt am Dienstag um 16:40 per Mail: „Wir bräuchten für unseren zweiten Standort das gleiche Paket wie letztes Jahr, allerdings mit zwölf statt acht Arbeitsplätzen, und die Schulung diesmal vor Ort." Wer das Angebot schreibt, muss die Mail lesen, den Kunden finden, das Angebot vom letzten Jahr heraussuchen, die passenden Artikel wählen, Mengen anpassen und die Schulungsvariante tauschen. Das sind zwanzig Minuten, bevor überhaupt über Preis und Formulierung nachgedacht wird. Bei zehn solcher Anfragen pro Woche ist das ein halber Arbeitstag, der vor allem aus Suchen und Abtippen besteht.

Genau dieser Teil lässt sich an einen Workflow übergeben. Ein Sprachmodell kann aus einer Anfrage den Bedarf herauslesen und passende Artikel aus Ihrem Artikelstamm vorschlagen. n8n legt daraus über die REST-API von ameax einen Angebotsentwurf an. Was die KI dabei ausdrücklich nicht tut: Preise festlegen, Rabatte vergeben oder das Angebot verschicken. Das bleibt bei ameax und bei dem Menschen, der den Entwurf prüft.

Der Ablauf im Überblick

ameax ist das führende System: Kunde, Artikelstamm, Preise, Belegvorlagen und Verkaufschancen liegen dort, und dort entsteht auch der Beleg. n8n ist der Taktgeber, der die Anfrage entgegennimmt und die API-Aufrufe in der richtigen Reihenfolge macht. Das Sprachmodell liest die Anfrage und wählt Artikel aus einer Kandidatenliste. Der Mensch prüft, ergänzt und gibt frei.

1. Anfrage erfassen. Eine Mail, ein Formular oder eine Gesprächsnotiz erreicht n8n.
2. Kunde zuordnen. n8n findet Kunde und Ansprechpartner in ameax über die E-Mail-Adresse. Unbekannte Anfragende gehen einen eigenen Weg.
3. Bedarf ermitteln. Das Sprachmodell zerlegt die Anfrage in Bedarfspositionen mit Menge, Einheit und Suchbegriffen und notiert offene Fragen.
4. Artikel suchen. n8n sucht zu jedem Suchbegriff im Artikelstamm von ameax; das Modell wählt aus den Treffern und nur aus diesen.
5. Entwurf anlegen. n8n erzeugt das Angebot aus einer Belegvorlage, verknüpft Ansprechpartner und Verkaufschance und hinterlegt offene Fragen als interne Notiz.
6. Positionen einfügen. Die Artikel kommen mit Artikelnummer und Menge in den Beleg; die Preise lädt ameax aus dem eigenen Artikelstamm.
7. Prüfen und freigeben. Der zuständige Mitarbeiter bekommt eine Wiedervorlage und das PDF, prüft den Entwurf in ameax und versendet ihn.
8. Nach der Annahme. Das Angebot wird zum Auftrag weitergeführt, über die Online-Beauftragung durch den Kunden selbst oder per API.

Vorbereitung in ameax

Belegvorlagen als Ausgangspunkt

Die REST-API legt Angebote am einfachsten aus einer Belegvorlage an. Eine Belegvorlage ist in ameax ein eigener Belegtyp. Sie trägt Kopf- und Schlusstext, Zahlungsbedingungen und auf Wunsch Standardpositionen. Legen Sie für die typischen Anfragearten je eine Vorlage an, zum Beispiel „Angebot Lizenzen und Einrichtung" oder „Angebot Wartung", und notieren Sie deren IDs für den Workflow. Die Vorlage bestimmt Form und Standardtexte. Der Workflow ergänzt nur, was sich von Anfrage zu Anfrage unterscheidet.

Artikelstamm und Preise

Die KI kann nur so gute Artikel finden, wie der Artikelstamm sie beschreibt. Aussagekräftige Artikelbezeichnungen und Artikelnummern mit erkennbarem Muster helfen der Suche mehr als jede Prompt-Formulierung. Artikel lassen sich über die REST-API nur lesen, nicht anlegen oder ändern; der Artikelstamm bleibt damit in der Hand der Menschen, die ihn pflegen. Preise, Preisgruppen, Staffelpreise, Mindestpreise und Rabattsperren sind in der Faktura von ameax hinterlegt. Das ist der Grund, warum die KI keine Preise setzen muss: Die Preislogik liegt bereits im System.

Verkaufschancen und Phasen

Wenn Angebote mit Verkaufschancen verknüpft werden, sieht die Vertriebsleitung, welches Volumen in der Phase „Angebot" steckt. Die Standardphasen sind Identifikation, Gewinnung, Qualifikation, Angebot und Verkauf (IDs 6 bis 10 im Standard, in Ihrer Installation eventuell angepasst). Die Statuswerte sind interne IDs, 14 steht im Standard für „aktiv". Weil die API keinen Endpunkt zum Auflisten von Phasen bietet, hinterlegen Sie die IDs einmalig im Workflow.

Technischer Benutzer und Belegrechte

Das API-Token erbt die Rechte seines Benutzers. Der technische Benutzer für diesen Workflow braucht Lesezugriff auf Kunden, Ansprechpartner und Artikel, das Recht, Angebote anzulegen und zu bearbeiten, und das Recht, Wiedervorlagen für andere Benutzer anzulegen. Ob er darüber hinaus Belegstatus ändern oder Angebote weiterführen darf, entscheiden Sie über dieselben Rechte; für den Anfang genügt es, wenn er nur Entwürfe anlegt. Die Einrichtung in n8n beschreibt die Seite n8n anbinden.

Auslöser

ameax meldet Ereignisse nicht aktiv an andere Systeme. Der Workflow startet dort, wo die Anfrage eintrifft.

• Anfrageformular auf der Website. Das Formular schickt seine Daten per Webhook an n8n. Das ist der sauberste Weg, weil die Daten bereits strukturiert sind: Name, Firma, E-Mail und ein Freitextfeld für den Bedarf.
• Anfragen per E-Mail. n8n liest ein eigenes Postfach, etwa angebote@, zeitgesteuert aus und verarbeitet neue Nachrichten. Weiterleitungen aus dem Vertrieb an dieses Postfach funktionieren genauso.
• Aus einer Gesprächsnotiz. Wenn nach einem Termin vereinbart wurde, ein Angebot zu schicken, kann der Workflow zur Gesprächsnachbereitung diesen Schritt direkt an den Angebots-Workflow übergeben, samt Kunde, Ansprechpartner und Verkaufschance.

Der Auslöser ist ein eigener Baustein. Alle drei Wege münden in dasselbe Datenpaket: Anfragetext, Absender und, falls schon bekannt, die IDs aus ameax.

Umsetzung Schritt für Schritt

Die Beispiele verwenden die Beispiel-Domain https://ihrefirma.ameax.de. Alle IDs und Artikelnummern sind Beispielwerte. 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, wer anfragt und was gebraucht wird (1 bis 3). Dann legt er den Angebotsentwurf an und füllt ihn mit Positionen, deren Preise ameax rechnet (4 und 5). Zum Schluss geht der Entwurf an einen Menschen, und nach der Annahme wird daraus ein Auftrag (6 und 7).

Schritt 1: Kunde und Ansprechpartner finden

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

Ein Treffer liefert Ansprechpartner-ID und customer_id. Ohne Treffer sucht der Workflow den Kunden über die Domain mit /api/v2/customers?filter[email]=*@kunde-beispiel.de. Findet sich auch dann nichts, handelt es sich um einen neuen Interessenten. Diesen Fall sollte der Angebots-Workflow nicht selbst lösen, denn POST /customers prüft keine Dubletten und ordnet keinen Betreuer zu. Übergeben Sie ihn an den Workflow für den Leadeingang oder legen Sie eine Aufgabe für einen Mitarbeiter an. Das Angebot entsteht, sobald der Kunde sauber angelegt ist.

Schritt 2: Bedarf ermitteln

Ein KI-Knoten in n8n mit strukturierter Ausgabe, angebunden an ein Sprachmodell Ihrer Wahl, zerlegt die Anfrage. Zu diesem Zeitpunkt kennt das Modell den Artikelstamm noch nicht. Es beschreibt nur, was gebraucht wird, und liefert Suchbegriffe dazu.

Rolle:
Du liest Kundenanfragen und beschreibst den Bedarf für ein Angebot.
Du nennst keine Preise, keine Rabatte und keine Artikelnummern.
Was unklar ist, schreibst du als offene Frage auf, statt es anzunehmen.
Eingabe:
- anfrage: {{ $json.text }}
- kunde: {{ $json.kunde }}                (Name, Ort)
- fruehere_angebote: {{ $json.belege }}   (Datum, Betreff, Positionstexte)
Ausgabe (nur dieses JSON):
{
  "betreff": "max. 80 Zeichen",
  "bedarf": [
    {"beschreibung": "Arbeitsplatzlizenz", "menge": 12, "einheit": "Stück",
     "suchbegriffe": ["Arbeitsplatz", "Lizenz"]},
    {"beschreibung": "Schulung vor Ort", "menge": 1, "einheit": "Tag",
     "suchbegriffe": ["Schulung vor Ort", "Schulung"]}
  ],
  "offene_fragen": ["Gewünschter Termin für die Schulung?"],
  "wunschtermin": "YYYY-MM-DD oder null"
}

Die früheren Angebote des Kunden sind hilfreicher Kontext, wenn sich die Anfrage darauf bezieht („das gleiche Paket wie letztes Jahr"). n8n holt sie mit GET /api/v2/receipts?filter[customer_id]=4711&filter[receipttype]=offer.

Schritt 3: Artikel im Artikelstamm suchen

Für jeden Suchbegriff fragt n8n die Artikelsuche ab:

GET https://ihrefirma.ameax.de/api/v2/articles?search=Schulung

Die Suche durchsucht aktive Artikel nach Nummer und Bezeichnung und liefert ein schlankes Trefferformat mit nr, article, unit, price, tax_key und node_id. Ohne Suchbegriff gibt sie eine leere Liste zurück. Die Treffer aller Suchbegriffe sammelt n8n zu einer Kandidatenliste. Ein zweiter KI-Aufruf ordnet dann jedem Bedarf einen Kandidaten zu:

Rolle:
Ordne jedem Bedarf genau einen Artikel aus der Kandidatenliste zu.
Verwende ausschließlich Artikelnummern (nr) aus der Kandidatenliste.
Passt kein Kandidat, setze "nr": null und begründe das.
Eingabe:
- bedarf: {{ $json.bedarf }}
- kandidaten: {{ $json.kandidaten }}   (nr, article, unit)
Ausgabe:
{"positionen": [{"nr": "SCH-VOR-ORT", "menge": 1, "begruendung": "…"}],
 "nicht_zugeordnet": [{"beschreibung": "…", "grund": "…"}]}

Die Preise aus der Trefferliste gibt der Workflow dem Modell bewusst nicht mit. Sie spielen für die Zuordnung keine Rolle und würden das Modell nur dazu verleiten, mit ihnen zu rechnen. Ein Code-Knoten prüft danach, dass jede nr tatsächlich in der Kandidatenliste steht. Eine erfundene Artikelnummer wird hier aussortiert und landet bei den offenen Fragen.

Schritt 4: Angebotsentwurf aus der Vorlage anlegen

POST https://ihrefirma.ameax.de/api/v2/receipts/from-template
{
  "template_receipt_id": 950,
  "customer_id": 4711,
  "receipttype": "offer"
}

Die Antwort ist 201 mit dem neuen Beleg einschließlich der Positionen aus der Vorlage und einem Location-Header. Der Beleg ist ein Entwurf. Im nächsten Aufruf ergänzt der Workflow, was die Vorlage nicht wissen kann. Ansprechpartner, Verkaufschance, Kopftext und eine interne Notiz lassen sich per PATCH setzen:

PATCH https://ihrefirma.ameax.de/api/v2/receipts/88123
{
  "person_id": 802,
  "sale_id": 311,
  "user_id": 12,
  "subject": "vielen Dank für Ihre Anfrage. Gern bieten wir Ihnen für Ihren zweiten Standort an:",
  "notice": "Automatisch vorbereitet aus Anfrage vom 29.09.2026.\nOffene Fragen:\n- Gewünschter Termin für die Schulung?\nNicht zugeordnet:\n- Anbindung an Bestandssystem (kein passender Artikel)"
}

Das Feld notice ist die interne Notiz am Beleg und erscheint nicht auf dem Angebot. Dort gehören offene Fragen und nicht zugeordnete Wünsche hin, damit der prüfende Mitarbeiter sie sofort sieht.

Gibt es noch keine Verkaufschance, legt der Workflow sie vorher an, mit Status aktiv und Phase „Angebot":

POST https://ihrefirma.ameax.de/api/v2/sales
{
  "customer_id": 4711,
  "user_id": 12,
  "name": "Zweiter Standort: 12 Arbeitsplätze und Schulung",
  "salestatus": 14,
  "sellingstatus": 9
}

Den Betrag der Verkaufschance setzt der Workflow erst nach Schritt 5, wenn ameax die Belegsumme berechnet hat, oder er überlässt ihn dem Mitarbeiter bei der Freigabe.

Schritt 5: Positionen einfügen, Preise von ameax

Für das Einfügen der ausgewählten Artikel eignet sich der Import-Endpunkt. Er nimmt Positionen als JSON an und findet Artikel über ihre Nummer:

POST https://ihrefirma.ameax.de/api/v2/receipts/88123/positions/import
{
  "mode": "append",
  "positions": [
    {"postype": "article", "nr": "LIZ-ARBEITSPLATZ", "qty": 12},
    {"postype": "article", "nr": "SCH-VOR-ORT", "qty": 1}
  ]
}

Der Workflow schickt kein price-Feld mit. Ohne Preisangabe übernimmt ameax den Preis aus dem Artikelstamm. Danach lädt ein weiterer Aufruf die Artikelpreise für den Entwurf neu aus der Datenbank, sodass die in ameax hinterlegten Preise gelten und nicht irgendein Wert aus dem Workflow:

POST https://ihrefirma.ameax.de/api/v2/receipts/88123/reload-prices

Summen, Steuern und Rabatte berechnet bei Bedarf POST /api/v2/receipts/{id}/recalculate neu. Die Antworten enthalten den Beleg mit seinen Positionen, sodass der Workflow den berechneten Stand direkt weiterverwenden kann, etwa für den Betrag der Verkaufschance.

Einzelne Positionen lassen sich alternativ mit POST /api/v2/receipts/{id}/positions anlegen. Mit postype article braucht dieser Endpunkt die article_id, die das schlanke Trefferformat der Artikelsuche nicht enthält. Für den Weg über die Artikelnummer ist der Import deshalb der direktere. Freie Positionen mit postype manual sollte der Workflow nicht anlegen, denn sie tragen einen Preis, den jemand festlegen müsste, und das ist hier ausdrücklich nicht die Aufgabe der KI.

Soll das Modell einen bestehenden Entwurf in einem zweiten Durchgang überarbeiten, etwa nach einer Rückfrage des Mitarbeiters, liefert GET /api/v2/receipts/{id}/positions/export alle Positionen als JSON, aufbereitet für die Verarbeitung durch KI: mit Referenzblöcken zu Steuerschlüsseln, Kategorien und markierten Artikeln sowie einer Beschreibung des Formats.

Schritt 6: Zur Prüfung vorlegen

Der Entwurf ist fertig, aber nicht versendet. n8n legt beim zuständigen Mitarbeiter eine Wiedervorlage an:

POST https://ihrefirma.ameax.de/api/v2/reminds
{
  "customer_id": 4711,
  "person_id": 802,
  "user_id": 12,
  "sale_id": 311,
  "date": "2026-09-30 09:00:00",
  "subject": "Angebotsentwurf prüfen: 2. Standort, 12 Arbeitsplätze + Schulung vor Ort (1 offene Frage)",
  "priority": 5
}

Zusätzlich kann n8n das PDF abrufen und dem Mitarbeiter intern zuschicken, damit er den Entwurf auch unterwegs ansehen kann:

GET https://ihrefirma.ameax.de/api/v2/receipts/88123/pdf

Der Mitarbeiter öffnet den Beleg in ameax, beantwortet die offenen Fragen, passt Texte oder Positionen an und entscheidet über Rabatte. Den Versand an den Kunden übernimmt er selbst aus ameax. Die REST-API verschickt keine E-Mails. Soll der Versand trotzdem angestoßen werden, gibt es zwei Wege: Der Workflow verschickt die Mail selbst, oder ein in ameax hinterlegter Prozess-Button mit E-Mail-Schritt wird per API ausgelöst. Bei Prozess-Buttons antwortet die API auch bei Misserfolg mit HTTP 200; der Workflow muss deshalb das Feld success in der Antwort prüfen.

Schritt 7: Nach der Annahme zum Auftrag

Nimmt der Kunde an, wird aus dem Angebot ein Auftrag. Ist die Online-Beauftragung eingerichtet, erledigt der Kunde das selbst: Er erhält einen Link in der Angebotsmail oder scannt den QR-Code auf dem Angebots-PDF, beauftragt ohne Login verbindlich, und ameax führt das Angebot automatisch zum Auftrag weiter. Der Workflow muss dann nichts tun. Prüfen Sie einmal mit einem per API erzeugten Angebot, dass Link und QR-Code in Ihrer Konfiguration erscheinen, bevor Sie sich darauf verlassen.

Kommt die Annahme per Mail, kann ein Workflow den Schritt vorbereiten. Das Sprachmodell erkennt die Zusage und ordnet sie dem Angebot zu. Nach Bestätigung durch den Mitarbeiter führt n8n das Angebot weiter:

POST https://ihrefirma.ameax.de/api/v2/receipts/88123/pursue
{
  "receipttype": "order"
}

Das Weiterführen erzeugt den Auftrag mit den Positionen des Angebots und einer Verknüpfung zum Ursprung, und es setzt das Angebot dabei auf „angenommen". Ein bereits weitergeführter Beleg ist gegen erneutes Weiterführen gesperrt. Welche Belegtypen aus einem Angebot entstehen können, beschreibt die Seite Belege weiterführen. Lehnt der Kunde ab, setzt der Workflow nur den Status. Welche Übergänge erlaubt sind, liefert vorher eine Abfrage:

GET  https://ihrefirma.ameax.de/api/v2/receipts/88123/status
POST https://ihrefirma.ameax.de/api/v2/receipts/88123/status
{
  "status": "refused"
}

Die Antwort auf die Abfrage enthält den aktuellen Status und available_transitions; ein nicht erlaubter Übergang wird abgelehnt. Die Verkaufschance setzt danach der Verkäufer auf gewonnen oder verloren. Auch das kann ein Workflow vorbereiten, aber diese Entscheidung sollte ein Mensch bestätigen.

Was in ameax sichtbar wird

Am Beleg und beim Kunden

Der Angebotsentwurf erscheint in der Belegliste und am Kunden, mit Ansprechpartner, Verkaufschance, Kopftext und interner Notiz. Der Mitarbeiter sieht in seinen Wiedervorlagen, welcher Entwurf auf ihn wartet und ob offene Fragen bestehen. Nach dem Weiterführen ist die Kette vom Angebot zum Auftrag am Beleg nachvollziehbar, einschließlich der späteren Lieferscheine und Rechnungen.

In Verkaufschancen und Forecast

Weil das Angebot mit der Verkaufschance verknüpft ist, zeigt die Auswertung „Angebote in Verkaufschancen" je Chance Belegnummer, Belegstatus, Belegdatum und Nettoumsatz des Angebots. Die Verkaufschance selbst geht mit Betrag, Wahrscheinlichkeit und Abschlussdatum in den gewichteten Forecast ein. Mehr dazu auf der Seite Forecast und Pipeline.

Im Hub

In den Hub-Dashboards zeigt die Belegauswertung Anzahl und Netto-Summe der Belege, gefiltert nach Belegart, und der Verkaufschancen-Forecast das Volumen in der Pipeline. Auf demselben Hub stehen die Umsatzbausteine aus der Faktura, sodass Angebote, Pipeline und Umsatz nebeneinander sichtbar sind.

Im Produkt ohne Workflow

Auch ohne n8n hilft ameax beim Formulieren. Im KI-Assistenzsystem gibt es den Textassistenten für Belege, der Betreff und Schlusstext formuliert, und einen Textassistenten für Artikelbeschreibungen. Diese Funktionen arbeiten in der Oberfläche und sind nicht über die REST-API aufrufbar; der Workflow nutzt sein eigenes Sprachmodell.

Best Practices und Stolperstellen

• Die KI setzt keine Preise. Der Workflow schickt weder price noch Rabatte mit. Preise kommen aus dem Artikelstamm und der Preislogik von ameax, Rabatte entscheidet der Mitarbeiter. So kann ein Missverständnis des Modells nie zu einem falschen Preis im Angebot führen, sondern höchstens zu einer falschen Position, die bei der Prüfung auffällt.
• Nur Artikel aus der Kandidatenliste. Sprachmodelle erfinden gern plausible Artikelnummern. Die Regel „nur aus der Liste" im Prompt reicht nicht; der Code-Knoten muss jede Nummer gegen die tatsächlichen Suchtreffer prüfen.
• Offene Fragen sichtbar machen, nicht raten. Was unklar ist, gehört in die interne Notiz des Belegs und in den Betreff der Wiedervorlage. Ein Angebot mit einer ehrlich markierten Lücke ist schneller fertig als eines, bei dem der Prüfer erst herausfinden muss, welche Annahme die KI getroffen hat.
• Suchbegriffe kurz halten. Die Artikelsuche vergleicht Nummer und Bezeichnung. Kurze, charakteristische Begriffe („Schulung", „Wartung") finden mehr als ganze Sätze. Lassen Sie das Modell je Bedarf zwei bis drei Varianten liefern und sammeln Sie die Treffer.
• Wiederholungen verhindern. Die API kennt keine Idempotenz-Schlüssel. Wird der Workflow nach einem Abbruch neu gestartet, entsteht sonst ein zweiter Entwurf. Speichern Sie die Kennung der Anfrage, etwa die Message-ID der Mail, im Feld external_id des Belegs, und prüfen Sie vor dem Anlegen die Entwürfe des Kunden (filter[customer_id], filter[receipttype]=offer, filter[receiptstatus]=draft) auf diese Kennung.
• Entwurf bleibt Entwurf. Positionen lassen sich nur in Entwürfen importieren, und das ist gut so. Der Workflow sollte den Status nicht selbst ändern. Aktiv wird das Angebot erst, wenn ein Mensch es freigibt.
• Weiterführen erst nach Prüfung. Ein weitergeführtes Angebot ist gesperrt und steht auf „angenommen". Deutet das Modell eine höfliche Antwort fälschlich als Zusage, ist der Auftrag angelegt. Lassen Sie diesen Schritt deshalb bestätigen, oder nutzen Sie die Online-Beauftragung, bei der der Kunde selbst ausdrücklich beauftragt.
• Vorlagen je Anfrageart. Eine Vorlage für alles führt zu Angeboten mit Standardpositionen, die nicht passen. Einige gut geschnittene Vorlagen und eine Regel im Workflow, welche Vorlage wann gilt, sparen bei der Prüfung Zeit.

Fazit

Ein Angebot per KI vorzubereiten heißt, das Suchen und Abtippen an einen Workflow abzugeben und die Entscheidungen bei den Menschen zu lassen. Das Sprachmodell liest die Anfrage und wählt Artikel aus Ihrem Artikelstamm, n8n legt den Entwurf aus einer Belegvorlage an, und ameax rechnet mit Ihren Preisen. Der Mitarbeiter prüft, ergänzt und versendet. Nach der Annahme wird das Angebot zum Auftrag, durch den Kunden selbst über die Online-Beauftragung oder per API nach Bestätigung. So entsteht aus einer Anfrage in wenigen Minuten ein Entwurf, bei dem nur noch das geprüft werden muss, was tatsächlich Urteilsvermögen braucht. Die technische Anbindung beschreibt n8n anbinden; wie Verkaufschancen danach gepflegt bleiben, zeigt Pipeline-Pflege durch einen KI-Agenten.