Datenqualität und Anreicherung mit KI automatisieren

Im Kundenstamm steht „frankfurt a.M.“ neben „Frankfurt am Main“, die Website fehlt bei jedem dritten Kunden, eine Firma gibt es zweimal, weil der Messekontakt unter der privaten E-Mail-Adresse angelegt wurde. Niemand hat das absichtlich so gemacht. Es ist das Ergebnis von Jahren, in denen Menschen unter Zeitdruck Daten erfasst haben, von Importen aus alten Tabellen und von Formularen, die jeder anders ausfüllt. Spätestens wenn ein Serienbrief an „Sehr geehrte Damen und Herren GMBH“ geht oder der Abgleich mit dem Shop an unterschiedlichen Schreibweisen scheitert, wird aus Schönheitsfehlern ein Kostenfaktor.

Die übliche Antwort ist eine Aufräumaktion: Jemand exportiert die Kundenliste, korrigiert zwei Wochen lang in einer Tabelle und spielt sie wieder ein. Ein halbes Jahr später sieht der Bestand wieder aus wie vorher. Datenqualität ist kein Projekt, sondern ein Dauerlauf. Und genau dafür eignet sich die Kombination aus einem führenden System, einem Taktgeber und einem Sprachmodell: Der Lauf findet jede Nacht statt, prüft einen überschaubaren Teil des Bestands, korrigiert, was eindeutig ist, und legt dem Team nur die Fälle vor, bei denen ein Mensch entscheiden muss.

Der Ablauf im Überblick

Die Aufgabenteilung ist dieselbe wie in allen Automatisierungs-Szenarien: ameax hält die Daten und das Gedächtnis, n8n gibt den Takt vor, das Sprachmodell bearbeitet Text, und ein Mensch entscheidet dort, wo eine Korrektur Folgen haben kann.

1. Takt setzen. Ein Schedule Trigger in n8n startet den Lauf, zum Beispiel jede Nacht um zwei Uhr.
2. Kunden abrufen. n8n liest über GET /api/v2/customers seitenweise Kunden aus ameax, sortiert nach dem Änderungsdatum, und bringt Kundenkennungen und Kategorien gleich mit.
3. Regeln prüfen. Ein Code-Knoten prüft jeden Datensatz gegen feste Regeln: Fehlt die E-Mail-Adresse, die Postleitzahl, das Land? Hat die Website kein Protokoll? Ist die PLZ für Deutschland fünfstellig?
4. Sprachmodell normalisieren lassen. Datensätze mit Auffälligkeiten gehen an ein Sprachmodell Ihrer Wahl. Es schlägt Korrekturen für Schreibweisen, Adressen und die Branchenzuordnung vor und bewertet selbst, wie sicher es ist.
5. Eindeutiges direkt schreiben. Nur Vorschläge, die als eindeutig gelten und die eine zweite, feste Prüfung in n8n bestehen, schreibt der Workflow per PATCH /api/v2/customers/{id} zurück und hält die Änderung als Aktivität fest.
6. Unklares vorlegen. Alle anderen Vorschläge landen als Notiz am Kunden, der Kunde bekommt eine Prüf-Kategorie, und der Datenpfleger erhält eine Wiedervorlage.
7. Dubletten und Abgleich. Externe IDs aus Shop, ERP oder Buchhaltung hinterlegt der Workflow als Kundenkennungen. Dublettenverdacht markiert er, zusammengeführt wird im Produkt.

Der Lauf ist bewusst klein geschnitten. Er muss nicht in einer Nacht den gesamten Bestand prüfen. Hundert oder zweihundert Kunden pro Lauf reichen, wenn er jeden Tag stattfindet, und halten die Kosten für das Sprachmodell kalkulierbar.

Was ameax ohne Workflow schon abdeckt

