Was er leistet: Menschen, die sich für ein Webinar angemeldet und es nicht
besucht haben, per WhatsApp zum nächsten Termin einladen und mit einem Klick
dort anmelden.
Bewiesen bei: Dr. Carmen Mayer, Läufe 05.05. · 09.06. · 30.06. · 04.08.2026.
Erster Lauf, der vollautomatisch lief: 14 launchd-Wecker haben stündlich
selbst gefeuert, ohne dass jemand daneben saß.
| Kampagnen / Empfänger | 18 Kampagnen · 1.593 verschickt (davon 14 Batches à ~100 im aktuellen Plan = 1.363) |
|---|---|
| Zugestellt / gelesen | 1.393 · 1.085 (76 %) |
| Antworten | 239 |
| Anmeldungen aus dem Lauf | 187 · Anmelde-Liste gesamt 1.751 → 2.265 |
| Fehlgeschlagen | 196 (12 %, alte Nummern) |
| Kontoqualität | durchgehend GELB, keine Sperre |
| Pool am Ende | 0 |
Kein Fehlversand: kein Empfänger auf einer Sperrliste hat eine Nachricht
bekommen. Vor jedem einzelnen Batch wurde erneut gegen alle Sperrlisten geprüft.
Gehärtet in drei Kaltstart-Runden (kontextfreie Prüfer): Runde 1 fand 5 echte
Fehler, Runde 2 fand 2 in den Fixes von Runde 1, Runde 3 fand 0. Erst danach
galt es als fertig. Selbsttest steht bei 10/10.
Das ausführbare Runbook (11 Stationen inkl. 6b Reminder, Fallen-Index, Verifikation je Station):
Brand - Carmen Mayer/Superchat-Prozedere/03-runbook-reaktivierung.md
Lesbare Fassung: https://domi.share.benediktglass.com/carmen-runbook/
Kennzahlen: https://domi.share.benediktglass.com/carmen-dashboard/
| Voraussetzung | Warum |
|---|---|
| Messenger-Werkzeug mit WhatsApp-Business-Zugang | Der Versandkanal. Bei Carmen: Superchat. |
| Genehmigte Nachrichten-Vorlage bei Meta | Ohne sie geht kein Massenversand. Tage Vorlauf. |
| Automations-Werkzeug | Zusage → Anmeldung. Bei Carmen: Zapier. |
| Webinar-System mit Teilnehmer-Export | Liefert die Kohorte. Bei Carmen: WebinarJam. |
| Eine hochgestufte Versand-Nummer | ⚠️ Eine frische Nummer startet bei 250 Empfängern pro 24 h. Die üblichen Batch-Größen setzen eine hochgestufte Nummer voraus. |
Das ist der Teil, den man monatlich anfasst. Alles andere bleibt stehen.
Wo der Partner es sieht: das Dashboard wird nach
carmen-mayer.share.dominik-fuertbauer.com/superchat-reaktivierung-<JAHR>-<MONAT>/
veröffentlicht — auf Domis eigener Domain, weil der ClientShare-Kunde
carmen-mayer seine Partner-Basis trägt; dadurch erscheint es auch in seiner
Übersicht. Der Monat im Slug ist Absicht: jeder Lauf bleibt als eigene Seite
erhalten und lässt sich mit dem Vormonat vergleichen. Beim Umbenennen die alte
Adresse per clientshare redirect am Leben lassen, der Partner hat sie schon.
⭐ Seit 02.08.2026 gibt es dafür EINE Datei: konfig.json. Alle IDs (Kanal,
Vorlage, Kohorte, gesendet, alle Sperrlisten, Testnummern) stehen dort genau
einmal; die sechs Skripte lesen von dort. Vorher lagen dieselben ~13 IDs in sechs
Skripten dupliziert, und wer eine Datei vergaß, verglich alten mit neuem Stand.
**Neuer Lauf = diese eine Datei umstellen, dann selbsttest.py. Kein Python
anfassen.** Anleitung: Superchat-Prozedere/KONFIG.md.
| # | Was | Falle, wenn man es vergisst |
|---|---|---|
| 1 | Neue Kohorte aus dem Webinar-Export ziehen und bereinigen | Falsches Quell-Webinar ⇒ falsche Zielgruppe, merkt man erst nach dem Versand |
| 2 | Vier neue Kontaktlisten mit neuem Datum anlegen | — |
| 3 | Arbeits-Filter auf die neuen Listen-IDs | Eine vergessene Sperrliste ⇒ Abgemeldete bekommen Werbung |
| 4 | Konversions-Workflow auf den neuen Termin | Zusagen laufen ins Leere |
| 5 | Anmelde-Zap auf das neue Webinar und die neue Session | Menschen sagen zu und sind nirgends eingetragen |
| 6 | „Template sent"-Zap auf die neue gesendet-Liste UND die neue Template-ID | ⛔ Der Zap filtert auf die Template-ID. Neue Vorlage plus nur umgehängte Liste heißt: er feuert nie wieder. Dann landet niemand in gesendet, und jeder Batch geht an alle vorherigen Empfänger erneut. |
| 7 | Riegel gegen Doppelnachricht auf die neue gesendet-Liste | Reaktivierte bekommen zwei Nachrichten |
| 8 | Den dauerhaften Opt-in-Workflow prüfen | ⛔ Er ist nicht datumsgebunden, hat die Zielliste aber fest verdrahtet. Er schreibt still weiter in die Liste des Vormonats. Meldet sich nie. |
| 9 | Eigene Testnummern aus der Import-Liste entfernen | Sonst stehen sie im echten Verteiler |
| 10 | Automations-Kontingent prüfen | Bei Erschöpfung geht ein Workflow auf SUSPENDED und meldet sich nicht |
| 11 | Reminder-Kampagne für kurz vor dem Start aufsetzen | ⛔ Fehlte bis 02.08.2026 in jeder Checkliste. Sie ist die einzige Nachricht mit einem Link, ging an 296 Menschen und brachte 33 Konversionen. Wer sie vergisst, merkt nichts — kein Punkt schlägt an. |
| 12 | Bei LIVE-Webinar: den Reminder-Link prüfen | ⛔ Es ist ein Channel-Link, der einem bestimmten Live-Webinar gehört. Bei neuem Termin zeigt er auf „Webinar ist vorbei" und antwortet trotzdem mit HTTP 200. Ein Status-Check fängt das nicht, nur der Redirect. Neuer Link heißt außerdem neue Meta-Genehmigung, also Tage Vorlauf. |
| 13 | Genau EINEN Registrierungs-Trigger aktiv lassen | Live-Variante und EverWebinar-Variante existieren beide. Beide an ⇒ doppelt, beide aus ⇒ gar nicht. |
⚠️ Reihenfolge ist kein Stilfrage: Punkte 4 bis 8 müssen stimmen, bevor der
erste Batch rausgeht. Im Lauf vom 01.08.2026 wurde genau das verletzt: 30 echte
Menschen bekamen die Nachricht, bevor die Kette fertig verdrahtet war.
Benedikts Auflage (04.08.2026): *„Wir sollten Sachen bauen, die sich auch
selbst wieder aufräumen, weil sich sonst niemand mehr daran erinnern kann."*
Ein Lauf hinterlässt Zeitschaltungen: 14 Batch-Wecker und einen Beobachter, der
alle 14 Minuten misst. Nach dem Webinar haben die ihren Zweck erfüllt. Was dann
weiterläuft, tickt monatelang unbemerkt weiter, und in drei Monaten ordnet es
niemand mehr zu — genau die Zeitbombe, die ein Schnellschuss ohne Spur erzeugt.
Wie es hier gelöst ist: In konfig.json steht lauf_ende (Datum/Uhrzeit
nach dem Webinar). Der Beobachter macht danach genau noch eine letzte Messung,
veröffentlicht sie, entlädt die verbrauchten Batch-Wecker und zum Schluss
sich selbst — Plist gelöscht, Prozess beendet. Kein Handgriff nötig.
⚠️ Bewusst fail-safe in die andere Richtung als der Sendepfad: ist
lauf_ende unlesbar oder nicht gesetzt, wird nicht abgebaut. Ein Beobachter,
der zu früh verschwindet, nimmt dem Partner das Dashboard weg; einer, der einen
Tag zu lang läuft, kostet nichts.
Für jeden neuen Lauf stehen alle drei Betriebs-Angaben in derselben Datei wie
die IDs, also ein Handgriff:
"dashboard_kunde": "carmen-mayer",
"dashboard_slug": "superchat-reaktivierung-2026-08", ← Monat hochzählen
"lauf_ende": "2026-08-04 23:00" ← nach dem Webinar
⚠️ Falle aus dem eigenen Umbau (04.08.2026): Beim Verlagern des Ziels in die
Konfig ist einmal das --kunde-Flag aus dem clientshare publish-Aufruf
gerutscht. Das wäre still schiefgegangen — veröffentlicht hätte er beim
Standard-Kunden, der Aufruf hätte trotzdem „erfolgreich" gemeldet, und niemand
hätte es gemerkt. Nach jeder Änderung am Publish-Ziel den echten Aufruf einmal
fahren und die Live-URL auf Inhalt prüfen, nicht nur auf Syntax.
Vollständiger Index: Superchat-Prozedere/FEHLERLOG.md (F-01 … F-19).
Diese vier treffen jeden neuen Lauf wieder:
ein sauberer, ein toter Zugang wie „0 Zusagen". Am Morgen des 04.08. zeigte
das Dashboard dem Partner 0 verschickt und 17.500 % Anmeldequote, während
alle Batches längst draußen waren: der Zugang war über Nacht abgelaufen, der
Fehler wurde verschluckt und die entstandenen Nullen als Messwerte
weggeschrieben. **Regel: lieber ein ehrlich alter Wert mit Datum als eine
erfundene Null.** Das Dashboard zeigt jetzt „Zahlen sind nicht aktuell,
letzter Stand von X Uhr" (F-19).
Datei ist nicht live, bevor der Prozess neu gestartet wurde. Real passiert am
04.08.: der Beobachter schrieb nach dem Fix noch eine Stunde blind weiter.
3 Kontakte „offen" — sie hatten gar keinen WhatsApp-Kanal, nur eine
E-Mail. Der Pool wäre nie auf 0 gegangen. Erst nachsehen *warum*, dann an der
Quelle korrigieren (in Superchat auf „Kontakt nicht auf Whatsapp"), nicht
im Dashboard wegrechnen.
deshalb war die Nacht auf den 04.08. blind. Zugangsdaten liegen in ClientShare
(Kunde domi), der Zero-Touch-Login ist der offene Wurzel-Fix.
unterscheiden sie sich nicht: gleicher Zapier-Konnektor, gleiche Felder
webinar + schedule, nur andere Werte. Auch der persönliche Zugangslink ist
gleich aufgebaut. Der Unterschied steckt allein im Reminder kurz vor Start,
siehe die neue Station 6b im Runbook.
⚠️ Hier stand bis 02.08. „unterscheiden sich beim Zugangslink und beim
Eintragen". Der zweite Teil war falsch.
auf 1.234 Nachrichten. Die Richtung ist bewusst zugunsten des Empfängers
gewählt (lieber einen zu viel austragen als eine Abmeldung übergehen).
WhatsApp-Opt-in. Bewusste unternehmerische Entscheidung, hier nur vermerkt.
Was ohne Anpassung trägt: das Listen-Verfahren (Kohorte, zu senden, gesendet,
Sperren), die Batch-Logik, die Verifikationen, der Fallen-Index.
Was pro Marke neu ist: der gesamte Aufsatz (Messenger-Konto, WhatsApp-Kanal,
Vorlagen-Genehmigung, Automations-Bau) und die Frage, ob das Webinar-System
überhaupt einen Export und einen programmatischen Anmelde-Weg hat.
⚠️ Der Aufsatz ist nicht im Runbook beschrieben. Das Runbook beschreibt einen
Wiederhol-Vorgang. Für Marke Nummer 2 fehlt die Aufsetz-Phase, und sie ist
mit Abstand der größte Brocken (Tage bis Wochen, vor allem wegen der
Meta-Vorlagen-Genehmigung).