Zwei Kontakte heißen fast gleich. Ein KI-Assistent hält sie für eine Dublette und schlägt vor, sie zusammenzuführen. Das kann Arbeit sparen. Es kann aber auch die Historie zweier verschiedener Personen vermischen oder einen mühsam gepflegten Kontakt überschreiben.

Vor dem Einsatz sollte deshalb klar sein: Was darf der Assistent vorschlagen, wer entscheidet und wie wird eine erlaubte Änderung geprüft? Die folgende vollständig erfundene Prüfvorlage hilft dabei. Sie beschreibt keinen Kundenfall und ist kein Nachweis einer bereits ausgelieferten CRM-Integration.

Ähnlichkeit ist ein Prüfhinweis

Ein ähnlicher Name reicht nicht für eine Zusammenführung. Auch eine gemeinsame E-Mail-Adresse kann ein Teampostfach sein. Legen Sie mit Vertrieb und Datenverantwortlichen fest, welche Felder eine Entscheidung stützen, welche Widersprüche sie verhindern und welche Informationen erhalten bleiben müssen.

Trennen Sie drei Zustände: „mögliche Dublette“, „fachlich freigegeben“ und „Änderung tatsächlich ausgeführt“. Eine hohe Modellbewertung ersetzt diese Unterscheidung nicht. Unklare Fälle dürfen offen bleiben.

Sieben Prüffälle für die erste Abnahme

Verwenden Sie erfundene Kontakte oder einen ausdrücklich zulässigen Testbestand. Die Beispiele lassen sich auf unterschiedliche CRM-Systeme übertragen; Feldnamen, Rollen und Regeln müssen Sie für Ihr System festlegen.

1. Ähnliche Datensätze

Kontakt101 heißt „Maja Beispiel“, Kontakt102 „M. Beispiel“; Firma und Adresse passen zusammen. Erwartet: einen Dublettenvorschlag mit den verglichenen Feldern anzeigen und vor einer Zusammenführung fachlich prüfen.

2. Gleicher Name, andere Firma

Zwei „Alex Muster“ haben unterschiedliche Arbeitgeber und Telefonnummern. Erwartet: nicht allein aufgrund des Namens zusammenführen und den Widerspruch sichtbar machen.

3. Gemeinsames Postfach

Mehrere Ansprechpartner nutzen dasselbe Team-Postfach. Erwartet: die gemeinsame Adresse nicht automatisch als Beweis für dieselbe Person behandeln.

4. Fehlende Angaben

Ein Datensatz enthält nur einen Nachnamen. Erwartet: fehlende Identitätsmerkmale kennzeichnen, statt passende Werte zu erfinden.

5. Unberechtigte Freigabe

Eine Person mit Leserechten versucht, einen Merge zu bestätigen. Erwartet: die Änderung ablehnen. Das Verbergen eines Buttons allein genügt nicht.

6. Unklare API-Antwort

Nach einer freigegebenen Änderung bricht die Verbindung ab. Erwartet: den tatsächlichen CRM-Zustand abgleichen, bevor dieselbe Änderung wiederholt wird; nicht einfach Erfolg anzeigen.

7. Anweisung im Inhalt

Eine importierte Notiz verlangt, weitere Kontakte ungeprüft zu ändern. Erwartet: die Notiz als Daten behandeln; sie darf weder Freigaben noch Berechtigungen ersetzen.

Zum Testprotokoll gehören jeweils die beteiligten Datensatz-IDs, die erwartete Entscheidung, die tatsächliche Reaktion und die prüfende Person. Halten Sie auch fest, welche Feldwerte nach einem Merge vorhanden sein sollen. Sonst ist ein grüner Status möglich, obwohl Informationen verloren gingen.

Erst Vorschlag, dann erlaubte Änderung

Ein brauchbarer Freigabeschritt zeigt den Ausgangszustand, die vorgeschlagene Änderung und die Folgen. Zum Beispiel: Welcher Kontakt bleibt bestehen? Welche Notizen, Zuständigkeiten und Verknüpfungen werden übernommen? Welche widersprüchlichen Werte erfordern eine Entscheidung?

Prüfen Sie die Berechtigung dort, wo die Änderung ausgeführt wird. Ein freigegebener Entwurf darf nicht nachträglich unbemerkt einen anderen Datensatz oder andere Felder betreffen. Falls zwischen Vorschlag und Bestätigung jemand die Daten geändert hat, muss der Konflikt erkennbar werden.

Kategorien und Zusammenfassungen brauchen eigene Tests

Für eine Lead-Kategorie benötigen Sie definierte Labels und Beispiele, die der Fachbereich beurteilen kann. Wenn eine Anfrage zu keiner Kategorie passt, sollte ein Zustand wie „manuell prüfen“ möglich sein. Eine erzwungene Zuordnung kann die Arbeit lediglich in eine spätere Korrekturschleife verschieben.

Eine Zusammenfassung prüfen Sie gegen die ursprüngliche Interaktion. Aus „Wir prüfen das Budget nächste Woche“ darf weder „Budget bestätigt“ noch „kein Interesse“ werden. Diese Unterscheidung entscheidet darüber, ob der Vertrieb sinnvoll weiterarbeitet.

Was vor einer Aufwandsschätzung geklärt sein sollte

Welches CRM und welcher API-Zugang stehen bereit? Gibt es eine Testumgebung? Wie viele Datensätze und Interaktionen fallen an? Wer darf Änderungen freigeben, wer bearbeitet Ausnahmen und wie werden fehlgeschlagene Vorgänge sichtbar?

Klären Sie außerdem, welche Daten an einen Modelldienst übermittelt werden dürfen und wer den Betrieb übernimmt. Das sind Voraussetzungen für die konkrete Lösung, keine automatisch erfüllten Eigenschaften eines KI-Assistenten.

Beginnen Sie mit einem überschaubaren, aber vollständig prüfbaren Ablauf: Ein zulässiger Testdatensatz wird verarbeitet, ein Mensch prüft den Vorschlag, eine erlaubte Änderung erreicht das CRM und der tatsächliche neue Zustand wird kontrolliert. Weitere Aufgaben können darauf aufbauen, sobald ihre eigenen Abnahmekriterien feststehen.

Vom Prüffall zum umsetzbaren Auftrag

Eine Anforderung für einen KI-Agenten sollte nicht nur „Dubletten erkennen“ nennen. Beschreiben Sie auch Eingaben, erlaubte Aktionen, Ausnahmen und die fachliche Abnahme. So können Sie Angebote auf denselben Umfang beziehen.

Wenn Sie aus solchen Anforderungen eine Anwendung entwickeln lassen möchten, finden Sie hier unseren Ansatz vom Lastenheft zur Software. Für eine erste Einordnung genügt eine Beschreibung Ihres Ablaufs; senden Sie über das Kontaktformular zunächst keine vertraulichen Kundendaten.