Vertrieb und Support automatisieren mit ameax

Ein Sprachmodell schreibt in Sekunden eine Gesprächszusammenfassung, bewertet eine Anfrage oder entwirft eine Antwort auf ein Ticket. Die eigentliche Frage beginnt danach: Wo landet dieses Ergebnis? Wer sieht es morgen, wenn der Kunde anruft? Und wer kann in drei Monaten nachvollziehen, warum ein Lead als „nicht passend" aussortiert wurde?

In vielen Unternehmen lautet die ehrliche Antwort: Das Ergebnis steht in einer Tabelle, die ein Workflow nachts befüllt, in einem geteilten Postfach, in einem Chatverlauf oder im Protokoll des Automatisierungswerkzeugs. Jede einzelne Automatisierung funktioniert, aber zusammen hinterlassen sie verstreute Spuren. Der Vertrieb sieht die Bewertung nicht, der Support weiß nichts von der offenen Verkaufschance, und niemand kann sagen, welche Aussage ein Mensch und welche eine Maschine getroffen hat.

Diese Seite beschreibt einen anderen Aufbau: KI-Agenten und Workflows arbeiten zu, aber sie schreiben ihre Ergebnisse dorthin, wo auch Ihr Team arbeitet. In ameax ist das dieselbe Kundenakte, in der Aktivitäten, Wiedervorlagen, Verkaufschancen, Tickets und Belege liegen. Sie erfahren, wie die Rollen verteilt sind, welche Information an welchen Ort gehört, welche Schnittstellen es gibt und nach welchen zehn Grundsätzen Sie Workflows bauen, die sich auch nach einem Jahr noch prüfen lassen.

Drei Stufen: eingebaut, verbunden, mit KI

Nicht jede Automatisierung braucht ein Sprachmodell, und nicht jede braucht ein externes Werkzeug. In ameax lassen sich Abläufe auf drei Stufen automatisieren, die aufeinander aufbauen. Die meisten Unternehmen beginnen sinnvollerweise mit der ersten.

Stufe 1: In ameax eingebaut

Ein großer Teil der Routine lässt sich direkt in ameax automatisieren, ohne Programmierung und ohne Zusatzwerkzeug. Die wichtigsten Werkzeuge dafür sind Prozess-Buttons und der Automailer.

Ein Prozess-Button führt auf einen Klick eine feste Kette von Schritten aus: Aktivität festhalten, E-Mail aus einer Textvorlage schreiben, Wiedervorlage setzen, Status wechseln, Beleg erzeugen. Solche Buttons gibt es am Kunden und an der Verkaufschance, an Tickets, an Belegen, an Objekten und im Matching, jeweils mit den Aktionen, die dort gebraucht werden. Manche laufen auch ohne Klick: beim Absenden eines Webformulars, bei einer Registrierung oder Buchung im Kundenportal oder wenn zu einem Ticket eine neue E-Mail eingeht. Kunden können im Portal die Ticket-Buttons drücken, die für ihre Rolle freigegeben sind.

Der Automailer verschickt E-Mail-Strecken Schritt für Schritt im festgelegten Abstand, mit Double-Opt-in, Abmeldung und Kopplung an den Kampagnenstatus. Dazu kommen zeitgesteuerte Abläufe, die ameax selbst übernimmt: wiederkehrende Wiedervorlagen, Abo-Rechnungen, Sammelrechnungen, der Versand versandbereiter Belege oder die Zuordnung neuer Kunden zum Betreuer nach PLZ-Gebiet.

Stufe 2: Mit anderen Systemen verbunden

Sobald ein Ablauf ein anderes System einbezieht, etwa ein Formular-Werkzeug, einen Shop, ein Telefonsystem oder eine Buchhaltung, übernimmt ein Werkzeug wie n8n den Takt. Es liest und schreibt über die REST-API. Die eingebauten Bausteine bleiben dabei nutzbar: Ein Workflow kann einen Prozess-Button per API auslösen. Der Ablauf selbst bleibt in ameax gepflegt, der Workflow entscheidet nur, wann er läuft.

Stufe 3: Mit Sprachmodell

Wo Text verstanden, eingeordnet oder formuliert werden muss, kommt ein Sprachmodell in den Workflow: eine Anfrage qualifizieren, ein Gespräch zusammenfassen, ein Ticket einordnen, einen Antwortentwurf schreiben. Um diese Stufe geht es im größten Teil dieser Seite. Die Regel dahinter ist einfach: So viel wie möglich mit den eingebauten Werkzeugen lösen, die Verbindung nach außen dort ergänzen, wo sie gebraucht wird, und das Sprachmodell dort einsetzen, wo es tatsächlich Arbeit abnimmt, die ein fester Ablauf nicht leisten kann.

Die Architektur: drei Rollen und eine Freigabe

Eine belastbare Automatisierung trennt vier Aufgaben, die in der Praxis oft vermischt werden: speichern, steuern, bearbeiten und entscheiden. Jede Aufgabe bekommt einen eigenen Ort. Das klingt nach Aufwand, spart ihn aber, sobald der erste Workflow ausgetauscht, erweitert oder geprüft werden muss.

ameax: das Gedächtnis und das führende System

ameax ist keine reine Datenbank hinter einer Schnittstelle, sondern die Software, in der Ihr Team arbeitet. Das AkquiseManager CRM hält Kunden, Ansprechpartner, Aktivitäten, Wiedervorlagen und Kampagnen. Die Verkaufschancen tragen Status, Phase, Wahrscheinlichkeit und Betrag. In der Faktura entstehen Angebote, Aufträge, Lieferscheine und Rechnungen. Vorgänge und Tickets laufen im Aufgabenmanagement und, wo gewünscht, im Ticketsystem mit Kundenportal. Das Dokumentenportal gibt Ihren Kunden einen eigenen Zugang.

