Runbook: monatliche WhatsApp-Reaktivierung

Runbook: monatliche WhatsApp-Reaktivierung (Superchat)

Was der Ablauf leistet: Menschen, die sich fuer ein Webinar angemeldet und es

nicht besucht haben, per WhatsApp zum naechsten Termin einladen und mit einem

Klick dort anmelden.

Zwei Phasen, nicht vermischen:

• Reaktivieren (Tage vor dem Termin): Nicht-Teilnehmer des LETZTEN Webinars anschreiben.
• Erscheinen (am Termintag): alle Angemeldeten erinnern.

Dieses Runbook beschreibt Phase 1.

---

Wenn Du das hier zum ersten Mal liest

Lies zuerst diesen Abschnitt zu Ende, dann Station 1 bis 10 der Reihe nach.

Die Stationen bauen aufeinander auf. Station 7 (die Kette) muss stimmen, bevor

der erste Batch rausgeht, sonst laufen Zusagen ins Leere und man merkt es erst,

wenn Menschen sich beschweren.

Reihenfolge fuer einen kompletten Lauf: 1 → 2 → 3 → 4 → 5 → 7 → 8 →

6 (mit wachsenden Batches) → 9 laeuft nebenher → 10 vor jedem Batch.

Was Du auf keinen Fall tust:

• Einen Batch senden, bevor Station 8 vier Mal sauber durchgelaufen ist.
• Die Kohorte des Vormonats erneut anschreiben. Alte Laeufe sind abgeschlossen.
• Kontakte von Hand zusammensuchen. Es wird immer importiert (Station 4).
• Bei WhatsApp ueber ein fremdes Unipile-Konto senden (siehe Station 10).

---

Die IDs dieses Kunden (Stand 01.08.2026)

⚠️ Alles, was ein <Datum> im Namen traegt, wird pro Lauf NEU angelegt.

Die Zeilen ohne Datum sind dauerhaft.

Superchat-Kontaktlisten

⚠️ EW_Anmeldung stand hier bis 01.08.2026 als „Anmeldungen" statt als Sperre.

Das ist die Tabelle, aus der man beim Bauen die IDs kopiert. Wer die fuenf fett

markierten nahm, bekam einen Pool von 1.677 statt 1.574 — also **103 Menschen,

die bereits fuer den 04.08. eingetragen sind**, haetten „Du warst leider nicht dabei,

melde Dich an" bekommen. Zum Vergleich: die Falle, vor der Station 5 ausdruecklich

warnt (AW_Optout vergessen), kostet eine Person. Diese kostete 103, und es gab

keine Warnung.

Superchat-Workflows (GET /v1/workflow-file-nodes?type=WORKFLOW)

⚠️ Die Route braucht zwingend ?type=WORKFLOW. Ohne den Parameter antwortet sie

200 mit leerem Array, und man haelt es fuer „es gibt keine Workflows". GET /v1/workflows

und /v2/workflows sind 410 Gone. Ein Kaltstart-Pruefer ist am 01.08.2026 genau

darueber gestolpert und kam an Station 7 nicht weiter.

Zapier (Ordner Superchat, 0195b328-ea70-bb9c-cd10-96b7370d5da9)

Webinare, beide braucht man:

⚠️ Die Quell-ID fehlte hier bis 01.08.2026 komplett. Ein falsches webinar= liefert

still eine falsche Kohorte, und das merkt man erst, wenn 1.800 falsche Menschen

angeschrieben sind.

⚠️ Es ist ein EverWebinar, wird aber ueber die WebinarJam-Zapier-App

eingetragen. Das verwirrt zuverlaessig, ist aber richtig so.

Zugaenge: liegen in ClientShare, nicht in dieser Datei und nicht im Chat.

Hinterlegt sind Superchat (API-Key, Mail, Passwort) und WebinarJam (Mail, Passwort).

⚠️ WIDERLEGT 01.08.2026: clientshare secrets --kunde domi gibt es NICHT. Die CLI

kennt nur publish|new|ls|rm|mv|versions|rollback|redirect. Der Lesezugriff laeuft ueber

die Management-API (/_api/kunden/<kunde>/vars) und braucht einen Bearer-Key, oder ueber

das Cockpit im Browser. Der falsche Befehl stand hier genau an der Stelle, an der man

unter Zeitdruck ist.

---

Die zwei Ansichten dieses Wissens

Die Seite wird aus dieser Datei erzeugt, nicht gepflegt:

python3 render-doku.py && clientshare publish /tmp/carmen-doku --kunde domi --slug carmen-runbook

⚠️ Wer die HTML-Seite direkt bearbeitet, verliert es beim naechsten Rendern.

---

Werkzeuge

⚠️ Vorbedingung fuer scapi.mjs, sonst passiert gar nichts: es zieht den Bearer aus

dem Mitschnitt des Browsers arc-bene. Dafuer muss (a) der Recorder laufen

(cdp_capture.py --port 9280 --name arc-bene) und (b) in Arc eine Superchat-Sitzung

offen sein. Der Bearer lebt nur rund 143 Minuten, der Refresh-Weg ist seit 25.06.2026

tot. Wer morgens weiterarbeitet, braucht zuerst eine frische Sitzung. Ohne das meldet

