Kundenerkennung
Legitimierung von Kunden
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 – mit einer Ausnahme: Rückfragen, die einen nicht legitimierten Kunden nach den fehlenden Angaben fragen (siehe unten).
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 Legitimation erfolgt stets auf Vertrags- und nicht auf Kundenebene, wobei dafür auch Merkmale aus den Kundendaten verwendet werden können. So stellt enneo sicher, dass vertragsbezogene Änderungen auch für den korrekten Vertrag durchgeführt werden.
Die 4 Stufen der Legitimierung
Die Kundenerkennung in enneo kennt die folgenden Stufen der Legitimierung:
| Level | Stufe | Darstellung im Ticket | Verhalten im Chat-/Voicebot | Dunkelverarbeitung |
|---|---|---|---|---|
| 0 | Kein Kunde erkannt | Kein Kunde in der rechten Leiste | Keine Erkennung | Nein |
| 10-19 | Kunde erkannt, aber nicht legitimiert | Kunde in der rechten Leiste, mit Warnmeldung | Wie keine Erkennung | Nur Rückfragen nach fehlenden Angaben |
| 20 | Kunde erkannt und legitimiert | Kunde in der rechten Leiste | Erkennung, KI-Agenten voll nutzbar | Ja |
| 30 | Kunde manuell bestätigt | Kunde in der rechten Leiste | Entfällt | Entfällt |
Beispiele:
- Level 0: Der Kunde nennt weder Vertrags- noch Kundennummer, und seine E-Mail-Adresse ist nirgends hinterlegt.
- Level 10: Die KI erkennt Kunde 123, in dessen Daten die Adresse jan@berger.de steht. Die E-Mail kommt aber von lea@weber.de.
- Level 20: Die KI erkennt Kunde 123, in dessen Daten die Adresse jan@berger.de steht, und die E-Mail kommt auch von jan@berger.de.
- Level 30: enneo hat den Kunden nur ohne Legitimation erkannt (Level 10), ein Mitarbeiter hat ihn aber bestätigt.
Erkennung der Legitimierungs-Levels im Standard von enneo:
Ab wann ein Kunde Level 20 erreicht, legen Sie mit dem Regeleditor fest. Unter Einstellungen → Kunden- und Vertragssuche gibt es dafür zwei getrennte Regelsätze:
- „Kundenlegitimationsregeln für E-Mails und Briefe" gilt für E-Mails und Briefe.
- „Kundenlegitimationsregeln für Chatbot und Voicebot" gilt für Chat und Telefon.
Für einzelne Chat- oder Voicebots können Sie davon abweichen: Schalten Sie im jeweiligen Bot „Spezifische Kundenlegitimationsregeln verwenden" ein und legen Sie unter „Spezifische Kundenlegitimationsregeln" fest, welche Angaben der Kunde nennen muss. Diese Angaben gelten dann für diesen Bot anstelle des allgemeinen Regelsatzes.
Sind keine Regeln eingerichtet, bleibt ein erkannter Kunde auf Level 10, ist also nicht legitimiert.
Was dem Kunden noch fehlt
Bleibt ein erkannter Kunde nach den Regeln des Regeleditors unter Level 20, nennt die Warnmeldung je nicht erfüllter Prüfgruppe, welche Angaben noch fehlen – mit den Namen der Angaben, nie mit gespeicherten Werten:
Zur Legitimation fehlt noch:
• Vertragsnummer oder Kundennummer
• 2 aus Lieferadresse, Vorname, NachnameJeder Punkt muss erfüllt werden. „A oder B“ heißt, eine der Angaben genügt; „2 aus A, B, C“ heißt, zwei davon. Angaben, die der Kunde nicht per Antwort nachreichen kann – etwa wenn die Absender-E-Mail-Adresse nicht zum Kundenprofil passt –, sind als „per Antwort nicht erfüllbar“ markiert.
Dieselbe Liste bekommt bei E-Mails und Briefen der smarte KI-Agent, der den Lösungsplan erstellt. So kann er den Kunden gezielt nach den fehlenden Angaben fragen. Antwortet der Kunde, prüft enneo die Legitimation erneut; erreicht er Level 20, wird sein Anliegen normal verarbeitet. Wie solche Rückfragen freigegeben werden: Wie die Dunkelverarbeitung die Stufe bestimmt.
Regeleditor für Legitimierungen
Mit diesem Regeleditor lassen sich komplexe Geschäftsregeln abbilden, welche definieren, wann ein Kunde sich ausreichend legitimiert hat, damit sein Anliegen bearbeitet werden kann. Auch kann so sichergestellt werden, dass nur dann eine Dunkelverarbeitung stattfindet, 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 Merkmale 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:
- 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.
Tip
Mit „Test legitimation rules" können Sie Ihre Regeln an einem Beispiel-Ticket ausprobieren, ohne ein echtes Ticket anzulegen. So prüfen Sie neue Matching-Gruppen, bevor sie im Alltag greifen.
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 unter Ablauf der Kundenerkennung definiert zur Verfügung gestellt werden. Der 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 |
| 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 füllen Sie je Kriterium diese Felder aus:
- Bezeichnung: ein beschreibender Name für das Kriterium (z. B. „Bestellnummer angegeben“)
- Schlüssel: das Feld in Ihren Kunden- oder Vertragsdaten, dessen Wert enneo sucht. Punkt-Notation wie
rawData.orderData.numberwird unterstützt. - Grund: der Text, den Mitarbeiter sehen, wenn das Kriterium nicht erfüllt ist (z. B. „Bestellnummer
{0}wurde nicht gefunden.“).{0}wird durch den gesuchten Wert ersetzt. - Suchen in: wo enneo nach dem Wert sucht: „Absender (nur E-Mails und Telefonanrufe)“, „Betreff (nur E-Mails)“ oder „Nachricht“. Groß- und Kleinschreibung spielt bei der Suche keine Rolle.
Individuelle Festlegung von Legitimierungs-Levels
Abweichend vom Regel-Editor können auch nach einer vollständig freien Logik Regeln festgelegt werden, 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 Ihr Code für „Merkmalbasierte Suche von Verträgen“ (unter Einstellungen → Integration in Umsysteme → API-Integration) nicht nur die Kunden- und Vertragsnummer zurückgeben, sondern zusätzlich das Feld:
customerLegitimationHier ein Beispiel für eine Rückgabe des User-Codes bei einem legitimierten Kunden:
{
"contractId":"1234"
"customerId":"Cust-1232131"
"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
}Hier ein Beispiel für eine Rückgabe des User-Codes bei einem nicht Kunden. Hier wird für Sachbearbeiter eine Warnmeldung erscheinen.
{
"contractId":"1234"
"customerId":"Cust-1232131"
"customerLegitimation": 10 // Kunde vermutet, aber nicht sicher
"customerLegitimationMessage": "Kunde hat richtige Vertragsnummer genannt, aber der Name stimmt nicht überein"
}Das Feld customerLegitimation definiert welche Warnmeldung einem User angezeigt werden soll.
Warning
customerLegitimationMessage bekommt auch der smarte KI-Agent, der den Lösungsplan erstellt, und er darf daraus dem Kunden gegenüber zitieren. Die Meldung soll deshalb nennen, was fehlt, und nie einen gespeicherten Wert enthalten.