Alle diese Bereiche arbeiten auf denselben Kundendaten. Für die Automatisierung ist das der entscheidende Punkt: Ein Workflow, der ein Ticket einordnet, kann im selben System nachsehen, ob der Kunde eine offene Verkaufschance oder eine unbezahlte Rechnung hat. Und das Ergebnis, das er zurückschreibt, sieht der Vertrieb genauso wie der Support, weil es am selben Kunden hängt.

n8n: der Taktgeber

n8n ist ein Werkzeug, in dem Sie Abläufe aus Knoten zusammensetzen: ein Auslöser, dann Abfragen, Verzweigungen, Aufrufe anderer Dienste. In dieser Architektur hat n8n genau eine Aufgabe: Es bestimmt, wann etwas passiert und in welcher Reihenfolge. Es startet den Ablauf, holt die Daten aus ameax, übergibt sie dem Sprachmodell, prüft die Antwort und schreibt das Ergebnis zurück. n8n speichert keine Kundendaten dauerhaft, allenfalls technische Hilfswerte wie den Zeitpunkt der letzten Abfrage.

Die Anbindung erfolgt über den HTTP-Request-Knoten von n8n und ein API-Token. Einen eigenen ameax-Knoten braucht es dafür nicht. Wie das im Einzelnen aussieht, beschreibt die Anleitung n8n mit ameax verbinden.

Das Sprachmodell: der Bearbeiter

Das Sprachmodell liest Text und liefert strukturierte Ergebnisse: eine Einordnung, eine Zusammenfassung, einen Antwortentwurf, eine Liste erkannter Felder. Es entscheidet nicht selbst, was in ameax geschrieben wird. Es gibt ein Ergebnis in einem vereinbarten Format zurück, meist JSON, und der Workflow prüft dieses Ergebnis, bevor er daraus API-Aufrufe macht. Welches Modell Sie verwenden, entscheiden Sie: ein Sprachmodell Ihrer Wahl, gehostet bei einem Dienst Ihrer Wahl oder im eigenen Rechenzentrum.

Der Mensch: die Freigabe

Nicht jeder Schritt braucht eine Freigabe. Eine Gesprächsnotiz als Aktivität abzulegen ist unkritisch, einen Kunden umzuhängen oder eine Verkaufschance als verloren zu markieren ist es nicht. Die Freigabe ist deshalb kein Formular in n8n, sondern eine Wiedervorlage in ameax: Der Workflow legt sie bei der zuständigen Person an, die sie in ihrer gewohnten Liste findet, den Vorschlag prüft und entscheidet. So bleibt die Entscheidung dort, wo auch die Verantwortung liegt.

Ein Durchlauf als Beispiel

Wie die Rollen zusammenspielen, zeigt ein einfacher Fall: Ein Vertriebsmitarbeiter diktiert nach einem Kundentermin eine Notiz, die als Transkript in n8n ankommt.

1. n8n empfängt den Text und fragt ameax nach dem Kunden, zum Beispiel über die Kundennummer, die im Kalendereintrag stand: GET /api/v2/customers?filter[customer_number]=10457.
2. n8n holt den Kontext, etwa die offenen Verkaufschancen des Kunden: GET /api/v2/sales?filter[customer_id]=4711&filter[salestatus]=14.
3. Das Sprachmodell bearbeitet Transkript und Kontext und gibt JSON zurück: Zusammenfassung, vereinbarter nächster Schritt mit Datum, Hinweis auf eine geänderte Phase der Verkaufschance, Sicherheit der Einschätzung.
4. n8n schreibt zurück: eine Aktivität mit der Zusammenfassung, zugeordnet dem Mitarbeiter, und eine Wiedervorlage für den nächsten Schritt.
5. Der Mensch entscheidet über die Phase: Statt die Verkaufschance selbst zu ändern, legt der Workflow den Vorschlag in den Aktivitätstext und eine Wiedervorlage „Phase prüfen" an. Der Mitarbeiter bestätigt mit zwei Klicks in ameax.

Der Aufruf in Schritt 4 sieht so aus (IDs sind Beispielwerte):

POST /api/v2/actions
Content-Type: application/json

{
  "customer_id": 4711,
  "person_id": 802,
  "user_id": 17,
  "sale_id": 3301,
  "activity_id": 12,
  "date": "2026-09-28 14:30:00",
  "subject": "Termin vor Ort: Erweiterung um zweiten Standort besprochen",
  "notice": "Zusammenfassung (KI): ... Vorschlag: Phase Angebot. Sicherheit: mittel."
}

Nach diesem Durchlauf steht alles, was passiert ist, am Kunden: Wer am nächsten Tag die Akte öffnet, sieht die Zusammenfassung, die Verkaufschance und die offene Wiedervorlage, ohne zu wissen, dass ein Workflow beteiligt war. Und wer es wissen will, erkennt es an der Aktivitätsart.

Wie Daten hinein- und herauskommen

ameax bietet für diese Architektur drei Eingänge:

1. REST-API v2. Lesen und Schreiben fast aller Vertriebs-, Support- und Belegdaten sowie der Konfiguration: Kunden, Ansprechpartner, Aktivitäten, Wiedervorlagen, Notizen, Verkaufschancen, Kampagnenzuordnungen, Vorgänge, Belege, Zusatzfelder, Textvorlagen und mehr. Das ist der Hauptweg für jeden Workflow.
2. Webhook-Posteingang. Unter POST /p/webhook/{quelle} nimmt ameax Rohtext, JSON oder CSV an, speichert die Nachricht zuerst und lässt dann eine KI Firma und Person herauslesen und einem Kunden zuordnen. Eindeutige Fälle werden übernommen, unklare landen zur Prüfung bei einem Menschen.
3. Prozess-Buttons per API. Abläufe, die Sie in ameax als Prozess-Button hinterlegt haben, etwa „Aktivität schreiben, Wiedervorlage setzen, Status wechseln", lassen sich von außen für einen Kunden oder ein Ticket auslösen. So nutzt der Workflow die fachliche Logik, die Ihr Team ohnehin pflegt.

