Use this file to discover all available pages before exploring further.
Enneo führt für jedes eingehende Ticket — unabhängig vom Kanal — eine Kundenerkennung durch. Ziel ist es, den passenden Vertrag und Kunden in Ihrem stammdatenführenden System (ERP/CRM) zu finden und die Erkennung gemäß den hinterlegten Regeln zu legitimieren, bevor Anliegen weiter verarbeitet oder dunkelverarbeitet werden. Enneo ist dabei selbst nicht das führende System, sondern ruft die Daten in Echtzeit über User-Code aus Ihrem Quellsystem ab.
Enneo analysiert den Nachrichtentext (sowie Anhänge, falls per OCR ausgelesen).
2
Deterministische Vor-Erkennung (optional)
Vor dem LLM versucht Enneo, den Vertrag mit günstigen, deterministischen Verfahren direkt zu finden. Wird so eine contractId gefunden und liefern die ERP-APIs gültige Vertrags- und Kundendaten dazu, wird die LLM-basierte Merkmalsextraktion (Schritt 3) übersprungen.
Anzeigen Verfahren und Konfiguration
Enneo wendet drei Strategien an:
Regex auf Vertrags- und Kundennummern im Betreff und Body der Nachricht.
Absender-E-Mail-Adresse im ERP nachschlagen (über die merkmalbasierte Suche mit email als Parameter).
Weitere E-Mail-Adressen aus dem Nachrichtentext auf dieselbe Weise nachschlagen (interne Domains werden ausgeschlossen).
Unter Einstellungen → Integration in Umsysteme → Kunden- und Vertragssuche → Verträgen durch Suchmuster erkennen lässt sich konfigurieren:
das Suchmuster (regulärer Ausdruck) für Vertragsnummern — z. B. „immer 12 Ziffern”, „immer mit 1 beginnend” usw.
das Suchmuster für Kundennummern
oder dieser gesamte Schritt kann deaktiviert werden.
3
Merkmale per LLM extrahieren
Aus der Nachricht extrahiert die KI alle Parameter, die unter Einstellungen → Integration in Umsysteme → Kunden- und Vertragssuche → Suchparameter Kundenidentifikation konfiguriert sind — z. B. Vertragsnummer, Kundennummer, Name, Adresse, Zählernummer. Nur Parameter, die explizit in der Nachricht erwähnt werden, werden weitergegeben.
Je mehr Merkmale Sie hier konfigurieren und im Quellsystem bereitstellen, desto präziser arbeitet die Kundenerkennung.
4
Vertrag per Merkmal suchen
Die erkannten Parameter werden an den User-Code für die merkmalbasierte Suche (searchContractByFieldsExecutor) übergeben.Der User-Code darf maximal einen Vertrag zurückgeben (oder gar keinen). Eine Liste mit mehreren Treffern ist nicht zulässig — die Auswahl des wahrscheinlichsten Vertrags muss bereits im User-Code erfolgen.
5
Vertrags- und Kundendaten nachladen
Sobald die merkmalbasierte Suche eine contractId (und idealerweise auch eine customerId) zurückgegeben hat, lädt Enneo die vollständigen Stammdaten nach:
Mit der customerId aus der vorigen Stage — bzw. ersatzweise der customerId aus dem Vertrag — wird searchCustomerByIdExecutor aufgerufen.
Beide Aufrufe laufen parallel, sodass die zusätzliche Latenz minimal bleibt. Sämtliche hier zurückgegebenen Felder werden anschließend dem LLM als Kontext bereitgestellt und stehen damit für die Service-Antwort, KI-Agenten und die Legitimierungsprüfung zur Verfügung.
Anzeigen Typische Felder, die sich erfahrungsgemäß lohnen
Je reichhaltiger Vertrag und Kunde im ERP modelliert sind, desto besser können Antworten formuliert werden.
Stammdaten: Vor- und Nachname, Firma, Anrede, Geburtsdatum, Sprache
Kontaktdaten: E-Mail, Telefonnummer, Mobilnummer
Adressen: Rechnungs- und Lieferadresse
Vertragsdaten: Vertragstyp/Produkt, Status (aktiv, gekündigt, in Anbahnung), Vertragsbeginn/-ende, Kündigungsfrist, Tarif, Preis
Branchen-/Produktspezifika: z. B. Zähler- und Verbrauchsdaten (Energie), Bestellungen und Sendungsstatus (Handel), Police und Schadenshistorie (Versicherung), letzte Rechnung und offener Saldo
Bankdaten: IBAN, Zahlungsmethode, SEPA-Status
Die Ergebnisse dieser Aufrufe werden zwischengespeichert. Über die Einstellung ERP-Cache-Dauer (in Minuten) lässt sich steuern, wie lange Verträge und Kundendaten gecacht bleiben, bevor sie erneut frisch aus dem Quellsystem geladen werden. Ein Wert von 0 deaktiviert den Cache komplett.
6
Plausibilität & Legitimierung prüfen
Anhand der nachgeladenen Daten prüft Enneo, ob die in der Nachricht genannten Merkmale tatsächlich zum gefundenen Vertrag/Kunden passen (z. B. Absender-E-Mail = Vertrags-E-Mail, Postleitzahl stimmt überein). Daraus ergibt sich das Legitimierungs-Level — Details siehe Legitimierung von Kunden.
Anzeigen Woher das Level kommt
Das Level wird wahlweise bestimmt durch:
die in Enneo hinterlegten Legitimierungsregeln (Regeleditor), oder
das Feld customerLegitimation, das der searchContractByFieldsExecutor direkt aus dem User-Code zurückgibt — dann übernimmt Enneo dieses Level unverändert.
7
Darstellung & Verarbeitung
Legitimiert (Level ≥ 20): Enneo zeigt den Vertrag dem Sachbearbeiter an und kann das Anliegen — sofern konfiguriert — dunkel verarbeiten (automatische Ausführung von KI-Agenten ohne menschliche Freigabe).
Erkannt, aber nicht legitimiert (Level 10–19): Enneo zeigt den Vertrag als Vorschlag mit Warnhinweis an. Eine Dunkelverarbeitung findet nicht statt; der Sachbearbeiter prüft manuell.
Nicht erkannt (Level 0): Kein Vertrag wird zugeordnet.
Der Ablauf ist weitgehend identisch zur E-Mail-Verarbeitung — der Unterschied liegt darin, wann und wie Merkmale erhoben werden.
1
Merkmale aktiv erfragen
Im Chatbot-/Voicebot-Prompt ist konfiguriert, welche Daten der Bot vom Kunden aktiv erfragt (z. B. „Bitte nennen Sie mir Ihre Vertragsnummer und Postleitzahl”). Welche Parameter überhaupt zur Identifikation verwendet werden, ist in der Chatbot-/Voicebot-Konfiguration (Authentication Instructions) festgelegt.
2
Vertrag suchen, Daten nachladen, legitimieren
Sobald die nötigen Merkmale vorliegen, läuft der Rest exakt wie bei E-Mails: Schritte 4–6 von oben — also searchContractByFieldsExecutor, anschließend searchContractByIdExecutor und searchCustomerByIdExecutor, dann Plausibilitäts- und Legitimierungsprüfung.
3
Autonome Ausführung nur ab Level ≥ 20
Im Chat-/Voicebot wird jeder Kunde mit einem Legitimierungs-Level < 20 wie ein nicht-identifizierter Kunde behandelt. Der Bot führt keine kundenbezogenen Aktionen aus, sondern bittet den Kunden erneut um die fehlenden Merkmale, bis die Schwelle erreicht ist.
Unabhängig von der automatischen Kundenerkennung können Sachbearbeiter Verträge jederzeit über das Suchfeld in der UI manuell finden. Dafür ruft Enneo den User-Code für die Freitextsuche auf, der Suchanfragen nach Name, E-Mail oder anderen relevanten Feldern unterstützen sollte.
Anzeigen Konkretes Beispiel mit echten Werten anzeigen
Eingangsmail an service@example-company.com:
From: maria.schmidt@example.comSubject: Frage zu meiner RechnungSehr geehrte Damen und Herren,zu meinem Konto mit Kundennummer K-2024-0815 habe ich eine Fragezu der Rechnung vom letzten Monat. Mein Name ist Maria Schmidt,ich wohne in der Hauptstraße 5, 80331 München.Viele GrüßeMaria Schmidt
1
Analyse
Body und Betreff werden als reiner Text aufbereitet.
2
Deterministische Vor-Erkennung
Regex sucht nach dem konfigurierten Vertragsnummern-Pattern (z. B. [0-9]{6,7}). Die Kundennummer K-2024-0815 matcht das Format nicht, der Absender maria.schmidt@example.com ist im ERP nicht als Vertrags-E-Mail hinterlegt → kein Treffer, weiter zu Schritt 3.
3
LLM-Extraktion
Anhand der konfigurierten Suchparameter liefert das LLM:
Alle diese Felder gehen anschließend als Kontext an den LLM und stehen KI-Agenten zur Verfügung — z. B. um die Rückfrage zur letzten Rechnung fundiert zu beantworten.
6
Plausibilität & Legitimierung
Absender-E-Mail stimmt mit Vertrags-E-Mail überein, Name und PLZ aus der Nachricht passen zu den ERP-Daten → Legitimierungs-Level 20.
7
Darstellung & Verarbeitung
Kunde wird als legitimiert angezeigt; ein passender KI-Agent „Rechnungsauskunft” kann das Anliegen dunkel verarbeiten.
Ein Kunde ruft die Hotline +49 89 1234500 an. In der Voicebot-Konfiguration ist hinterlegt, dass für eine Legitimierung Vertragsnummer und Postleitzahl genannt werden müssen (analog gilt das gleiche Schema für den Chatbot).
1
Merkmale aktiv erfragen
Gespräch:
Bot: Guten Tag, hier ist der Service-Assistent von Example-Company. Wie kann ich Ihnen helfen?Kunde: Ich möchte gerne meine Bankverbindung ändern.Bot: Gerne. Damit ich Sie eindeutig identifizieren kann, nennen Sie mir bitte Ihre Vertragsnummer und Ihre Postleitzahl.Kunde: Vertragsnummer ist C-987654, Postleitzahl 80331.
2
searchContractByFieldsExecutor
Sobald Vertragsnummer und PLZ vorliegen, wird der User-Code aufgerufen:
searchContractByIdExecutor und searchCustomerByIdExecutor werden parallel aufgerufen (identische Ein-/Ausgaben wie im E-Mail-Beispiel). Alle Felder gehen anschließend als Kontext an den Voicebot.
4
Plausibilität & Legitimierung
Genannte PLZ 80331 stimmt mit der Adresse aus dem ERP überein und der Anrufer ruft von der Telefonnummer +49 89 1234567 an, die auf den Kunden registriert ist → Legitimierungs-Level 20.Hätte der Kunde nur die Vertragsnummer, aber keine passende PLZ genannt, bliebe das Level bei 10 — der Voicebot würde die fehlenden Merkmale erneut erfragen, statt fortzufahren.
5
Autonome Ausführung
Erst jetzt darf der Voicebot kundenbezogene Aktionen ausführen. Der KI-Agent „Bankverbindung ändern” wird aufgerufen, fragt die neue IBAN ab, validiert sie und schreibt sie ins ERP zurück.
Bot: Danke, Sie sind nun authentifiziert. Bitte nennen Sie mir die neue IBAN.Kunde: DE12 3456 7890 1234 5678 90.Bot: Die IBAN endet auf 5890, korrekt?Kunde: Ja.Bot: Vielen Dank, Ihre Bankverbindung wurde geändert. Möchten Sie eine schriftliche Bestätigung per E-Mail?
