Technischer Deep Dive: So funktioniert CRM Outreach Campaigns unter der Haube
CRM Outreach Campaigns ist ein serverseitiges Python-Modul für Odoo Community Edition. Kein JavaScript-Frontend, keine externen Dependencies, keine API-Calls zu Drittanbieter-Services. Dieser Artikel erklärt die Architektur — Datenmodell, Email-Sendefluss, Reply Detection, Do-Not-Contact-Kaskade und die Design-Entscheidungen dahinter.
Das ist keine Marketing-Seite. Es ist ein technischer Walkthrough für Leute, die das Modul vor der Installation evaluieren oder die Architektur nach der Installation verstehen wollen.
Datenmodell: Fünf Objekte, ein Flow
Das Modul fügt 5 neue Models zu Odoo hinzu und erweitert das bestehende CRM-Lead-Model.
crm.outreach.sender — Absender-Email
Repräsentiert eine Absender-Identität: Display-Name, Email-Adresse, Signatur (HTML) und ein Link zu einem ir.mail_server (ausgehender SMTP). Ein Sender pro Vertriebsmitarbeiter. Das Modul sendet Emails über den SMTP-Server des Senders, nicht über den System-Default.
Key Fields: name, email, signature, mail_server_id
crm.outreach.campaign — Kampagne
Ein benannter Container für eine Email-Sequenz. Hat eine One2many-Beziehung zu Kampagnen-Steps (Email-Templates). Trackt den Gesamt-Kampagnenstatus und verlinkt auf alle zugewiesenen Leads.
Key Fields: name, step_ids (One2many), lead_ids (One2many)
crm.outreach.step — Kampagnen-Step
Eine Email in einer Sequenz. Definiert Email-Betreff, Body-Template (mit Platzhaltern) und die Verzögerung in Tagen vom vorherigen Step. Steps sind per Sequenznummer innerhalb einer Kampagne sortiert.
Key Fields: campaign_id, sequence, subject, body_template, delay_days
crm.outreach.lead — Kampagnen-Lead (Junction)
Das Junction-Model zwischen Kampagnen und CRM-Leads. Hier passiert das Per-Lead-Tracking. Jeder Record trackt: welche Kampagne, welcher Lead, bei welchem Step der Lead gerade ist, den Status des Leads (New, Contacted, Replied, Positive, Not Now, Dead) und das nächste Email-Fälligkeitsdatum.
Key Fields: campaign_id, lead_id, current_step_id, status, next_send_date, sender_id
crm.lead (erweitert) — CRM-Lead-Erweiterung
Das Standard-CRM-Lead-Model wird um ein "Do Not Contact"-Flag und einen Reverse-Link zu allen Kampagnen-Zuweisungen erweitert. Das DNC-Flag wird auch auf res.partner (Kontakte und Firmen) für Kaskaden-Blocking hinzugefügt.
Added Fields: do_not_contact, do_not_contact_reason, do_not_contact_date, outreach_lead_ids
Email-Sendefluss
Das Modul sendet Emails nicht automatisch. Das ist eine bewusste Design-Entscheidung. Hier ist der Flow:
1. Lead wird einer Kampagne zugewiesen
Ein crm.outreach.lead-Record wird erstellt. Status = "New". Das next_send_date wird basierend auf dem Delay des ersten Steps berechnet (normalerweise 0 = heute).
2. Mitarbeiter öffnet seine Arbeitsliste
Das Dashboard zeigt alle Leads, bei denen next_send_date <= today und der Status "New" oder "Contacted" ist. Das sind die heute fälligen Emails.
3. Mitarbeiter prüft und sendet jede Email
Das Template wird mit den Lead-Daten gerendert (Kontaktname, Firma etc.) und zur Prüfung angezeigt. Der Mitarbeiter kann vor dem Senden bearbeiten. Die Email geht über den SMTP-Server des Senders, nicht über den System-Default.
4. Status und nächster Step werden aktualisiert
Nach dem Senden wechselt der Lead-Status zu "Contacted", der aktuelle Step rückt vor, und das next_send_date wird basierend auf dem Delay des nächsten Steps neu berechnet.
5. Sequenz endet oder wird unterbrochen
Wenn der Lead antwortet, als "Not Now" markiert wird oder den letzten Step erreicht, stoppt die Sequenz für diesen Lead. Keine weiteren Emails werden geplant.
Warum nicht automatisch senden?
Viele Email-Outreach-Tools senden auf Autopilot. Wir haben uns bewusst für ein Review-then-Send-Modell entschieden:
Qualitätskontrolle: Mitarbeiter sehen jede Email vor dem Versand. Sie können Platzhalter-Fehler (fehlender Firmenname, falscher Kontakt) erkennen, eine persönliche Note hinzufügen oder einen unpassenden Lead überspringen.
Zustellbarkeits-Sicherheit: Automatisches Senden von Hunderten Emails über ein Standard-Odoo-SMTP-Setup kann Spamfilter auslösen. Manuelles Senden in menschlichem Tempo (30–50/Tag) hält die Zustellraten hoch.
Compliance-Awareness: Menschliche Prüfung ist die letzte Verteidigungslinie gegen das Anschreiben von Personen, die nicht kontaktiert werden sollten. Der Mitarbeiter sieht die Email und den Lead-Kontext vor dem Klick auf Senden.
Keine Cron-Abhängigkeit: Automatisches Senden braucht zuverlässige Cron-Jobs, die lautlos fehlschlagen können. Manuelles Senden bedeutet: Der Mitarbeiter weiß, ob Emails rausgegangen sind oder nicht.
Reply Detection: So werden Antworten erkannt
Reply Detection nutzt Odoos eingebauten Incoming-Mail-Server. Wenn das Modul eine Email sendet, setzt es die Message-ID und Reply-To Headers korrekt. Wenn eine Antwort eingeht, matched Odoos Mail-Gateway sie über den In-Reply-To-Header an die Original-Nachricht.
Das Modul hakt sich in diesen Prozess ein: Wenn eine Antwort zu einem Lead gematched wird, der Teil einer aktiven Kampagne ist, wechselt der Lead-Status automatisch zu "Replied". Der Antwort-Inhalt erscheint im Chatter-Thread des Leads.
Voraussetzung: Reply Detection braucht einen Incoming-Mail-Server (IMAP oder POP3) in Odoo. Ohne ihn werden Emails trotzdem gesendet, aber Antworten nicht automatisch erkannt — der Mitarbeiter müsste den Status manuell aktualisieren.
Do-Not-Contact-Kaskade
Das DNC-System operiert auf drei Ebenen: Lead, Kontakt (Partner) und Firma (Parent Partner). Wenn DNC auf einer höheren Ebene gesetzt wird, kaskadiert es nach unten:
Lead-Level DNC: Nur dieser spezifische Lead wird geblockt. Andere Leads mit demselben Kontakt bleiben aktiv. Nützlich für Leads, die offensichtlich irrelevant sind (falsche Abteilung, falsches Produkt).
Kontakt-Level DNC: Der Kontakt (res.partner) wird geflaggt. Alle CRM-Leads, die mit diesem Kontakt verknüpft sind, werden für Outreach geblockt. Neue Leads für diesen Kontakt werden ebenfalls geblockt.
Firmen-Level DNC: Die Firma (Parent res.partner) wird geflaggt. Alle Child-Kontakte erben den Block. Alle Leads, die mit irgendeinem Kontakt dieser Firma verknüpft sind, werden geblockt. Das ist der "Diese Organisation nicht mehr kontaktieren"-Button.
Jede DNC-Aktion protokolliert einen Grund und Zeitstempel für Audit-Zwecke. Die Kaskade wird sowohl in der UI (Leads werden visuell als geblockt markiert) als auch in der Send-Logik (das Modul prüft den DNC-Status vor dem Erlauben einer Email) durchgesetzt.
Template-Rendering
Template-Rendering passiert zum Sendezeitpunkt, nicht bei der Zuweisung. Wenn der Mitarbeiter eine Email zur Prüfung öffnet, löst das Modul alle {{ placeholder }}-Variablen auf, indem es Daten aus drei Quellen zieht:
- Lead: contact_name, email, phone, mobile, company_name, street, city, zip, country, website, job_title, first_name
- Sender: sender_name, sender_email, signature
- Kontext: today, current_day
Wenn ein Platzhalter nicht aufgelöst werden kann, wird er als leerer String gerendert. Der Mitarbeiter sieht die finale Email vor dem Senden und kann Lücken manuell füllen.
Was das Modul nicht macht
Transparenz über den Scope ist wichtig für die technische Evaluation:
- Kein automatischer Email-Versand — Emails werden vom Mitarbeiter manuell geprüft und gesendet
- Kein Email Warm-up — Zustellbarkeits-Management liegt außerhalb des Modul-Scopes
- Kein Open/Click Tracking — das Modul injiziert keine Tracking-Pixel oder Redirect-Links
- Kein A/B Testing — Template-Varianten werden manuell durch separate Kampagnen verwaltet
- Kein JavaScript-Frontend — alle Views nutzen Standard-Odoo-Server-Side-Rendering
Fazit
CRM Outreach Campaigns ist ein fokussiertes Modul: Fünf Models, ein klarer Flow, keine externen Dependencies. Es macht eine Sache — strukturierte Email-Sequenzen im CRM — und macht sie sauber. Kein Versuch, ein vollständiges Marketing-Automation-System zu sein.
Für technische Evaluatoren: Der Code ist serverseitiges Python, standard Odoo ORM, keine Hacks. Installierbar auf Odoo 16–19, keine Konflikte mit dem CRM-Kernmodul.
Das CRM Outreach Campaigns Modul ist auf dem Odoo App Store verfügbar. Empfehlung: Auf einer Staging-Datenbank installieren, Code prüfen und den Workflow testen, bevor es in Produktion geht.
Weiterführende Artikel:
