Use this file to discover all available pages before exploring further.
For every incoming ticket — regardless of channel — Enneo performs a customer identification. The goal is to find the matching contract and customer in your master-data system (ERP/CRM) and legitimize the match against your configured rules before any request is processed further or dark-processed. Enneo itself is not the system of record — it queries the data in real time via user code from your source system.
Enneo analyzes the message body (and attachments, when extracted via OCR).
2
Deterministic pre-detection (optional)
Before the LLM step, Enneo tries to resolve the contract with cheap, deterministic methods. If a contractId is found this way and the ERP APIs return valid contract and customer data for it, the LLM-based attribute extraction (step 3) is skipped.
Show Methods and configuration
Enneo applies three strategies:
Regex on contract and customer numbers in the subject and body.
Sender email address lookup against the ERP (via the attribute-based search with email as a parameter).
Other email addresses found in the body are looked up the same way (internal domains are excluded).
Under Settings → Integration with external systems → Customer and contract search → Detect contracts via search pattern you can configure:
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 disable this entire step.
3
Extract attributes via LLM
The AI extracts every parameter configured under Settings → Integration with external systems → Customer and contract search → Search parameters for customer identification — e.g. contract number, customer number, name, address, meter number. Only attributes explicitly mentioned in the message are passed on.
The more attributes you configure here and expose in your source system, the more accurate the customer identification gets.
4
Search the contract by attributes
The recognized parameters are handed to the user code for the attribute-based search (searchContractByFieldsExecutor).The user code must return at most one contract (or none). A list of multiple matches is not allowed — picking the most likely contract has to happen inside the user code.
5
Load contract and customer data
Once the attribute-based search has returned a contractId (and ideally also a customerId), Enneo loads the full master data:
With the customerId returned from the previous stage — or, as a fallback, the customerId carried on the contract — searchCustomerByIdExecutor is called.
Both calls run in parallel, so the added latency is minimal. Every field returned here is then made available to the LLM as context and used for the service response, for AI agents, and for the legitimation check.
Show Fields that typically pay off
The richer your contract and customer model in the ERP, the better the answers Enneo can produce.
Master data: first and last name, company, salutation, date of birth, preferred language
Industry-/product-specific: e.g. meter & consumption data (utilities), orders & shipment status (retail), policy & claims history (insurance), last invoice and open balance
Banking data: IBAN, payment method, SEPA status
Results of these calls are cached. The ERP cache duration setting (in minutes) controls how long contract and customer data stay cached before they are reloaded fresh from the source system. A value of 0 disables the cache entirely.
6
Plausibility & legitimation check
Using the freshly loaded data, Enneo verifies that the attributes mentioned in the message actually match the resolved contract/customer (e.g. sender email = contract email, zip code matches). The result is the legitimation level — for details see Customer legitimation.
Show Where the level comes from
The level is determined either by:
the legitimation rules configured in Enneo (rule editor), or
the customerLegitimation field that the searchContractByFieldsExecutor returns directly from the user code — in which case Enneo uses that level as-is.
7
Presentation & processing
Legitimized (level ≥ 20): Enneo shows the contract to the agent and — if configured — can dark-process the request (AI agents execute automatically, without human approval).
Recognized but not legitimized (level 10–19): Enneo proposes the contract with a warning. Dark processing is not allowed; the agent reviews manually.
Not recognized (level 0): No contract is assigned.
The flow is largely identical to email — what differs is when and how the attributes are collected.
1
Actively ask for attributes
The chatbot/voicebot prompt defines what the bot actively asks the customer for (e.g. “Please provide your contract number and zip code”). Which parameters are used for identification at all is configured in the chatbot/voicebot’s Authentication Instructions.
2
Search contract, load data, legitimize
Once the required attributes are available, the rest runs exactly as for email: steps 4–6 above — searchContractByFieldsExecutor, then searchContractByIdExecutor and searchCustomerByIdExecutor, then the plausibility and legitimation check.
3
Autonomous execution only at level ≥ 20
On chat/voice, any customer with a legitimation level below 20 is treated as a non-identified customer. The bot performs no customer-specific actions and keeps asking for the missing attributes until the threshold is reached.
Independent of the automatic identification flow, agents can search for 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 queries by name, email, or other relevant fields.
From: maria.schmidt@example.comSubject: Question about my invoiceHello,I have a question about last month's invoice on my account(customer number K-2024-0815). My name is Maria Schmidt,I live at Hauptstraße 5, 80331 Munich.Best regardsMaria Schmidt
1
Analyze
Body and subject are prepared as plain text.
2
Deterministic pre-detection
Regex looks for the configured contract-number pattern (e.g. [0-9]{6,7}). The customer number K-2024-0815 doesn’t match that format, and the sender maria.schmidt@example.com is not registered as a contract email in the ERP → no hit, continue with step 3.
3
LLM extraction
Based on the configured search parameters, the LLM returns:
All of these fields are then passed as context to the LLM and become available to AI agents — e.g. to answer the invoice question with concrete numbers.
6
Plausibility & legitimation
Sender email matches the contract email, name and zip from the message match the ERP data → legitimation level 20.
7
Presentation & processing
The customer is shown as legitimized; a matching “invoice inquiry” AI agent can dark-process the request.
A customer calls the hotline +49 89 1234500. The voicebot is configured to require contract number and zip code for legitimation (the same scheme applies to the chatbot).
1
Actively ask for attributes
Conversation:
Bot: Hello, this is the Example-Company service assistant. How can I help you?Customer: I'd like to change my bank details.Bot: Sure. To identify you, please tell me your contract number and your zip code.Customer: Contract number is C-987654, zip code 80331.
2
searchContractByFieldsExecutor
Once contract number and zip are available, the user code is called:
// Input{ "contractId": "C-987654", "zip": "80331", "phone": "+49891234567", "ticketId": 8132}// Output (from the user code){ "contractId": "C-987654", "customerId": "K-2024-0815", // Optional: preview tiles for the right-hand sidebar in the ticket "agentPreview": [ { "label": "Status", "value": "Active" }, { "label": "Open balance", "value": "€0.00" } ]}
3
Load full master data
searchContractByIdExecutor and searchCustomerByIdExecutor run in parallel (identical inputs/outputs to the email example). All fields are then passed as context to the voicebot.
4
Plausibility & legitimation
The stated zip 80331 matches the address in the ERP and the caller is calling from +49 89 1234567, which is registered on the customer → legitimation level 20.Had the customer only stated the contract number but no matching zip, the level would have stayed at 10 — the voicebot would have asked again for the missing attributes instead of continuing.
5
Autonomous execution
Only now is the voicebot allowed to perform customer-specific actions. The “change bank details” AI agent kicks in, asks for the new IBAN, validates it, and writes it back to the ERP.
Bot: Thank you, you are now authenticated. Please tell me your new IBAN.Customer: DE12 3456 7890 1234 5678 90.Bot: That IBAN ends in 5890, correct?Customer: Yes.Bot: Thank you, your bank details have been updated. Would you like a written confirmation by email?
