Die eingebaute „Dublettenkontrolle" in Bitrix24 sucht Übereinstimmungen bei Leads, Kontakten und Unternehmen — Deals prüft sie nicht. Zwei offene Deals zu einem Kunden gelten nicht als Dublette: ein Deal hat keine eigene Telefonnummer und E-Mail, dem eingebauten Mechanismus fehlt der Vergleichsschlüssel. Deshalb fängt man Deal-Dubletten anders ab: ein Geschäftsprozess sucht vor der Neuanlage einen offenen Deal des Kontakts, eine Bedingung entscheidet, was mit dem Fund geschieht, und eine blockierende Prüfung auf den Phasen ergänzt die App „Dublettenkontrolle".
Warum sieht die eingebaute Dublettensuche keine Deals?
Der eingebaute Mechanismus vergleicht Name, Telefon und E-Mail — die Stammdaten des Kunden. Diese Felder gibt es bei Lead, Kontakt und Unternehmen, weshalb für sie sowohl die Warnung beim Anlegen einer Karte als auch die massenhafte „Dublettensuche" aus der Liste funktionieren. Ein Deal hat keine Kontaktdaten: er verweist auf einen Kontakt und ein Unternehmen, und seine eigenen Felder — Name, Betrag, Phase — stimmen bei verschiedenen Deals ständig überein und können kein Vergleichsschlüssel sein. Zwei Deals „Lieferung von Geräten" zu einem Kontakt sind für das System einfach zwei verschiedene Datensätze. Wie der eingebaute Mechanismus für Leads und Kontakte funktioniert — in der Analyse zu Dubletten in Bitrix24.
Woher kommen Deal-Dubletten?
Die Hauptquelle sind wiederholte Anfragen. Der Kunde hat eine Anfrage auf der Website hinterlassen und einen Tag später angerufen: jeder Kanal hat seinen eigenen Deal erzeugt, obwohl bereits ein offener bestand. Integrationen verstärken den Effekt: Telefonie, Formulare und Messenger erstellen Deals nach ihren eigenen Regeln und prüfen bestehende nicht. Die dritte Quelle sind die Mitarbeiter: einen Deal in der langen Liste nicht gefunden, einen neuen angelegt. Die vierte — Import ohne Abgleich. Das Ergebnis ist immer dasselbe: die Verhandlungshistorie ist über zwei Karten verschmiert, zwei Mitarbeiter rufen denselben Kunden an, und der Trichter zeigt eine Konversion, die es nicht gibt — ein erheblicher Teil der „verlorenen" Deals ist in Wirklichkeit doppelt angelegt. Je mehr Kanäle für den Anfrageeingang, desto schneller häufen sich solche Paare an.
Wie verhindert man eine Dublette bei einer wiederholten Anfrage?
Die Regel: vor dem Anlegen eines Deals sucht der Prozess einen bestehenden. Der erste Schritt — der Roboter „Kontakt per Telefon/E-Mail finden": anhand der Telefonnummer aus der Anfrage gibt er die Kontakt-ID und das Kennzeichen „Gefunden" (J/N) zurück. Der zweite Schritt — der Roboter „Deal nach Bedingung finden": anhand der Kontakt-ID und des Filters {"CLOSED":"N"} sucht er die offenen Deals des Kunden und gibt die ID des ersten Treffers, die Liste aller IDs, die Anzahl und ein J/N-Kennzeichen zurück. Danach folgt eine Verzweigung nach Bedingung: bei J wird die Anfrage dem bestehenden Deal als Kommentar oder Aktivität hinzugefügt, bei N erstellt der Prozess einen neuen. Die Dublette ist abgefangen, bevor sie entstanden ist.
Wie prüft man einen bereits erstellten Deal auf Dubletten?
Dieselbe Suche funktioniert auch nach dem Anlegen — zum Beispiel in der ersten Phase des Trichters. Der Prozess auf dem Deal startet „Deal nach Bedingung finden" mit der Kontakt-ID dieses Deals und einem Filter auf offene: die zurückgegebene Anzahl zeigt, wie viele offene Deals der Kunde hat. Der Roboter „Komplexe Bedingung (AND / OR / NOT)" prüft mehrere Bedingungen auf einmal — etwa Anzahl größer als eins UND der Betrag des neuen Deals nicht ausgefüllt — und gibt ein einheitliches J/N-Kennzeichen zurück. Bei J setzt der Prozess dem Verantwortlichen eine Aufgabe, die Dublette zu klären, und benachrichtigt den Vorgesetzten. Deals automatisch zusammenzuführen ist nicht ratsam: welcher der Haupt-Deal ist, entscheidet ein Mensch.
Wann reichen Prozesse nicht aus?
Ein Geschäftsprozess fängt Dubletten an den Punkten ab, die Sie vorgesehen haben: Anlage, erste Phase, wiederholte Anfrage. Alles, was an diesen Punkten vorbei kommt — manuelles Anlegen unter Umgehung des Prozesses, alte doppelte Datensätze, Dubletten von Leads und Kontakten, aus denen Deal-Dubletten erwachsen — bleibt in der Datenbank. Die systemische Lösung ist die App „Dublettenkontrolle": sie prüft die Karte bei jeder Bewegung durch den Trichter und lässt sie nicht weiter, bis die Dublette zusammengeführt ist, und scannt zusätzlich die bestehende Datenbank im Massenbetrieb. Es entsteht eine dreischichtige Verkettung: Prozesse verhindern das Anlegen von Dubletten, die Prüfung auf den Phasen fängt Übersehenes ab, das Scannen arbeitet das Angesammelte auf.
Checkliste
Setzen Sie die Suche nach Kontakt und offenem Deal vor die Neuanlage; prüfen Sie in der ersten Phase die Anzahl der offenen Deals des Kunden über eine komplexe Bedingung; geben Sie gefundene Dubletten als Aufgabe an den Mitarbeiter weiter, statt sie blind zusammenzuführen; für die blockierende Prüfung auf den Phasen und das Massen-Scanning installieren Sie „Dublettenkontrolle". Die Roboter zur Suche und Prüfung finden Sie im Katalog der CRM-Roboter. Wenn der benötigte Roboter fehlt — beschreiben Sie die Aufgabe, wir bauen ihn kostenlos und fügen ihn der gemeinsamen Bibliothek hinzu.