Jede Nachricht bekommt einen klaren nächsten Schritt.

Jeder Vorgang zeigt, warum er dort ist.

Die Warteschlange enthält ausstehende Entscheidungen, Fallback-Vorgänge, mehrdeutige Identitäten, technische Fehler und Bestätigungen. Das Übernehmen eines Vorgangs gibt keinen Vorschlag frei.

Beispieldaten; nichts Gezeigtes ist ein Live-Postfach.

Eine Empfehlung neben der Nachricht.

Absicht, Priorität, ein Konfidenzband, Kundenkandidaten und die Routing-Entscheidung, mit den Versionen von Regel, Manifest und Dienstplan sowie einem nummerierten „Warum diese Route“.

Zwei mögliche Kunden, also muss ein Mensch wählen. Beispieldaten.

Dieselbe Reihenfolge für jede Nachricht.

Das Routing ist darauf ausgelegt, in einer festen Abfolge zu laufen, in der der erste zutreffende Schritt die Route festlegt. Ein Vorschlag unterhalb der Konfidenzschwelle routet sich nie selbst: Er landet in einem zugewiesenen Fallback, wo ein Mensch entscheidet.

Vier ehrliche Ergebnisse.

OneMail ist darauf ausgelegt, den Kunden anhand von Nummern, Referenzen, Adressen und früheren Vorgängen zu ermitteln und gereihte Kandidaten mit dem jeweiligen Grund für den Treffer anzuzeigen.

Sechzig Geschäftsminuten bis zur ersten Entscheidung.

Vorgänge werden als kurz vor Fristüberschreitung markiert, sobald 45 Minuten verbraucht sind. Dienstkalender werden in der Vorschau angezeigt und als Richtlinie veröffentlicht; welche Feiertage gelten, gibt der Kunde vor. Eine Änderung der Richtlinie verschiebt niemals bereits gesetzte Fristen.

Beispielkonfiguration.

Bestätigen, korrigieren, nachfragen oder neu zuweisen.

• Bearbeiter bestätigen, korrigieren, fordern eine Klärung an, wählen zwischen Kundenkandidaten oder weisen neu zu. Versionsprüfungen verhindern, dass zwei Personen auf Basis einer veralteten Entscheidung handeln.
• Das Warten auf den Kunden ist eine separate Uhr: Nach einer Klärungsanfrage folgen eine Erinnerung und ein Abschlusshinweis an vereinbarten Geschäftstagen, und eine spätere Antwort öffnet die ursprüngliche Konversation wieder.
• Antworten aus freigegebenen Vorlagen. Vorlagen werden pro Locale versioniert und durchlaufen Einreichen, Freigeben und Aktivieren nach dem Vier-Augen-Prinzip. Die Auflösung einer Vorlage erfindet nie eine Ersatzsprache.

• Nachweise begleiten die Entscheidung. Konfidenz, hervorgehobene Quellstellen, Identitätskandidaten, fehlende Daten und die exakten Regel- und Modellversionen gehen in den Audit-Datensatz ein.
• Nichts wird überschrieben. Eine Neubewertung einer Nachricht bewahrt frühere Entscheidungen als unveränderliche Ereignisse, und Korrekturen behalten die vorherige Version im Verlauf. Prüfpfade lassen nur Anhängen zu (Append-only).
• Jeder Seiteneffekt hat einen Schlüssel, einen Journaleintrag und einen Beleg. Ein Timeout ist ein unbekanntes Ergebnis, niemals ein doppelter Wiederholungsversuch. Warteschlangenbefehle verwenden Idempotenzschlüssel, Versionsvorbedingungen, atomare Befehlsbelege und eine Outbox.
• Kein falsches Rückgängigmachen. Jede automatische Aktion hat eine Kompensation oder einen manuellen Wiederherstellungspfad, und irreversible Arbeit wird nie als rückgängig machbar dargestellt.

Jedes Feld verweist auf seine Quelle.

Parsing, OCR und eine nachvollziehbare Arbeitsübersetzung erzeugen typisierte Felder. Jedes Feld trägt seine Quellpassage und Konfidenz und erhält ausdrücklich den Status „fehlend“, wenn die Nachricht dazu nichts sagt.

Fehlende Informationen werden als fehlend angezeigt. Beispieldaten.

Felder mit ihrer Quelle oder als fehlend markiert.

• ProduktFörderbandhoch
• StandortWerk 4hoch
• KundennummerC-20417exakt
• Kontakttelefonfehltper Klärungsanfrage erfragen

Ein Timeout ist ein unbekanntes Ergebnis, niemals ein doppelter Wiederholungsversuch.

Jeder Seiteneffekt trägt einen deterministischen Aktionsschlüssel, einen Journaleintrag und einen Beleg vom Zielsystem.

Anweisungen in E-Mails sind Daten, keine Befehle.

Modelle erhalten niemals Anmeldedaten, und eine versteckte Anweisung in einem Anhang kann weder ein Ziel wählen noch handeln.

Von einer zweiten Person freigegeben.

Beispielkonfiguration.

Wer was betreibt.

• Sie betreiben Kubernetes, Speicher, Netzwerk, Ihren Identitätsanbieter und MFA, die Länderplatzierung, SIEM und Incident Response.
• Das OneMail-Release liefert Voreinstellungen nach dem Least-Privilege-Prinzip, exakte Durchsetzung des Geltungsbereichs, signierte Artefakte, Belege und dokumentierte Wiederherstellung.

Es wird keine Zertifizierung beansprucht. Datenspeicherort, Verarbeitungsort und Aufbewahrung werden vor dem Go-live dokumentiert.

Mindestanforderungen an die Verfügbarkeit, keine Dimensionierung.

Drei Fehlerdomänen, ein PostgreSQL-Cluster mit drei Instanzen, RabbitMQ mit drei Mitgliedern, mindestens drei OpenSearch-Knoten, zwei oder mehr Repliken jeder API und jedes Workers sowie GPU-Knoten nur, wenn lokale Modelle aktiviert sind. Ist KI nicht verfügbar, funktioniert der Eingang weiter.

Was Ihr IT-Team bereitstellt.

• Angaben zum Tenant für Microsoft 365 und Entra sowie ein gekennzeichnetes Gruppenpostfach für das Pilotprojekt; ein live genutztes info@-Postfach nur mit ausdrücklicher Autorisierung, für die Kennzeichnung im Schattenbetrieb
• Postfachzugriff über Exchange Application RBAC auf genau die Postfachgruppe (für ein Pilotprojekt nur lesend), niemals tenantweites Mail.Read
• App-Registrierungen und Administratorzustimmung, eine Gruppe für den ersten Administrator und Bearbeitergruppen
• Ein Azure-Abonnement und eine Ressourcengruppe mit Bereitstellungsrechten sowie ein DNS-Hostname
• Eine Leserolle in Dataverse, wenn die Identifizierung zum Umfang gehört; die Schreibrolle nur, wenn Schreibvorgänge aktiviert sind
• Datenschutzentscheidungen vor jeder Live-E-Mail: Rechtsgrundlage, Geografie der Verarbeitung und des Modell-Hostings, ob ein selbst gehostetes Modell erforderlich ist, Aufbewahrung und ob eine Datenschutz-Folgenabschätzung (DSFA) oder eine Unterrichtung des Betriebsrats nötig ist