Und wodurch startet ein Workflow? Heute auf drei Wegen. Erstens zeitgesteuert: n8n fragt in einem festen Takt über die API ab, welche Datensätze neu sind oder sich geändert haben, sortiert nach Änderungszeitpunkt. Zweitens durch das externe System: Ein Webformular, ein Voice-Agent-Dienst oder ein Postfach schickt seine Daten an einen Webhook in n8n, und der Workflow schreibt das Ergebnis nach ameax. Drittens über den Webhook-Posteingang von ameax, wenn Rohdaten direkt in ameax ankommen und dort zugeordnet werden sollen. Jede Szenario-Seite beschreibt in einem eigenen Abschnitt, welcher Auslöser dort passt.

Das Datenmodell: welche Information wohin gehört

Die häufigste Ursache für unbrauchbare Automatisierungen ist nicht ein schlechter Prompt, sondern ein falscher Ablageort. Wenn ein Workflow alles in ein Notizfeld schreibt, ist die Information zwar gespeichert, aber weder auswertbar noch für Wiedervorlagen, Zielvorgaben oder Kampagnen nutzbar. ameax hat für die meisten Informationen, die in Vertrieb und Support anfallen, einen eigenen, strukturierten Ort.

Kunde, Ansprechpartner und Kundenkennung

Der Kunde ist der Anker. Pflicht ist nur der Name, dazu kommen Adresse, Kontaktdaten, Kundentyp, zuständige Betreuergruppe (agent_id) und Ihre Zusatzfelder. Ansprechpartner hängen immer an einem Kunden und brauchen mindestens einen Nachnamen. Für Automatisierungen besonders wichtig ist die Kundenkennung: Sie speichert zu einem Kunden beliebig viele externe IDs, jeweils mit einem Typ wie shop oder voice. Ein Workflow, der eine Bestellung, einen Anruf oder ein Formular verarbeitet, findet den Kunden über diese Kennung wieder, ohne auf Namensgleichheit angewiesen zu sein. Für eine einzelne externe ID gibt es zusätzlich das Feld external_id direkt am Kunden.

Aktivität, Notiz und Wiedervorlage

Diese drei werden oft verwechselt. Eine Aktivität beschreibt ein Ereignis mit Datum: „Anruf am 28.09., Ergebnis: Rückruf erwünscht". Sie trägt eine Aktivitätsart, optional ein Ergebnis, einen Betreff bis 250 Zeichen und einen Text. Aktivitäten bilden den Verlauf des Kunden und zählen, je nach Einrichtung, auf Zielvorgaben ein. Eine Notiz hält Wissen fest, das nicht an einen Zeitpunkt gebunden ist: „Bestellt nur über den Einkauf in Hamburg". Eine Wiedervorlage ist eine terminierte Aufgabe für eine Person oder ein Team. Sie hat kein eigenes Textfeld; die Begründung gehört in die Aktivität oder Notiz, die der Workflow gleichzeitig anlegt, und der Betreff der Wiedervorlage verweist darauf.

Verkaufschance und Kampagne

Eine Verkaufschance ist ein konkretes mögliches Geschäft. Ihr Status (aktiv, gewonnen, verloren, passiv, eingestellt, storniert) und ihre Phase (etwa Qualifikation oder Angebot) sind in ameax interne IDs, die Sie einmalig nachsehen. Wahrscheinlichkeit und Betrag fließen in Forecast und Pipeline ein. Eine Kampagne dagegen fasst viele Kunden unter einem Ziel zusammen, zum Beispiel eine Telefonaktion oder eine Messe-Nachfassung. Jeder Kunde hat in einer Kampagne einen Kampagnenstatus mit Wirkung (positiv, neutral, negativ) und der Angabe, ob der Status abschließend ist. Die Win/Loss-Analyse in ameax wertet Kampagnen aus, nicht Verkaufschancen.

Vorgang, Ticket und Beleg

Ein Vorgang gehört zu einem Vorgangs-Schema, das seine Status festlegt. Er hat Titel, Beschreibung, Priorität, eine zuständige Person oder ein Team und Termine. Kommentare lassen sich intern oder öffentlich anlegen; öffentliche Kommentare sieht der Kunde im Kundenportal. Belege schließlich bilden alles ab, was einen Preis hat. Ein Workflow kann ein Angebot aus einer Belegvorlage erzeugen, Positionen ergänzen und das PDF abrufen. Artikel sind über die API nur lesbar.

Häufige Fehlzuordnungen

