Ablauf der Kundenerkennung

Wie Enneo Kunden und Verträge aus E-Mails, Chats und Telefonaten identifiziert

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.

​

Ablauf bei E-Mails und Briefen

1. Nachricht analysieren

   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 contractId wird searchContractByIdExecutor aufgerufen.
   • 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.

​

Ablauf bei Chat und Voicebot

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.

​

Manuelle Suche durch Sachbearbeiter

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.

​

Beispiele

​

E-Mail

Anzeigen Konkretes Beispiel mit echten Werten anzeigen

Eingangsmail an [e-mail]:

From:    [e-mail]
Subject: Frage zu meiner Rechnung

Sehr geehrte Damen und Herren,

zu meinem Konto mit Kundennummer K-2024-0815 habe ich eine Frage
zu der Rechnung vom letzten Monat. Mein Name ist Maria Schmidt,
ich wohne in der Hauptstraße 5, 80331 München.

Viele Grüße
Maria 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 [e-mail] 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:

   {
     "customerId": "K-2024-0815",
     "firstName":  "Maria",
     "lastName":   "Schmidt",
     "zip":        "80331",
     "city":       "München",
     "street":     "Hauptstraße 5"
   }
   
4. searchContractByFieldsExecutor

   Aufruf mit den extrahierten Parametern plus Ticket-Kontext:

   // Input
   {
     "customerId": "K-2024-0815",
     "firstName":  "Maria",
     "lastName":   "Schmidt",
     "zip":        "80331",
     "city":       "München",
     "street":     "Hauptstraße 5",
     "email":      "[e-mail]",
     "ticketId":   4711
   }
   
   // Output (vom User-Code)
   {
     "contractId":  "C-987654",
     "customerId":  "K-2024-0815",
   
     // Optional: Preview-Kacheln für die rechte Leiste im Ticket
     // (Quick-Infos, die der Sachbearbeiter sofort sieht)
     "agentPreview": [
       { "label": "Status",           "value": "Aktiv"     },
       { "label": "Offener Saldo",    "value": "0,00 €"    },
       { "label": "Letzte Rechnung",  "value": "84,20 €",
         "tooltip": "Versendet am 2026-04-10" }
     ]
   }
   
5. Nachladen der Stammdaten

   searchContractByIdExecutor und searchCustomerByIdExecutor laufen parallel:

   // searchContractByIdExecutor — Input
   { "contractId": "C-987654" }
   
   // Output
   {
     "id":         "C-987654",
     "customerId": "K-2024-0815",
     "product":    "Standard-Abo",
     "status":     "active",
     "startDate":  "2023-04-01",
     "lastInvoice": { "date": "2026-04-10", "amount": 84.20, "open": 0.00 }
   }
   

   // searchCustomerByIdExecutor — Input
   { "customerId": "K-2024-0815" }
   
   // Output
   {
     "id":         "K-2024-0815",
     "firstName":  "Maria",
     "lastName":   "Schmidt",
     "email":      "[e-mail]",
     "phone":      "[phone]",
     "address":    { "street": "Hauptstraße 5", "zip": "80331", "city": "München" },
     "language":   "de",
     "iban":       "DE89 3704 0044 0532 0130 00"
   }
   

   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.

​

Voicebot

Anzeigen Konkretes Beispiel eines Anrufs anzeigen

Ein Kunde ruft die Hotline [phone] 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:

   // Input
   {
     "contractId": "C-987654",
     "zip":        "80331",
     "phone":      "[phone]",
     "ticketId":   8132
   }
   
   // Output (vom User-Code)
   {
     "contractId":  "C-987654",
     "customerId":  "K-2024-0815",
   
     // Optional: Preview-Kacheln für die rechte Leiste im Ticket
     "agentPreview": [
       { "label": "Status",          "value": "Aktiv"  },
       { "label": "Offener Saldo",   "value": "0,00 €" }
     ]
   }
   
3. Nachladen der Stammdaten

   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 [phone] 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?