Zuerst eingehende Nachrichten speichern, dann verarbeiten
Ich würde nicht mit „lass uns alles in einen Chat schmeißen“ starten. Zuerst würde ich jede eingehende Nachricht separat speichern—sonst zerstört der erste Classifier-Fehler Quelldaten und Historie.
Den Fehler, den ich zuerst entfernen würde: Eine Shared Inbox ohne external_id, Owner und SLA wird zur Müllhalde: Nachrichten sind für alle sichtbar, aber niemand ist verantwortlich.
Was vorbereiten und welches Ergebnis erwarten
- Ergebnis: E-Mail-, Formular- und Messenger-Nachrichten folgen einem Pfad, duplizieren sich nicht und gehen nicht zwischen Schichten verloren.
- Beschreibe Kanäle und Felder: channel, external_id, received_at, sender, text, attachments, intent, priority, status und owner.
- Halte Quelldaten und Zugriffsrechte getrennt vom Ergebnis, damit du prüfen kannst, was die einheitliche KI-Inbox wirklich getan hat.
- Sende dieselbe Nachricht aus zwei Kanälen, eine Nachricht mit Anhang und eine Nachricht außerhalb der Geschäftszeiten.
Eine funktionierende Queue aus E-Mail, Formularen und Messengern bauen
- Speichere das Original vor der KI
Schreibe jeden Webhook oder jede E-Mail zuerst in raw_inbox mit external_id und Timestamp. Erst dann Klassifikation laufen lassen.
Проверьте: Du kannst die Originalnachricht öffnen, auch wenn der KI-step fehlgeschlagen ist.
Если не сработало: Deaktiviere automatisches E-Mail-Löschen und aktiviere ein Error-Log.
- Normalisiere Text und Anhänge
Füge einen Normalize-step hinzu: Text, Dateiname, Anhangstyp und Quell-Link extrahieren. Keine Passwörter oder Secrets aus Signaturen an das Modell übergeben.
Проверьте: Dieselbe Phrase aus E-Mail und Formular sieht für den Classifier gleich aus.
Если не сработало: Behandle PDF, Bilder und leere E-Mails separat.
- Weise Queue und Frist zu
Nach intent füge Router hinzu: Sales, Support, Dokumente, urgent to lead. Für jeden Branch Owner und SLA, zum Beispiel Antwort bis Geschäftsende.
Проверьте: Jede Nachricht hat Status und Owner.
Если не сработало: Sende unbekannte Themen in geteiltes Triage, nicht in einen zufälligen Branch.
- Schließe die Schleife
Nach der Antwort speichere sent_at, outcome und Link zur Karte. Hat ein Mitarbeitender die Klassifikation korrigiert, protokolliere den Grund für künftige Tests.
Проверьте: Du misst nicht nur Inbound-Volumen, sondern Zeit bis zur ersten Antwort.
Если не сработало: Füge ein manuelles Resolution-Feld und ein wöchentliches Queue-Review hinzu.
Einheitliches Intake-Schema
Vor der KI schreibe channel, external_id, received_at, sender, text, attachment_url und raw_payload. Dann Normalize, Classify, Route und Assign owner. Unbekannte Themen brauchen dediziertes Triage, keinen zufälligen Branch.
Halte Status kurz: new, classified, assigned, waiting_customer, resolved, needs_human. In der Benachrichtigung zeige SLA und Link zum Original. So siehst du, wo eine Anfrage steckt: Zustellung, Klassifikation oder ein konkretes Team.
- Lösche die Quell-E-Mail nicht, bis raw_payload erfolgreich gespeichert ist.
- Dieselbe Nachricht aus E-Mail und Formular braucht eine klare Duplikat-Lookup-Methode.
Checks am ersten Tag
Sende denselben Text aus Formular und Telegram, eine E-Mail mit Anhang, eine leere E-Mail und eine Nachricht außerhalb der Geschäftszeiten. Für jede prüfe owner, due_at und Link zum Original. Scheitert KI, muss der Datensatz in raw_inbox bleiben.
Ich speichere den Roh-Input vor der Klassifikation
In n8n sollte der erste Node nach Webhook/Email `raw_payload`, `external_id`, `received_at`, `channel`, `sender`, `text` und `attachment_url` schreiben. Erst nach erfolgreichem Write Normalize und Classify. Scheitert KI, bleibt die Nachricht in `raw_inbox` und bekommt `needs_review`.
Für die Queue nutze `new → classified → assigned → waiting_customer → resolved → needs_human`. Unbekannte Themen brauchen geteiltes Triage mit Owner und SLA. Ein Shared Chat ohne Status und Frist ist keine Inbox—dort gehen Anfragen verloren.
Wie Nachrichten über Teams geroutet werden
| Kriterium | Frage | Gutes Zeichen |
|---|---|---|
| Input | Was kommt genau in die einheitliche KI-Inbox? | Beschreibe Kanäle und Felder: channel, external_id, received_at, sender, text, attachments, intent, priority, status und owner. |
| Aktion | Was darf das System allein tun? | Nur vorab gelistete Aktionen, ohne Zugriff auf das gesamte Konto |
| Prüfung | Woran erkennst du, dass das Ergebnis akzeptabel ist? | Sende dieselbe Nachricht aus zwei Kanälen, eine Nachricht mit Anhang und eine Nachricht außerhalb der Geschäftszeiten. |
| Fehlerfall | Wohin geht ein unklarer Fall? | Speichere das Event in raw_inbox und weise einen Queue-Owner zu; lösche die Quellnachricht nicht, bis der Write gelingt. |
Was sich nach der Einrichtung ändern sollte
E-Mail-, Formular- und Messenger-Nachrichten folgen einem Pfad, duplizieren sich nicht und gehen nicht zwischen Schichten verloren.
Wo eine Unified Inbox Anfragen verliert
Klassifizieren, bevor das Original gespeichert ist.
Anhänge und Links bei der Normalisierung verlieren.
Keinen Owner für ein unbekanntes Thema zuweisen.
Eine Nachricht als geschlossen werten, nur weil KI eine Antwort erzeugt hat.
Wann du eine separate Routing-Schicht brauchst
Hole einen Spezialisten, wenn die Inbox hohes Volumen, mehrere Teams, Anhänge oder Aufbewahrungspflichten für Korrespondenz handhaben muss.
Was an den ersten zwanzig Nachrichten prüfen
Für wen ist dieser Ansatz zur einheitlichen KI-Inbox?
KI-Anfragenverarbeitung heißt nicht, jede Nachricht in einen Chat zu kippen. Zuerst Inputs normalisieren, die Quelle behalten und eine Queue mit klarem Owner anlegen.
Wo starten, wenn alles noch manuell ist?
Beschreibe Kanäle und Felder: channel, external_id, received_at, sender, text, attachments, intent, priority, status und owner.
Wie prüfst du, dass das Setup dir nicht schadet?
Sende dieselbe Nachricht aus zwei Kanälen, eine Nachricht mit Anhang und eine Nachricht außerhalb der Geschäftszeiten.
Was, wenn das Ergebnis unklar ist?
Speichere das Event in raw_inbox und weise einen Queue-Owner zu; lösche die Quellnachricht nicht, bis der Write gelingt.