das Skript einen Fehler, der leicht als „Superchat ist kaputt" fehlgedeutet wird.

⚠️ wa.py senden nimmt den Text als FLAG, nicht als zweites Argument. Die frueher

hier stehende Form wa.py senden "<Name>" "<Text>" schlaegt fehl. Zusaetzlich verlangt

es --wirklich-senden. Immer wa.py senden -h gegenlesen.

⚠️ bxwj.mjs ist NICHT das WebinarJam-Werkzeug fuer diesen Kunden — es haengt fest

an Port 9257. Der Name legt etwas anderes nahe und hat schon Zeit gekostet.

Die Detail-Dokumentation liegt woanders und wird hier gebraucht:

---

⭐ Der automatische Betrieb (seit 02.08.2026)

**Bis zum 01.08. war jeder Batch Handarbeit. Seit dem 02.08. laeuft der Takt ohne

Menschen — und ohne Chat-Sitzung.** Wer den Ablauf kennenlernen will, liest die

Stationen unten; wer ihn BETREIBT, braucht diesen Abschnitt.

Die Werkzeuge und wie sie ineinandergreifen

batches-anlegen.py → daten/batch-plan.json → takt-einrichten.sh

↓ launchd

batch-feuern.py <nr> --senden

↓

lauf-beobachten.py (launchd, alle 14 min) → daten/lauf-protokoll.jsonl

↓

dashboard-bauen.py → ClientShare

Ein kompletter Lauf, in Befehlen

python3 batches-anlegen.py # zeigen, was entstuende

python3 batches-anlegen.py --anlegen # Entwuerfe in Superchat anlegen

./takt-einrichten.sh # zeigen, welche Wecker entstuenden

./takt-einrichten.sh --setzen # Wecker laden — ab hier laeuft es allein

python3 selbsttest.py # alle Sicherungen pruefen (nur eigene Nummern)

⛔ selbsttest.py VOR dem ersten scharfen Batch laufen lassen. Am 02.08.2026

hat die Vorab-Pruefung „alles sauber" gemeldet, obwohl der Empfaenger abgemeldet

war (FEHLERLOG F-01). Sie sah nur deshalb richtig aus, weil niemand sie geprueft

hatte. Eine ungetestete Sicherung ist keine Sicherung, sondern eine Attrappe.

Was der Wecker bei jedem Batch prueft

⚠️ Gestoppt wird ausschliesslich bei ROT. Hier stand kurzzeitig auch eine

