Automatisierte Zusammenführung doppelter Deals

1. Ausgangslage (heute manuell)

Laut Anleitung wird pro Person am Ende nur ein Deal behalten. Ein gespeicherter Filter „Zusammenführen" grenzt die Kandidaten ein, dann wird jeder Fall von Hand über E-Mail gesucht und zusammengeführt. Die im Filter hinterlegten Bedingungen:

Der manuelle Aufwand skaliert schlecht: Eine Person kann 2 bis 50 offene Deals haben, und der Vorgang muss je Person mehrfach wiederholt werden. Genau das übernimmt die Automation.

2. Machbarkeit – die API-Bausteine

Beim Merge wird der Deal {id} in merge_with_id hineingeführt; merge_with_id ist also der Gewinner. Aktivitäten, Notizen und Historie der Dublette wandern mit.

3. So würde die Automation ablaufen

# Pseudocode – Kern der Automation
kandidaten = lade_offene_deals(filter=ZUSAMMENFUEHREN)      # API
gruppen    = gruppiere_nach(email_der_person)               # eindeutiger Schlüssel

for email, deals in gruppen:
    deals = [d for d in deals if d.status == "open"]   # verlorene raus
    if len(deals) <= 1: continue
    gewinner  = waehle_gewinner(deals)                       # Regel Abschnitt 4
    dubletten = [d for d in deals if d.id != gewinner.id]

    for dub in dubletten:
        if DRY_RUN:
            report.add(email, behalten=gewinner.id, merge=dub.id)   # nur Vorschau
        else:
            merge_deals(dub.id, merge_with_id=gewinner.id)   # PUT …/merge  (irreversibel!)
            log(email, behalten=gewinner.id, gemergt=dub.id)
    dearchiviere_wenn_noetig(gewinner.id)

4. Regel: Welcher Deal bleibt?

Direkt aus der Anleitung übernommen und als eindeutige Priorität kodiert (erste zutreffende Regel gewinnt):

• 1. Recruiter-Zuordnung zuerst: Deals, die bereits einem Recruiter zugeordnet sind, haben Vorrang.
• 2. Sonst der neueste Deal – nach Erstellungsdatum (add_time).
• 3. Gleichstand: tie-break über letzte Aktivität, dann letzte Aktualisierung (update_time).
• Nie mergen: verlorene und gelöschte Deals bleiben unangetastet.

Hinweis aus der Anleitung: Partner wie Worklane / Ritter von Gral vermeiden Dubletten teils selbst – die Regel prüft trotzdem immer, welcher Deal der aktuellste/zugeordnete ist.

5. Schutzmechanismen (Pflicht)

6. Betrieb – wo läuft das?

Taktung wie im Filter: „Deal erstellt = diesen Monat" – ein täglicher oder stündlicher Lauf hält die Dubletten laufend klein. Jeder Lauf erzeugt einen kurzen Report (wie viele Gruppen, wie viele Merges).

7. Offene Punkte vor dem Bau

• Recruiter-Erkennung: Woran ist „einem Recruiter zugeordnet" technisch festzumachen – Owner-Feld, ein bestimmtes Custom-Feld oder eine Pipeline-Phase?
• Feld-Gewinner beim Merge: Bei Konflikten behält Pipedrive die Werte des Ziel-Deals. Reicht das, oder müssen einzelne Felder gezielt übernommen werden?
• Gruppierung: Nur innerhalb einer Person, oder auch personenübergreifend bei gleicher E-Mail (dann zusätzlich Personen mergen)?
• Filter-Umfang: Genau die sechs Bedingungen aus der Anleitung, oder erweiterbar (weitere Pipelines)?

8. Empfehlung / nächste Schritte

1. Phase 1 – Vorschau: Ich baue den Kandidaten- und Auswahl-Teil und liefere einen Dry-Run-Report (HTML/CSV): „Diese Gruppen, dieser Deal bleibt, diese werden gemergt." Es wird noch nichts verändert.
2. Phase 2 – kontrolliert scharf: Nach deiner Freigabe die Merges für eine kleine Charge ausführen, Ergebnis prüfen.
3. Phase 3 – Automatik: In n8n als geplanten Lauf mit Report je Durchlauf produktiv setzen.

So bleibt der unwiderrufliche Schritt (der Merge) bis zuletzt unter menschlicher Kontrolle, während der aufwändige Teil (Suchen, Gruppieren, Regel anwenden) sofort automatisiert ist.