Jeder Monat, den ein Unternehmen mit der Bereinigung seiner CRM-Daten verbringt, bevor die Implementierung beginnt, ist ein Monat, in dem der Agent nicht läuft. Die Annahme ist falsch: Agenten lesen keine Datenbanken — sie lesen über eine API spezifische Felder aus spezifischen Systemen. Der Follow-up-Agent einer Personalvermittlung liest drei Felder: Kontaktname, Datum der letzten E-Mail und Deal-Phase. Ob die anderen vierzig Spalten ausgefüllt sind, hat keinen Einfluss darauf, ob der Agent korrekt läuft.
Agenten lesen Felder, keine Datenbanken
Ein KI-Agent durchsucht keine Datenbank und verarbeitet nicht alles, was er findet. Ein Agent liest über eine konfigurierte Integration spezifische Felder aus spezifischen Datensätzen — dieselben Felder, bei jedem Lauf.
Ein Kandidaten-Follow-up-Agent bei einer Personalvermittlung liest drei HubSpot-Felder: Kontaktname, Datum der letzten E-Mail und Deal-Phase. Der Agent prüft, ob das Datum der letzten E-Mail älter als sieben Tage ist und ob die Deal-Phase noch „Active" lautet. Wenn beide Bedingungen erfüllt sind, erstellt der Agent eine Follow-up-E-Mail, adressiert an den Kontaktnamen.
Die anderen 40 Felder in diesem Kontaktdatensatz — Unternehmensgröße, Lead-Quelle, letztes Meeting-Ergebnis, LinkedIn-URL, Branche — sind für den Agenten unsichtbar. Nicht verborgen oder gefiltert: Sie sind schlicht nicht Teil des Integrationsbereichs des Agenten. Ob sie vollständig, leer, inkonsistent formatiert oder ganz fehlend sind, hat keinen Einfluss auf die Ausgabe des Agenten.
Warum „erst Daten bereinigen" das Falsche verzögert
Die Bereinigungsannahme setzt voraus, dass ein Agent wie ein Mensch arbeitet, der ein CRM durchsieht: Felder scannt, Lücken bemerkt und auf Basis unvollständiger Informationen Urteile fällt. So funktionieren Agenten nicht.
Ein Agent folgt einem definierten Lesepfad. Die Integration gibt an, welches Objekt abgefragt wird, welche Felder abgerufen werden und welche Bedingungen zu prüfen sind. Ein Kontakt mit leerer LinkedIn-URL und fehlendem Unternehmensgrößenfeld läuft identisch durch den Agenten wie ein Kontakt mit jedem ausgefüllten Feld — solange die drei Felder, die der Agent liest, vorhanden und konsistent sind.
Unternehmen, die drei bis sechs Monate damit verbringen, das CRM zu „bereinigen", bevor sie mit der Implementierung beginnen, verbessern oft die falschen Felder. Der Agent brauchte das Datum der letzten E-Mail als zuverlässig befülltes Feld. Alles andere war bereits irrelevant.
Ein Agent scheitert, wenn er nicht konsistent aus einer einzigen Quelle lesen kann — wenn ein erforderliches Feld leer ist, für den betreffenden Datensatztyp nicht befüllt ist oder ein Format zurückgibt, das die Integration nicht verarbeiten kann. Unordentliche Daten in anderen Feldern verursachen keine Fehler.
Die Vorbereitung, die eine Implementierung tatsächlich beschleunigt, ist die Identifizierung der Felder, die der Workflow benötigt, und die Verifizierung, dass diese Felder für den relevanten Datensatztyp zuverlässig befüllt sind. Dieses Audit dauert eine Stunde, nicht drei Monate.
Die tatsächliche Datenanforderung
Drei Fragen bestimmen, ob die Daten für eine Agenten-Implementierung bereit sind.
Welche Felder prüft die Auslöserbedingung? Für einen Kandidaten-Follow-up-Agenten: Datum der letzten E-Mail und Deal-Phase. Diese Felder müssen für jeden aktiven Kontaktdatensatz vorhanden und konsistent befüllt sein. Wenn das Datum der letzten E-Mail für 30 % der Kontakte leer ist, überspringt der Agent diese Datensätze — oder es muss eine Fallback-Bedingung zum Prompt hinzugefügt werden.
Welche Felder verwendet die Ausgabe? Der Agent adressiert E-Mails an das Kontaktnamensfeld. Wenn dieses Feld für einige Datensätze leer ist, verwendet der Agent einen Fallback — „Guten Tag," oder eine generische Anrede. Dies vor dem Build zu wissen bestimmt, ob der Fallback akzeptabel ist oder ob dieses Feld vor dem Go-live befüllt werden muss.
Wo befinden sich die Daten, und gibt es einen API-Zugang? Wenn das für den Workflow benötigte Feld in einer Tabellenkalkulation statt in einem CRM liegt, ändert sich die Integration. Wenn das System keine API hat, ändert sich der Implementierungsumfang. Beides lässt sich im Scoping-Gespräch klären, bevor Build-Arbeiten beginnen.
Der Agent liest zwei Felder. Die anderen vierzig müssen nicht bereinigt werden.
Welche Felder nach Workflow-Typ tatsächlich relevant sind
Die Felder, die ein Agent benötigt, werden durch den Workflow bestimmt — nicht durch das System. Die folgende Tabelle zeigt, welche Felder für fünf gängige Kleinunternehmen-Workflows relevant sind und welche Felder im selben System für den Agenten irrelevant sind.
| Workflow | System | Felder, die der Agent benötigt | Felder, die der Agent ignoriert |
|---|---|---|---|
| Kandidaten-Follow-up | HubSpot / Pipedrive | Kontaktname, Datum letzte E-Mail, Deal-Phase | Unternehmensgröße, Lead-Quelle, LinkedIn-URL, Branche |
| Rechnungserinnerung | Xero / QuickBooks | Rechnungsbetrag, Kundenname, Fälligkeitsdatum, Zahlungsstatus | Kontohistorie, Branche, Rechnungsadresse |
| Kunden-Status-Update | Notion / Asana | Projektname, Datum letztes Update, Status-Feld | Aufgabenanzahl, Beauftragtenhistorie, Dateianhänge |
| Lead-Qualifizierung | HubSpot | Lead-Score oder Phasen-Feld, Kontakt-E-Mail, Name | Deal-Wertschätzung, Empfehlungsquelle, Anruf-Log |
| Meeting-Follow-up | CRM + Kalender-Integration | Meeting-Datum, Teilnehmer, Deal-Phase | Frühere Notizen, benutzerdefinierte Tags, Legacy-Felder |
Für jeden Workflow ist die Anzahl der relevanten Felder klein. Drei bis fünf zuverlässig befüllte Felder sind die Datenanforderung. Die anderen Dutzenden von Spalten im selben System liegen außerhalb des Integrationsbereichs des Agenten und haben keinen Einfluss darauf, ob der Agent korrekt läuft.
Wie man Datenbereitschaft vor dem Scoping-Gespräch prüft
Das Datenbereitschafts-Audit ist eine einstündige Übung. Es liefert die Antworten, die ein Implementierer vor Baubeginn benötigt — und bestätigt, ob die Implementierung sofort starten kann oder ob ein spezifisches Feld Aufmerksamkeit braucht.
Das Audit hat drei Schritte.
Schritt eins: Workflow-Felder kartieren. Den Workflow-Trigger, die verwendeten Eingabedaten und das Ausgabeformat aufschreiben. Für jede im Workflow verwendete Information identifizieren: welches Feld sie enthält, in welchem System sie liegt und ob dieses Feld für die betreffenden Datensätze zuverlässig befüllt ist.
Schritt zwei: Befüllungsrate prüfen. Das System öffnen und nach dem Datensatztyp filtern, gegen den der Agent laufen wird. Für jedes in Schritt eins identifizierte Feld: Welcher Prozentsatz der Datensätze hat dieses Feld befüllt? Ein Feld, das bei mehr als 20 % der Datensätze leer ist, benötigt eine Fallback-Bedingung. Ein Feld, das bei mehr als 50 % leer ist, muss befüllt werden, bevor die Implementierung startet — nicht durch CRM-Bereinigung, sondern durch die Etablierung der Gewohnheit, dieses eine Feld künftig einzutragen.
Schritt drei: API-Zugang bestätigen. Verifizieren, dass das System mit den erforderlichen Feldern eine funktionsfähige API hat. Für HubSpot, Pipedrive, Notion, Airtable, Google Workspace und die meisten nach 2015 gebauten SaaS-Tools existiert die API und ist zugänglich. Für eigenentwickelte Systeme, Legacy-Software oder Datenbanken ohne Web-Interface erfordert der API-Zugang eine separate Prüfung.
Das Ergebnis dieses Audits ist eine einseitige Liste: die Felder, die der Agent benötigt, die Befüllungsrate für jedes Feld und die Bestätigung, dass der API-Zugang besteht. Dieses Dokument ersetzt die drei Monate CRM-Bereinigung, die die meisten Unternehmen für erforderlich halten.
Wann Daten eine Implementierung tatsächlich blockieren
Zwei Datensituationen blockieren eine Implementierung tatsächlich — keine davon ist ein „unordentliche Daten"-Problem.
Das benötigte Feld existiert nirgendwo strukturiert. Eine Unternehmensberatung möchte, dass ein Agent Projektstatusberichte versendet, aber der Projektstatus wird informell in Slack-Threads verfolgt und kein Feld im Projektmanagement-Tool spiegelt den aktuellen Status wider. Der Agent kann nicht lesen, was nicht strukturiert ist. Die Lösung ist, das Feld hinzuzufügen und die Gewohnheit zu etablieren, es zu aktualisieren — was eine Woche dauert, nicht Monate der CRM-Bereinigung.
Das System hat keine API. Ein CRM auf veralteter Infrastruktur ohne dokumentierte API und ohne Datenexportformat, das die Integrationsschicht lesen kann, erfordert benutzerdefinierte Arbeit oder eine Systemmigration, bevor die Implementierung starten kann. Dies ist die eine Situation, in der „das System zuerst vorbereiten" tatsächlich richtig ist — aber es betrifft den API-Zugang, nicht die Datenqualität.
Für die meisten Unternehmen auf modernen Tools — HubSpot, Pipedrive, Notion, Airtable, Salesforce — sind beide Bedingungen nicht gegeben. Die API existiert. Die Felder existieren. Die Daten in diesen spezifischen Feldern sind ausreichend befüllt, um damit zu arbeiten. Die Implementierung ist bereit zu starten.
Häufig gestellte Fragen
Braucht ein KI-Agent saubere Daten, um zu funktionieren?
Nein. Ein KI-Agent liest über eine konfigurierte Integration spezifische Felder aus spezifischen Datensätzen. Die Datenqualität in anderen Feldern hat keinen Einfluss auf die Agentenleistung. Nur was der Integrationsbereich des Agenten spezifiziert, spielt eine Rolle: die Auslöserbedingungsfelder, die Ausgabefelder und eventuelle Entscheidungspunktfelder. Diese Felder müssen für die Datensatztypen, gegen die der Agent läuft, zuverlässig befüllt sein.
Welche Datenvorbereitung ist für eine KI-Agenten-Implementierung tatsächlich erforderlich?
Drei Dinge: Identifizieren, welche Felder der Auslöser prüft, welche Felder die Ausgabe verwendet, und bestätigen, dass diese Felder für den relevanten Datensatztyp zuverlässig befüllt sind. Dieses Audit dauert typischerweise eine Stunde in einem Scoping-Gespräch. Es erfordert keine Bereinigung, Standardisierung oder Vervollständigung von Daten in anderen Feldern.
Welche Datensituation blockiert eine Implementierung tatsächlich?
Zwei Situationen blockieren eine Implementierung. Erstens: Ein benötigtes Feld existiert in keinem strukturierten System — die Daten befinden sich in E-Mail-Threads, Slack-Nachrichten oder informellen Notizen ohne maschinenlesbares Äquivalent. Zweitens: Das System, das die Daten enthält, hat keine API. Beides lässt sich beim Scoping identifizieren und ist lösbar. Keines davon ist ein allgemeines CRM-Hygieneproblem.
Können wir implementieren, wenn unsere CRM-Daten inkonsistent sind?
Inkonsistenz in den spezifischen Feldern, die der Agent liest, erfordert eine Fallback-Bedingung im Prompt. Wenn das Datum der letzten E-Mail für einige Datensätze leer ist, gibt der Prompt an, wie damit umzugehen ist: Datensatz überspringen, stattdessen ein Erstellungsdatum-Feld verwenden oder zur manuellen Überprüfung markieren. Inkonsistenz in anderen Feldern hat keinen Einfluss. Eine Implementierung erfordert keine generell sauberen Daten — sondern eine definierte Behandlung der Edge Cases in den Feldern, die der Agent liest.
Wie behandelt man ein erforderliches Feld, das bei einigen Datensätzen leer ist? Die Implementierung fügt eine Fallback-Bedingung für dieses Feld hinzu. Wenn das Auslöserfeld leer ist, überspringt der Agent den Datensatz und markiert ihn zur manuellen Behandlung, verwendet ein alternatives Feld als Näherungswert oder erstellt eine generische Version der Ausgabe, die nicht vom fehlenden Wert abhängt. Die Fallback-Bedingung wird beim Scoping definiert. Eine beim Scoping gestaltete Fallback-Bedingung dauert fünfzehn Minuten. Eine nach drei Wochen falscher Ausgaben in der Produktion entdeckte dauert erheblich länger.
Sollte man vor der Implementierung von KI-Agenten zu einem neuen CRM migrieren? Nur wenn das aktuelle System keine API hat und die erforderlichen Felder nicht in einem maschinenlesbaren Format exportiert werden können. In allen anderen Fällen: erst nach dem Agenten migrieren — nicht davor. Zuerst gegen das aktuelle System zu implementieren zeigt, welche Daten der Agent tatsächlich benötigt, was den Migrationsumfang viel klarer macht. Zuerst zu migrieren und dann zu implementieren verdoppelt den Projektumfang ohne entsprechenden Nutzen.
Was ist der schnellste Weg zu verifizieren, ob Daten implementierungsbereit sind? Das System nach dem Datensatztyp filtern, gegen den der Agent laufen wird. Prüfen, ob die drei bis fünf Felder, die der Workflow benötigt, für mindestens 80 % dieser Datensätze befüllt sind. Wenn ja, sind die Daten bereit. Wenn ein oder zwei Felder unter 80 % liegen, kann die Implementierung mit einer Fallback-Bedingung für diese Felder starten. Wenn die erforderlichen Felder im System gar nicht existieren, hinzufügen und warten, bis sie für eine repräsentative Stichprobe befüllt sind — typischerweise zwei bis vier Wochen normaler Workflow-Ausführung — bevor der Build beginnt.
Anmerkungen
Keine externen Statistiken zitiert. Die in diesem Beitrag beschriebenen Integrationsanforderungen und feldspezifischen Datenbedingungen spiegeln Standard-Implementierungsmuster für HubSpot, Pipedrive, Notion, Airtable und Salesforce wider.