Use this file to discover all available pages before exploring further.
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.
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 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.
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.
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.
From: maria.schmidt@example.comSubject: Question about my invoiceDear Sir or Madam,I have a question about the invoice from last monthfor my account with customer number K-2024-0815. My name is Maria Schmidt,I live at Hauptstraße 5, 80331 Munich.Many RegardsMaria 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 maria.schmidt@example.com 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:
A customer calls hotline +49 89 1234500. 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": "+49891234567", "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 +49 89 1234567, 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?