Bevor Sie einen Workflow bauen, lohnt der Blick darauf, was ameax selbst an Datenpflege leistet. Der Workflow ergänzt diese Funktionen, er ersetzt sie nicht. Einige davon sind über die API gar nicht erreichbar, weil sie bewusst in der Oberfläche liegen, wo ein Mensch das Ergebnis sieht und bestätigt.

Dublettenerkennung und Zusammenführung

Die Dublettenerkennung in ameax sucht doppelte Kunden über konkrete Merkmale: Telefon, E-Mail (auch in Zusatzfeldern und bei Ansprechpartnern), Website, Name, Adresse, externe Kundennummer und eine Inhalts-Prüfsumme. Datensätze, die bewusst getrennt bleiben sollen, kommen auf eine Liste „kein Dublett“ und tauchen nicht wieder auf. Beim Zusammenführen wählt ein Mensch den Zieldatensatz, und jedes Modul zieht seine Daten mit: Belege, Objekte, Zeiten, Ansprechpartner, Aktivitäten. Nichts geht verloren, und nur berechtigte Datensätze werden zusammengeführt.

Diese Zusammenführung ist genau der Schritt, den man keinem Workflow überlassen sollte. Ein Workflow kann Verdachtsfälle sammeln und sichtbar machen. Welcher Datensatz der richtige ist, entscheidet das Team.

Impressum-Crawler und Visitenkarten-Scan

Mit dem KI-Assistenzsystem bringt ameax zwei Anreicherungen mit, die direkt am Kunden sitzen. Der Impressum-Crawler ruft die Website des Kunden ab, lässt sie auswerten und zeigt einen Vergleich gegen die vorhandenen Stammdaten. Übernommen wird erst, was ein Mitarbeiter bestätigt. Jeder Abruf kostet einen festen Betrag aus dem KI-Guthaben. Der Visitenkarten-Scan in der Kunden-Neuanlage und im Ansprechpartner-Formular macht aus ein bis zwei Fotos strukturierte Firmen- und Personendaten. Dazu kommt die Datenermittlung aus Freitext: Ein eingefügtes Impressum oder eine E-Mail-Signatur wird zu Firma und Ansprechpartner.

Diese Funktionen laufen in der Oberfläche. Über die API v2 ist keine KI-Funktion von ameax erreichbar. Ein Workflow, der nachts arbeitet, nutzt deshalb ein eigenes Sprachmodell und schreibt das Ergebnis über die API zurück.

Webhook-Posteingang: ergänzen statt überschreiben

Wer Kontaktdaten aus Formularen oder Mails über den Webhook-Posteingang POST /p/webhook/{source} einliefert, bekommt eine eingebaute Vorsichtsregel: Bei erkannten Bestandskunden werden Name und Adresse aktualisiert, Telefon, E-Mail und Website aber nur ergänzt, wenn das Feld leer ist. Automatisch übernommen wird nur bei eindeutiger Zuordnung. Alles andere wartet mit dem Status „suggested“ auf einen Menschen. Diese Regel ist ein gutes Vorbild für den eigenen Workflow. Wie der Posteingang beim Leadeingang arbeitet, beschreibt das Szenario Leadeingang und Qualifizierung.

Sammelbearbeitung

Für Korrekturen an vielen Kunden auf einmal gibt es die Sammelbearbeitung: Kategorie setzen oder entfernen, Zusatzfelder und Standard-Kundenfelder ändern, Betreuer neu setzen, auch per PLZ-Gebiet. Das ist oft der schnellere Weg für eine einmalige Bereinigung. Der Workflow übernimmt den Dauerlauf danach.

Vorbereitung in ameax

Die Vorbereitung entscheidet hier mehr als der Workflow. Die REST-API filtert nur auf Gleichheit — eine Abfrage wie „alle Kunden ohne E-Mail" gibt es nicht — und Aktivitätsarten kann sie gar nicht auflisten. Was der Workflow später findet und wohin er schreibt, legen Sie deshalb vorher in ameax an: vier Dinge, und jedes endet als eine ID, die Sie in n8n hinterlegen. Danach fragt der Workflow nichts mehr nach, sondern arbeitet mit diesen festen Werten.

