Customer Identification Process

How Enneo identifies customers and contracts from emails, chats and phone calls

Enneo performs customer identification for each incoming ticket, irrespective of the channel. The goal is to find the corresponding contract and customer in your master data system (ERP/CRM) and to authorize the identification according to the rules set, before requests are further processed or are processed in the dark. Enneo is not the lead system itself, but retrieves the data in real time via User-Code from your source system.

Process for Emails and Letters

1. Analyze message

   Enneo analyzes the message text (as well as attachments, if read out by OCR).

2. Deterministic pre-identification (optional)

   Before the LLM, Enneo attempts to directly find the contract using cost-effective, deterministic methods. If a contractId is found and the ERP APIs return valid contract and customer data for it, the LLM-based feature extraction (Step 3) is skipped.

   Show Procedure and configuration

   Enneo applies three strategies:

   • Regex on contract and customer numbers in the subject and body of the message.
   • Look up sender email address in ERP (via feature-based search with email as parameter).
   • Look up additional email addresses from the message text in the same way (internal domains are excluded).

   Under Settings → Integration into peripheral systems → Customer and contract search → Recognize contracts by search pattern, the following can be configured:

   • the search pattern (regular expression) for contract numbers — e.g. “always 12 digits”, “always starting with 1”, etc.
   • the search pattern for customer numbers
   • or this entire step can be deactivated.
3. Extract features using LLM

   The AI extracts all parameters from the message that are configured under Settings → Integration into peripheral systems → Customer and Contract Search → Search Parameters Customer Identification — e.g. contract number, customer number, name, address, meter number. Only parameters that are explicitly mentioned in the message are passed on.

   The more features you configure here and provide in the source system, the more precise the customer identification will be.

4. Search for contract by feature

   The recognized parameters are passed to the User-Code for the feature-based search (searchContractByFieldsExecutor).

   The User-Code may return a maximum of one contract (or none at all). A list with multiple hits is not permitted — the selection of the most probable contract must already take place in the User-Code.

5. Reload contract and customer data

   As soon as the feature-based search has returned a contractId (and ideally also a customerId), Enneo reloads the complete master data:

   • With the contractId, searchContractByIdExecutor is called.
   • With the customerId from the previous stage — or alternatively the customerId from the contract — searchCustomerByIdExecutor is called.

   Both calls run in parallel, so that the additional latency remains minimal. All fields returned here are subsequently provided to the LLM as context and are thus available for the service response, AI agents and the legitimization check.

   Show Typical fields that are worth based on experience

   The richer a contract and customer are modelled in the ERP, the better answers can be formulated.

   • Master data: First and last name, company, salutation, date of birth, language
   • Contact data: Email, phone number, mobile number
   • Addresses: Billing and delivery address
   • Contract data: Contract type/product, status (active, cancelled, in progress), start/end of contract, notice period, tariff, price
   • Industry/Product specifics: e.g. meter and consumption data (energy), orders and shipping status (trade), policy and claims history (insurance), last invoice and open balance
   • Bank data: IBAN, payment method, SEPA status

   The results of these calls are cached. Via the setting ERP cache duration (in minutes), you can control how long contracts and customer data remain cached before they are fresh reloaded from the source system. A value of 0 disables the cache completely.

6. Check plausibility & legitimization

   Based on the reloaded data, Enneo checks whether features mentioned in the message actually match the identified contract/customer (e.g. sender email = contract email, postal code matches). This will result in the Legitimization Level — more details in Customer Legitimization.

   Show Where the level comes from

   The level is determined by either:

   • the Legitimization rules stored in Enneo (rule editor), or
   • the customerLegitimation field, which the searchContractByFieldsExecutor directly returns from the User-Code — then Enneo takes over this level unchanged.
7. Display & Processing

   • Legitimized (Level ≥ 20): Enneo displays the contract to the case handler and, if configured, can process the request in the dark (automatic execution of AI agents without human approval).
   • Recognized, but not legitimized (Level 10–19): Enneo displays the contract as a suggestion with warning. Processing in the dark does not take place; manual review is required by the case handler.
   • Not recognized (Level 0): No contract is assigned.

Process for Chat and Voicebot

The process is largely identical to email processing — the difference is when and how features are collected.

1. Actively request features

   In the Chatbot/Voicebot prompt, it is configured which data the bot actively requests from the customer (e.g. “Please tell me your contract number and postal code”). Which parameters are used for identification is determined in the chatbot/voicebot configuration (Authentication Instructions).

2. Search contract, reload data, authorize

   As soon as the necessary features are available, the rest proceeds exactly as with emails: Steps 4–6 from above — i.e. searchContractByFieldsExecutor, then searchContractByIdExecutor and searchCustomerByIdExecutor, followed by plausibility and legitimization check.

3. Autonomous execution only from Level ≥ 20

   In the Chat/Voicebot, every customer with a legitimization level < 20 is treated as a non-identified customer. The bot does not perform any customer-related actions, but instead asks the customer again for the missing features, until the threshold is reached.

Manual Search by Case Handler

Regardless of automatic customer identification, case handlers can find contracts at any time via the search field in the UI. For this, Enneo calls the User-Code for the Free text search, which should support search queries by name, email or other relevant fields.

Examples

Email

Show Show concrete example with real values

Incoming email at [e-mail]:

From:    [e-mail]
Subject: Question about my invoice

Dear Sir or Madam,

I have a question about the invoice from last month
for my account with customer number K-2024-0815. My name is Maria Schmidt,
I live at Hauptstraße 5, 80331 Munich.

Many Regards
Maria Schmidt

1. Analysis

   Body and subject are prepared as plain text.

2. Deterministic pre-identification

   Regex searches for the configured contract number pattern (e.g. [0-9]{6,7}). The customer number K-2024-0815 does not match the format, the sender [e-mail] is not registered as a contract email in the ERP → no match, continue to step 3.

3. LLM extraction

   Based on the configured search parameters, the LLM provides:

   {
     "customerId": "K-2024-0815",
     "firstName":  "Maria",
     "lastName":   "Schmidt",
     "zip":        "80331",
     "city":       "Munich",
     "street":     "Hauptstraße 5"
   }
   
4. searchContractByFieldsExecutor

   Call with the extracted parameters plus ticket context:

   // Input
   {
     "customerId": "K-2024-0815",
     "firstName":  "Maria",
     "lastName":   "Schmidt",
     "zip":        "80331",
     "city":       "Munich",
     "street":     "Hauptstraße 5",
     "email":      "[e-mail]",
     "ticketId":   4711
   }
   
   // Output (from user-code)
   {
     "contractId":  "C-987654",
     "customerId":  "K-2024-0815",
   
     // Optional: Preview tiles for the right side in the ticket
     // (Quick info that the agent sees immediately)
     "agentPreview": [
       { "label": "Status",           "value": "Active"     },
       { "label": "Outstanding Balance",    "value": "0.00 €"    },
       { "label": "Last Invoice",  "value": "€84.20",
         "tooltip": "Sent on 2026-04-10" }
     ]
   }
   
5. Reloading of master data

   searchContractByIdExecutor and searchCustomerByIdExecutor run in parallel:

   // searchContractByIdExecutor — Input
   { "contractId": "C-987654" }
   
   // Output
   {
     "id":         "C-987654",
     "customerId": "K-2024-0815",
     "product":    "Standard subscription",
     "status":     "active",
     "startDate":  "2023-04-01",
     "lastInvoice": { "date": "2026-04-10", "amount": 84.20, "open": 0.00 }
   }
   

   // searchCustomerByIdExecutor — Input
   { "customerId": "K-2024-0815" }
   
   // Output
   {
     "id":         "K-2024-0815",
     "firstName":  "Maria",
     "lastName":   "Schmidt",
     "email":      "[e-mail]",
     "phone":      "[phone]",
     "address":    { "street": "Hauptstraße 5", "zip": "80331", "city": "Munich" },
     "language":   "de",
     "iban":       "DE89 3704 0044 0532 0130 00"
   }
   

   All these fields then go as context to the LLM and are available to AI agents — for example, to answer the question about the last invoice in detail.

6. Plausibility & Legitimation

   Sender email matches the contract email, name and zip code from the message match the ERP data → Legitimation level 20.

7. Display & Processing

   The customer is displayed as legitimated, a suitable AI agent “Invoice Information” can process the concerns in the dark.

Voicebot

Show Show a specific example of a call

A customer calls hotline [phone]. The voicebot configuration stipulates that contract number and postal code must be mentioned for legitimation (the same scheme applies analogously to the chatbot).

1. Ask for characteristics actively

   Dialogue:

   Bot:    Good day, this is the service assistant of Example-Company.
           How can I assist you?
   Customer:  I would like to change my bank details.
   Bot:    Of course. In order to uniquely identify you, could you 
           please give me your contract number and your postal code?
   Customer:  Contract number is C-987654, postal code 80331.
   
2. searchContractByFieldsExecutor

   As soon as the contract number and zipcode are available, the user code is called:

   // Input
   {
     "contractId": "C-987654",
     "zip":        "80331",
     "phone":      "[phone]",
     "ticketId":   8132
   }
   
   // Output (from user-code)
   {
     "contractId":  "C-987654",
     "customerId":  "K-2024-0815",
   
     // Optional: Preview tiles for the right side in the ticket
     "agentPreview": [
       { "label": "Status",          "value": "Active"  },
       { "label": "Outstanding Balance",   "value": "0.00 €" }
     ]
   }
   
3. Reloading master data

   searchContractByIdExecutor and searchCustomerByIdExecutor are called parallel (identical inputs/outputs as in the email example). All fields then go as context to the voicebot.

4. Plausibility & Legitimation

   Mentioned postcode 80331 matches the address from the ERP and the caller is calling from the phone number [phone], which is registered to the customer → Legitimation level 20.

   Had the customer only mentioned the contract number, but no matching postcode, the level would remain at 10 — the voicebot would ask again for the missing characteristics instead of proceeding.

5. Autonomous execution

   Only then may the voicebot carry out customer-related actions. The AI agent “Change Bank Details” is called, asks for the new IBAN, validates it and writes it back to the ERP.

   Bot:    Thank you, you are now authenticated. Please give me the
           new IBAN.
   Customer:  DE12 3456 7890 1234 5678 90.
   Bot:    The IBAN ends in 5890, correct?
   Customer:  Yes.
   Bot:    Thank you, your bank details have been changed. Would you 
           like a written confirmation by email?