Konzeption: KI-gestützte Auto-Antwort für das Kontaktformular

Status: Zurückgestellt — gehört thematisch zur KI-Pipeline und wird dort eingegliedert. Erstellt: 13. April 2026 Abhängigkeiten: CF7-Formular (Post 341), lib/prompts.php, CREOVATE_AI_MODEL (Haiku 4.5), bestehender AJAX-Enrichment-Handler als Pattern-Vorlage.

---

1. Motivation

Klassische CF7-Auto-Antworten nach dem Muster "Vielen Dank für deine Nachricht, wir melden uns bald" schaffen kurzfristig das Gefühl, dass das Anliegen angekommen ist — aber der Nutzer durchschaut schnell, dass da inhaltlich nichts passiert ist. Das Vertrauen bröckelt, manchmal sofort.

Eine personalisierte Eingangsbestätigung soll diese Lücke schließen: Sie spiegelt das Anliegen des Absenders erkennbar zurück, ordnet es in eine nachvollziehbare Kategorie ein und nennt die daraus resultierenden nächsten Schritte — ohne dabei inhaltlich auf die Frage zu antworten.

Explizit kein Ziel: Die KI ersetzt Peters persönliche Antwort nicht. Sie schafft nur eine hochwertigere Empfangsbestätigung.

---

2. Leitprinzipien

Diese Prinzipien sind nicht verhandelbar und gelten als Kriterium für jede Implementierungs-Entscheidung:

1. Keine freie Antwort durch die KI. Die KI klassifiziert strukturiert, sie formuliert nicht. Der gesamte sprachliche Mail-Inhalt stammt aus redaktionell vorgegebenen Bausteinen.
2. Fehler fallen immer sicher zurück. Jeder denkbare Fehlerfall (API down, JSON-Parse-Fehler, niedrige Confidence, unbekannte Kategorie, sensibles Thema) landet bei einer neutralen Default-Mail, die in jedem Kontext angemessen ist.
3. Keine peinlichen Mismatches. Lieber generisch und warm als spezifisch und falsch. Bei Unsicherheit: Default.
4. Transparenz für Peter. Jede Klassifizierung wird geloggt. Die ersten 50 Auto-Antworten werden manuell nachkontrolliert, bevor das System als "produktiv" gilt.
5. Asynchron. Der User darf nicht warten, bis die KI fertig ist. Die Sende-Bestätigung im Frontend erscheint sofort; die personalisierte Mail wird zeitversetzt (z.B. 30 Sekunden nach Submit) versendet.
6. Nur unkritische Bausteine mit KI-Variablen. Wenn die KI entgleist, darf der Schaden maximal "zu generische Antwort" sein — niemals "unpassende, verletzende oder falsche Aussage".

---

3. Zweistufige Architektur

Phase 1 — Klassifizierung (KI-Call)

Haiku bekommt die Nachricht des Absenders plus einen System-Prompt, der ausschließlich strukturierte JSON-Antwort zulässt. Keine Prosa, keine Erklärungen, keine Kommentare.

Eingabe an Haiku:

• Nachricht des Absenders (aus [nachricht]-Feld)
• Vorname des Absenders (aus [vorname]-Feld, für Kontext der Anrede)
• System-Prompt mit Kategorien-Definition, Confidence-Regeln, JSON-Schema

Ausgabe von Haiku (strikt JSON):

{
  "kategorie": "tech_frage",
  "thema_kurz": "WordPress-Setup mit Carbon Fields",
  "dringlichkeit": "normal",
  "tonfall": "fachlich",
  "anrede_empfehlung": "du",
  "confidence": "hoch",
  "sensibel": false
}

Alle Felder sind Pflicht. Alle Werte außer thema_kurz sind Enums aus einem geschlossenen Set. Jede Abweichung → JSON-Parse-Fehler → Fallback.

Phase 2 — Mail-Komposition (Template-System)