Regel auf die Fehlzustellung („Fruehindikator") — die war **erfunden und nicht

gemessen** und wurde entfernt. Eine Abbruchregel auf einer unbelegten Annahme

stoppt entweder grundlos oder wiegt in falscher Sicherheit.

Benachrichtigung

ntfy-App, Server https://ntfy.benediktglass.com, Topic carmen-lauf-83acea.

Bei einem Not-Aus kommt die Meldung mit Prioritaet urgent aufs Handy, zusaetzlich

Systemmeldung am Mac und ein rotes Banner oben im Dashboard.

Im Notfall

launchctl list | grep carmen # laeuft alles?

./takt-einrichten.sh --loeschen # LAUF STOPPEN

./takt-einrichten.sh --setzen # fortsetzen …

rm daten/ALARM.json # … und den Alarm quittieren

python3 batch-feuern.py <nr> # einen Batch pruefen, ohne Versand

python3 batch-feuern.py <nr> --senden # einen Batch von Hand senden

cat /tmp/carmen-batch-<nr>.log # Protokoll eines Batches

cat /tmp/carmen-beobachter.log # Protokoll des Beobachters

⚠️ Zum Fortsetzen braucht es bewusst zwei Handgriffe (Wecker setzen UND Alarm

loeschen). Ein Not-Aus, der sich selbst zurueckstellt, waere keiner.

Zwei Fallen, die den ganzen Betrieb lahmlegen koennen

⛔ launchd startet mit einem minimalen PATH. node liegt unter

/opt/homebrew/bin und ist dort nicht auffindbar. Alle Skripte rufen es

deshalb absolut auf, und die Wecker bringen ein eigenes PATH mit. Real passiert

am 02.08.: der Wecker feuerte puenktlich und starb sofort, im Terminal lief

derselbe Befehl einwandfrei (F-02). **Jeder neue Wecker muss EINMAL unter launchd

gelaufen und sein Protokoll gelesen worden sein.**

⛔ Nichts Betriebsrelevantes an einer Chat-Sitzung haengen lassen. Der

Beobachter lief zuerst als nohup aus einem Chat — waere der geschlossen worden,

haette niemand mehr gemessen, und das Dashboard waere eingefroren, **ohne das

anzuzeigen**. Er ist jetzt ein LaunchAgent mit KeepAlive (F-10).

---

Station 1 · Zielgruppe aus WebinarJam holen

• Session-IDs besorgen. ⚠️ **GET /analytics/webinarSchedules?webinar=<id> ist so

NICHT reproduzierbar** (Kaltstart-Test 01.08.2026: sechs Varianten aus dem

Seiten-Kontext von :9262, mit und ohne x-requested-with, jedes Mal HTTP 200 mit

Redirect auf /home statt JSON). Es ist kein Sitzungsproblem, derselbe Tab

rendert die Registranten-Tabelle. Was fehlt, ist ungeklaert; CSRF-Header und ein

abweichender Parametername sind nicht ausgeschlossen.

Verlaesslicher Weg: die IDs stehen in der URL der Registranten-Ansicht

(webinar=67&schedule=644 fuer den Lauf vom 30.06.2026). Ablesen statt abfragen.

• In der Oberflaeche my-registrants: Webinar, Session, **Live room behavior =

„Did not attend live session", Replay room behavior = „Did not attend replay room"**.

• Export → „Export the currently selected filters", Fenster offen lassen

(serverseitig, bis 60 s). Datei landet mit Zufallsnamen in ~/Downloads.

Verifikation: Zeilenzahl der CSV muss dem total aus

GET /my-registrants/filter?webinar=&schedule=&attendedLive=2&attendedReplay=2 entsprechen.

Am 01.08.2026: 2.844 = 2.844 ✅

⚠️ Nicht per API durchblaettern. Die Tabelle laedt in 25er-Seiten; wer zusaetzlich

selbst blaettert, loest ein Cloudflare-Rate-Limit aus (HTTP 429, Error 1015, hielt

ueber 10 Minuten). Der Export-Knopf ist der richtige Weg.

---

Station 2 · Liste bereinigen

Aus dem Export entfernen:

Nummern normalisieren: fuehrende 0 nach der Laendervorwahl streichen. ⚠️ Und die

kaputte +1-Vorwahl heilen: WebinarJam liefert deutsche Nummern teils als

+1 49… (305 Faelle am 01.08.). Wenn Vorwahl 1 und die Nummer mit 49/43/41

beginnt, ist die echte Vorwahl die ersten zwei Ziffern der Nummer.

Import-CSV mit genau vier Spalten, Semikolon-getrennt:

Vorname;Nachname;Telefon;E-Mail

---

Station 3 · Listen anlegen

Pro Lauf vier Listen (POST /v1/contact-lists, Body {name, description, contactIds:[]}):

---

Station 4 · Import

POST /v2/contact-uploads

{"encoding":"UTF-8","delimiter":";","hasHeaderCells":true,

"contactListId":"<cl_ der Kohorte>",

"mappings":[{"type":"MAPPED_COLUMN","attribute":{"id":"builtin-firstName","name":"Vorname","type":"BUILTIN"}},

{"type":"MAPPED_COLUMN","attribute":{"id":"builtin-lastName","name":"Nachname","type":"BUILTIN"}},

{"type":"MAPPED_COLUMN","attribute":{"id":"builtin-phone","name":"Telefon","type":"BUILTIN"}},

{"type":"MAPPED_COLUMN","attribute":{"id":"builtin-mail","name":"E-Mail","type":"BUILTIN"}}]}

→ {"contactUploadId":"cu_…"}

POST /v2/contact-uploads/<cu_>/csv multipart, Feldname "file"

⚠️ Der Import laeuft ASYNCHRON. GET /v2/contact-uploads/<cu_> gibt 404, das ist

kein Fehler. Status steht in der Liste: GET /v2/contact-uploads → PENDING → DONE.

Am 01.08. dauerte er fuer 1.871 Zeilen etwa 25 Minuten.

⚠️ Verifikation, und „Liste zaehlen" reicht dafuer NICHT.

Der Import verwirft still Zeilen. Gemessen am 01.08.2026: 1.871 Zeilen in der CSV,

1.785 Kontakte in der Liste. Aufgeschluesselt durch Abgleich der Nummern:

Es sind keine Dubletten: die 1.871 Nummern sind sowohl nach einfacher als auch

nach strenger Normalisierung (Trunk-Null nach der Laendervorwahl) eindeutig — gepruefte

und widerlegte Hypothese. Superchat wirft die Zeilen bei seiner eigenen

Nummernpruefung weg und meldet das nirgends.

Deshalb: nach dem Import die Nummern der CSV gegen den Bestand abgleichen, nicht

nur die Liste zaehlen. Ein Verlust um 5 % ist normal; ein Verlust um 30 % heisst,

dass die Bereinigung in Station 2 etwas falsch macht — und ohne diesen Abgleich

sieht beides gleich aus.

---

Station 5 · Arbeits-Filter anlegen

Gespeicherte Filter heissen intern contact-views (POST /v1/contact-views,

Body {name, filter, pinned:true, visibility:"PRIVATE"}). Drei Stueck:

⚠️ Die Umschreibung „nicht in Sperren, gesendet, zu_senden" stand hier bis 01.08.2026

und laesst sich als „nicht in Sperren, ABER in gesendet und zu_senden" lesen. Gemeint

war immer „in keiner dieser Listen". Genau so ein Satz wird nachts falsch herum gebaut.

**⭐ Das Feld filter ist eine eigene Mini-Query-Sprache. Ohne diese Zeile kann niemand

den Filter bauen** (fehlte hier komplett, obwohl an zwei Stellen gebraucht: hier und als

filterQuery der Kampagne in Station 6):

and(

containsAll(contactListIds,[<Kohorte>,<zu_senden>]),

not(containsAny(contactListIds,[<Sperre1>,…,<Sperre6>,<gesendet>]))

)

Real gelaufen am 01.08.2026 (Kampagne cp_uexwxYwJBpBvLc3nKKSvT, Batch 02), in einer Zeile:

and(containsAll(contactListIds,[cl_IKgNIECJ0aZM88a01FwHj,cl_5GTatu9ROxvYg4StuUIfb]),not(containsAny(contactListIds,[cl_Ud85EpLOJ9sH124cwpHPN,cl_d2FFMkdAwKtjSukmQurTF,cl_S60u79592V4UeykKb05Md,cl_w8MxyooN31biL4qIGhLU6,cl_81meqYaFUXBmgdWfRcV0T,cl_wB1rUZGwR0eYGS5ZNLmJ3,cl_Vb0sN8sQ5aEDwSBwB2NI8])))

⚠️ Es sind SIEBEN ausgeschlossene Listen, nicht sechs: die sechs Sperren plus

die gesendet-Liste. Wer nach dem Merksatz „alle sechs" baut, schreibt bereits

Angeschriebene erneut an.

⚠️ GET /v1/contact-views liefert in der Listen-Antwort filter: null. Den echten

Ausdruck bekommt man nur ueber den Einzel-GET auf ctv_….

Die sechs Sperrlisten (im Filter kommt als SIEBTE die gesendet-Liste dazu, siehe oben):

Whatsapp OptOut · AW_Optout · Kein Optin · NUMMER NICHT MEHR KONTAKTIEREN ·

Kontakt nicht auf Whatsapp · EW_Anmeldung (<Zieldatum>)

⭐ Verifikation, und die ist NICHT optional:

python3 pool-gegenrechnen.py --batch

Das Skript zaehlt den Pool aus den rohen Kontaktdaten, **ohne die filterQuery

anzufassen**. Danach die Zahl mit validation.audienceContactsCount der Kampagne

vergleichen. Sie muessen uebereinstimmen.

⚠️ Warum das der wichtigste Check im ganzen Runbook ist: Filter und Kampagne

benutzen dieselbe filterQuery. Wer der Zahl in der Kampagne glaubt, glaubt dem

Filter, den er gerade selbst geschrieben hat. Ein Tippfehler in einer Listen-ID

faellt so nicht auf, und die Folge ist, dass Abgemeldete Werbung bekommen. Zwei

unabhaengige Wege zur selben Zahl sind der einzige Schutz.

Gemessen am 01.08.2026: Skript 1.574, Kampagne 1.574. ✅

⚠️ WIDERLEGT 01.08.2026: Whatsapp OptOut und AW_Optout sind NICHT disjunkt.

Hier stand „vollstaendig disjunkt, null Ueberschneidung" (und davor die alten Zahlen

39/109 ohne Datum). Live gemessen: 65 bzw. 134 Personen, 25 davon auf beiden Listen.

