Die 4 Stufen der Legitimierung
Die Kundenerkennung in Enneo die folgenden Stufen der Legitmierung:| Beschreibung | Bedeutung (E-Mail) | Bedeutung (Chatbot/Voicebot) | Beispiel | Level | Dunkelverarbeitung |
|---|---|---|---|---|---|
| Kein Kunde identifiziert | Sachbearbeiter sieht keinen Kunden | Keine Erkennung | Kunde nennt weder Vertrags- noch Kundennummer, genutzte E-Mail ist zudem nirgends hinterlegt | 0 | Nein |
| Kunde erkannt, aber nicht legitimiert | Sachbearbeiter sieht Kunden in rechter Leister, aber mit Warnmeldung | Wie keine Erkennung | KI hat Kunde 123 erkannt, dessen Unterlagen die E-Mail tom@smith.com ausweisen. Die E-Mail stammt jedoch von michael@jackson.com | 10-19 | Nein |
| Kunde von der KI erkannt und Daten stimmen überein | Sachbearbeiter sieht Kunde in rechter Leiste | Erkennung, volle ausführung von KI-Agenten | KI hat Kunde 123 erkannt, dessen Unterlagen die E-Mail tom@smith.com ausweisen. Die E-Mail stammt von tom@smith.com | 20 | Ja |
| Kunde manuell bestätigt | Sachbearbeiter sieht Kunde in rechter Leiste | Entfällt | Kunde wurde von Enneo nur ohne Legitimation erkannt (Level 10), aber vom User bestätigt | 30 | (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).
Vorgehen
So konfigurieren Sie Regeln in zwei Schritten:- 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)
- 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
| Standardkriterium | Verwendete Datenfelder für das Matching |
|---|---|
| Absender-E-Mail stimmt mit Daten im ERP überein | email in einem der Verträge eines Kunden |
| In der Nachricht erwähnte E-Mail stimmt mit Daten im ERP überein | email in einem der Verträge eines Kunden |
| Telefonnummer stimmt mit Daten im ERP überein | phone in Kunden- oder Vertragsdaten |
| Vertrags-ID erwähnt | Vertrags-ID (aus ERP/Vertragsdaten) |
| Kunden-ID erwähnt | Kunden-ID (aus ERP/Kundendaten) |
| Vorname erwähnt | firstname in Kunden- oder Vertragsdaten |
| Vorname oder Initial von Vorname erwähnt | firstname in Kunden- oder Vertragsdaten |
| Nachname erwähnt | lastname in Kunden- oder Vertragsdaten |
| Lieferadresse exakt erwähnt | deliveryAddress |
| Rechnungsadresse exakt erwähnt | billingAddress |
| 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 FeldcustomerLegitimation definiert welche Warnmeldung einem User angezeigt werden soll.