Zum Hauptinhalt springen
Sobald ein Kunde, bzw. genauer gesagt ein Vertrag, erkannt worden ist, startet Enneo eine Prüfung ob die Erkennung ausreichend konkret ist für eine weitere Verarbeitung. Dieses Konzept ist die “Legitimierung” in Enneo. Erkannte, aber nicht legitimierte Kunden werden dem User vorgeschlagen, aber mit einer entsprechenden Warnmeldung, so dass der User besonders prüfen kann, ob die KI-Erkennung korrekt war und alle notwendigen Merkmale genannt wurden. Ist ein Kunde legitimiert, erlischt diese Warnmeldung. Eine Dunkelverarbeitung ohne menschliche Interaktion ist auch nur für Kunden möglich, welche legitimiert wurden. Typische Legitimierungsregeln bestehen aus 2 unabhängigen Merkmalen, die zueinander passen müssen. So kann man sicherstellen, dass es zu keiner Fehlidentifikation gekommen ist. Beispiele für reale Identifikationsmethoden sind weiter unten aufgeführt. Eine Legitiation erfolgt stets auf Vertrags- und nicht auf Kundenebene, wobei dafür auch Merkmale aus den Kundendaten verwendet werden können. So stellt Enneo sicher, das vertragsbezogene Änderungen auch für den korrekten Vertrag durchgeführt werden.

Die 4 Stufen der Legitimierung

Die Kundenerkennung in Enneo die folgenden Stufen der Legitmierung:
BeschreibungBedeutung (E-Mail)Bedeutung (Chatbot/Voicebot)BeispielLevelDunkelverarbeitung
Kein Kunde identifiziertSachbearbeiter sieht keinen KundenKeine ErkennungKunde nennt weder Vertrags- noch Kundennummer, genutzte E-Mail ist zudem nirgends hinterlegt0Nein
Kunde erkannt, aber nicht legitimiertSachbearbeiter sieht Kunden in rechter Leister, aber mit WarnmeldungWie keine ErkennungKI hat Kunde 123 erkannt, dessen Unterlagen die E-Mail tom@smith.com ausweisen. Die E-Mail stammt jedoch von michael@jackson.com10-19Nein
Kunde von der KI erkannt und Daten stimmen übereinSachbearbeiter sieht Kunde in rechter LeisteErkennung, volle ausführung von KI-AgentenKI hat Kunde 123 erkannt, dessen Unterlagen die E-Mail tom@smith.com ausweisen. Die E-Mail stammt von tom@smith.com20Ja
Kunde manuell bestätigtSachbearbeiter sieht Kunde in rechter LeisteEntfälltKunde wurde von Enneo nur ohne Legitimation erkannt (Level 10), aber vom User bestätigt30(Entfällt)

Erkennung der Legitimierungs-Levels im Standard von Enneo:

  • Bei Chat und Voice erfolgt die Festlegung, ab wann Level 20 erreicht wird über die Einstellung Assistant authentication instructions im jeweiligen Chat-/Voicebot. Die Einstellung ist standardmäßig Vertragsnummer (contractId) und Postleitzahl (zip) ist. Nur wenn die Kombination aus beiden genannt wird, ist der Kunde legitimiert.
  • Bei E-Mails und Briefen erfolgt die Einstellung, ab wann Level 20 erreicht wird über einen Regeleditor für Legitimierungen. Mit diesem lassen sich komplexe Sicherheitsniveaus festlegen.

Regeleditor für Legitimierungen bei E-Mails und Briefen

