MOKI Dispatcher v2¶

Wird vom DAILY mokebo-ops Sync automatisch befüllt — bitte nicht manuell editieren.

Status: — Letzter Erfolgs-Run: — Erfolgsquote 7d: — Trigger: — Node-Count: —

🟢 Auf einen Blick¶


Was tut der Workflow	KI-gestützter Triage-Dispatcher für Zendesk-Tickets — läuft einmal täglich, klassifiziert Intent, ruft passenden Sub-Workflow auf, schreibt Internal Notes mit Diagnose und Antwort-Vorschlag.
Wann greift er	Scheduled (Cron, einmal täglich) — er holt die Tickets der letzten 24h auf der Whitelist (Beta-Rollout) und arbeitet sie in einem Lauf ab. Nicht real-time pro Ticket.
Sichtbarer Effekt für CS	Pro Ticket eine Internal Note mit Intent-Klassifikation + Antwort-Vorschlag im Draft. Bei Miss / unklarem Intent: Ticket landet im CS-Hold. (Macros werden aktuell noch nicht in Zendesk gesetzt — das `sub_macro_id`-Feld im Output ist Vorbereitung für später.)
Symptom wenn kaputt	Heute morgen / nach dem letzten erwarteten Run keine neuen Internal Notes vom Dispatcher in den Tickets, obwohl welche reingekommen sind. Oder: Note kommt, aber `lookup_error` / „no intent matched" steht drin.
Owner	Susi (Backup: TBD)
Eskalation	Susi direkt anschreiben (Slack-DM). Ticket-ID + Screenshot der Internal Note mitschicken.
Link in n8n	MOKI Dispatcher v2

Architektur¶

flowchart TB
  Cron[Cron Trigger
1× täglich 7:00] --> Fetch[Fetch Tickets
letzte 24h]
  Fetch --> Config[Read MOKI Config
Google Sheet]
  Config --> ETD[Extract Ticket Data
pro Ticket]
  ETD --> Pre{Pre-Noise
Patterns?}
  Pre -- ja --> Skip[Set: skipped]
  Pre -- nein --> SUB1["Call SUB PlentyOne Lookup"]
  SUB1 --> IF1{lookup_status
== found?}
  IF1 -- ja --> SUB2["Call SUB Sendungsstatus"]
  IF1 -- nein --> SUB3["Call SUB CS Hold"]
  SUB2 --> Merge[Merge Branches]
  SUB3 --> Merge
  Merge --> Intent[Intent-Klassifikation
Claude API]
  Intent --> Routing[Routing Decision
Code-Node]
  Routing --> Switch{Route Switch}
  Switch -- sub_retoure --> SubRet["Call SUB Retoure"]
  Switch -- sub_portalverweis --> SubP["Call SUB Portalverweis"]
  Switch -- sub_rechnung --> SubR["Call SUB Rechnung"]
  Switch -- sub_cs_hold --> SubH["Call SUB CS Hold"]
  SubRet --> Log[Build Log Row → Sheet]
  SubP --> Log
  SubR --> Log
  SubH --> Log

Subworkflow-Calls¶

Auto-generiert aus den executeWorkflow-Nodes — bitte nicht manuell editieren.

SUB PlentyOne Lookup — Lookup von Bestelldaten via Plenty
SUB Sendungsstatus — Tracking-Lookup
SUB Retoure — Amazon-RSA Auto-Anlage + Portalverweis (live ab 13.05.2026)
SUB Rechnung — Rechnungs-Generierung / -Versand
SUB Portalverweis — Standalone (legacy, wird durch SUB Retoure abgelöst)
SUB CS Hold — Eskalation an CS-Mensch

Trigger & Datenfluss¶

Trigger: Cron, einmal täglich. (Kein Webhook, keine Real-time-Verarbeitung — Tickets werden in Tagesblöcken abgearbeitet.)
Daten rein: Pro Ticket: Ticket-ID, Subject, Body, Requester-Email, Tags.
Daten raus:
Internal Note in Zendesk (pro Ticket).
Optional: gedraftete Antwort.
Log-Row in Sheet Ticket Log v2 (1bB1ZK21M1-sRGsqgcAFoWMNxL9ZnkJrm5R1b5Nm7chg, gid 59404923) — eine Zeile pro Ticket mit ticketId, intent, sub_action, sub_status, sub_reason, sub_macro_id, sub_message.
Hinweis: sub_macro_id ist im Output-Schema vorbereitet, aber Macros werden aktuell nicht in Zendesk gesetzt.

Bekannte Stolpersteine / Edge-Cases¶

lookup_status: not_found darf nicht in Sendungsstatus laufen — sonst NPE auf orderData: null. Lösung: IF-Routing nach SUB PlentyOne Lookup, bei not_found direkt zu SUB CS Hold (siehe handover.md Schritt 1).
Marketplace-Forwarder-Mails (z.B. marketplace@…, donotreply@…) dürfen NICHT als Email-Lookup-Strategie genutzt werden — sonst falsche Customer-Matches. Siehe SUB PlentyOne Lookup, Lookup Strategie-Code.
XXXLutz-Bestellnummern ab 5xxx… werden vom aktuellen Regex (/517\d{10}(-[A-Z])?/g) nicht erkannt. Pattern muss erweitert werden — Susi liefert echte Beispiele.
Plenty externalOrderId-Lookup für Amazon-Order 370637 schlägt fehl — Filter typeId === 1 && statusId !== 8 in Validierung extern evtl. zu eng. Investigation offen.

Debug-Anleitung¶

Für CS-Agent (zusammen mit Claude) und Susi.

Erste Anlaufstelle: n8n → Executions → Filter „Failed".
Im Sheet Ticket Log v2 das Ticket finden (ticketId-Spalte) → sub_status und sub_reason anschauen.
Häufigste Fail-Modes:
- lookup_error: not_found + Email war Marketplace-Forwarder → Pattern-Match-Frage, kein echter Bug.
- orderData: null durch SUB Sendungsstatus → IF-Routing-Bug (siehe Stolperstein 1).
- 401 vom PlentyOne-Login → Login-Lock, siehe Runbook.
Letzter Ausweg: Susi direkt anschreiben (Slack-DM). Mitschicken: Ticket-ID, Screenshot der Failed Execution, ggf. Sheet-Row.

Du darfst auch jederzeit Claude konsultieren — siehe FAQ: Was schicke ich Claude…. Claude liest die Workflow-Karte mit allen Stolpersteinen und kann oft schnell eine Diagnose-Hypothese liefern.

Entscheidungen / Geschichte¶

2026-05-12: Routing-Erweiterung: Read MOKI Config (Google Sheet 1bB1ZK21M1…, Tab MOKI Config) + Routing Decision Code-Node + Route Switch mit neuem sub_retoure-Output. Neuer Node Call 'SUB Retoure' eingebunden. Live ab 13.05.2026.
2026-05-06: Plenty-Token-Lookup Bug gefixt (Login-Lock — siehe Reference: Auth-Patterns).
2026-05-06: Entscheidung: SUB Sendungsstatus null-safe NICHT im Sub fixen, sondern Parent routet bei lookup_status: not_found direkt zu SUB CS Hold (Option B).
(älter): Whitelist-Rollout statt Big-Bang.