Das ist kein Fehler, sondern Folge des Abmelde-Zaps aus Station 9, der bewusst in

beide Listen schreibt. Die Aussage war schon in dem Moment veraltet, in dem sie

geschrieben wurde.

Praktisch bleibt es gleich: immer BEIDE ausschliessen. Wer nur eine nimmt, laesst

je nach Liste 40 bis 109 Abgemeldete durch. Wer nur eine davon ausschliesst, schreibt Opt-outs an.

---

Station 6 · Batch bilden und senden

• Kontakte des Batches in AW_NT_zu_senden:

```

PATCH /v1/contacts

{"contactIds":[…max 50…],

"changes":[{"operation":"ADD","changeType":"CONTACT_LIST","contactListIds":["<zu_senden>"]}]}

```

⭐ **Die Schreibform des PUT (kartiert 02.08.2026). Zwei Feldnamen unterscheiden

sich zwischen Lesen und Schreiben — daran scheitert jeder Versuch, der es raet:**

{"name":"…",

"audience":{"filterQuery":"and(containsAll(…),not(containsAny(…)))","type":"DYNAMIC"},

"channelId":"mc_…",

"content":{"templateId":"tn_…","templateHeaderFileId":null,"wildcardValues":null},

"scheduling":{"type":"SCHEDULED","value":"2026-08-03T07:13:19Z","timezone":"Europe/Berlin"}}

⚠️ PUT ERSETZT. Wer nur name schickt, loescht Kanal, Inhalt und Zeitplan.

⚠️ value ist UTC, timezone steht daneben. 09:13 Berlin = 07:13Z.

⚠️ Eine gesendete Kampagne ist gesperrt (409). PATCH gibt es nicht (405).

Loeschen geht ueber die API gar nicht (405) — nur in der Oberflaeche.

Wie das gefunden wurde: vier geratene content-Formen ergaben alle 400 ohne

Feldangabe. Die Antwort lag in einer Minute vor, nachdem der Vorgang einmal ueber

die Oberflaeche im CDP-Browser geklickt und der Mitschnitt gelesen wurde.

**Bei einem 400 ohne Feldangabe nicht weiterraten, sondern einmal klicken und

mitschneiden.**

• Kampagne aus der letzten duplizieren: POST /v5/campaigns/<cp_>/duplicate

⚠️ Welche ist „die letzte"? Es stehen rund 28 Kampagnen im Konto, darunter

mehrere Tests mit aehnlichem Namen. Die Vorlage des Laufs vom 01.08.2026 war