[Der Regeleditor befindet sich aktuell in der Entwicklung] Mit diesem Regeleditor lassen sich komplexe Geschäftsregeln abbilden, welche definieren wann ein Kunde sich ausreichend legitimiert hat um sein Anliegen zu bearbeiten. Auch kann so sichergestellt werden, dass nur dann eine Dunkelverarbeitung statt findet wenn der Kunde eindeutig und ausreichend identifiziert wurde. Beispiele für Regeln, welche mit diesem Editor abgebildet werden können:
  • Vertragsnummer ODER Kundennummer erwähnt UND Absender-E-Mail stimmt mit ERP
  • Vor- UND Nachname erwähnt UND (Vertrags- ODER Kunden- ODER Zählernummer erwähnt) UND (Rechnungs-/Lieferadresse ODER E-Mail stimmt mit Daten aus ERP überein
  • Insgesamt 4 Markmale genannt; davon mindestens 1 Pflichtmerkmal (Vertrags-, Kunden- oder Bestell-ID).
Für die konkrete Implementierung dieser Beispiele bitte hier aufklappen:

Vorgehen

So konfigurieren Sie Regeln in zwei Schritten:
  1. Matching-Gruppen anlegen
  • Eine Regel besteht aus einer oder mehreren Matching-Gruppen.
  • Ein Kunde gilt nur dann als legitimiert, wenn alle Matching-Gruppen erfolgreich erfüllt sind.
  • Jede Matching-Gruppe hat:
    • Eine Bezeichnung (z. B. “Identifikation per ID”)
    • Eine Mindestanzahl an Kriterien, die innerhalb dieser Gruppe erfüllt sein müssen
    • Eine Auswahl an Kriterien (Standardkriterien von enneo und optional eigene Kriterien)
  1. Kriterien je Matching-Gruppe wählen
  • Innerhalb einer Matching-Gruppe wählen Sie die Kriterien, die geprüft werden sollen.
  • Die Gruppe gilt als erfüllt, wenn mindestens so viele Kriterien zutreffen, wie unter “Mindestanzahl” festgelegt ist.

Verfügbare Kriterien

Für die typischen Kriterien, z.B. die Nennung von Vertrags- oder Kundennummer hat Enneo bereits Prüfkriterien vorentwickelt. Diese können einfach angeklickt werden. Die jeweiligen Datenfelder, also z.B. die konkrete Vertragsnummer bei einer Prüfung auf Nennung der Vertragsnummer, müssen dafür natürlich wie in https://docs.enneo.ai/de/guides/customer-recognition/integration-of-customer-data-in-enneo definiert definiert zur Verfügug gestellt werden. Die entsprechende Name der Variable ist in folgender Tabelle ebenfalls genannt.

Standardkriterien

StandardkriteriumVerwendete Datenfelder für das Matching
Absender-E-Mail stimmt mit Daten im ERP übereinemail in einem der Verträge eines Kunden
In der Nachricht erwähnte E-Mail stimmt mit Daten im ERP übereinemail in einem der Verträge eines Kunden
Telefonnummer stimmt mit Daten im ERP übereinphone in Kunden- oder Vertragsdaten
Vertrags-ID erwähntVertrags-ID (aus ERP/Vertragsdaten)
Kunden-ID erwähntKunden-ID (aus ERP/Kundendaten)
Vorname erwähntfirstname in Kunden- oder Vertragsdaten
Vorname oder Initial von Vorname erwähntfirstname in Kunden- oder Vertragsdaten
Nachname erwähntlastname in Kunden- oder Vertragsdaten
Lieferadresse exakt erwähntdeliveryAddress
Rechnungsadresse exakt erwähntbillingAddress
Lieferadresse ähnlich erwähnt (≥ 80% Übereinstimmung)deliveryAddress
Rechnungsadresse ähnlich erwähnt (≥ 80% Übereinstimmung)billingAddress

Eigene (benutzerdefinierte) Kriterien

Wenn Sie zusätzlich zu den Standardkriterien eigene Merkmale aus Ihrem ERP verwenden möchten (z. B. Bestellnummer, Zählernummer), können Sie benutzerdefinierte Kriterien anlegen. Dafür definieren Sie:
  • Namen des Kriteriums (z. B. “Bestellnummer angegeben”)
  • Datenpfad/Variable, nach der enneo suchen soll (muss einem Feld in Ihren Kunden-/Vertragsdaten entsprechen; Punkt-Notation wie rawData.orderData.number wird unterstützt)
  • Anzeigetext bei Nichterfolg (z. B. “Bestellnummer 0 wurde nicht gefunden.”; 0 wird durch den gesuchten Wert ersetzt)

Individuelle Fetslegung von Legitimierungs-Levels

Abweichend vom Regel-Editor kunden können auch nach einer vollständig freien Logik Regeln festlegen, ab wann ein bestimmtes Level erreicht werden soll, um damit kundenindividuelle Regeln abzubilden. Im Zuge dessen können beispielsweise auch ergänzende Legitimierungsinformationen via API eingeholt werden. Dazu muss unter ERP-Integration im User-Code für **Merkmalbasierte Suche von Verträgen **nicht nur die Kunden- und Vertragsnummer zurück gegeben werden, sondern zusätzlich das Feld
customerLegitimation
Hier ein Beispiel für eine Rückgabe des User-Codes bei einem legitimierten Kunden:
[
 {
  "id":"1234"
  "customerLegitimation": 20 // Kunde ist sicher legitimiert: Dunkelverarbeitung für E-Mail ist möglich; Bei Chat und Voice ist voller Zugriff auf KI-Agenten möglich
  "contract":{
    "customerId":"Cust-1232131"
  }
 }
]
Hier ein Beispiel für eine Rückgabe des User-Codes bei einem nicht Kunden. Hier wird für Sachbearbeiter eine Warnmeldung erscheinen.
[
 {
  "id":"1234"
  "customerLegitimation": 10 // Kunde vermutet, aber nicht sicher
  "contract":{
    "customerId":"Cust-1232131"
  },
  "customerLegitimationMessage": "Kunde hat richtige Vertragsnummer genannt, aber der Name stimmt nicht überein"
 }
]
Das Feld customerLegitimation definiert welche Warnmeldung einem User angezeigt werden soll.