Das Problem: Jede Antwort beginnt beim leeren Blatt
Die teuerste Arbeit an einem Kontaktformular ist die Vorsortierung: Jede Anfrage muss gelesen, eingeordnet und individuell beantwortet werden. Welche Anfragen sind dringend? Welche sind Werbung? Bei wenigen Nachrichten pro Woche ist das machbar. Sobald mehrere Kanäle und höhere Stückzahlen dazukommen, frisst genau diese Vorsortierung den Tag auf.
Die Lösung auf dieser Website besteht aus drei Teilen, die einzeln unspektakulär sind. Zusammen ergeben sie einen Workflow, der die manuelle Arbeit pro Anfrage deutlich reduziert und trotzdem unter menschlicher Kontrolle bleibt.
Teil 1: Anfragen als strukturierte Datensätze statt loser E-Mails
Das Kontaktformular dieser Website verschickt nicht einfach eine E-Mail. Jede Anfrage wird zusätzlich als strukturierter Datensatz in einer SQLite-Datenbank auf dem Webserver gespeichert: Name, Unternehmen, Branche, Anliegen, Teamgröße, genutzte Systeme, der größte Zeitfresser und die Nachricht selbst. Schon das Formular qualifiziert also vor.
Jeder Datensatz trägt außerdem Workflow-Felder, die für die spätere
Verarbeitung gedacht sind: einen Status (neu,
klassifiziert, entwurf, beantwortet,
erledigt oder spam), eine Priorität, eine Kategorie
und ein Feld für den Antwortentwurf. Diese Struktur ist die Grundlage für
alles Weitere. Ohne saubere Daten gibt es keine sinnvolle Automatisierung,
das gilt hier genauso wie bei Produktdaten im Onlineshop.
Spam wird bereits vor der Datenbank abgefangen, ohne Captcha: Ein für Menschen unsichtbares Formularfeld und eine serverseitig signierte Zeitprüfung sortieren automatisierte Einsendungen aus. Besucher merken davon nichts.
Teil 2: Eine API, über die Agenten lesen und schreiben dürfen
Auf dem Server läuft ein kleiner, Token-geschützter JSON-Endpoint. Er erlaubt zwei Dinge: neue Anfragen abrufen und Workflow-Felder aktualisieren. Die Originaldaten der Anfrage sind über die API bewusst nicht veränderbar, eine Whitelist im Endpoint lässt nur Status, Priorität, Kategorie, Antwortentwurf und Bearbeiter-Kennung zu. Ein fehlerhafter oder kompromittierter Agent kann also klassifizieren und Entwürfe ablegen, aber keine Kundendaten manipulieren.
Teil 3: Der Triage-Agent mit lokalem Sprachmodell
Der eigentliche Agent ist ein Node.js-Skript mit rund 150 Zeilen, ohne
externe Abhängigkeiten. Es holt alle Anfragen mit Status neu,
übergibt sie einem Sprachmodell und schreibt das Ergebnis zurück. Pro Anfrage
entstehen vier Dinge:
- eine Priorität (hoch, mittel, niedrig), nach klaren Kriterien im Prompt
- eine Kategorie, zum Beispiel
shop-automatisierungoderspam - eine Zusammenfassung in einem Satz für die interne Übersicht
- ein vollständiger Antwortentwurf auf Deutsch, in meiner Tonalität, mit konkreten Rückfragen zur jeweiligen Anfrage
Damit das Ergebnis verlässlich maschinenlesbar ist, erzwingt das Skript über ein JSON-Schema ein strukturiertes Ausgabeformat. Das Modell kann also nicht „frei erzählen", es muss die vier Felder liefern.
Warum das Sprachmodell lokal läuft
Das Modell (gpt-oss:120b) läuft über Ollama auf eigener
Hardware. Kein Cloud-Anbieter, kein API-Schlüssel, keine Übertragung der
Anfragedaten an Dritte. Der Grund ist simpel: Die Datenschutzerklärung dieser
Website sagt zu, dass Anfragedaten nicht an Dritte weitergegeben werden.
Diese Zusage gilt auch für die KI-Verarbeitung, sonst wäre sie wertlos.
Das ist keine Dogmatik gegen Cloud-Modelle. In anderen Projekten kann ein Cloud-LLM mit Auftragsverarbeitungsvertrag die richtige Wahl sein, etwa wenn keine geeignete Hardware vorhanden ist oder größere Volumen anfallen. Die Entscheidung gehört nur bewusst getroffen, bevor Kundendaten fließen. Genau diese Abwägung ist Teil jeder Potenzialanalyse.
Der erste Lauf, ehrlich gemessen
Der erste produktive Lauf brauchte 26 Sekunden auf eigener Hardware, für
Klassifikation und Antwortentwurf zusammen. Im Status neu lag
genau eine Anfrage: ein interner Systemtest, den ich nach dem Deployment des
Formulars selbst abgeschickt hatte. Der Agent hat ihn korrekt als
system-test kategorisiert, die Priorität auf niedrig gesetzt und
trotzdem einen brauchbaren, höflichen Antwortentwurf formuliert.
Dass der Agent einen Testeintrag als Testeintrag erkennt, klingt banal. Es ist aber genau die Fähigkeit, die im Alltag zählt: Werbung, Tests und vage Nachrichten landen unten im Stapel, ernst gemeinte Anfragen oben.
Die Spielregeln: Wo der Mensch sitzt
- Der Agent versendet nie. Er legt Entwürfe ab und setzt den
Status auf
entwurf. Gelesen, korrigiert und verschickt wird von einem Menschen. - Originaldaten sind schreibgeschützt. Die API-Whitelist verhindert, dass automatisierte Verarbeitung Kundendaten verändert.
- Fehler bleiben sichtbar. Jeder Datensatz trägt die Kennung des Bearbeiters, auch wenn es ein Agent war. Was der Agent entschieden hat, lässt sich jederzeit nachvollziehen und übersteuern.
Sprachmodelle arbeiten nicht fehlerfrei. Ein Workflow, der das ignoriert, fällt einem früher oder später auf die Füße. Deshalb ist die menschliche Freigabe hier kein vorläufiger Zustand, sondern Architekturprinzip.
Was sich davon übertragen lässt
Der Aufbau ist bewusst generisch: strukturierte Datenhaltung, eine geschützte API mit klaren Schreibrechten, ein austauschbares Sprachmodell und ein Mensch an der Freigabestelle. Dasselbe Muster funktioniert für E-Mail-Postfächer mit hohem Aufkommen, für Ticketsysteme im Kundenservice und für die Prüfung eingehender Bestellungen. Die Details unterscheiden sich, die Architektur bleibt. Wie solche Projekte ablaufen, beschreibt die Seite KI-Agenten & individuelle Software; die technischen Grundsätze dahinter stehen im Tech-&-Compliance-Hub.
Übrigens misst diese Website auch ihre Besucherzahlen mit einem selbst entwickelten System. Wie das ohne Cookies und ohne Consent-Banner funktioniert, zeigt die Case Study Cookieloses Web-Analytics auf Shared Hosting.