Love Repair · Technische Prüfung · 11. August 2026
CRM an eine E-Mail-Automation anbinden
Antwort auf Olis Anfrage: Lässt sich der beschriebene Prozess direkt über die Schnittstellen von Typeform, unserem CRM und GetResponse umsetzen? Ja — ohne Zwischendienst wie Zapier, und der größere Teil steht in unserem CRM bereits. An einer Stelle muss der Weg allerdings anders gebaut werden als beschrieben.
1. Was unser CRM heute schon kann
- Jede Statusänderung wird bereits protokolliert. Tabelle
lead_events, Typstage_change, aktuell 486 Einträge. Der Termin steht schon mit drin:{"stage": "terminiert", "scheduled_at": "2026-08-12T10:45:00Z"}. Damit sind Punkt 4 und 6 datenseitig fertig — es fehlt nur der Ausgang. - Ausgehende Aufrufe direkt aus der Datenbank sind möglich
(
pg_net), samt Zeitsteuerung für Wiederholungen (pg_cron). - Ein erprobtes Muster für genau so etwas: die WhatsApp-, Digistore-, Calendly- und sipgate-Anbindungen laufen alle nach demselben Bauplan.
- Duplikaterkennung existiert (gleiche Nummer und gleiche Mailadresse → Stufe „Duplikat“).
2. Der eine Punkt, der anders gelöst werden muss
In der Anfrage steht es so: „Unser CRM übermittelt den Status → GetResponse stoppt die bisherige Sequenz und startet die neue.“
So arbeitet die Schnittstelle nicht. Es gibt keinen Aufruf, der eine laufende Sequenz für einen Kontakt beendet. Das Beenden ist eine Aktion innerhalb eines Workflows in GetResponse („Kontakt entfernen → Autoresponder-Zyklus“) — also etwas, das dort konfiguriert und nicht von außen angestoßen wird.
Der Weg, der funktioniert:
Unser CRM setzt per Schnittstelle nur ein Tag, etwa
status_lg_gebucht. In GetResponse liegt dazu ein Workflow mit dem
Auslöser „Tag hinzugefügt“, und der macht zuerst das Aufräumen
(alte Sequenz entfernen), dann den Start der neuen.
Das ist am Ende die bessere Bauweise
Unser CRM sagt immer nur: „Dieser Lead ist jetzt in Zustand X.“ Es muss nicht wissen, welche Sequenzen es gibt und welche gerade laufen. Die gesamte Stopp- und Start-Logik liegt einmalig in GetResponse — dort, wo sie ohne Entwickler geändert werden kann.
3. Zur Terminsteuerung (Punkt 6)
GetResponse kann Datumsfelder vergleichen („ist vor / nach / am“), hat aber kein sauberes „sende 24 Stunden vor diesem Termin“. Mit Warteelementen lässt sich das nachbauen, wird aber empfindlich.
Wir haben diese Funktion bereits. Unsere Terminerinnerung
läuft minutengenau und kennt den Termin. Vorschlag: Das CRM setzt die Tags
vorcall_24h und vorcall_1h zum richtigen
Zeitpunkt, und GetResponse verschickt daraufhin sofort. Datum und Uhrzeit
wandern zusätzlich als Feld mit, damit sie im Mailtext stehen können.
4. Zur Frage nach dem eindeutigen Identifier
Empfehlung: die E-Mail-Adresse als Schlüssel, die Telefonnummer als zusätzliches Feld. Das ist keine Geschmacksfrage, sondern an unseren Daten geprüft:
- Alle 275 aktiven Leads haben beides — Mailadresse und Telefonnummer. Keine Lücken.
- In der Historie: 20.039 verschiedene Adressen auf 23.351 Anfragen, im Schnitt 1,17 Anfragen je Adresse.
- Bei keiner einzigen der 269 Telefonnummern gab es zwei verschiedene Mailadressen.
Ein zusammengesetzter Schlüssel bringt hier also nichts — die beiden Angaben widersprechen sich nie, und ein E-Mail-Werkzeug arbeitet ohnehin über die Adresse. Die Telefonnummer sollte trotzdem mitlaufen, damit Einzelfälle nachprüfbar bleiben.
5. Doppelte Kontakte und parallele Sequenzen: drei Fallen
Falle 1 — Wiederkehrer. Der häufigste Fall.
23 von 275 Leads (8,4 %) haben sich schon einmal gemeldet. In unserem CRM ist das ein neuer Lead, im E-Mail-Werkzeug derselbe Kontakt — und der steckt womöglich noch in einer alten Strecke.
Lösung: Auch der Auslöser „neuer Lead“ muss zuerst aufräumen. Jeder Workflow beginnt mit Entfernen, dann Starten. Nie nur starten.
Falle 2 — Reihenfolge
Verklickt sich ein Setter und korrigiert sofort, gehen zwei Aufrufe raus, deren Ankunftsreihenfolge nicht garantiert ist. Der Lead landet dann in der Sequenz, die eigentlich widerrufen wurde.
Lösung, zweiteilig: Ein Kontakt trägt immer nur ein einziges Status-Tag — beim Setzen werden alle übrigen im selben Durchgang entfernt. Und übertragen wird der Zustand mit Zeitstempel, nicht die Änderung; ältere Meldungen werden verworfen.
Falle 3 — fehlgeschlagene Aufrufe
Niemals direkt aus dem Auslöser heraus senden. Statusänderungen laufen in eine Warteschlange, ein Arbeiter holt sie ab und wiederholt bei Fehlern.
Ohne das geht bei jeder Netzwerkstörung still eine Änderung verloren — und der Lead bleibt dauerhaft in der falschen Strecke, ohne dass es jemandem auffällt.
6. Wichtig: Die Statusliste passt noch nicht zusammen
Die Liste in der Anfrage entspricht nicht dem, was in unserem CRM tatsächlich existiert. Das sollte vor dem Bauen geklärt werden, sonst wird an der Wirklichkeit vorbei konfiguriert:
| In Olis Liste | Bei uns | Anmerkung |
|---|---|---|
| Neuer Lead | Offen | passt |
| Setting / Kontaktaufnahme | Kontaktiert | passt |
| Nicht erreicht | Nicht erreicht | passt |
| Nicht qualifiziert | Disqualifiziert | passt |
| Qualifiziert | — | fehlt bei uns als eigene Stufe |
| Lösungsgespräch gebucht | Terminiert oder Sales Call | zwei Stufen, nicht eine |
| Lösungsgespräch gehalten | — | gibt es nicht; danach direkt Gewonnen / Überlegen / Verloren |
| No-Show | No Show oder SC No-Show | zwei Stufen — eine davon darf keine Mail auslösen |
| Follow-up | Überlegen (Follow-up) | passt |
| Kunde | Gewonnen | passt |
Alle Stufen und was dort passieren sollte
| Stufe in unserem CRM | Schlüssel | Mail? | Was dort passieren sollte |
|---|---|---|---|
| Offen | offen | ja | Allgemeine Lead-Sequenz starten |
| Kontaktiert | kontaktiert | nein | Erstkontakt läuft über WhatsApp |
| Bot: NEIN | bot_nein | nein | Interne Merkstufe |
| Terminiert | terminiert | ja | Setting-Termin, 45 Min — eigene Vorlauf-Sequenz |
| Sales Call | sales_call | ja | Lösungsgespräch, 120 Min — Pre-Call-Sequenz |
| SC No-Show | sc_no_show | NEIN | Ausdrücklich intern: „keine Nachricht an den Kunden“ |
| No Show | no_show | ja | No-Show-Sequenz |
| Überlegen (Follow-up) | ueberlegen | ja | Follow-up-Sequenz |
| Gewonnen | gewonnen | ja | Alle Verkaufsstrecken stoppen, Kundensequenz |
| Termin abgesagt | abgesagt | ja | Absage geht heute schon per WhatsApp raus |
| Nicht erreicht | nicht_erreicht | ja | Reaktivierung denkbar |
| Disqualifiziert | disqualifiziert | ja | Alles stoppen |
| Verloren | verloren | ja | Alles stoppen |
| Nummer falsch | nummer_falsch | nein | Datenfehler, kein Zustand des Leads |
| U18 | u18 | NEIN | Minderjährig — rechtlich keine Ansprache |
| Duplikat | duplikat | NEIN | Würde den echten Lead aus seiner Sequenz werfen |
| Test | test | NEIN | Eigene Probeanmeldung |
7. Zur Werkzeugfrage
Falls es nicht GetResponse sein muss: Das sind die drei Anforderungen, an denen sich jedes Werkzeug messen lässt.
- Workflows müssen sich per Tag auslösen lassen
- Die Schnittstelle muss Tags und eigene Felder setzen können
- Ein Workflow muss einen Kontakt aus laufenden Sequenzen entfernen können
GetResponse erfüllt alle drei. ActiveCampaign und Brevo ebenfalls und etwas komfortabler — aber das ist kein Grund zu wechseln, wenn GetResponse bereits im Einsatz ist.
8. Aufwand
Auf unserer Seite überschaubar, weil das Fundament steht: eine Warteschlange mit Auslöser, ein Arbeiter, die Zuordnungstabelle in den Einstellungen und ein Notschalter zum Abstellen. Schätzung: ein Arbeitstag bis zum Testbetrieb.
Der größere Teil ist die Konfiguration in GetResponse — pro Status ein Workflow, jeweils mit Aufräumen und Start.
9. Zwei Punkte, die vorher geklärt gehören
Einwilligung
Werbliche E-Mail-Strecken brauchen ein dokumentiertes Einverständnis. Ob das Typeform es sauber einholt und wo es festgehalten wird, sollte jemand prüfen, bevor die erste Sequenz läuft. Das ist kein technisches, sondern ein rechtliches Risiko — und es trifft den Absender, nicht das Werkzeug.
Überschneidung mit WhatsApp
Über WhatsApp gehen bereits Terminbestätigungen, Erinnerungen und Absagen raus. Bevor parallel E-Mail-Strecken dazukommen, sollte einmal durchgegangen werden, wer wann was bekommt — sonst erhält derselbe Mensch dieselbe Erinnerung zweimal auf zwei Kanälen.