Erste Hilfe¶
Hier findest du in einem Klick zur Lösung — sortiert nach Symptom, nicht nach Workflow.
💡 Faustregel: Erst hier schauen → wenn du nicht innerhalb von 5 Minuten weißt, was zu tun ist, Susi direkt anschreiben (Slack-DM). Du kannst auch jederzeit Claude konsultieren — siehe unten.
Was siehst du gerade?¶
„MOKI hat heute (oder seit dem letzten erwarteten Lauf) keine Internal Notes geschrieben"¶
Wichtig zu wissen: MOKI Dispatcher läuft scheduled, einmal täglich — nicht real-time pro Ticket. Es ist also normal, dass ein gerade reingekommenes Ticket noch keine Internal Note hat. Verdächtig ist erst, wenn nach dem nächsten erwarteten Lauf alle offenen Tickets noch ohne Internal Note sind.
Wahrscheinlich: Der Cron-Lauf ist gestört oder ein vorgelagerter Service (PlentyOne-Auth, Claude-API) hat versagt.
- Schau in n8n → MOKI Dispatcher v2 → Executions → wann lief der letzte Run? Hat er „Success" oder „Failed"?
- Wenn „Failed": klick rein, schau welcher Node explodiert ist → Screenshot machen.
- Im Sheet Ticket Log v2 schauen: hat der heutige Lauf überhaupt Zeilen geschrieben?
- Wenn unklar: Susi direkt anschreiben (Slack-DM) mit Screenshot der Failed Execution + Zeitpunkt.
→ Workflow-Karte: MOKI Dispatcher v2
„Ein einzelnes Ticket hat keine Internal Note, andere schon"¶
Wahrscheinlich: Absender steht nicht auf der Whitelist (Beta-Rollout) — MOKI ignoriert das Ticket bewusst.
- Schau im Sheet Ticket Log v2 nach der Ticket-ID → wenn nicht vorhanden, hat MOKI das Ticket nicht verarbeitet.
- Frag Susi, ob die Whitelist erweitert werden soll.
- Bis dahin: Ticket manuell bearbeiten wie alle anderen außerhalb der Whitelist.
„PlentyOne-Lookup schlägt mit 401 / 403 fehl"¶
Wahrscheinlich: Der n8n-api-User in PlentyOne ist gesperrt (Login-Lock).
→ Folge dem Runbook: PlentyOne Login entsperren.
„Tracking-Status / Sendungsstatus wird im Ticket nicht angezeigt"¶
Wahrscheinlich: orderData: null ist beim Sub-Workflow angekommen — er konnte den Auftrag nicht finden.
- Im Sheet Ticket Log v2 schauen:
sub_reason=not_found? - Wenn ja: Plenty hat den Auftrag nicht — entweder noch nicht angelegt, oder der Lookup hat die Bestellnummer nicht gefunden (Marketplace-Forwarder, XXXLutz, etc.).
- Manuell die Bestellnummer im Plenty suchen → wenn gefunden, Susi pingen (Lookup-Pattern muss erweitert werden).
→ Workflow-Karten: SUB PlentyOne Lookup, SUB Sendungsstatus
„Im Ticket Log v2 steht überall Sub Action: no_op für Portalverweis"¶
Wahrscheinlich: SUB Portalverweis hat noch das alte Output-Format. Bekannter Bug, Susi arbeitet dran.
→ Tagging im Ticket trotzdem manuell prüfen — Status im Sheet ist nicht zuverlässig für diesen Sub.
„Auto-Retoure aus Amazon-RSA enthält kein Hermes-Tracking"¶
Erwartet, kein Bug. Hermes-Tracking ist in Phase 1 noch nicht angebunden — kommt in Phase 2.
Im Ticket Log v2 steht in dem Fall sub_action: retoure_amazon_rsa_skipped_hermes.
→ Tracking manuell aus Amazon-RSA kopieren und ins Plenty-Retourenfeld eintragen.
→ Workflow-Karte: SUB Retoure, Glossar Hermes Phase 2
„Amazon-RSA-Mail kam rein, aber keine Plenty-Retoure wurde angelegt"¶
Wahrscheinlich ist einer von vier Skip-Pfaden gegriffen:
- Im Sheet Ticket Log v2 den Ticket-ID suchen →
sub_action-Spalte lesen:…skipped_already_marked→ Hauptauftrag hatte schon einen Idempotency-Marker. Doppellauf, kein Bug.…skipped_existing→ Hauptauftrag hatte bereits eine Retoure.…skipped_no_sku→ Keine bekannte mokebo-SKU in der Mail. Manuell anlegen.…skipped_unknown_carrier→ Carrier in Mail nicht erkennbar (oder Hermes Phase 1).…failed_no_parent→ Hauptauftrag nicht in Plenty. Susi anschreiben.…failed_create→ Plenty-POST scheiterte. Susi anschreiben mit Failed Execution-Screenshot.
- → Workflow-Karte: SUB Retoure
„Kunde bekommt mehrfach den Portalverweis-Link"¶
Wahrscheinlich funktioniert der Loop-Schutz (Tag portalverweis-gesendet) nicht — das Tag wurde nicht gesetzt oder bei der nächsten Mail nicht gelesen.
- Im Ticket: schau in die Tags-Liste. Ist
portalverweis-gesendetda? - Wenn nein: SUB Retoure hat das Tag nicht gesetzt → Susi anschreiben.
- Wenn ja: SUB Retoure liest es nicht korrekt → Susi anschreiben.
→ Workflow-Karte: SUB Retoure, Sektion „Bekannte Stolpersteine".
„Ein Workflow zeigt in n8n rote Fehler-Marker"¶
- n8n öffnen → Workflow → Tab Executions → Filter „Failed".
- Auf den fehlgeschlagenen Run klicken → linke Spalte zeigt den Node, der explodiert ist.
- Screenshot machen + im Ticket Log nach Auswirkung schauen.
- Susi pingen mit: Workflow-Name, Execution-ID, Screenshot, Zeitpunkt, ggf. betroffene Ticket-IDs.
„8returns Reconciliation: Status passt nicht"¶
→ TBD — Karte wird in den nächsten Tagen ergänzt. Bis dahin: Susi pingen.
„Ich weiß nicht, welche Automation für meinen Fall zuständig ist"¶
- Status-Dashboard öffnen → Spalte „Was tut der Workflow" überfliegen.
- Suche oben rechts → Stichwort tippen (z.B. „Retoure", „Rechnung", „Sendung").
- Wenn nichts passt → vermutlich noch nicht automatisiert. Susi pingen mit „kann ich diesen Fall automatisieren?".
Wenn alles brennt¶
Mehrere Workflows gleichzeitig kaputt (Ticket-Stau, Plenty-Lookup-401, Sheet-Updates fehlen) → wahrscheinlich PlentyOne ist down oder der n8n-api-User ist gesperrt.
- Trigger den Stack Heartbeat manuell (er läuft nicht scheduled — du musst auf „Execute Workflow" klicken). Der Heartbeat pingt alle Systeme einmal durch und zeigt dir, was kaputt ist.
- Wenn der Heartbeat bei PlentyOne / n8n-Auth scheitert → Runbook PlentyOne Login entsperren.
- Wenn der Heartbeat sauber durchgeht: einzelne Workflows haben verschiedene Probleme → Susi direkt anschreiben (Slack-DM).
Susi nicht erreichbar? → CS-Lead pingen, parallel Tickets in Zendesk-Hold setzen, NICHT manuell ohne Plenty-Sync antworten (führt zu Daten-Drift).
Mit Claude debuggen — du darfst und sollst!¶
Wenn dir ein Symptom unklar ist und Susi nicht sofort verfügbar:
- Öffne Claude (Web oder Desktop).
- Schick die URL der relevanten Workflow-Karte von dieser Doku-Site (z.B.
https://…/workflows/moki-dispatcher-v2/). - Beschreib das Symptom in einem Satz + ggf. Screenshot.
- Claude liest die Karte mit allen Stolpersteinen und Debug-Anleitungen → kann oft sofort eine sinnvolle Hypothese liefern.
Du wirst dadurch nichts kaputt machen — Claude kann nur lesen und Vorschläge machen, nicht direkt Workflows ändern. Erst recht keine Sorge: jede Änderung läuft am Ende über Susi.