Customer Validation

Once a customer, or to put it more precisely a contract, has been recognised, enneo initiates a check if the recognition is specific enough for further processing. This concept is the "validation" in enneo.

Recognised but not validated customers are suggested to the user, but with a corresponding warning message. This allows the user to closely examine whether the AI recognition was correct and all necessary features have been mentioned.

Once a customer is validated, this warning message disappears. Dark processing without human interaction is also only possible for customers who have been validated.

Typical validation rules consist of 2 independent features, which must match each other. This ensures that there is no misidentification. Examples of real identification methods are listed further below.

Validation always takes place at the contract level, not at the customer level, although characteristics from the customer data can also be used. This is how enneo ensures that contract-related changes are also carried out for the correct contract.

The 4 Stages of Validation

The customer recognition in enneo goes through the following stages of validation:

Recognising the Validation Levels in enneo Standard:

• For Chat and Voice, the decision as to when Level 20 is achieved is made via the Assistant authentication instructions setting in the respective chat/voice bot. The default setting is Contract number (contractId) and zip code (zip). The customer is only validated if the combination of both is mentioned.
• For Emails and Letters, the decision as to when Level 20 is reached is made via a rule editor for validations. This allows you to define complex security levels.

Rule Editor for Validations for Emails and Letters

[The rule editor is currently under development]

This rule editor allows you to map complex business rules that define when a customer has adequately validated themselves to process their concerns. It can also ensure that dark processing only takes place when the customer has been clearly and adequately identified.

Examples of rules that can be depicted with this editor:

• Contract number OR customer number mentioned AND sender email matches with ERP
• First AND last name mentioned AND (Contract OR Customer OR Counter number mentioned) AND (Billing/Delivery Address OR Email matches data from ERP
• Total 4 features mentioned; of which at least 1 mandatory feature (Contract, Customer or Order ID).

For the specific implementation of these examples, please unfold here:

Procedure

This is how you configure rules in two steps:

1. Create Matching Groups

• A rule consists of one or more matching groups.
• A customer is only considered validated if all matching groups are successfully fulfilled.
• Each matching group has:
  • A title (e.g. "Identification by ID")
  • A minimum number of criteria that must be fulfilled within this group
  • A selection of criteria (Standard criteria from enneo and optionally your own criteria)

1. Choose criteria per matching group

• Within a matching group, you choose the criteria to be checked.
• The group is considered fulfilled if at least as many criteria apply as specified under "Minimum quantity".

Available Criteria

For the typical criteria, e.g. mention of contract or customer number, enneo has already developed test criteria. These can be selected easily.

The respective data fields, i.e. the concrete contract number in a test for mention of the contract number, must of course be defined as defined in /de/system-integration/customer-recognition/flow. The corresponding name of the variable is also mentioned in the following table.

Standard Criteria

Own (custom) criteria

If you wish to use distinctive criteria from your ERP in addition to the standard ones (e.g. order number, meter number), you can create custom criteria.

For this, you define:

• The name of the criterion (e.g. "Order number stated")
• Data path/variable that Enneo should search for (must correspond to a field in your customer / contract data; shopNotation like rawData.orderData.number is supported)
• Text to display when not successful (e.g. "Order number 0 was not found."; 0 is replaced by the searched value)

Individual definition of authentication levels

Apart from the rule editor, rules can be defined according to a completely free logic, deciding when a certain level should be reached, thereby depicting individual customer rules. In this context, additional authentication information can be obtained via API.

For this, not only the customer and contract number must be returned in the User Code under ERP-Integration for Feature-based contract search, but also the field

customerLegitimation

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

{
  "contractId":"1234"
  "customerId":"Cust-1232131"
  "customerLegitimation": 20 // Customer is securely legitimized: Dark processing for e-mail is possible; full access to AI agents is possible for chat and voice
 }

Here is an example of a return of the user code for a non customer. A warning message will appear for the clerks.

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

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