Die Mail wird nicht von der KI geschrieben, sondern aus vordefinierten Bausteinen zusammengesetzt. Pro Kategorie existiert ein eigenes Mail-Template mit festem Text und wenigen Einsetz-Variablen. Die KI-Klassifizierung dient nur als Schalter.

Template-Variablen (einzige Stellen, an denen KI-Output die Mail beeinflusst):

• {vorname} — aus Form-Feld, nicht aus KI
• {thema_kurz} — aus KI-Output, begrenzt auf 3-7 Wörter, gefiltert auf erlaubte Zeichen
• {anrede} — aus KI-Empfehlung (du oder Sie), aber nur wenn confidence == "hoch", sonst Default du

Alle anderen Mail-Inhalte sind statisch und redaktionell von Peter verfasst.

---

4. Offene Konzeptionsfragen (zu entscheiden in Stufe A)

Die folgenden Punkte müssen vor jeder Code-Umsetzung festgelegt werden. Das ist redaktionelle Arbeit, nicht technische.

4.1 Kategorien-Set

Vorschlag zur Diskussion (5-6 Kategorien, eng am Profil von stieff.de):

Kategorie	Beschreibung	Typische Nachrichten
event_anfrage	Fragen zum Event-Magazin, Tipps, Veranstalter-Meldungen	"Kennt ihr den Termin für…", "Wir veranstalten…"
ki_beratung	Fragen rund um KI-Einsatz in Unternehmen	"Wie könnte KI in meinem Betrieb…"
tech_frage	Technische Fragen zu Tutorials, Code, Setup	"Dein Tutorial zu X funktioniert nicht…"
kooperation	Kooperations-, Werbe-, Partnerschafts-Anfragen	"Wir würden gerne mit euch zusammenarbeiten…"
feedback	Lob, Kritik, Fehler-Hinweise	"Auf Seite X ist ein Tippfehler…"
sonstiges	Alles andere	—

Fragen:

• Sind 6 Kategorien zu viele/zu wenige? Granularität vs. Übersichtlichkeit.
• Fehlt etwas? Z.B. presse_anfrage, bewerbung, support?
• Soll sonstiges als Default-Fallback zählen oder als eigene Kategorie mit eigener Antwort?

4.2 Mail-Bausteine pro Kategorie

Für jede Kategorie muss Peter einen Mail-Text schreiben. Dieser Text ist das, was der Absender tatsächlich liest.

Vorlage-Struktur:

Hallo {vorname},

deine Nachricht zum Thema "{thema_kurz}" ist bei mir angekommen.

[Kategorie-spezifischer Text: Was passiert jetzt? Wann ist mit Antwort zu rechnen?
 Gibt es einen Verweis auf existierende Inhalte? Welcher Tonfall?]

Bis dahin
Peter

Zu schreiben (pro Kategorie):

1. 2-4 Sätze kategorie-spezifischer Kern
2. Erwartungsmanagement (Antwortzeit)
3. Optional: Verweis auf existierende Inhalte ("Im Tech-Blog findest du vielleicht…")

Fragen:

• Soll die Antwortzeit pro Kategorie variieren? ("Tech-Fragen in 2-3 Werktagen", "Kooperationen in 1 Woche")
• Duzen oder Siezen als Default? Oder variabel nach KI-Empfehlung?
• Soll jede Kategorie auf eine passende Seite verlinken (Tech-Blog, KI-News, Event-Magazin)?

4.3 Neutrale Default-Mail

Diese Mail wird gesendet, wenn:

• API-Call fehlschlägt
• JSON-Parse-Fehler auftritt
• Kategorie nicht erkannt
• Confidence niedrig
• Sensibles Thema erkannt (sensibel: true)

Anforderungen:

• Muss in jedem Kontext angemessen wirken — auch wenn es eine schlechte Nachricht, eine Beschwerde, eine sensible Anfrage ist
• Keine spezifische Erwähnung von Themen, Kategorien, KI-Einordnung
• Warm, aber zurückhaltend
• Keine Angabe konkreter Antwortzeiten, die man nicht halten kann

Peter schreibt diese Mail als letzte — sie ist der wichtigste einzelne Text des Systems.

