Enneo

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:

LevelStufeDarstellung im TicketVerhalten im Chat-/VoicebotDunkelverarbeitung
0Kein Kunde erkanntKein Kunde in der rechten LeisteKeine ErkennungNein
10-19Kunde erkannt, aber nicht legitimiertKunde in der rechten Leiste, mit WarnmeldungWie keine ErkennungNur Rückfragen nach fehlenden Angaben
20Kunde erkannt und legitimiertKunde in der rechten LeisteErkennung, KI-Agenten voll nutzbarJa
30Kunde manuell bestätigtKunde in der rechten LeisteEntfälltEntfä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, Nachname

Jeder 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:

  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.

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

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
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 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.number wird 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:

customerLegitimation

Hier 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.