Zum Inhalt

MOKI Prompt v04 + Parse-Fallback-Härtung

Was

Drei chirurgische Patches am MOKI-Stufe-1-Prompt (v03 → v04) plus ein Workflow-Patch am Code-Node Parse LLM Output.

Prompt v04 (Patches im <edge_cases>-Block): 1. Marketplace-Notification mit substanzlosem Customer-Body ("Vielen Dank", "okay", "Danke für die Rückerstattung") → auto_noise statt eskalation. 2. native_messaging-Tickets mit Body Conversation with Web User <hash> (Regex-Match) → auto_noise statt eskalation — Regel war in v03 implizit, ist jetzt explizit + regex-präzise. 3. Bol.com Klantvraag-Mail ohne extrahierbaren Customer-Freitext → auto_noise mit Verweis auf Bol Partner Portal, statt eskalation als Sprach-Cop-Out. 4. Plus 3 neue Beispiele (10026 Amazon-Floskel, 10027 native_messaging Web User, 10028 Bol Klantvraag-Reactie) zur Verstärkung.

Workflow-Patch (Parse LLM Output Code-Node): 1. Aggressiverer JSON-Repair-Retry (Code-Fences, trailing commas, single-quote-Heuristik) vor dem Fallback. 2. Fallback auf auto_noise + needs_cs_attention=true (statt eskalation). So bleibt der Eskalations-Bucket sauber, das Ticket bleibt aber via needs_cs_attention auf CS-Radar. 3. Neuer Output-Counter parse_attempts für Debug.

Warum

Analyse von Moki Agent Log (8).xlsx (May 11, 1.222 Rows) am 13.05.2026 hat 15 aktuelle MOKI-Eskalations in 18 Tagen (≈ 0,83/Tag) gezeigt — davon ~7 in 3 erkennbaren Misklassifikations-Mustern, plus 1 Workflow-Bug (R179 Möwe Immobilien Rechnung, "JSON konnte nicht geparst werden" → forced eskalation).

Ursprünglicher Auftrag war "neuer Sub-Workflow für Eskalations-Tickets". Bei genauerer Analyse stellte sich heraus, dass der Sub erst sinnvoll ist, wenn der Eingangsbucket sauber ist — sonst baut man Triage-Logik für Misklassifikationen statt für echte Eskalations.

Erwartete Wirkung: Eskalations-Bucket-Volumen sinkt von ~0.83/Tag auf ~0.3–0.4/Tag. Verbleibende Cases fallen in klar erkennbare Cluster (Shopify Chargeback, DSGVO, DHL-Schadensfälle, echte komplexe Cases). Auf Basis dieser Daten in 1-2 Wochen entscheiden, ob ein Sub-Workflow überhaupt Wert schafft oder ob 3 Zendesk-Macros + 1 Slack-Routing-Regel ausreichen.

Wie

  1. Prompt-Deploy (Susi via UI-Paste):
  2. n8n öffnen → Workflow MOKI Dispatcher v2 → Node AI Agent Stufe 1 → Messages-Reiter → Inhalt durch prompt review/versions/v04_DEPLOY_PASTE.txt ersetzen → Save + Publish.
  3. NICHT via update_workflow (zerstört Credential-Bindungen, siehe CLAUDE.md).
  4. Code-Node-Patch (Susi via UI-Paste):
  5. Im selben Workflow Node Parse LLM Output öffnen → jsCode-Feld komplett durch den Block aus docs/parse-llm-output-v04-patch.md ersetzen → Save + Publish.
  6. Smoke-Test:
  7. 8 Test-Tickets aus prompt review/versions/v04_smoke_test_pindata.json durchschicken (3× Patch-Cases, 1× native_messaging, 1× Bol-Klantvraag-leer, 3× Regression: Amazon Return-Auth, Bol Klantvraag MIT Inhalt, Anwaltsdrohung).
  8. Erwartete Outputs in prompt review/versions/v04_2026-05-13_eskalation_cleanup.md Frontmatter → Akzeptanz-Kriterien.
  9. Live-Beobachtung 7 Tage: Ticket Log v2 Sheet filtern intent=eskalation ab Deploy-Datum. Akzeptanz: 0 Treffer in den 3 Patch-Mustern, JSON-Parse-Errors landen in auto_noise mit parse_error-Flag.
  10. Promotion zu deployed: Wenn alle Akzeptanz-Kriterien grün, CHANGELOG-Status auf deployed setzen, MEMORY.md-Eintrag finalisieren.

Bewusst NICHT in diesem Schritt

  • Kein neuer presale-Intent. v03 klassifiziert Presale bereits korrekt als produktfrage. Eigener Intent macht erst Sinn, wenn Saskia (CS-Lead, startet 18.05.) eine Presale-Macro definiert und Auto-Reply produktivisiert werden soll.
  • Kein Sub-Workflow für Eskalations. Erst Eingangsbucket bereinigen, dann mit echten v04+-Daten entscheiden.
  • Kein Stand-2-LLM für native_messaging-chat_transcript-Extraktion (analog zum WhatsApp-Fix aus 2026-05-07). Future-Track in MEMORY.md, nicht im v04-Scope.

Risiken

  • Low. Drei chirurgische <edge_cases>-Patches mit klaren Regex-/Keyword-Triggern. Worst Case: ein echter Customer-Reply mit Subject "Danke" landet fälschlich in auto_noise — aber das wäre vorher in eskalation gelandet, kein zusätzlicher Schaden für den Kunden (in beiden Fällen CS-Handoff).
  • Parse-Fallback: Vorher eskalation (sichtbar), jetzt auto_noise + needs_cs_attention=true (auch sichtbar, anderer Bucket). CS-Workload identisch, Bucket-Analytics ehrlicher.