Technischer Benutzer und Token

Legen Sie einen eigenen Benutzer für den Workflow an und erzeugen Sie für ihn unter /c/apitoken ein Token. Ein Token hat keine eigenen Rechte-Scopes, es erbt die Rechte seines Benutzers. Der technische Benutzer braucht also genau die Rechte, die der Lauf benötigt: Kunden lesen und bearbeiten, Notizen, Aktivitäten und Wiedervorlagen anlegen, Kategorien zuordnen, Kundenkennungen pflegen. Für das Token lassen sich ein Ablaufdatum und eine IP-Liste festlegen. Wie die Verbindung in n8n eingerichtet wird, beschreibt n8n an ameax anbinden.

Kategorien als Arbeitslisten

Die API filtert nur auf Gleichheit und mit * als Platzhalter. Eine Abfrage wie „alle Kunden ohne E-Mail“ gibt es nicht. Kategorien lassen sich aber über filter[cat_id] abfragen, und in der Kundenliste der Oberfläche sind sie ohnehin ein Filter. Deshalb eignen sie sich als Arbeitsliste. Legen Sie zwei Kategorien an, etwa „Stammdaten prüfen“ und „Dublettenverdacht“, und notieren Sie deren IDs. Der Workflow setzt sie, das Team arbeitet sie ab.

Ein Zusatzfeld für das Prüfdatum

Ein Zusatzfeld vom Typ Datum am Kunden, etwa „Letzte Datenprüfung“, hält fest, wann der Workflow einen Datensatz zuletzt angesehen hat. Beim nächsten Lauf überspringt er Kunden, die kürzlich geprüft und seitdem nicht geändert wurden. Das Feld erscheint in der OpenAPI-Spezifikation Ihrer Installation mit Bezeichnung und Feldnamen, sodass der Workflow es wie ein Standardfeld schreiben kann.

Aktivitätsart und Zuständigkeit

Für die Protokollierung automatischer Korrekturen empfiehlt sich eine eigene Aktivitätsart, etwa „Datenpflege automatisch“. Eine API zum Auflisten der Aktivitätsarten gibt es nicht. Sie sehen die ID einmal in den Einstellungen nach und hinterlegen sie im Workflow. Dasselbe gilt für die Benutzer-ID des Datenpflegers, der die Wiedervorlagen bekommt, und für die Branchen-IDs, falls das Sprachmodell eine Branche vorschlagen soll.

Auslöser

Der Workflow startet zeitgesteuert. In n8n übernimmt das ein Schedule Trigger, der zum Beispiel jede Nacht einmal läuft. ameax meldet Änderungen nicht von sich aus. Der Workflow fragt deshalb selbst nach, welche Kunden sich geändert haben: Er ruft die Kundenliste mit sort=-updated_at ab, also die zuletzt geänderten zuerst, und blättert Seite für Seite, bis er auf Einträge stößt, die älter sind als der letzte Lauf. Den Zeitpunkt des letzten Laufs speichert n8n selbst, etwa in den statischen Daten des Workflows.

Ein zweiter, langsamerer Takt deckt den Altbestand ab. Ein wöchentlicher Lauf blättert mit sort=id durch den gesamten Bestand und merkt sich, bis zu welcher Seite er gekommen ist. So wird über einige Wochen jeder Kunde einmal geprüft, auch wenn ihn seit Jahren niemand angefasst hat.

Ein dritter Auslöser kommt von außen: Wenn Ihr Shop, Ihr ERP oder Ihre Buchhaltung eine neue Kundennummer vergibt und das über einen Webhook an n8n melden kann, startet derselbe Workflow den Abgleich für genau diesen Kunden.

Umsetzung Schritt für Schritt