4.4 Sensibilitäts-Erkennung

Wann soll Haiku sensibel: true zurückgeben?

Vorschlag:

• Hinweise auf persönliche Krise (Krankheit, Tod, Trennung)
• Wut, Frustration, Beschwerde-Tonfall
• Rechtliche Drohungen, Abmahnungen
• Emotionale Aufladung unklarer Richtung

Bei sensibel: true → automatisch neutrale Default-Mail, unabhängig von Kategorie und Confidence.

Fragen:

• Wie genau soll das im System-Prompt formuliert werden, ohne Haiku zu überempfindlich zu machen? (Risiko: alles wird als "sensibel" eingestuft)
• Soll Peter bei sensibel: true eine sofortige Benachrichtigung bekommen, die höher priorisiert ist als normale Mail-Eingänge?

4.5 Confidence-Schwellen

Vorschlag:

• hoch → Kategorie-spezifische Mail mit KI-Variablen
• mittel → Kategorie-spezifische Mail, aber ohne {thema_kurz} (nur Kategorie-Textbausteine)
• niedrig → neutrale Default-Mail

Fragen:

• Stimmen die drei Stufen, oder brauchen wir nur zwei (hoch/niedrig)?
• Wie bringt man Haiku dazu, Confidence ehrlich einzuschätzen und nicht zu überschätzen?

---

5. Technische Umsetzung (Stufe B — erst nach Stufe A)

5.1 Hook-Punkt

Empfohlen: wpcf7_before_send_mail als Trigger, aber der eigentliche KI-Call läuft nicht synchron im Hook — sondern wird als Job in Action Scheduler (oder WP-Cron) eingeplant. Vorteil: User-Frontend antwortet sofort, unabhängig von Haiku-Latenz und API-Verfügbarkeit.

5.2 Mail-Versand

Mail (2) von CF7 wird deaktiviert. Stattdessen versendet der geplante Job die personalisierte Mail via wp_mail() mit den Template-Bausteinen aus einer Config-Datei.

Wichtig: Die reguläre Benachrichtigungs-Mail an Peter (Mail 1) bleibt unberührt und wird weiterhin von CF7 synchron versendet. Peter bekommt also sofort seine interne Notification, die Auto-Antwort an den Absender kommt zeitversetzt.

5.3 Prompt-Ablage

Der System-Prompt wird in lib/prompts.php als neue Konstante/Funktion ergänzt, analog zum existierenden Highlights-Prompt. Versioniert, git-tracked, ohne Admin-UI.

5.4 Mail-Templates

Zwei Optionen:

• Option A: PHP-Array in lib/contact-reply-templates.php
• Option B: Eigene Template-Datei pro Kategorie in lib/contact-reply-templates/

Option A ist einfacher, Option B bietet bessere Übersicht wenn Bausteine länger werden. Entscheidung hängt von der Länge der finalen Bausteine ab.

5.5 Logging

Jede Auto-Antwort wird geloggt. Gespeichert werden:

• Zeitstempel
• Empfänger-Mail (hashed oder plain, zu entscheiden)
• Originalnachricht (gekürzt, erste 200 Zeichen)
• KI-Antwort komplett (JSON)
• Tatsächlich versendetes Template (Kategorie oder default_fallback)
• Confidence-Wert
• Fehler (falls Fallback ausgelöst)

Speicherort: Eigene DB-Tabelle wp_creovate_contact_log (via dbDelta wie bei der Pipeline).

5.6 Admin-Übersicht

Neues Untermenü unter "Redaktion" (dem Pipeline-Menü): "Kontakt-Log". Liste der letzten 50 Auto-Antworten mit Filter nach Kategorie, Confidence, Fallback-Status. Zweck: Peter kann nachvollziehen, wie Haiku entscheidet, und Kategorien/Prompts nachjustieren.

5.7 Feature-Toggle

Das gesamte Feature muss über eine einzelne Konstante in wp-config.php oder functions.php komplett deaktivierbar sein:

define( 'CREOVATE_AUTO_REPLY_ENABLED', false );

Bei false → CF7 Mail (2) bleibt aktiv wie zuvor, keine KI-Calls, kein Logging. Zero-Risk-Rollback jederzeit möglich.

5.8 Testphase und Rollout

1. Phase 1 — Dry-Run (1-2 Wochen): Feature aktiv, aber keine Mails werden versendet. Nur Logging läuft. Peter kontrolliert manuell, ob die Klassifizierungen stimmen.
2. Phase 2 — Peter-only (1 Woche): Auto-Antworten gehen ausschließlich an Peters eigene Test-Mail, nicht an echte Absender. Externe Mails laufen weiterhin über CF7 Mail (2) oder manuell.
3. Phase 3 — Live, aber überwacht (2 Wochen): Echte Auto-Antworten gehen raus. Peter überprüft die ersten 50 nachträglich.
4. Phase 4 — Regulärer Betrieb: Feature läuft, Logging läuft, gelegentliche Stichproben.

---

6. Risiken und Mitigation

Risiko	Schwere	Mitigation
Haiku klassifiziert falsch und Mail ist peinlich	Mittel	Bausteine so generisch halten, dass sie auch bei Fehl-Klassifizierung nicht peinlich wirken; Confidence-Schwellen
Anthropic-API down → keine Mail	Niedrig	Fallback auf neutrale Default-Mail, asynchrone Ausführung
Haiku halluziniert trotz JSON-Schema	Mittel	Strikte JSON-Validierung, Enum-Checks, bei Abweichung → Fallback
Sensibles Thema wird als normale Kategorie behandelt	Hoch	sensibel-Flag im Schema, restriktive Prompt-Anweisung, Peter-Benachrichtigung bei true
Rate-Limit der API bei Spam-Welle	Mittel	CF7 hat bereits Spam-Schutz (Akismet, reCAPTCHA), KI-Call nur bei validierten Submissions; zusätzlich: max. N Calls pro Stunde als Throttle
User erkennt dass Mail von KI kommt und verliert Vertrauen	Mittel	Sparsame, zurückhaltende Formulierung der Bausteine; keine überzogen "intelligente" Sprache; gezielt menschliche Formulierungen Peters übernehmen
Logging enthält personenbezogene Daten → DSGVO	Niedrig	Löschkonzept: Log nach 90 Tagen automatisch löschen; in Datenschutzerklärung erwähnen

---

7. Entscheidungs-Checkpoints

Bevor Implementierung startet, müssen folgende Entscheidungen getroffen sein:

---

8. Offene Fragen für die KI-Pipeline-Session

Dieser Block gehört in die größere KI-Pipeline-Konzeption. Dort ist zu klären:

• Wird der Contact-Auto-Reply eigenständig entwickelt, oder wird er als erste kleine Anwendung der Pipeline genutzt — also als Pilot, aus dem Lerneffekte für die große Pipeline gezogen werden?
• Teilt sich der Contact-Auto-Reply Infrastruktur mit der Artikel-Pipeline (Prompt-Handling, Logging, Admin-UI), oder bekommt er eigene, einfachere Mechanismen?
• Wann macht es Sinn, auf einen Scheduler umzusteigen (z.B. Action Scheduler statt WP-Cron), und gibt es Synergien mit der Pipeline-Infrastruktur, die ohnehin einen braucht?

---

9. Zeitschätzung

Block	Aufwand
Stufe A: Konzeption, Kategorien, Bausteine schreiben	2-4 Stunden (vor allem redaktionell)
Stufe B: Hook, Scheduler, Prompt, Logging, Admin-View	4-6 Stunden mit Claude Code
Testphase (Phasen 1-3)	ca. 4 Wochen Kalenderzeit
Gesamt bis Live	ca. 1 Monat ab Session-Start

---

Dieses Dokument ist die Einfriermarke für die Idee. Weiter geht es erst, wenn die KI-Pipeline-Konzeption wieder aufgegriffen wird und dieser Block dort als Unterprojekt eingegliedert werden kann.