cp_uexwxYwJBpBvLc3nKKSvT („2026-08-04 - Webinareinladung V5 (Batch 02 - 24)").

Vor dem Duplizieren GET /v5/campaigns?size=30 und nach createdAt sortiert

die juengste ECHTE Kampagne nehmen, keine mit „TEST" im Namen.

⚠️ Beim Duplizieren wird die Audience auf leeres STATIC zurueckgesetzt und die

Conversion-Goals sind weg. Beides muss neu gesetzt werden (Schritte 3 und 4).

• PUT /v5/campaigns/<cp_> mit DYNAMIC-Audience (filterQuery = derselbe

Ausdruck wie im zu_senden-Filter), Kanal, Template, scheduling: IMMEDIATELY

• PUT /v5/campaigns/<cp_>/conversion-goal auf den Quick-Reply-Button
• Vor dem Senden: validation.audienceContactsCount muss der Batch-Groesse entsprechen
• POST /v5/campaigns/<cp_>/send (leerer Body, 204)

• Nach dem Versand: den Batch aus zu_senden entfernen.

```

PATCH /v1/contacts

{"contactIds":[…],"changes":[{"operation":"REMOVE","changeType":"CONTACT_LIST",

"contactListIds":["<zu_senden>"]}]}

```

⚠️ **Dieser Schritt fehlte hier bis 01.08.2026, und die Lage ist unangenehmer als

sie aussieht.** Die beiden Laeufe machen es unterschiedlich: AW_NT_zu_senden (09.06.)

enthaelt bis heute 1.153 Kontakte (nie geleert), AW_NT_zu_senden (30.06.) ist

leer (geleert). Beides funktioniert, aber sie sind unterschiedlich sicher:

• Nicht leeren (Juni): die Audience waechst mit jedem Batch. Der Zaehl-Check in

Schritt 5 faellt auf, wenn der gesendet-Zap kaputt ist, weil die Zahl dann zu gross ist.

• Leeren (aktuell): die Audience ist immer genau der neue Batch. Bequemer, aber

der Zaehl-Check ist blind gegen einen kaputten gesendet-Zap.

Wer leert, muss den gesendet-Zap deshalb separat pruefen (Station 7 Zeile 3), sonst

gibt es keine zweite Sicherung mehr.

Verifikation: GET /v5/campaigns/<cp_>/recipients → Status je Empfaenger.

⚠️ Das Feld recipients in /v5/campaigns ist unbrauchbar (steht oft auf 0).

Die echte Zahl liefert GET /v5/campaigns/<cp_>/funnel → total.

---

Station 6b · Der Reminder kurz vor dem Start (⚠️ fehlte hier komplett)

Das ist die einzige Nachricht des ganzen Ablaufs, die je einen LINK enthielt.

Sie ging am 09.06.2026 an 296 Menschen und hatte 33 Konversionen —

und stand bis 02.08.2026 in keiner Station dieses Runbooks. Wer das Runbook

abarbeitet, baut sie nicht, und es faellt nicht auf, weil kein Punkt fehlt.

Aufsetzen: duplizieren, Audience auf die neue Eingetragen-Liste,

scheduling: SCHEDULED auf drei Minuten vor Start.

⚠️ Und hier ist der Unterschied Live-Webinar gegen EverWebinar, nach dem

lange gesucht wurde. Beim Eintragen unterscheiden sich die beiden nicht:

derselbe Zapier-Konnektor, dieselbe Aktion, dieselben Felder webinar +

schedule, nur andere Werte. Auch der persoenliche Zugangslink ist bei beiden

gleich aufgebaut. Der Unterschied steckt allein in diesem Reminder:

Der Link darin ist kein persoenlicher, sondern ein generischer Channel-Link

(event.webinarjam.com/channel/aktien_workshop). Der gehoert fest zu

Live-Webinar 67 und zeigt heute auf …/ended/81p3ycy6hps0so —

81p3ycy6 ist genau dessen webinar_hash. Fuer das EverWebinar (Hash

2386ysl4) ist er tot. ⚠️ **Und „tot" heisst hier nicht Fehlermeldung, sondern

HTTP 200 auf eine „ist vorbei"-Seite.** Ein Link-Check auf den Status-Code

merkt davon nichts.

Warum ueberhaupt ein generischer Link: ein *persoenlicher* live_room_url

laesst sich nicht in die Vorlage schreiben, dafuer braeuchte die genehmigte

Meta-Vorlage eine URL-Variable (wildcardValues war in allen erfassten

Kampagnen null). Deshalb der Channel-Link.

⚠️ Ehrlich zur Ursache: dass der Reminder wegen des EverWebinar-Wechsels

entfiel, ist nicht belegt. Er fehlte schon beim Lauf am 30.06., und der war

noch live (67/644). Zwei andere Erklaerungen sind dokumentiert: Lauf II

wurde bei ~750 von 2.187 wegen der Meta-Qualitaetswarnung abgebrochen, und am

25.06. wurde von MARKETING- auf UTILITY-Vorlagen umgestellt — der Reminder ist

eine MARKETING-Vorlage. Belegt ist nur die Wirkung, nicht der Grund.

---

Station 7 · Die Kette dahinter (muss VOR dem ersten Batch stimmen)

⚠️ Diese Tabelle hat bis 01.08.2026 nur die Haelfte geprueft. Ein Kaltstart-Pruefer

hat drei Stellen belegt, an denen man alles abhaken konnte und die Kette trotzdem kaputt

war. Die Spalte „woran es scheitert" ist der eigentliche Inhalt.

⚠️ EW_Anmeldung ist keine Anmeldeliste im Wortsinn. Befuellt wird sie vom

dauerhaften Opt-in-Workflow (#5), nicht von AW_Automations. Sie ist damit eine

kumulierte Opt-in-Liste, keine Liste der fuer diesen Termin Angemeldeten. Der Vermerk

weiter unten („erfasst nur etwa die Haelfte") beschreibt das Symptom, aber die Ursache

ist eine andere als dort vermutet: es ist gar kein Anmelde-Mechanismus.

---

Station 8 · Abnahme-Test vor dem echten Versand

• Kampagne an zwei eigene Testnummern (STATIC-Audience).
• Über WhatsApp mit dem Button-Text antworten.
• Pruefen, alle vier:
• Superchat-Workflow-Lauf DONE
• Bestaetigungsnachricht kam an
• Zapier-Lauf success, WebinarJam-Schritt success
• Kontakt steht in der Anmelde-Liste, Anmeldung ist in WebinarJam sichtbar
• Danach Labels zuruecksetzen und wiederholen, bis alles vier Mal sitzt.

⛔ Und nach JEDER Aenderung an der Kette erneut testen, bevor der naechste Batch geht.

Das fehlte hier und ist im Lauf vom 01.08.2026 real schiefgegangen: der einzige

Konversionslauf (wr_wjbWvN46g87AlDPKuqjTG, 18:09 UTC) lief auf Workflow-Version

wfv_7NSBXNfk8vKXn5D5B5xC1. Live ging um 18:42 eine andere Version

(wfv_ivmG3KsxbAfqNUiU2oKKT). **Die produktiv laufende Version ist nie end-to-end

getestet worden.** „Vier Mal getestet" gilt fuer die getestete Version, nicht fuer die,

die danach veroeffentlicht wurde.

⚠️ Ebenfalls aus diesem Lauf, als Mahnung: die Batches 01 (6 Menschen, 18:20) und 02

(24 Menschen, 18:31) gingen raus, bevor Konversions-Workflow (18:42), Riegel (18:46)

und gesendet-Zap (18:53) fertig verdrahtet waren, und 75 Minuten bevor der

Abmelde-Zap ueberhaupt existierte (19:35). Die Reihenfolge-Regel ganz oben in diesem

Dokument wurde in genau dem Lauf gebrochen, fuer den sie geschrieben wurde. Sie steht

deshalb jetzt zusaetzlich hier, an der Stelle, an der man sie braucht.

---

Station 9 · Abmeldungen einsammeln (seit 01.08.2026 automatisch)

Superchats eingebaute Behandlung erkennt nur exakt STOPP. Real geschrieben wird

aber fast immer STOP mit einem P. Deshalb laeuft seit dem 01.08. ein eigener Zap.

Zap 374885742 „Abmeldung // Wortvarianten → Opt-out-Listen" (Ordner Superchat)

⚠️ Warum ein Zap und keine Superchat-Automation: eine Automation muesste bei

*jeder* eingehenden Nachricht anlaufen. Bei ~800 Antworten pro Lauf wird das teuer.

Der Zapier-Filter kostet keine Task, wenn er nicht zutrifft.

⚠️ Superchats eigene Dokumentation nennt dafuer eine Schlagwort-Funktion in den

Einstellungen. Die ist veraltet, Superchat verweist selbst auf Automations

(von Benedikt getestet, 01.08.2026).

Die vier Woerter sind gemessen, nicht geraten. Gegen den echten Bestand

(819 eingehende Nachrichten, Export siehe daten/export/) geprueft:

⚠️ WIDERLEGT 01.08.2026, und zwar durch mich selbst: „0 Fehlalarme" war falsch.

Hier stand zuerst „36 von 36, 0 Fehlalarme", dann „43 von 43, 0 Fehlalarme". Beides

entstand, weil ich Grenzfaelle von Hand aussortiert und danach trotzdem null

Fehlalarme gemeldet habe. Das ist zweierlei: „der Filter liefert keine Fehlalarme"

und „ich habe die Fehlalarme weggestrichen". Der Zap kann nicht von Hand aussortieren.

Die zwei Fehlalarme im Wortlaut (beide wuerden vom Zap ausgetragen):

> „Hallo Carmen Ich muss mich leider für heute abmelden. **Beim nächsten Mal bin ich

> gerne dabei**, wenn das geht." — Gudrun, 06.05.2025

> „STOPP habe vergessen das es Samstag ist und dann bin ich nicht da." — 01.07.2026

Beide heissen „diesmal nicht", nicht „schreib mich ab". Wer so schreibt, wird dauerhaft

ausgetragen und erfaehrt es nie.

Groessenordnung: 2 auf 1.234 eingehende Nachrichten, also rund 0,16 %.

Warum der Filter trotzdem so bleibt (bewusste Entscheidung, offen zur Revision):

Enger ziehen tauscht den harmlosen Fehler gegen den schaedlichen. Ein faelschlich

Ausgetragener kostet einen Lead. Eine faelschlich beworbene Abmeldung kostet Vertrauen

und ist rechtlich heikel. Die jetzige Richtung schuetzt den Empfaenger.

Wer es anders will, hat zwei Wege:

• In den Gruppen abmelden/abbestellen zusaetzlich „enthaelt nicht heute"

und „enthaelt nicht nächste" — faengt Gudrun, nicht den Samstag-Fall.

• Statt automatisch auszutragen eine Benachrichtigung ausloesen und einen Menschen

entscheiden lassen. Sauber, aber nicht mehr autonom.

⚠️ Keiner der beiden Fehlalarm-Kontakte wurde ausgetragen: Gudrun steht auf Kein Optin

(faellt ohnehin raus), der Samstag-Fall wurde beim Nachtragen von Hand ausgenommen.

Basis: 1.234 eingehende Nachrichten aus 1.779 Verlaeufen. Kontrollzahl mitzaehlen:

756 dieser Verlaeufe enthielten ueberhaupt eine Kontakt-Nachricht. Ohne diese Zahl

waere ein Auswertungsfehler als „0 Abmeldungen" durchgegangen (siehe letzter Abschnitt).

Der Unterschied sind Schreibweisen wie "Stopp" in Anfuehrungszeichen oder

STOP. mit Punkt. Tatsaechlich gefunden: ganz ueberwiegend STOP mit EINEM P, dazu Stop, Stopp,

"Stopp" in Anfuehrungszeichen und drei ausformulierte Abmeldungen.

Nachtrag 01.08.2026: die Nachlese ueber den vollstaendigen lokalen Export fand

43 statt der zunaechst gemeldeten 36. 34 davon waren bereits ausgetragen, 7 nicht —

die wurden nachgetragen und gegengelesen. Wer den Filter neu aufsetzt, prueft immer

gegen den GANZEN Export, nicht gegen die erste Teilmenge.

⚠️ Bekannte Schwaeche: Teilstring heisst, ein Wort wie „Stopschild" wuerde

ebenfalls anschlagen. Auf 819 echten Nachrichten ist das null Mal passiert, deshalb

bewusst so belassen. Wer es haerten will, braucht Wortgrenzen, und die kann

Zapiers Filter nicht. Dann Code-Step statt Filter.

Grenzfaelle bewusst NICHT ausgetragen: Nachrichten wie

STOPP habe vergessen das es Samstag ist… sind keine Abmeldung, sondern ein Zuruf.

Wer den Bestand nachtraeglich bereinigt, liest die Treffer einzeln, bevor er schreibt.

---

Station 10 · Test vor jedem echten Batch

Zwei eigene Nummern sind bei Unipile angebunden und duerfen beliebig oft

angeschrieben werden:

python3 ~/.claude/skills/whatsapp-melden/wa.py senden --text "<Text>" --wirklich-senden "<Name>"

⚠️ Der Text ist ein Flag, kein zweites Argument, und ohne --wirklich-senden

passiert nichts. Im Zweifel wa.py senden -h.

⛔ **Das Konto 4hMTWP2YS1iZQgG87JLPZA (+49 162 2859271) gehoert Danny Mittenzwey.

Niemals darueber senden.** wa.py hat dafuer eine Sperre (EIGENE_ACCOUNTS).

Nach jedem Test aufraeumen, sonst faelscht die Testnummer den naechsten Zaehlstand:

aus zu_senden und beiden Opt-out-Listen wieder entfernen

(PATCH /v1/contacts, operation:"REMOVE").

⛔ ABER NICHT aus der gesendet-Liste, solange die Testnummer in der Kohorte steht.

Hier stand bis 01.08.2026 „aus gesendet, zu_senden und beiden Opt-out-Listen

entfernen". Das ist eine Falle: der Testkontakt Bene -

(ct_yNEXuEydV0e0M92kre3nB) ist Mitglied von AW_NT (30.06.2026), also der echten

Kohorte. Er faellt heute nur deshalb nicht in den Live-Pool, weil er in

AW_NT_gesendet steht. Wer der alten Anweisung folgte, setzte die Testnummer in den

Produktions-Verteiler zurueck.

Richtig ist die Ursache zu beseitigen, nicht das Symptom:

• In Station 2 die eigenen Testnummern aus der Import-CSV entfernen. Sie haben in

der Kohorte nichts verloren. Diese Regel fehlte in der Bereinigungstabelle.

• Testkontakte, die schon drin sind, aus der Kohorte nehmen, nicht aus gesendet.
• Erst dann ist das Aufraeumen nach dem Test gefahrlos.

⚠️ Auch Bene2 - (ct_1gNOZTcJsRxGBdKf5GuJm) steht in mehreren AW_NT-Listen frueherer

Laeufe. Vor dem naechsten Lauf beide Testkontakte durchsehen.

---

Fallen-Index (alle am 01.08.2026 real passiert)

Fallen, die in 01-rekonstruktion / 02-befunde belegt sind und hier lange fehlten

Ergaenzt 01.08.2026 nach einem Kaltstart-Befund: wer nur dieses Runbook las, kannte

diese sechs nicht, obwohl sie real gefressen haben.

Zwei Zusammenhaenge, die man kennen muss

**Die Liste Kontakt nicht auf Whatsapp fuellt sich NUR, wenn der Sending-Failed-Zap

laeuft.** Fehlt der Zap, bleibt die Liste leer, alles sieht normal aus, und dieselben

toten Nummern werden jeden Monat neu beschossen. Genau das ist der Hauptverdaechtige

fuer eine sinkende Qualitaetsbewertung. Eine leere Sperrliste ist deshalb ein

Alarmzeichen, kein guter Zustand.

Kontaktlisten lassen sich ueber die API nicht loeschen (DELETE /v1/contact-lists/<cl_>

= 405, gemessen 01.08.2026). Vier neue Listen pro Lauf, zwoelf Laeufe im Jahr, mal die

Kundenzahl. Wer skaliert, braucht eine Namenskonvention, die das ertraegt, und muss

damit rechnen, dass alte Listen stehen bleiben.

Zaehlen (die einzige verlaessliche Methode)

GET /v4/contacts?size=1000&page=N durchblaettern und das Feld contactLists

je Kontakt auswerten. ⚠️ Ab etwa 13 schnellen Seiten kommt HTTP 429, deshalb

Pause zwischen den Seiten. Listen-Filter-Parameter auf /v3//v4/contacts

werden ignoriert (liefern immer die Gesamtzahl) und sind wertlos.

Offen (Stand 01.08.2026, 21:45)

• Rechtliche Grundlage: rund 91 % der Kohorte haben keinen dokumentierten

WhatsApp-Opt-in. Bewusste unternehmerische Entscheidung von Benedikt, hier nur vermerkt.

• Vorlage laeuft als UTILITY, obwohl es eine Einladung ist. Kein Abmelde-Button,

bewusst so (Benedikt: Abmelden soll nicht ein Klick sein).

⚠️ WIDERLEGT/erledigt 01.08.2026: hier stand „getipptes STOPP wird erkannt,

STOP mit einem P nicht" als offenes Problem. Das stimmt fuer Superchats

eingebaute Behandlung weiterhin, ist aber geloest durch den eigenen

Abmelde-Zap in Station 9 (36 von 36 Treffern, 0 Fehlalarme).

Wer diesen Absatz liest und Station 9 nicht kennt, baut die Loesung ein zweites Mal.

• EW_Anmeldung (04.08.) erfasst nur etwa die Haelfte der echten Anmeldungen.

Der Ausschluss „schon angemeldet" ist damit unvollstaendig; vollstaendig geht es

nur ueber die WebinarJam-Registrierungen.

---

⚠️ Nicht Teil des Ablaufs, aber gefunden: ein offener Datenkanal

TEST Automation - 25.06.2026, 14:12:48 (wffn_qqZMzxmWF2niBPAyzRNvf, angelegt von

Carmen Mayer selbst) steht auf ACTIVE und schickt per HTTP_REQUEST

CONTACT_FIRST_NAME, CONTACT_LAST_NAME und CONTACT_HANDLE (= die Telefonnummer)

an https://webhook.site/e398d880-…. Das ist ein oeffentlicher Endpunkt: wer die

Kennung hat, sieht die uebertragenen Daten.

Einordnung, damit niemand in Panik verfaellt: der Ausloeser ist MANUAL_TRIGGER und

numberOfRuns steht auf 0. Sie ist also nie gelaufen und feuert nicht von selbst.

Sie ist damit kein Doppelfeuer-Risiko fuer den Versand.

Trotzdem: ein aktiver Workflow, der Kundendaten an einen fremden oeffentlichen

Dienst sendet und den ein Klick ausloest, gehoert nicht in ein Produktivkonto.

⚠️ Nicht eigenmaechtig deaktivieren — er gehoert Carmen, nicht uns. Ansprechen und

sie oder Domi entscheiden lassen.

---

⚠️ DIE TEUERSTE FALLE: eine Null, die „falsch gemessen" heisst

Am 01.08.2026 ist dasselbe Muster vier Mal aufgetreten. Jedes Mal sah es aus wie

ein Befund, jedes Mal war es ein Messfehler.

Regel, die daraus folgt: Wer eine 0 bekommt, muss sie gegen einen Fall pruefen, der

garantiert NICHT 0 sein kann. Beispiele: eine Liste, von der man weiss dass sie voll ist;

ein Zap, den man selbst gerade ausgeloest hat; ein Verlauf, in dem man selbst geschrieben hat.

Erst wenn die Kontrolle anschlaegt, ist die 0 ein Ergebnis.

Zweite Regel: Auswertungen so bauen, dass sie die BASIS mitzaehlen, nicht nur die Treffer.

„0 Treffer aus 917 Verlaeufen" sieht gut aus. „0 Treffer, und 0 von 917 Verlaeufen enthielten

ueberhaupt eine Nachricht" entlarvt den Fehler sofort. Der Unterschied ist eine Zeile Code.

Feldnamen, die man leicht falsch raet

⚠️ Die Konversations-Liste und die Zeitleiste benutzen also UNTERSCHIEDLICHE

Absenderfelder. Wer den einen Namen vom anderen uebernimmt, bekommt still eine leere Menge.

---

Gerenderte Fassung. Die gepflegte Quelle liegt im Kundenordner als 03-runbook-reaktivierung.md. Aenderungen dort machen, nicht hier.
Kennzahlen zum laufenden Versand: Dashboard