Die folgenden Aufrufe zeigen den Kern des Workflows. Alle IDs sind Beispielwerte, die Installation heißt hier https://ihrefirma.ameax.de. Jede Anfrage trägt das Token im Kopf Authorization: Bearer …, Anfragen mit Inhalt zusätzlich Content-Type: application/json.

Schritt 1: Geänderte Kunden abrufen

Der HTTP-Request-Knoten ruft die Kundenliste ab, 100 Einträge pro Seite, das ist das Maximum. Mit include kommen Kundenkennungen und Kategorien gleich mit, damit der Workflow nicht für jeden Kunden nachfragen muss.

GET https://ihrefirma.ameax.de/api/v2/customers?sort=-updated_at&per_page=100&page=1&include=identifiers,categories
Authorization: Bearer <token>

Die Antwort enthält die Liste unter data und dazu total, page und per_page. Der Workflow erhöht page, solange der letzte Eintrag der Seite jünger ist als der letzte Lauf. Jeder Kunde bringt seine Standardfelder mit, darunter name, street, postal_code, city, country_code, phone, email, website, branch_id, external_id, updated_at und last_activity_at, außerdem Ihre Zusatzfelder.

Schritt 2: Feste Regeln vor dem Sprachmodell

Nicht jede Prüfung braucht ein Sprachmodell. Was sich mit einer Regel entscheiden lässt, entscheidet ein Code-Knoten, schneller, billiger und nachvollziehbar. Er sammelt pro Kunde eine Liste von Befunden:

