Authentication of Clients

As soon as a client, or more precisely a contract, has been recognized, Enneo initiates a review to verify if the recognition is specific enough for further processing. This concept is “authentication” in Enneo. Recognized but not authenticated clients are suggested to the user, but with an appropriate warning message, so the user can thoroughly check whether the AI recognition was correct and all necessary features have been named. Once a client is authenticated, this warning message disappears. Dark processing without human interaction is also only possible for clients who have been authenticated. Typical authentication rules consist of 2 independent features that need to match. This ensures that there is no misidentification. Examples of real identification methods are listed further below. Authentication always takes place at the contract level and not at the client level, whereby features from the client data can also be used. This way, Enneo ensures that contract-related changes are executed for the correct contract.

The 4 Stages of Authentication

Client recognition in Enneo has the following stages of authentication:

Description	Meaning (Email)	Meaning (Chatbot/Voicebot)	Example	Level	Dark processing
No client identified	Service agent sees no client	No recognition	Client mentions neither contract nor client number, used email is also not deposited anywhere	0	No
Client recognized, but not authenticated	Service agent sees client on the right bar, but with a warning	As with no recognition	AI has recognized client 123, whose documents show the email tom@smith.com. However, the email is from michael@jackson.com	10-19	No
Client recognized by the AI and data matches	Service agent sees client on the right bar	Recognition, full execution of AI agents	AI has recognized client 123, whose documents show the email tom@smith.com. The email comes from tom@smith.com	20	Yes
Client manually confirmed	Service agent sees client on the right bar	Not applicable	Client was only recognized by Enneo without authentication (level 10), but confirmed by the user	30	(Not applicable)

Detection of Authentication Levels in the Enneo Standard:

For Chat and Voice, the setting when level 20 is reached is determined by the Assistant authentication instructions in the respective chat/voicebot. The default setting is contract number (contractId) and zip code (zip). Only when the combination of both is mentioned, the client is authenticated.
For Emails and Letters, the setting when level 20 is reached is made via a rule editor for authentications. This editor allows to set up complex security levels.

Rule Editor for Authentications in Emails and Letters

[The rule editor is currently under development] This rule editor can depict complex business rules which define when a client has sufficiently authenticated themselves to process their request. It also ensures that dark processing only takes place when the client has been clearly and sufficiently identified. Examples of rules that can be depicted with this editor:

Contract number OR customer number mentioned AND sender email matches ERP.
First AND last name mentioned AND (contract OR customer OR meter number mentioned) AND (invoice/delivery address OR email matches data from ERP.
4 features mentioned in total; of which at least 1 mandatory feature (contract, customer or order ID).

For the concrete implementation of these examples, please expand here:

Show Content

Example 1 (Standard)

Business rule: Contract number OR customer number mentioned AND sender email matches ERP.
Implementation:
- Group 1 “ID mentioned”: Minimum quantity 1; Criteria: Contract ID, Customer ID
- Group 2 “Sender email matches”: Minimum quantity 1; Criterion: Sender email matches

Example 2

Business rule: All three conditions must be met:
1. First AND last name mentioned
2. Contract OR customer OR meter number available
3. Invoice/delivery address OR email matches ERP
Implementation:
- Group 1 “Full name mentioned”: Minimum quantity 2; Criteria: First name, Last name
- Group 2 “An identification number mentioned”: Minimum quantity 1; Criteria: Contract ID, Customer ID; user-defined: Meter number
- Group 3 “Address or email matches”: Minimum quantity 1; Criteria: Invoice/delivery address (exact/similar), Email match

Example 3

Business rule: 3 criteria met in total; at least 1 mandatory criterion mentioned (contract, customer or order ID).
Implementation:
- Group 1 “Mandatory requirement met”: Minimum quantity 1; Criteria: Contract ID, Customer ID; user-defined: Order ID
- Group 2 “3 criteria mentioned in total”: Minimum quantity 3; Criteria: Last name, Addresses (exact/similar), Email match; plus the IDs; user-defined: Order ID

Procedure

Configure rules in two steps:

Create matching groups

A rule consists of one or more matching groups.
A client is only considered authenticated if all matching groups are successfully fulfilled.
Each matching group has:
- A name (e.g. “Identification via ID”)
- A minimum number of criteria that must be met within this group
- A selection of criteria (standard criteria from enneo and optionally your own criteria)

Choose criteria for each matching group

Within a matching group, you select the criteria to be checked.
The group is considered fulfilled if at least as many criteria are met as defined under “Minimum quantity”.

Available Criteria

Enneo has pre-developed test criteria for typical criteria, such as the mentioning of contract or client number. These can simply be clicked on. The respective data fields, i.e., the actual contract number in a check for the mention of the contract number, must of course be made available as defined in /de/system-integration/customer-recognition/flow. The corresponding name of the variable is also mentioned in the following table.

Standard Criteria

Standard criterion	Data fields used for the match
Sender’s email matches data in the ERP	email in one of a client’s contracts
Email mentioned in the message matches data in the ERP	email in one of a client’s contracts
Phone number matches data in the ERP	phone in client or contract data
Contract ID mentioned	Contract ID (from ERP/Contract data)
Client ID mentioned	Client ID (from ERP/Client data)
First name mentioned	firstname in client or contract data
First name or initial of the first name mentioned	firstname in client or contract data	Last name mentioned	lastname in customer or contract data
Exact delivery address mentioned	deliveryAddress
Exact billing address mentioned	billingAddress
Similar delivery address mentioned (≥ 80% match)	deliveryAddress
Similar billing address mentioned (≥ 80% match)	billingAddress

Own (custom) Criteria

If you want to use your own features from your ERP in addition to the standard criteria (e.g. order number, meter number), you can create custom criteria. For this you define:

Name of the criterion (e.g. “Order number specified”)
Data path/variable that Enneo should search for (must correspond to a field in your customer/contract data; dot notation like rawData.orderData.number is supported)
Display text in case of failure (e.g. “Order number 0 was not found.”; 0 is replaced by the searched value)

Individual Determination of Legitimation Levels

Contrary to the rule editor, customers can also determine rules according to an entirely free logic, from when a certain level should be attained, in order to thus depict customer-specific rules. In the course of this, supplementary legitimization information can also be obtained via API, for example. For this purpose, not only should the customer and contract number be returned under ERP integration in the user code for Feature-based search for contracts, but also the field

customerLegitimation

Here is an example of a return from user code for a legitimate customer:

{
  "contractId":"1234"
  "customerId":"Cust-1232131"
  "customerLegitimation": 20 // Customer is definitely legitimized: Dark processing for email is possible; Full access to AI agents is possible with chat and voice
 }

Here is an example of a return from user code for a non-customer. Here, a warning message will appear for staff.

{
  "contractId":"1234"
  "customerId":"Cust-1232131"
  "customerLegitimation": 10 // Customer is suspected, but not certain
  "customerLegitimationMessage": "Customer has stated the correct contract number, but the name does not match"
}

The field customerLegitimation defines which warning message should be displayed to a user.

Show Representation with older data structure from the feature-based search

Customers who use the old version (v1) of the data structure for feature-based searches use this structure.Here is an example of a return from user code for a legitimate customer:

[
 {
  "id":"1234"
  "customerLegitimation": 20 // Customer is definitely legitimized: Dark processing for email is possible; Full access to AI agents is possible with chat and voice
  "contract":{
    "customerId":"Cust-1232131"
  }
 }
]

Here is an example of a return from the user code for a non-customer. Here, a warning message will appear for staff.

[
 {
  "id":"1234"
  "customerLegitimation": 10 // Customer is suspected, but not certain
  "contract":{
    "customerId":"Cust-1232131"
  },
  "customerLegitimationMessage": "Customer has stated the correct contract number, but the name does not match"
 }
]

Fundamentals

Tickets

Work Resources

Routing & Tags

User Management

Quality Assurance

System Integration & Administration

AI Agents & Automation

Reports & Analytics

The 4 Stages of Authentication

Detection of Authentication Levels in the Enneo Standard:

Rule Editor for Authentications in Emails and Letters

Example 1 (Standard)

Example 2

Example 3

Procedure

Available Criteria

Standard Criteria

Own (custom) Criteria

Individual Determination of Legitimation Levels

Fundamentals

Tickets

Work Resources

Routing & Tags

User Management

Quality Assurance

System Integration & Administration

AI Agents & Automation

Reports & Analytics

Documentation Index

​The 4 Stages of Authentication

​Detection of Authentication Levels in the Enneo Standard:

​Rule Editor for Authentications in Emails and Letters

​Example 1 (Standard)

​Example 2

​Example 3

​Procedure

​Available Criteria

​Standard Criteria

​Own (custom) Criteria

​Individual Determination of Legitimation Levels

The 4 Stages of Authentication

Detection of Authentication Levels in the Enneo Standard:

Rule Editor for Authentications in Emails and Letters

Example 1 (Standard)

Example 2

Example 3

Procedure

Available Criteria

Standard Criteria

Own (custom) Criteria

Individual Determination of Legitimation Levels