Drei Muster tauchen in fast jedem ersten Entwurf eines Workflows auf. Erstens: Der Stand in einer Kampagne wird als Aktivität geschrieben („Kunde hat kein Interesse"), aber der Kampagnenstatus bleibt unverändert. Dann zeigt die Kampagnenauswertung ein falsches Bild. Richtig ist beides: der Kampagnenstatus über PATCH /api/v2/customer-projects/{id} mit neuem type_id und eine Aktivität, die den Anlass festhält. Ein Statuswechsel über die API schreibt selbst keine Aktivität und keine Statushistorie, und er ändert auch nicht den Kundentyp.

Zweitens: Aufgaben werden als Notiz abgelegt („bitte nächste Woche anrufen"). Eine Notiz erinnert niemanden. Was jemand tun soll, gehört in eine Wiedervorlage mit Datum und Zuständigkeit.

Drittens: Externe Kennungen landen im Freitext. Eine Shop-Kundennummer im Notizfeld ist für den nächsten Workflow nicht auffindbar, weil der Notiztext kein Filterfeld der API ist. In die Kundenkennung geschrieben, ist sie mit einem einzigen Filter erreichbar.

Die Schnittstellen im Detail

Die vollständige Referenz mit allen Ressourcen, Endpunkten und Feldern steht auf der Seite REST-API. Hier geht es um die Eigenschaften, die für Automatisierungen den Unterschied machen.

API v2: Konventionen

Die API liegt unter /api/v2/ Ihrer Installation und ist nur über HTTPS erreichbar. Sie folgt REST-Konventionen: GET liest, POST legt an, PUT und PATCH ändern, DELETE löscht. Anfragen mit Inhalt brauchen den Header Content-Type: application/json. Eine Anlage antwortet mit Status 201 und einem Location-Header, ein Löschen mit 204. Listen kommen in einer festen Hülle:

{
  "data": [ { "id": 4711, "name": "Muster GmbH", ... } ],
  "total": 132,
  "page": 1,
  "per_page": 25
}

Geblättert wird mit page und per_page; Standard sind 25 Einträge, höchstens 100. Sortiert wird mit sort, ein Minus kehrt die Richtung um, etwa sort=-updated_at. Mit include laden Sie verbundene Daten mit, etwa die Ansprechpartner eines Kunden, und mit fields[typ] begrenzen Sie die zurückgegebenen Felder.

Filter: bewusst einfach

Gefiltert wird ausschließlich auf Gleichheit: filter[email]=info@beispiel.de. Ein Stern dient als Platzhalter, etwa filter[email]=*@beispiel.de für alle Adressen einer Domain. Mehrere Filter werden mit UND verknüpft. Operatoren wie „größer als" oder einen Filter „geändert seit" gibt es nicht; für Belege existiert zusätzlich ein Datumsbereich in der Form filter[date]=2026-01-01..2026-03-31. Wer ein Feld filtert, das nicht zulässig ist, bekommt Status 400 und in der Fehlermeldung die Liste der zulässigen Felder. Das ist hilfreich beim Bauen: Der erste Fehlversuch zeigt, welche Filter es gibt.

Fehlerformat und Nachvollziehbarkeit

Fehler kommen als application/problem+json nach RFC 7807. Bei Validierungsfehlern (Status 422) enthält die Antwort eine Liste errors mit Feldname, Fehlercode und Meldung. Jede Antwort, auch eine erfolgreiche, trägt den Header X-Request-Id. Wenn Sie diese ID in Ihrem Workflow mitschreiben, lässt sich jeder einzelne Aufruf später eindeutig zuordnen.

HTTP/1.1 422
Content-Type: application/problem+json; charset=utf-8

{
  "type": "about:blank",
  "title": "Validation Error",
  "status": 422,
  "detail": "The submitted data could not be validated",
  "request_id": "...",
  "errors": [
    { "field": "subject", "code": "required", "message": "..." }
  ]
}

Token und Rechte

Authentifiziert wird mit einem API-Token, als Authorization: Bearer <token> oder per Basic-Auth mit dem Benutzernamen api und dem Token als Passwort. Ein Token gehört immer zu einem Benutzer und erbt genau dessen Rechte. Eigene Rechte-Bereiche je Token gibt es nicht; was ein Workflow darf, steuern Sie über den Benutzer. Je Token lassen sich ein Ablaufdatum und eine Liste erlaubter IP-Adressen hinterlegen, zusätzlich gibt es eine systemweite IP-Freigabeliste mit CIDR-Bereichen. Nach wiederholten Fehlversuchen sperrt ameax mit Status 429. Die Token verwalten Sie in ameax unter /c/apitoken.

OpenAPI als Werkzeugbeschreibung für Sprachmodelle

Unter GET /api/v2/openapi.json (oder .yaml) liefert jede Installation eine maschinenlesbare Beschreibung aller Endpunkte. Das Besondere: Die Spezifikation ist mandantenspezifisch. Sie enthält Ihre eigenen Zusatzfelder mit Bezeichnung und Auswahlwerten. Ein Sprachmodell, das Werkzeuge aufrufen soll, oder ein KI-Agent in n8n bekommt damit eine Beschreibung, die zu Ihrer Installation passt, statt einer allgemeinen, in der Ihre Felder fehlen. Mit ?neutral=1 erhalten Sie die Fassung ohne Mandantenfelder. Die Spezifikation ist per Token oder Doku-Passwort geschützt.

Webhook-Posteingang

Der Posteingang ist für Daten gedacht, die unstrukturiert ankommen: eine weitergeleitete E-Mail, ein Formularinhalt, eine CSV-Zeile. Sie schicken sie an /p/webhook/{quelle}, wählen den Posteingang und das Format. ameax speichert die Nachricht immer zuerst, sodass nichts verloren geht, auch wenn die Verarbeitung scheitert. Danach liest eine KI Firma und Person heraus und sucht passende Kunden über Prüfsumme, Domain, E-Mail und Name. Je Posteingang legen Sie fest, ob überhaupt eine Aktion folgt, ob Kunden angelegt beziehungsweise aktualisiert oder Ansprechpartner zu einem erkannten Kunden ergänzt werden.

Die automatische Übernahme ist eine Erlaubnis, keine Garantie: Übernommen wird nur, wenn die Zuordnung eindeutig ist. Alles andere steht mit Status „vorgeschlagen" zur Prüfung bereit, und ein Mensch entscheidet. Neukunden laufen dabei durch dieselbe Anlage wie in der Oberfläche, mit Prüfsumme, Standardbetreuer, Historie und Geodaten. Bei bestehenden Kunden werden Telefon, E-Mail und Website nur ergänzt, wenn das Feld leer ist.

Blueprints: Einrichtung als Datei

Kampagnen mit ihren Status, Vorgangs-Schemas mit Status und Prozess-Buttons, Objektarten sowie Wertelisten und Verwendungszwecke lassen sich als Blueprint lesen und einspielen. Zu jedem Blueprint gibt es ein JSON-Schema, gegen das Sie vor dem Einspielen prüfen können. Damit lässt sich die Einrichtung, die ein Workflow voraussetzt, beschreiben, versionieren und auf eine zweite Installation übertragen. Wie ein Sprachmodell dabei helfen kann, zeigt das Szenario ameax per KI einrichten.

Prozess-Buttons

Prozess-Buttons sind in ameax hinterlegte Abläufe, die mit einem Klick mehrere Schritte ausführen: eine Aktivität anlegen, eine E-Mail oder einen Brief erzeugen, eine Wiedervorlage setzen, einen Status wechseln, einen Beleg erstellen. Über GET /customers/{id}/proceedings fragt ein Workflow ab, welche Buttons für einen Kunden verfügbar sind, und löst einen davon mit POST /customers/{id}/proceedings/{pid}/execute aus. Für Tickets gibt es dasselbe unter /tasks/{id}/proceedings/{pid}/execute. Der Vorteil: Die fachliche Logik bleibt in ameax, wo Ihr Team sie pflegt, und der Workflow ruft sie nur auf. Da die API selbst keine E-Mails versendet, ist ein Prozess-Button mit E-Mail-Schritt auch der Weg, eine in ameax hinterlegte Mail von außen anzustoßen.

Zehn Grundsätze für Workflows mit ameax

Die folgenden Grundsätze sind aus den Eigenschaften der Schnittstellen abgeleitet. Sie sind nicht kompliziert, aber jeder einzelne verhindert eine typische Fehlerquelle, die sonst erst nach Wochen auffällt.

1. Ein technischer Benutzer je Workflow, mit genau den nötigen Rechten

Da ein Token die Rechte seines Benutzers erbt und keine eigenen Rechte-Bereiche kennt, ist der Benutzer das einzige Werkzeug, um einen Workflow zu begrenzen. Legen Sie deshalb für jeden Workflow oder jede Gruppe zusammengehöriger Workflows einen eigenen technischen Benutzer an, etwa „KI Leadeingang", und geben Sie ihm nur die Rechte, die der Ablauf braucht. Das Token bekommt ein Ablaufdatum und, wenn Ihr n8n unter festen Adressen läuft, eine IP-Beschränkung.

Beispiel: Ein Workflow, der nur Gesprächsnotizen als Aktivitäten ablegt, braucht Lesezugriff auf Kunden und Ansprechpartner und das Recht, Aktivitäten anzulegen. Belege, Zusatzfeld-Definitionen oder Benutzer muss er nicht sehen. Wird das Token kompromittiert, ist der Schaden auf genau diesen Umfang begrenzt, und Sie sperren es, ohne andere Workflows zu stören.

2. Vor jedem Anlegen suchen und externe IDs als Kundenkennung speichern

Die Anlage über POST /customers prüft keine Dubletten und ordnet keinen Betreuer und kein Gebiet zu. Das übernehmen in ameax die Oberfläche, der Import und der Webhook-Posteingang, nicht die API. Der Workflow muss also selbst suchen: nach E-Mail-Adresse, nach external_id oder über die Kundenkennungen. Erst wenn nichts gefunden wird, legt er an und setzt die agent_id, die er vorher aus den PLZ-Gebieten ermittelt hat.

Beispiel: Ein Shop meldet eine Bestellung mit Kundennummer 88213. Der Workflow fragt GET /api/v2/customer-identifiers?filter[type]=shop&filter[identifier]=88213. Gibt es einen Treffer, arbeitet er mit diesem Kunden weiter. Sonst sucht er per filter[email], legt bei Bedarf neu an und speichert danach die Shop-Nummer als Kundenkennung. Beim nächsten Durchlauf ist der Kunde sofort auffindbar, und ein wiederholter Durchlauf erzeugt keinen zweiten Datensatz.

3. Jede KI-Aktion als Aktivität protokollieren

Was ein Workflow in ameax tut, soll im Verlauf des Kunden sichtbar sein. Das ist die Grundlage für Vertrauen: Ein Vertriebsmitarbeiter, der eine veränderte Verkaufschance sieht, soll im Aktivitätsstrom lesen können, dass eine KI-Auswertung sie geändert hat, wann und mit welcher Begründung. Legen Sie dafür eine eigene Aktivitätsart an, etwa „KI-Auswertung", und schreiben Sie in den Text, was geprüft und was geändert wurde. Wichtig für Zielvorgaben: Ohne Angabe von user_id gilt der API-Benutzer als Verfasser. Soll eine Aktivität dem zuständigen Mitarbeiter zugerechnet werden, etwa weil sie ein Gespräch dokumentiert, das er geführt hat, setzen Sie user_id ausdrücklich.

Beispiel: Die KI stuft eine Anfrage als „passt nicht zur Zielgruppe" ein. Der Workflow legt eine Aktivität mit Aktivitätsart „KI-Auswertung", Betreff „Anfrage bewertet: nicht passend" und dem Begründungstext des Modells an. Fragt der Kunde drei Wochen später nach, sieht Ihr Team, was passiert ist.

4. Die KI schlägt vor, ein Mensch bestätigt bei Mehrdeutigkeit

Ein Sprachmodell liefert auch dann eine Antwort, wenn die Eingabe nicht eindeutig ist. Deshalb braucht jeder Workflow eine klare Regel, wann er selbst schreibt und wann er einen Menschen fragt. Lassen Sie das Modell neben dem Ergebnis eine Einschätzung der Sicherheit zurückgeben und definieren Sie im Workflow eine Schwelle. Unterhalb davon legt der Workflow keine Änderung an, sondern eine Wiedervorlage an die zuständige Person, dazu eine Aktivität oder Notiz mit dem Vorschlag. Der Webhook-Posteingang arbeitet nach demselben Prinzip: automatisch nur bei eindeutiger Zuordnung, sonst Vorschlag zur Prüfung.

Beispiel: Eine E-Mail erwähnt „Herrn Becker", und beim Kunden gibt es zwei Ansprechpartner dieses Namens. Statt zu raten, legt der Workflow die Gesprächsnotiz am Kunden ohne Ansprechpartner ab und eine Wiedervorlage „Ansprechpartner zuordnen: Becker" beim Betreuer.

5. Herkunft und Lead-Quelle als Zusatzfeld

ameax hat kein eigenes Standardfeld „Lead-Quelle". Weil Sie später auswerten wollen, welcher Kanal welche Kunden bringt, gehört die Herkunft in ein Zusatzfeld mit festen Auswahlwerten wie „Webformular", „Messe", „Telefonaktion". Feste Werte statt Freitext sind wichtig, denn ein Sprachmodell formuliert sonst jedes Mal etwas anders. Die technische Herkunft im Sinne einer externen ID gehört zusätzlich in die Kundenkennung.

Beispiel: Das Zusatzfeld „Lead-Quelle" erscheint mit seinen Auswahlwerten in der OpenAPI-Spezifikation Ihrer Installation. Geben Sie dem Sprachmodell genau diese Werte vor, und der Workflow schreibt nur Werte, die in der Liste stehen.

6. Einwilligung vor jeder Ansprache prüfen

Bevor ein Workflow einen Kunden per E-Mail oder Telefon anspricht oder ansprechen lässt, muss feststehen, dass das zulässig ist. ameax hält Einwilligungen je Kanal fest, für E-Mail, Telefon und Brief, erfasst über Webformular mit Double-Opt-in oder manuell. Legen Sie fest, an welchem Feld der Workflow die Zulässigkeit abliest, und prüfen Sie es bei jedem Durchlauf, nicht nur beim ersten. Ob eine Ansprache im Einzelfall erlaubt ist, hängt von Kanal, Empfänger und Art der Einwilligung ab; das sollten Sie mit Ihrer Datenschutzberatung klären, bevor ein Workflow automatisch Kontakt aufnimmt.

Beispiel: Ein Nachfass-Workflow wählt Kunden aus einer Kampagne aus. Er überspringt jeden Kunden ohne vermerkte Einwilligung für den geplanten Kanal und legt stattdessen eine Aktivität „Nicht kontaktiert: keine Einwilligung für E-Mail" an. So ist auch das Auslassen dokumentiert.

7. Zeitgesteuertes Abfragen richtig bauen

Weil es keinen Filter „geändert seit" gibt, fragt ein zeitgesteuerter Workflow nach Änderungszeitpunkt absteigend sortiert ab, also mit sort=-updated_at, und blättert so lange, bis er auf Einträge stößt, die älter sind als der Stand seines letzten Laufs. Diesen Stand merkt er sich. Ein Workflow, der stattdessen jedes Mal nur die erste Seite liest, verpasst Änderungen, sobald in einem Intervall mehr als eine Seite zusammenkommt.

Beispiel: Alle zehn Minuten ruft der Workflow GET /api/v2/sales?sort=-updated_at&per_page=100 ab. Er verarbeitet alle Einträge mit updated_at nach dem gespeicherten Zeitpunkt, holt bei Bedarf die nächste Seite und speichert am Ende den jüngsten gesehenen Zeitpunkt. Einträge, die er selbst geändert hat, erkennt er an updated_by und überspringt sie, damit er sich nicht in einer Schleife selbst auslöst.

8. Fehler auswerten, nicht nur abfangen

Ein Workflow, der bei jedem Fehler nur „fehlgeschlagen" meldet, ist im Betrieb kaum zu pflegen. Werten Sie die Antworten aus. Ein 422 enthält in errors das betroffene Feld und einen Fehlercode, etwa required oder read_only. Ein 400 bei Filtern nennt die zulässigen Felder. Ein 401 oder 403 deutet auf ein abgelaufenes Token, eine IP-Beschränkung oder fehlende Rechte des Benutzers. Schreiben Sie bei jedem Fehler die X-Request-Id mit. Und prüfen Sie bei Prozess-Buttons das Feld success in der Antwort: Ein Prozess-Button antwortet auch dann mit Status 200, wenn er nicht ausgeführt werden konnte.

Beispiel: Die Anlage einer Aktivität scheitert mit 422, Feld subject, Code max_length, weil das Modell einen zu langen Betreff geliefert hat. Der Workflow kürzt den Betreff auf 250 Zeichen, verschiebt den Rest in den Text und versucht es erneut, statt den Vorgang zu verwerfen.

9. Prompts und Texte aus Textvorlagen speisen

Ein Prompt, der im Code-Knoten eines Workflows steht, ist für Ihr Vertriebsteam unsichtbar. Wer die Tonalität einer Antwort ändern oder eine neue Regel ergänzen möchte, muss dann jemanden bitten, den Workflow anzufassen. Legen Sie Prompts und Mustertexte stattdessen als Textvorlagen in ameax ab und lassen Sie den Workflow sie über /api/v2/text-modules lesen. Die Fachabteilung pflegt den Text dort, wo sie ohnehin arbeitet, und der Workflow bleibt unverändert. Beim Ändern per API beachten: Textvorlagen werden mit PUT vollständig ersetzt, ein PATCH gibt es dafür nicht.

Beispiel: Eine Textvorlagen-Kategorie „KI-Prompts" enthält die Vorlagen „Leadbewertung", „Ticketeinordnung" und „Gesprächszusammenfassung". Der Workflow lädt die passende Vorlage per ID und übergibt ihren Text als Anweisung an das Sprachmodell.

10. IDs zentral im Workflow hinterlegen

Aktivitätsarten, Ergebnisse und Verkaufsphasen lassen sich über die API nicht auflisten. Sie sehen die IDs einmalig in den Einstellungen von ameax nach. Auch Status von Verkaufschancen sind IDs: in der Standardeinrichtung 14 für aktiv, 15 für gewonnen, 16 für verloren. Hinterlegen Sie alle diese Werte an genau einer Stelle im Workflow, zum Beispiel in einem Knoten „Konfiguration" am Anfang, statt sie in jedem API-Aufruf einzeln zu tippen. Setzen Sie beim Anlegen einer Verkaufschance den Status immer ausdrücklich.

Beispiel: Ein Konfigurationsknoten enthält activity_ki = 12, finding_rueckruf = 4, salestatus_aktiv = 14 (Beispielwerte). Wird in ameax eine Aktivitätsart ersetzt, ändern Sie eine Zeile, nicht zwanzig Knoten.

Welche Abläufe sich eignen und welche nicht

Gut geeignet sind Abläufe, bei denen viel Text anfällt, die Entscheidung aber an klaren Kriterien hängt, und bei denen ein Fehler sichtbar und korrigierbar bleibt. Weniger geeignet sind Abläufe, bei denen eine einzige falsche Entscheidung schwer rückgängig zu machen ist oder bei denen die Kriterien nirgendwo aufgeschrieben sind. Die Szenarien sind nach drei Bereichen geordnet; jedes hat eine eigene Seite mit Ablauf, Vorbereitung, Auslöser, API-Aufrufen und Stolperstellen.

Vertrieb

Im Vertrieb fällt die meiste Textarbeit zwischen den Gesprächen an. Beim Leadeingang liest ein Workflow Anfragen aus Formularen oder E-Mails, sucht den Kunden, legt ihn bei Bedarf an und bewertet die Anfrage. Beim Lead Nurturing bereitet die KI Folgekontakte vor, abhängig vom Kampagnenstatus. Bei KI-Telefonkampagnen liefert ameax die Liste per API an einen externen Voice-Agent-Dienst und nimmt die Ergebnisse als Aktivitäten und Kampagnenstatus auf. Die Gesprächsnachbereitung macht aus Notizen oder Transkripten eine Aktivität und eine Wiedervorlage. Die Pipeline-Pflege prüft Verkaufschancen auf veraltete Phasen und fehlende nächste Schritte. Und Angebote per KI entstehen aus Belegvorlagen, die ein Mensch vor dem Versand freigibt.

Support und Kundenbetreuung

Im Support geht es um Einordnung und Vorbereitung. Beim Ticket-Eingang ordnet ein Workflow eingehende Anliegen einem Kunden und einem Vorgangs-Schema zu und bereitet einen Antwortentwurf vor, den ein Mitarbeiter prüft. Beim Account-Briefing fasst die KI vor einem Termin zusammen, was über den Kunden bekannt ist: letzte Aktivitäten, offene Tickets, Verkaufschancen, Belege. Gerade hier zeigt sich der Vorteil einer Gesamtlösung, denn alle diese Daten liegen im selben System.

Daten, Einrichtung und Technik

Die dritte Gruppe betrifft das Fundament. Datenqualität und Anreicherung beschreibt Workflows, die fehlende Felder ergänzen und Auffälligkeiten zur Prüfung vorlegen. ameax per KI einrichten nutzt die Blueprints, um Kampagnen, Vorgangs-Schemas und Zusatzfelder aus einer Beschreibung vorzubereiten. Und n8n mit ameax verbinden ist die technische Anleitung, auf der alle anderen Szenarien aufbauen.

Was bewusst beim Menschen bleibt

Einige Entscheidungen sollten Sie auch dann nicht automatisieren, wenn es technisch möglich wäre:

• Verbindliche Zusagen an Kunden. Ein Angebot, eine Preisaussage oder eine Lösungszusage im Ticket verlässt das Haus erst nach Freigabe. Die KI entwirft, ein Mensch versendet.
• Zusammenführen und Löschen von Datensätzen. Die Dublettenbereinigung in ameax verschiebt verknüpfte Daten auf den Zieldatensatz; welcher Datensatz das Ziel ist, entscheidet ein Mensch.
• Abschließende Status. Eine Verkaufschance als verloren oder einen Kunden in einer Kampagne als „kein Bedarf" zu markieren, beeinflusst Auswertungen und künftige Ansprache. Die KI kann das vorschlagen, bestätigen sollte der Betreuer.
• Zuständigkeiten. Einen Kunden einer anderen Betreuergruppe zuzuordnen, ist eine organisatorische Entscheidung und kein Textverständnis.
• Grenzfälle bei der Einwilligung. Wenn unklar ist, ob eine Ansprache zulässig ist, kontaktiert der Workflow nicht.

Scoring ist ein gutes Beispiel für die Grenze: ameax selbst berechnet kein KI-Lead-Scoring und keine vorhersagende Abschlusswahrscheinlichkeit. Die Wahrscheinlichkeit einer Verkaufschance ergibt sich aus der Phase, den Bewertungsfeldern oder einer manuellen Angabe. Wenn Sie ein Scoring im Workflow berechnen, schreiben Sie das Ergebnis in ein Zusatzfeld und dokumentieren Sie die Begründung als Aktivität. So bleibt erkennbar, was Rechnung und was Einschätzung ist.

Datenschutz und Betrieb

Automatisierung mit Sprachmodellen verschiebt die Frage, wo Daten verarbeitet werden, an eine neue Stelle. Deshalb lohnt es sich, drei Ebenen auseinanderzuhalten: den Betrieb von ameax, die KI-Funktionen im Produkt und die Sprachmodelle in Ihren eigenen Workflows. Die folgenden Angaben beschreiben den Aufbau und ersetzen keine datenschutzrechtliche Beratung.

ameax: Hosting in Deutschland

ameax wird in Deutschland gehostet. Die Rechenzentren, in denen ameax betrieben wird, sind nach ISO 27001:2022 zertifiziert und nach dem BSI-Kriterienkatalog C5 (Typ 2) testiert. Die Zertifizierung bezieht sich auf die Rechenzentren. Kunden-, Kontakt- und Belegdaten liegen damit an einem Ort, und Ihre Workflows greifen über HTTPS mit Token darauf zu.

KI im Produkt: EU-Dienste oder eigenes Modell

Die KI-Funktionen, die ameax selbst mitbringt, etwa die Sprachnotiz als Aktivität, der Visitenkarten-Scan oder der Textassistent, beschreibt die Seite zum KI-Assistenzsystem. Dort wählen Sie den KI-Dienst, und alle Dienste, die angeboten werden, verarbeiten in Deutschland oder innerhalb der EU. Alternativ lässt sich ein eigener Schlüssel oder ein eigenes Modell anbinden, bis hin zu einem Modell im eigenen Rechenzentrum. Die KI-Funktionen des Produkts sind nicht über die API v2 aufrufbar; in einem n8n-Workflow arbeitet deshalb das Sprachmodell, das Sie dort selbst anbinden.

Sprachmodelle in Ihren Workflows

Für die Sprachmodelle, die Sie in n8n einsetzen, entscheiden Sie als Betreiber des Workflows, welchen Dienst Sie verwenden und wo er verarbeitet. ameax gibt die Daten über die API an Ihren Workflow; was dieser damit tut, liegt in Ihrer Verantwortung. Prüfen Sie für jeden Dienst, wo die Daten verarbeitet werden und welche vertraglichen Zusagen gelten. Wo die Anforderungen hoch sind, kommt auch ein selbst betriebenes Modell in Frage.

Datensparsamkeit im Prompt

Eine einfache Empfehlung mit großer Wirkung: Übergeben Sie dem Sprachmodell nur die Felder, die es für die Aufgabe braucht. Ein Workflow, der ein Ticket einordnet, braucht den Ticket-Text und vielleicht den Kundentyp, aber weder Rechnungsdaten noch die vollständige Kontakthistorie. Mit fields[typ] lassen Sie sich von der API ohnehin nur die benötigten Felder liefern; im Workflow wählen Sie dann aus, was davon in den Prompt geht. Diese Auswahl trifft Ihr Workflow, nicht ameax. Eine automatische Anonymisierung vor dem Prompt findet nicht statt.

Betrieb: Token pflegen und Workflows beobachten

Im laufenden Betrieb zählen wenige Routinen. Token mit Ablaufdatum müssen rechtzeitig erneuert werden; ein abgelaufenes Token zeigt sich als Authentifizierungsfehler (401). Technische Benutzer sollten in Ihrer Benutzerverwaltung erkennbar benannt sein, damit niemand sie für verwaiste Konten hält. Und die Aktivitäten, die Ihre Workflows schreiben, sind zugleich Ihr Betriebsprotokoll: Wenn an einem Tag keine einzige Aktivität der Art „KI-Auswertung" entsteht, obwohl Anfragen eingegangen sind, stimmt etwas nicht.

Drei Ansätze im Vergleich

Unternehmen, die mit KI-Automatisierung beginnen, landen meist bei einem von drei Ansätzen. Die Tabelle stellt sie nach den Kriterien gegenüber, die im Betrieb über Erfolg oder Frust entscheiden.

Der erste Ansatz ist der schnellste Start und der teuerste Betrieb. Der zweite funktioniert, solange die Aufgaben getrennt bleiben, und wird schwierig, sobald ein Ablauf zwei Bereiche berührt, etwa ein Ticket, das eine Verkaufschance auslöst. Der dritte verlangt am Anfang etwas mehr Überlegung, nämlich welche Information wohin gehört. Dafür wird jeder weitere Workflow einfacher, weil er auf einen vorhandenen Ort schreibt.

Fazit

Ein Sprachmodell in einem Workflow ist schnell eingerichtet. Ob daraus eine dauerhafte Entlastung wird, entscheidet sich an anderer Stelle: daran, ob die Ergebnisse dort landen, wo Ihr Team arbeitet, ob sich jede automatische Entscheidung nachvollziehen lässt und ob ein Mensch dort eingreift, wo es darauf ankommt.

Mit ameax als führendem System ist diese Stelle klar. Kunden, Kontakte, Aktivitäten, Verkaufschancen, Tickets und Belege liegen in einer Gesamtlösung. n8n gibt den Takt vor, das Sprachmodell bearbeitet Texte, und die API v2, der Webhook-Posteingang und die Prozess-Buttons verbinden beides mit ameax. Die zehn Grundsätze auf dieser Seite sorgen dafür, dass Workflows begrenzt, wiederholbar und prüfbar bleiben.

Der sinnvollste Einstieg ist ein einzelner Ablauf mit viel Textarbeit und klaren Kriterien, etwa die Gesprächsnachbereitung oder der Leadeingang.