// n8n Code-Knoten: einfache Befunde je Kunde (vereinfacht)
const c = $json;
const befunde = [];
if (!c.email) befunde.push('email_fehlt');
if (!c.postal_code || !c.city) befunde.push('adresse_unvollstaendig');
if (c.country_code === 'DE' && c.postal_code && !/^\d{5}$/.test(c.postal_code)) befunde.push('plz_format');
if (c.website && !/^https?:\/\//.test(c.website)) befunde.push('website_ohne_protokoll');
if (c.name && c.name === c.name.toUpperCase() && c.name.length > 4) befunde.push('name_grossbuchstaben');
if (!c.branch_id) befunde.push('branche_fehlt');
return { json: { ...c, befunde } };

Kunden ohne Befund bekommen nur das neue Prüfdatum. Kunden mit Befunden gehen weiter an das Sprachmodell, aber nur mit den Feldern, die es für die Prüfung braucht. Belegdaten, Notizen und Aktivitäten gehören nicht in diesen Prompt.

Schritt 3: Das Sprachmodell normalisiert

Das Sprachmodell bekommt eine klar umrissene Aufgabe: Schreibweisen vereinheitlichen, offensichtliche Tippfehler in Ort und Straße erkennen, eine Branche aus einer vorgegebenen Liste vorschlagen und passende Kategorien aus dem vorhandenen Kategoriebaum nennen. Den Baum holt der Workflow einmal pro Lauf mit GET /api/v2/categories/tree. Entscheidend ist das Ausgabeformat: Jeder Vorschlag trägt eine Einstufung, und das Modell darf nichts erfinden.

ROLLE
Du prüfst Kundenstammdaten eines deutschen B2B-Unternehmens. Du korrigierst nur
Schreibweise und Format. Du ergänzt keine Daten, die nicht in der Eingabe stehen.

EINGABE
- kunde: JSON mit id, name, street, postal_code, city, country_code, phone, email, website, branch_id
- befunde: Liste der Regelbefunde aus dem Vorlauf
- branchen: Liste {id, bezeichnung} der zulässigen Branchen
- kategorien: Liste {id, bezeichnung} der zulässigen Kategorien

REGELN
1. Ändere nur diese Felder: name, street, postal_code, city, website.
2. Erfinde niemals Telefonnummern, E-Mail-Adressen oder Websites.
3. "eindeutig" nur, wenn die Änderung reine Schreibweise ist
   (Groß-/Kleinschreibung, Abkürzung ausgeschrieben, Leerzeichen, Protokoll ergänzt).
4. Alles, was den Inhalt verändert (anderer Ort, andere PLZ), ist "pruefen".
5. Branche und Kategorien nur aus den übergebenen Listen, sonst null.

AUSGABE (nur JSON, kein Text davor oder danach)
{
  "customer_id": 4711,
  "aenderungen": [
    {"feld": "city", "alt": "frankfurt a.M.", "neu": "Frankfurt am Main",
     "einstufung": "eindeutig", "begruendung": "Abkürzung ausgeschrieben"}
  ],
  "branche_id": 12,
  "branche_einstufung": "pruefen",
  "kategorien": [5],
  "hinweis": "Website fehlt, Impressum-Abgleich im Produkt empfohlen"
}

Die Liste der zulässigen Felder steht im Prompt und wird in n8n noch einmal geprüft. Das ist kein Misstrauen gegen das Modell, sondern gewöhnliche Sorgfalt: Ein Modell, das in einem von tausend Fällen ein Feld nennt, das es nicht ändern soll, richtet sonst über Wochen unbemerkt Schaden an.

Schritt 4: Eindeutige Korrekturen zurückschreiben

Ein IF-Knoten lässt nur Änderungen durch, die als „eindeutig“ eingestuft sind, ein erlaubtes Feld betreffen und eine zusätzliche feste Probe bestehen. Eine einfache Probe für reine Schreibweise: Alter und neuer Wert stimmen nach Kleinschreibung und Entfernen von Leerzeichen und Punkten weitgehend überein, oder die Änderung ergänzt nur https://. Was diese Probe nicht besteht, wird trotz der Einstufung des Modells zur Prüfung vorgelegt. Die Korrektur selbst ist ein PATCH, der nur die geänderten Felder enthält:

PATCH https://ihrefirma.ameax.de/api/v2/customers/4711
Authorization: Bearer <token>
Content-Type: application/json

{
  "city": "Frankfurt am Main",
  "website": "https://www.beispiel-gmbh.de"
}

Damit später nachvollziehbar ist, wer was geändert hat, legt der Workflow im selben Zug eine Aktivität am Kunden an. activity_id ist die ID Ihrer Aktivitätsart „Datenpflege automatisch“, hier ein Beispielwert:

POST https://ihrefirma.ameax.de/api/v2/actions
Authorization: Bearer <token>
Content-Type: application/json

{
  "customer_id": 4711,
  "subject": "Stammdaten automatisch normalisiert",
  "date": "2026-09-28 02:14:00",
  "activity_id": 23,
  "notice": "Ort: \"frankfurt a.M.\" → \"Frankfurt am Main\"\nWebsite: Protokoll ergänzt"
}

Zuletzt setzt der Workflow das Zusatzfeld „Letzte Datenprüfung“ per PATCH auf das heutige Datum, unter dem Feldnamen, den die OpenAPI-Spezifikation Ihrer Installation dafür nennt.

Schritt 5: Unklare Fälle zur Prüfung vorlegen

Alles, was nicht eindeutig ist, geht an einen Menschen, und zwar so, dass er es am Kunden vorfindet. Eine Wiedervorlage in ameax hat kein Textfeld. Der Vorschlag kommt deshalb als Notiz an den Kunden, die Wiedervorlage erinnert den Datenpfleger daran:

POST https://ihrefirma.ameax.de/api/v2/notices
Content-Type: application/json

{
  "customer_id": 4711,
  "subject": "Datenprüfung: 2 Korrekturvorschläge",
  "notice": "PLZ: 60313 → 60311 (Straße liegt laut Eingabe im Bereich 60311, bitte prüfen)\nBranche: Maschinenbau (Vorschlag, bisher leer)"
}

POST https://ihrefirma.ameax.de/api/v2/reminds
Content-Type: application/json

{
  "customer_id": 4711,
  "date": "2026-09-29 09:00:00",
  "subject": "Korrekturvorschläge Stammdaten prüfen",
  "user_id": 12,
  "priority": 0
}

Zusätzlich ordnet der Workflow die Kategorie „Stammdaten prüfen“ zu. In der Kundenliste der Oberfläche entsteht damit eine Arbeitsliste, die sich als gespeicherte Suche mit eigenem Schnellfilter-Button ablegen lässt:

POST https://ihrefirma.ameax.de/api/v2/customer-categories
Content-Type: application/json

{"customer_id": 4711, "cat_id": 31}

Hat der Datenpfleger den Fall erledigt, entfernt er die Kategorie in der Oberfläche. Alternativ erledigt das der nächste Lauf mit DELETE /api/v2/customer-categories/4711/31, sobald die Regeln keinen Befund mehr finden. Wer lieber mit Vorgängen arbeitet, legt statt Notiz und Wiedervorlage einen Vorgang in einer eigenen Vorgangsart „Datenpflege“ an. POST /api/v2/tasks nimmt mit description auch längere Texte auf. Wie Sie eine solche Vorgangsart per Schnittstelle einrichten, zeigt das Szenario ameax per KI einrichten.

Schritt 6: Kategorien und Branche setzen

Kategorievorschläge aus einem festen Baum sind für ein Sprachmodell eine gut lösbare Aufgabe, weil es nur auswählen und nichts erfinden muss. Bei eindeutigen Fällen setzt der Workflow die Kategorie mit POST /api/v2/customer-categories. Vorher prüft der Workflow anhand der mitgeladenen categories, ob die Kategorie schon gesetzt ist. Die Branche steht als branch_id direkt am Kunden und wird wie jedes andere Feld per PATCH geschrieben. Neue Kategorien oder Branchen legt der Workflow nicht selbst an, das bleibt eine Entscheidung der Verwaltung.

Was Sie beim Bauen wissen müssen

Datenqualität endet nicht an der Grenze von ameax. Sobald Shop, ERP oder Buchhaltung eigene Kundennummern führen, entscheidet eine saubere Zuordnung darüber, ob ein Abgleich funktioniert oder jedes Mal neue Dubletten erzeugt. Dazu kommen Eigenheiten des Produkts: Was ameax über die Oberfläche automatisch tut, tut es über die Schnittstelle nicht immer. Übersieht man das, stockt der Workflow und die Datenqualität wird schlechter.

Kundenkennungen statt Namensvergleich

Am Kunden steht ein Feld external_id für genau eine fremde Nummer. Wer mehrere Systeme anbindet, nutzt zusätzlich die Kundenkennungen unter /customer-identifiers: je Kunde beliebig viele Einträge mit einem frei wählbaren type wie shop, erp oder fibu und dem jeweiligen identifier. Einmal hinterlegt, findet der Workflow den Kunden künftig über die Kennung und nicht mehr über den Namen:

GET https://ihrefirma.ameax.de/api/v2/customer-identifiers?filter[type]=shop&filter[identifier]=88123

POST https://ihrefirma.ameax.de/api/v2/customer-identifiers
Content-Type: application/json

{"customer_id": 4711, "type": "erp", "identifier": "D-10234", "active": true}

Beim ersten Abgleich, wenn noch keine Kennungen existieren, muss der Workflow die Zuordnung einmal herstellen. Hier hilft das Sprachmodell: Es vergleicht einen Kunden aus dem Shop mit einer Handvoll Kandidaten aus ameax und begründet, ob es derselbe ist. Eindeutige Treffer, etwa gleiche E-Mail-Domain und gleiche Anschrift, bekommen die Kennung direkt. Alles andere wird wie oben zur Prüfung vorgelegt.

Vor jeder Anlage suchen

Wichtig für jeden Workflow, der Kunden anlegt: POST /api/v2/customers führt keine Dublettenprüfung durch und ordnet keinen Betreuer und kein Gebiet zu. Das tun nur die Oberfläche, der Import und der Webhook-Posteingang. Ein Workflow muss deshalb vor jeder Anlage selbst suchen, in dieser Reihenfolge:

1. über die Kennung des Quellsystems: /customer-identifiers?filter[type]=shop&filter[identifier]=…
2. über filter[external_id]=… am Kunden
3. über die E-Mail-Adresse: filter[email]=info@beispiel-gmbh.de
4. über die Domain mit Platzhalter: filter[email]=*@beispiel-gmbh.de
5. über Name und PLZ, mit Platzhalter am Namensende: filter[name]=Beispiel*&filter[postal_code]=60311

Mehrere Filter werden mit UND verknüpft. Eine Suche nach Telefonnummer bietet die API nicht. Findet keine der Stufen einen Treffer, legt der Workflow den Kunden an, setzt agent_id selbst, ermittelt aus den PLZ-Gebieten unter /agent-territories, und hinterlegt sofort die Kennung. Findet er mehrere Treffer, legt er nichts an, sondern meldet den Fall.

Dublettenverdacht markieren, im Produkt zusammenführen

Trotz aller Vorsicht entstehen Dubletten, etwa durch Handanlagen am Messestand. Der Workflow kann Verdachtsfälle finden, etwa zwei Kunden mit derselben E-Mail-Domain und derselben PLZ, und beide mit der Kategorie „Dublettenverdacht“ markieren. Eine Notiz nennt jeweils die ID des anderen Datensatzes. Die eigentliche Zusammenführung findet in der Dublettenansicht von ameax statt. Dort wählt ein Mensch den Zieldatensatz, und Belege, Objekte, Zeiten, Ansprechpartner und Aktivitäten wandern vollständig mit. Bewusst getrennte Datensätze landen auf der Liste „kein Dublett“.

Nach der Zusammenführung sollten auch die Kundenkennungen des aufgelösten Datensatzes stimmen. Der nächste Abgleichslauf prüft, ob jede Kennung auf einen existierenden Kunden zeigt, und meldet Abweichungen.

Betreuer nach einer PLZ-Korrektur

Ein Detail, das leicht übersehen wird: Die automatische Zuordnung zu einer Betreuergruppe nach PLZ-Gebiet greift bei Anlage, Import, Webformular und Sammelbearbeitung, aber nicht rückwirkend, wenn sich später die PLZ ändert. Korrigiert der Workflow eine Postleitzahl, bleibt der bisherige Betreuer stehen. Entweder ermittelt der Workflow die passende Gruppe selbst aus /agent-territories und legt die Änderung zur Prüfung vor, oder das Team verteilt die betroffenen Kunden über die Sammelbearbeitung „Betreuer per PLZ“ neu. Mehr dazu im Gebietsmanagement.

Was in ameax sichtbar wird

Das Ergebnis des Workflows liegt dort, wo das Team ohnehin arbeitet, und nicht in einem Protokoll, das niemand liest.

• Am Kunden: Die korrigierten Stammdaten, eine Aktivität „Stammdaten automatisch normalisiert“ mit altem und neuem Wert und bei offenen Fällen eine Notiz mit den Vorschlägen.
• In den Wiedervorlagen des Datenpflegers: die Kunden, bei denen eine Entscheidung ansteht, mit Datum und Priorität.
• In der Kundenliste: die Kategorien „Stammdaten prüfen“ und „Dublettenverdacht“ als Filter, auf Wunsch als gespeicherte Suche mit eigenem Schnellfilter-Button.
• In der Dublettenansicht: die Kandidaten, die ameax selbst anhand von Telefon, E-Mail, Website, Name, Adresse, externer Nummer und Prüfsumme findet, mit der Zusammenführung über alle Module.
• Im Webhook-Posteingang unter /c/webhookmessage: eingelieferte Kontaktdaten, die nicht eindeutig zugeordnet werden konnten und auf eine Prüfung warten.

Über die Kategorie lässt sich außerdem jederzeit zählen, wie viele Fälle offen sind. Sinkt die Zahl über die Wochen, wirkt der Lauf. Steigt sie, liegt das Problem meist nicht im Lauf, sondern bei einer Quelle, die täglich neue Fehler nachliefert.

Best Practices und Stolperstellen

• Zwei Schranken statt einer. Das Sprachmodell stuft ein, n8n prüft noch einmal mit festen Regeln. Erst wenn beide „eindeutig“ sagen, wird geschrieben. Ein einzelnes Modell ist nie die letzte Instanz über Stammdaten.
• Ergänzen, nicht überschreiben. Übernehmen Sie die Regel des Webhook-Posteingangs: Kontaktdaten wie Telefon, E-Mail und Website werden höchstens ergänzt, wenn das Feld leer ist, und auch dann nur aus einer belegbaren Quelle. Ein vorhandener Wert wird nicht durch einen Vorschlag ersetzt.
• Nur die nötigen Felder in den Prompt. Für eine Schreibweisenprüfung braucht das Modell Name und Anschrift, keine Umsätze und keine Gesprächsnotizen. Welche Daten Sie an welchen Dienst übergeben dürfen, ist eine Frage des Datenschutzes, die Sie im Einzelfall prüfen sollten.
• Kleine Läufe, jeden Tag. Hundert Kunden pro Nacht sind überschaubar, die Kosten planbar, Fehler fallen früh auf. Ein Lauf über den gesamten Bestand in einer Nacht erzeugt im Fehlerfall tausend falsche Änderungen auf einmal.
• Jede Änderung als Aktivität. Eine Aktivität mit altem und neuem Wert steht im Aktivitätsstrom des Kunden, wo jeder Kollege sie ohnehin sieht. So ist jede automatische Korrektur nachvollziehbar und im Zweifel schnell zurückgenommen.
• Wiederholbar bauen. Die API kennt keine Idempotenz-Schlüssel. Bricht ein Lauf ab und startet neu, darf er keine zweite Notiz und keine zweite Kennung anlegen. Deshalb vorher nachsehen, ob die Kategorie schon gesetzt oder die Kennung schon vorhanden ist.
• Fehlermeldungen auswerten. Fehler kommen als application/problem+json mit einer Liste errors, die Feld, Code und Meldung nennt, und jede Antwort trägt eine X-Request-Id. Ein Filter auf ein unbekanntes Feld liefert 400 mit der Liste der zulässigen Felder. Protokollieren Sie diese Angaben in n8n, dann lässt sich jeder Fehlschlag später zuordnen.
• Pflichtangaben an der Quelle absichern. Ein Workflow, der fehlende Angaben nachträglich findet, ist gut. Besser ist, wenn sie gar nicht erst fehlen: Zusatzfelder lassen sich in ameax als Pflichtfeld einrichten, und Formulare und Posteingang liefern strukturierte Daten.

Fazit

Saubere Stammdaten entstehen nicht durch eine große Aufräumaktion, sondern durch einen kleinen, täglichen Lauf mit klaren Regeln. ameax liefert dafür die Grundlage: die Daten über die REST-API, Kategorien als Arbeitslisten, Kundenkennungen für den Abgleich, die Dublettenerkennung mit Zusammenführung über alle Module und im Produkt den Impressum-Crawler und den Visitenkarten-Scan. n8n gibt den Takt vor, ein Sprachmodell erledigt die Textarbeit, und alles, was nicht eindeutig ist, landet bei einem Menschen. So wird der Kundenstamm Woche für Woche besser, ohne dass jemand eine Tabelle exportieren muss.