# Enneo documentation
> Enneo — AI-native customer service platform documentation
This document contains the full content of all documentation pages for AI consumption.
---
## Erste Schritte
**URL:** https://richard-dev-playground.enneo.ai/docs/de/first-setup
## Grundlagen
Enneo verarbeitet Kundenanliegen in Tickets. Tickets entstehen durch eingehende Anfragen, die über beliebige Kommunikationskanäle übermittelt werden. Sobald ein Ticket existiert, kann es manuell oder durch KI-Agenten bearbeitet werden. Kundendaten stellen den Bezug zwischen Ticket und Kunde her und bilden die Voraussetzung für datengestützte Bearbeitung und Automatisierung.
Die grundlegenden Funktionsbausteine sind demnach:
**1. [Anbindung von Kommunikationskanälen](/docs/de/system-integration/integration-of-contact-channels/contact-channels-overview)**
Damit Enneo operativ arbeiten kann, benötigt die Plattform mindestens einen angebundenen Kommunikationskanal. Erst durch eingehende Nachrichten können Tickets entstehen. Dabei spielt es keine Rolle, ob es sich um E-Mail, Voice, Chat oder andere Kanäle handelt; die technische Logik bleibt identisch.
Die Auswahl des ersten Kanals erfolgt projektbezogen. Enneo kann mit jedem Kanal beginnen und später modulare Erweiterungen erhalten.
**2. [Tickets](/docs/de/ticket-processing/tickets-in-enneo)**
Eingehende Nachrichten erzeugen ein Ticket, das die gesamte Konversation umfasst. Tickets bilden die Grundlage für die Bearbeitung und ermöglichen sowohl manuelle Aktivitäten als auch KI-unterstützte Schritte. Ohne Ticket findet keine Prozessverarbeitung statt.
**3. [Kundendaten](/docs/de/system-integration/customer-recognition/flow)**
Durch die Anbindung von ERP- oder CRM-Systemen werden Kunden- und Vertragsdaten in Enneo verfügbar und bilden die Grundlage für kontextbezogene Bearbeitung und automatisierte Vorgänge.
**4. [KI-Agenten](/docs/de/ai-functions-agents/ai-agents-for-enneo)**
KI-Agenten analysieren Inhalte, treffen Entscheidungen innerhalb definierter Regeln und unterstützen die Bearbeitung. Der operative Einsatz setzt bestehende Tickets voraus. Für datengestützte Verarbeitung werden kundenzentrierte Daten benötigt, sodass KI-Agenten Informationen abrufen oder aktualisieren können.
## Empfohlene Umsetzung
Bei der Integration hat sich diese Abfolge bewährt:
1. Kommunikationskanal
2. ERP- oder CRM-Daten
3. KI-Agenten
Die Reihenfolge basiert auf praktischen Erfahrungen und bildet die fachlichen Abhängigkeiten ab, ohne einen festen Installationsablauf vorzugeben.
---
## Navigation
**URL:** https://richard-dev-playground.enneo.ai/docs/de/navigation
Diese Übersicht zeigt die zentralen Bereiche von Enneo. Jeder Bereich entspricht einem Funktionsschwerpunkt der Plattform und enthält Erläuterungen, Anleitungen oder Beispiele zur jeweiligen Anwendung.
---
## Enneo im Überblick
**URL:** https://richard-dev-playground.enneo.ai/docs/de/welcome
## Was Enneo auszeichnet
Enneo wurde von Grund auf als KI-System entwickelt – nicht als nachträgliches Add-on. Alle Kontaktkanäle, Prozesse und Automatisierungen folgen einer **zentralen Logik**, die einmal definiert und systemweit konsistent ausgeführt wird. So entsteht skalierbarer Kundenservice, der von assistierter Bearbeitung bis zur kontrollierten Vollautomatisierung reicht.
Zentrale Prinzipien von Enneo sind dabei Transparenz, Nachvollziehbarkeit und Kontrolle: KI unterstützt dort, wo sie sinnvoll ist, und bleibt steuerbar, überprüfbar und messbar.
- **Alle Informationen in einem Vorgang**
Jede Kundenanfrage – unabhängig vom Kanal – wird in einem Ticket gebündelt. Konversationen, Metadaten, Entscheidungen und Aktionen sind vollständig im Kontext nachvollziehbar.
- **Zentrale Entscheidungslogik**
KI erkennt Inhalte, klassifiziert Anliegen und trifft Entscheidungen auf Basis klar definierter Regeln, Tags und Automatisierungsstufen – einheitlich über alle Kanäle hinweg.
- **Assistenz statt Overload**
Wo menschliche Expertise gefragt ist, liefert Enneo strukturierte Kontexte, Empfehlungen und Antwortentwürfe, statt zusätzliche Komplexität zu erzeugen.
Das Ergebnis sind konsistente Prozesse, kürzere Reaktionszeiten und eine messbare Entlastung von Service-Teams.
## Für anspruchsvolle Service-Umgebungen entwickelt
Enneo ist speziell für komplexe und regulierte Service-Umgebungen konzipiert – insbesondere für den Energiesektor mit seinen spezifischen IT-Systemen, Prozessen und Compliance-Anforderungen. Die Plattform verbindet einen modernen Omnichannel-Ansatz mit einem flexiblen KI-Editor, der tiefgreifende Automatisierung ermöglicht, ohne Kontrolle abzugeben.
Unternehmen können Enneo modular einführen: vom ersten Kanal bis zur vollständigen Omnichannel-Lösung, vom Assist-Modus bis zur kontrollierten Vollautomatisierung. Bestehende Systeme und Prozesse lassen sich nahtlos integrieren.
So entsteht eine skalierbare, lernfähige Plattform, die Servicequalität verbessert, operative Aufwände reduziert und Kundeninteraktion zukunftssicher gestaltet.
---
## Getting Started
**URL:** https://richard-dev-playground.enneo.ai/docs/en/first-setup
## Basics
Enneo processes customer requests into tickets. Tickets are created by incoming requests, which are transmitted via any communication channel. Once a ticket exists, it can be processed manually or by AI agents. Customer data establishes the link between the ticket and the customer and forms the basis for data-driven processing and automation.
The basic functional building blocks are therefore:
**1. [Integration of Communication Channels](/docs/en/system-integration/integration-of-contact-channels/contact-channels-overview)**
In order for Enneo to operate, the platform requires at least one integrated communication channel. Incoming messages can create tickets. It doesn't matter whether it's email, voice, chat, or other channels; the technical logic remains identical.
The choice of the first channel is project-specific. Enneo can start with any channel and receive modular extensions later.
**2. [Tickets](/docs/en/ticket-processing/tickets-in-enneo)**
Incoming messages generate a ticket, encompassing the entire conversation. Tickets form the basis for processing and enable both manual activities and AI-supported steps. Without a ticket, no process processing occurs.
**3. [Customer Data](/docs/en/system-integration/customer-recognition/flow)**
By integrating ERP or CRM systems, customer and contract data become available in Enneo and form the basis for context-related processing and automated procedures.
**4. [AI Agents](/docs/en/ai-functions-agents/ai-agents-for-enneo)**
AI agents analyze content, make decisions within defined rules, and support processing. Operational use requires existing tickets. For data-driven processing, customer-centered data is needed so AI agents can retrieve or update information.
## Recommended Implementation
This order has proven successful in integration:
1. Communication channel
2. ERP or CRM data
3. AI agents
The order is based on practical experience and reflects the subject matter dependencies without dictating a fixed installation sequence.
---
## Navigation
**URL:** https://richard-dev-playground.enneo.ai/docs/en/navigation
This overview presents the central areas of Enneo. Each area corresponds to a function focus of the platform and contains explanations, instructions or examples for the respective application.
---
## Overview of Enneo
**URL:** https://richard-dev-playground.enneo.ai/docs/en/welcome
## What sets Enneo apart
Enneo was designed from the ground up as an AI system – not as a subsequent add-on. All contact channels, processes, and automations follow a **central logic** that is defined once and consistently executed system-wide. The result is scalable customer service that ranges from assisted processing to controlled full automation.
Transparency, traceability, and control are essential principles of Enneo: AI supports where it makes sense and remains controllable, checkable and measurable.
- **All information in one process**
Every customer inquiry – regardless of the channel – is bundled into a single ticket. Conversations, metadata, decisions and actions are fully traceable in context.
- **Central decision logic**
AI recognizes content, classifies concerns, and makes decisions based on clearly defined rules, tags, and automation levels – consistent across all channels.
- **Assistance instead of overload**
Where human expertise is needed, Enneo delivers structured contexts, recommendations, and draft responses, rather than creating additional complexity.
The result are consistent processes, shorter response times, and a measurable relief to service teams.
## Designed for demanding service environments
Enneo is specifically designed for complex and regulated service environments – especially for the energy sector with its specific IT systems, processes, and compliance requirements. The platform combines a modern omnichannel approach with a flexible AI editor that facilitates profound automation without relinquishing control.
Companies can introduce Enneo modularly: from the first channel to a complete omnichannel solution; from assist mode to controlled full automation. Existing systems and processes can be seamlessly integrated.
The result is a scalable, learnable platform that improves service quality, reduces operational efforts, and ensures future-proof customer interaction.
---
## KI-Agenten in Enneo
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/ai-agents-for-enneo
**Description:** Einsatz, Arten und Vorteile
### Vielfältige Einsatzmöglichkeiten
Enneo stellt standardmäßig zwölf spezialisierte KI-Agenten bereit, die kanalübergreifend agieren. Dazu gehören:
* **Abschlags-Agent:** Unterstützt Kunden bei Abschlagsanpassungen und deren Verwaltung.
* **Basis-Agent:** Erledigt grundlegende Aufgaben und leitet komplexe Anfragen weiter.
* **Bankdaten-Agent:** Hilft Kunden bei der Aktualisierung ihrer Bankverbindungen.
* **Fälligkeits-Agent:** Gibt Informationen zu Fälligkeiten und aktualisiert Zahlungsziele.
* **Guthaben-Agent:** Unterstützt bei der Verwaltung von Guthaben und deren Verrechnung.
* **Kündigungs-Agent:** Hilft bei Vertragskündigungen und den nächsten Schritten.
* **Lastschriftwiderrufs-Agent:** Widerruft ein SEPA-Lastschriftmandat auf Wunsch des Kunden.
* **Stammdaten-Agent:** Hilft Kunden bei der Änderung von Stammdaten.
* **Tarifberatungs-Agent:** Berät wechselwillige Kunden zu attraktiven Tarifen.
* **Wechsel-Agent:** Unterstützt Kunden während des Wechselprozesses.
* **Werbeeinverständnis-Agent:** Hilft bei der Verwaltung von Marketinganfragen und Opt-Ins.
* **Widerrufs-Agent:** Unterstützt beim Widerrufen von Verträgen und beantwortet dazugehörige Fragen.
### Zwei Arten von KI-Agenten
Enneo bietet **zwei flexible Ansätze**, um die Automatisierung optimal an die Bedürfnisse des Kundenservices anzupassen:
**1. Smarte KI-Agenten:** Diese KI-Agenten arbeiten selbstständig und treffen Entscheidungen auf Basis vorhandener Daten, früherer Anfragen und des jeweiligen Kontexts. Sie lernen ständig dazu und passen sich neuen Anforderungen an. Für die Einrichtung und Nutzung smarter KI-Agenten sind keine technischen Vorkenntnisse nötig. Die Einrichtung erfolgt über natürliche Sprache, ist einfach und benutzerfreundlich, sodass auch Personen ohne IT-Erfahrung die Automatisierung problemlos steuern können.
**2. Regelbasierte KI-Agenten:** Diese KI-Agenten arbeiten nach fest definierten Regeln und Workflows, die genau auf die jeweiligen Prozesse zugeschnitten sind. Sie bieten maximale Kontrolle und Flexibilität, da jeder Schritt präzise festgelegt werden kann. Diese Lösung eignet sich besonders für klar strukturierte Aufgaben und deterministische Prozesse. Allerdings erfordert die Einrichtung etwas mehr Zeit und technisches Verständnis, um die Workflows optimal zu gestalten.
### Vorteile im Überblick
Der Einsatz von KI-Agenten bietet gleich mehrere Vorteile:
* **Effizienzsteigerung:** Repetitive Aufgaben werden automatisiert, was die Bearbeitungszeit erheblich verkürzt.
* **Entlastung der Mitarbeiter:** Service-Teams können sich auf anspruchsvollere Aufgaben konzentrieren.
* **Bessere Kundenerfahrung:** Anfragen werden schneller und präziser bearbeitet – rund um die Uhr.
* **Einfache Anpassung:** KI-Agenten lassen sich mit unternehmensspezifischen Inhalten erweitern und individuell konfigurieren.
### Fazit
Mit den KI-Agenten von Enneo lässt sich der Kundenservice effizienter, flexibler und kundenorientierter gestalten. Ob smarter oder regelbasierter Agent – die passende Lösung lässt sich bedarfsgerecht implementieren und kontinuierlich weiterentwickeln.
---
## Schlüsselrolle Basis-Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/base-agent
**Description:** Einsatzmöglichkeiten, Funktionsweise und Konfiguration
### Grundkonfiguration
Die Grundkonfiguration des Basis-Agenten orientiert sich am gleichen Prinzip wie bei KI-Agenten mit [Smarter Argumentationslogik](https://docs.enneo.ai/de/ai-functions-agents/smart-agents).
Der zentrale Bestandteil ist der Prompt: Er legt fest, wie der Basis-Agent vorgeht und auf welche Tools er zugreifen kann.
### Individuelle Prompteinstellungen
Der Prompt des Basis-Agenten beschreibt das **Grundverhalten**: wie ein Anliegen verarbeitet wird, welche Tools verwendet werden und welche Struktur dabei zum Einsatz kommt. Es handelt sich um die gemeinsame, wiederverwendbare Logik für alle Einsatzszenarien.
Darüber hinaus lassen sich **ergänzende Anweisungen** im Bereich `KI-Anpassung → Sonstiges → Individuelle Prompts` hinterlegen. Diese werden bei der Antwortgenerierung zusätzlich zum Prompt des Basis-Agenten berücksichtigt.
Sie ermöglichen es, fachliche Sonderregeln, sprachliche Details oder mandantenspezifische Besonderheiten bedarfsgerecht abzubilden, ohne den Basis-Agenten selbst anpassen zu müssen.
### Zuweisung zu Kommunikationskanälen
Der Basis-Agent lässt sich direkt mit einem Kommunikationskanal verknüpfen, bspw. einem bestimmten E-Mail-Postfach, einem Chat- oder Telefonkanal. Die Zuordnung erfolgt in den Einstellungen der jeweiligen Unterkanäle im Bereich `Kommunikationskanäle` und ermöglicht eine passgenaue, mandantenspezifische Konfiguration.
So können verschiedene Varianten des Basis-Agenten parallel betrieben werden, jeweils mit individueller Tonalität in den Antwortvorschlägen, eigenem Tool-Set und Wiki-Zugriff.
**Beispiel:**
*Der **Voltlingen-Basis-Agent** ist mit dem Mail-Account service[at]sw-voltlingen.de verknüpft. Er formuliert die Antwortvorschläge locker in der Du-Form, greift auf FAQ-Artikel speziell für die Stadtwerke Voltlingen zu und kennt die dortigen Produktbesonderheiten.*
*Gleichzeitig arbeitet der **Stromhain-Basis-Agent** unter service[at]sw-stromhain.de mit formeller Sie-Ansprache, einer anderen Auswahl an Wissensdatenbankkategorien und eigenen Regeln für den Umgang mit bestimmten Themen.*
Beide Basis-Agenten basieren auf derselben technischen Grundlage, sind aber vollständig auf den jeweiligen Mandanten abgestimmt.
---
## Regelbasierte Logik
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/rule-based-agents
**Description:** Funktionsweise, Umsetzung und Beispiel
### Parameterverwaltung
#### 1. Eingabeparameter und ihre Quellen
Eingabeparameter können aus verschiedenen Quellen entnommen werden:
* **Ticketdaten**: Informationen aus dem ursprünglichen Ticket
* **Kundendaten**: Stammdaten des Kunden
* **Vertragsdaten**: Informationen zum Vertrag des Kunden
* **Extraktion durch KI**: Automatische KI-Analyse der Kundenanfrage zur Erkennung relevanter Informationen
* **Manuelle Festlegung**: Ein fester Wert, der von einem Nutzer definiert wird
#### 2. Parameterwerte und Pflichtfelder
Jeder Parameter benötigt einen Wert, der je nach Quelle automatisch übernommen, durch KI extrahiert oder manuell eingetragen wird. Pflichtfelder stellen sicher, dass bestimmte Informationen vorhanden sind, bevor der KI-Agent eine Verarbeitung ausführen kann.
#### 3. Parameterattribute
Die folgenden Felder sind bei der Konfiguration eines Parameters verfügbar:
| **Feld** | **Beschreibung** |
|---|---|
| **Referenz zu Quelle Key** | Technischer Schlüssel zur Identifikation im Datenobjekt, z. B. `channel` |
| **Variablenname in Business-Logik** | Interner Bezeichner zur Weiterverarbeitung in Logik und Aktionen |
| **Bezeichnung für User** | Anzeigename im UI, sofern der Parameter für Anwender sichtbar ist |
| **Format** | Datentyp, z. B. `String`, `Boolean`, `Number`, `Date` oder `Enum` |
| **Optionen** | Auswahlwerte für Parameter vom Typ `Enum` |
| **Interne Beschreibung** | Erläuterung zur Funktion oder Verwendung; bei KI-Extraktion dient sie als Erkennungshinweis |
| **Erforderlich** | Legt fest, ob der Parameter zwingend gesetzt sein muss |
| **Sichtbarkeit für Anwender** | Steuerung der UI-Darstellung: `Sichtbar`, `Versteckt`, `Schreibgeschützt` |
| **Anzeigeoptionen** | Zusätzliche Darstellungseinstellungen für sichtbare String-Parameter |
#### 4. Sichtbarkeit und Bearbeitungseinschränkungen
* **Sichtbar**: Der Parameter ist für Bearbeiter einsehbar und kann, sofern nicht anderweitig eingeschränkt, bearbeitet werden.
* **Versteckt**: Der Parameter wird im Hintergrund verarbeitet, aber nicht angezeigt.
* **Schreibgeschützt**: Der Wert ist sichtbar, kann jedoch nicht verändert werden.
#### 5. Anzeigeoptionen für sichtbare Textparameter
Für Parameter mit dem Format **String** und der Sichtbarkeit **Sichtbar** können zusätzliche Anzeigeoptionen konfiguriert werden:
* **Mehrzeilig**: Der Parameter wird als mehrzeiliges Eingabefeld dargestellt.
* **Zeilen**: Definiert die Höhe des mehrzeiligen Eingabefelds.
* **Automatisch absenden**: Legt fest, ob eine Eingabe automatisch übernommen/abgesendet wird.
Diese Anzeigeoptionen sind nur für sichtbare String-Parameter verfügbar. Für versteckte, schreibgeschützte oder anders formatierte Parameter werden sie nicht angezeigt.
#### 6. Erforderlichkeit eines Parameters
* **Ja**: Der Parameter muss zwingend angegeben sein, damit die Verarbeitung mithilfe oder durch den KI-Agenten erfolgen kann.
* **Nein**: Der Parameter ist optional und kann leer bleiben.
Parameter können jederzeit wieder entfernt werden.
### Beispiel Bankdaten
Um Kundenanliegen zu Bankdatenanpassungen bearbeiten zu können, benötigt der Bankdaten-Agent eine **Kombination** aus bestimmten **Informationen und Prüfungen**. Die relevanten Informationen bezieht er über die Eingabeparameter, während die Prüfungen in der Business-Logik definiert sind.
Es werden somit für diesen KI-Agent folgende Eingabeparameter konfiguriert:
* **`contractId`** *(Quelle: Vertragsdaten)* → Die Vertragsnummer des Kunden, um die Änderung dem richtigen Vertrag zuzuordnen.
* **`newIBAN`** *(Quelle: Extraktion aus der Kundenanfrage mit KI)* → Die neue Bankverbindung, die der Kunde hinterlegen möchte.
* **`oldIBAN`** *(Quelle: Vertragsdaten)* → Die bisher hinterlegte IBAN, um sie mit der neuen zu vergleichen.
* **`accountHolder`** *(Quelle: Extraktion aus der Kundenanfrage mit KI)* → Der Name des Kontoinhabers, um die Identität zu prüfen. Falls kein Name genannt wird, bleibt der Wert leer.
* **`date`** *(Quelle: Extraktion aus der Kundenanfrage mit KI)* → Falls angegeben, das Datum, ab wann die neue Bankverbindung gültig sein soll.
### Zusammenfassung
Die vordefinierte Konfiguration von Eingabeparametern ermöglicht es regelbasierten KI-Agenten, Kundenanliegen effizient zu verarbeiten. In Kombination mit der Business-Logik werden Daten strukturiert erfasst, geprüft, im UI passend dargestellt und automatisch verarbeitet. Dadurch erfolgt die Bearbeitung präzise und mit minimalem manuellem Aufwand.
### Funktionsweise
Nachdem die relevanten **Eingabeparameter** erfasst wurden, übernimmt die **Business-Logik** die **Verarbeitung**. Dazu gehören:
* Prüfungen auf Vollständigkeit und Plausibilität
* Validierung der Daten anhand vordefinierter Regeln
* Ermittlung zusätzlicher Werte, falls erforderlich
* Auslösung von Aktionen basierend auf den Ergebnissen der Prüfungen
### Technische Umsetzung
Die Business-Logik kann implementiert werden in:
* PHP (8.2)
* Python (3.11)
* JavaScript (Node 20)
Die Implementierung folgt einer strukturierten Verarbeitungspipeline:
**1. Initialisierung und Eingabevalidierung**
* Eingabeparameter werden aus dem Kontext übernommen und in ein standardisiertes Format überführt.
* Pflichtfelder werden geprüft, fehlende Werte ggf. durch Defaults ersetzt.
* Typumwandlungen (z. B. `bool`, `int`, `float`) erfolgen, um eine konsistente Verarbeitung zu gewährleisten.
**2. Regelbasierte Verarbeitung**
* Die Business-Logik validiert die Eingaben anhand definierter Regeln (z. B. Formatprüfungen, Plausibilitätschecks).
* Falls erforderlich, werden externe API-Aufrufe oder Datenbankabfragen durchgeführt, um zusätzliche Informationen zu ergänzen.
* Berechnungen und Entscheidungsprozesse laufen basierend auf den Parametern ab (z. B. Verzweigungen bei abweichenden Eingaben).
**3. Aktionen und Ergebnisausgabe**
* Die Business-Logik steuert den weiteren Ablauf, indem sie:
* Automatische Änderungen im System vornimmt
* Externe APIs aufruft (z. B. zur Datenspeicherung)
* Rückfragen oder Bestätigungen erzeugt
* Die Rückgabe erfolgt standardisiert als **Antwortobjekt**, das je nach Kontext eine **Bestätigung, Fehlerhinweise oder Interaktionsoptionen** enthalten kann.
Die Business-Logik liefert Ergebnisse, die via **Ausgabebehandlung** weiterverarbeitet werden. Dort wird festgelegt, wie der KI-Agent auf bestimmte Szenarien reagiert – sei es durch Bestätigungen, Rückfragen oder Interaktionsmöglichkeiten.
### Beispiel: Business-Logik zur Verarbeitung einer IBAN-Änderung
Ein KI-Agent verarbeitet Anfragen zur Änderung einer Bankverbindung. Die Business-Logik stellt sicher, dass die Änderung korrekt durchgeführt wird und alle relevanten Prüfungen erfolgen.
**1. Eingaben validieren**
Zunächst werden die Eingaben standardisiert und geprüft:
* Leerzeichen in der IBAN entfernen
* Falls kein Kontoinhaber angegeben ist, wird er aus den Vertragsdaten ergänzt
```php
$this->input->newIBAN = str_replace(' ', '', $this->input->newIBAN);
$this->input->oldIBAN = $this->input->oldIBAN ?? '';
$this->input->oldIBAN = str_replace(' ', '', $this->input->oldIBAN);
// Falls kein Kontoinhaber angegeben ist, aus Vertragsdaten übernehmen
if (!($this->input->accountHolder ?? null)) {
$this->input->accountHolder = sprintf(
'%s %s',
$this->contractData->firstname,
$this->contractData->lastname
);
}
```
**2. Eingaben validieren**
Die Business-Logik überprüft, ob die neue IBAN korrekt ist:
* **IBAN-Validierung:** Format- und Prüfziffernprüfung
* **Vertrag existiert:** Die Änderung muss einem gültigen Vertrag zugeordnet werden
```php
// Vertrag abrufen
$this->contractData = ApiEnneo::getContract($this->input->contractId);
if (!$this->contractData) {
throw new Exception('Vertrag nicht gefunden.');
}
// Format- und Prüfziffernvalidierung der IBAN
if (!$this->validateIbanFormatting($this->input->newIBAN) || !$this->validateIbanChecksum($this->input->newIBAN)) {
$this->interaction->infos[] = new IntentInfo(
type: 'warning',
message: 'IBAN nicht im korrekten Format oder Prüfsumme ungültig',
);
$this->interaction->options[] = new IntentOption(
type: self::ACTION_IBAN_INVALID,
name: 'Kunden nach korrekter IBAN fragen',
recommended: true,
);
throw new ChangeBankDataException();
}
```
**3. Ergebnis ausgeben und nächste Aktion bestimmen**
Je nach Ergebnis der Prüfungen entscheidet die Business-Logik, wie der Prozess weitergeht:
* Falls die Prüfungen erfolgreich sind → **IBAN wird gespeichert**
* Falls Fehler erkannt wurden → **Kunde erhält eine Rückfrage oder Korrekturmöglichkeit**
```php
if ($this->input->_action === self::ACTION_ENTER_INTO_SYSTEM) {
$this->saveBankData();
foreach ($this->form->fields as $field) {
$field->readonly = true;
}
} else {
$this->interaction->options[] = new IntentOption(
type: self::ACTION_ENTER_INTO_SYSTEM,
name: 'Bankverbindung im System hinterlegen',
recommended: true,
);
}
```
**4. Interaktionsgestaltung mit dem SDK**
Interaktionen sind das Hauptinstrument von Enneo, um Agenten strukturiertes Feedback zu geben. Eine Interaktion besteht aus vier Elementen:
1. **Infos:** Welche Nachrichten oder Warnungen sollen dem Agenten angezeigt werden?
2. **Form:** Welche Eingabefelder, z.B. Textfelder oder Dropdown-Menüs, sollen angezeigt werden?
3. **Data:** Welche Werte haben die Eingabefelder?
4. **Options:** Welche Schaltflächen sollen dem Nutzer angezeigt werden?
Um eine Interaktion zu erstellen, kann das Enneo SDK verwendet werden, eine Bibliothek mit Objektdefinitionen. Die obige Interaktion kann mit diesem Code erstellt werden:
Anstelle des SDK kann das JSON-Objekt für die Interaktion auch direkt erstellt werden. Hier ist ein vollständiges Beispiel für die Interaktion der oben gezeigten Kündigungs-KI-Funktionalität:
```json
{
"data": {
"date": "2023-12-08",
"type": "regular",
"dryRun": "true",
"_action": "null",
"contractId": 756852,
"dateReceived": "2023-12-08",
"proofIncluded": false
},
"form": {
"fields": [
{
"id": "contractId",
"type": "integer",
"label": "Vertragsnummer",
"fields": null,
"hidden": true,
"options": null,
"readonly": false,
"valueRef": "data.contractId",
"validation": null,
"placeholder": null,
"defaultValue": null
},{
"id": "date",
"type": "date",
"label": "K\u00fcndigungsdatum",
"fields": null,
"hidden": false,
"options": null,
"readonly": false,
"valueRef": "data.date",
"validation": null,
"placeholder": null,
"defaultValue": null
},{
"id": "type",
"type": "select",
"label": "K\u00fcndigungsart",
"fields": null,
"hidden": false,
"options": [
{
"id": "regular",
"label": "Regul\u00e4r",
"value": "regular"
},
{
"id": "priceAdjustment",
"label": "Preisanpassung",
"value": "priceAdjustment"
},
{
"id": "relocation",
"label": "Umzug",
"value": "relocation"
},
{
"id": "death",
"label": "Tod",
"value": "death"
},
{
"id": "custom",
"label": "Sonstiges",
"value": "custom"
}
],
"readonly": false,
"valueRef": "data.type",
"validation": null,
"placeholder": null,
"defaultValue": null
},
{
"id": "_action",
"type": "text",
"label": "_action",
"fields": null,
"hidden": true,
"options": null,
"readonly": false,
"valueRef": "data._action",
"validation": null,
"placeholder": null,
"defaultValue": null
},
{
"id": "proofIncluded",
"type": "checkbox",
"label": "Nachweis beigef\u00fcgt",
"fields": null,
"hidden": false,
"options": null,
"readonly": false,
"valueRef": "data.proofIncluded",
"validation": null,
"placeholder": null,
"defaultValue": null
},
{
"id": "dryRun",
"type": "checkbox",
"label": "(schreibzugriff tats\u00e4chlich ausf\u00fchren)",
"fields": null,
"hidden": true,
"options": null,
"readonly": false,
"valueRef": "data.dryRun",
"validation": null,
"placeholder": null,
"defaultValue": null
},
{
"id": "dateReceived",
"type": "date",
"label": "K\u00fcndigungseingang",
"fields": null,
"hidden": true,
"options": null,
"readonly": false,
"valueRef": "data.dateReceived",
"validation": null,
"placeholder": null,
"defaultValue": null
},
{
"id": "sourceCode-0",
"type": "dict",
"label": "Source code executor response",
"fields": null,
"hidden": false,
"options": null,
"readonly": false,
"valueRef": "data.sourceCode-0",
"validation": null,
"placeholder": null,
"defaultValue": null
}
]
},
"infos": [
{
"code": null,
"type": "warning",
"message": "Vertrag wurde vor Belieferungsbeginn storniert und kann daher nicht gek\u00fcndigt werden.",
"extraInfo": null
}
],
"options": [
{
"icon": "check",
"name": "Kunden dar\u00fcber informieren",
"type": "termination_already_processed",
"order": 1,
"handler": "",
"recommended": true
}
]
}
```
### Zusammenfassung
Die Business-Logik definiert, wie ein KI-Agent Eingabeparameter verarbeitet und darauf basierend Entscheidungen trifft. Sie stellt sicher, dass Kundenanfragen strukturiert geprüft, validiert und entsprechend weiterverarbeitet werden. Durch automatisierte Regeln und Abläufe werden Prozesse effizient gesteuert und nachvollziehbar ausgeführt, wodurch manuelle Eingriffe minimiert werden.
### Grundlegende Funktionsweise
Die Ausgabebehandlung basiert auf **vordefinierten Regeln**, die auf den Ergebnissen der Business-Logik aufbauen. Sie steuert unter anderem:
* **Textvorlagen:** Automatische Nachrichten an den Nutzer, z. B. Bestätigungen oder Rückfragen.
* **Interaktionen:** Bereitstellung von Schaltflächen oder Formularen zur weiteren Verarbeitung.
* **API-Aufrufe:** Weiterleitung der Ergebnisse an andere Systeme.
* **Automatische Ticket-Aktionen:** Einträge ins System oder Abschluss von Vorgängen.
In Enneo gibt es verschiedene **Aktionstypen**, die eine Reaktion auslösen können:
* **Antwortvorschlag von KI:** Die KI generiert auf Basis des Kontexts eine Antwort an den Kunden.
* **Textvorlage verwenden:** Eine definierte Nachricht wird direkt versendet.
* **Interaktion:** Der Nutzer erhält Auswahlmöglichkeiten zur weiteren Bearbeitung.
* **Ticket schließen, ohne zu antworten:** Das Anliegen wird automatisch abgeschlossen.
* **Textvorlage senden und Ticket schließen:** Eine Bestätigung wird versendet, und das Ticket wird abgeschlossen.
### Beispiel: Ausgabebehandlung im Bankdaten-Agenten
Die Business-Logik des Bankdaten-Agenten trifft Entscheidungen basierend auf den Eingabeparametern. Die **Ausgabebehandlung setzt darauf auf und steuert die Reaktion**.
**1. IBAN ist bereits im System**
Falls die neue IBAN bereits hinterlegt ist (`iban_already_in_system`), wird automatisch eine **Textvorlage** an den Kunden gesendet:
```bash
vielen Dank für die Übermittlung der Bankdaten.
Die Bankverbindung mit den Endziffern ...{{last4digits newIBAN}} ist bereits bei uns im System hinterlegt und wird von uns
{{#if payoutOnly}}für künftige Gutschriften{{else}}für monatliche Abschläge, Rechnungen sowie eventuelle Gutschriften{{/if}} verwendet.
```
* **Aktion:** **Textvorlage verwenden**
* **Bedingung:** `_action = iban_already_in_system`
* **Automatische Ausführung:** **Ja** → Nachricht wird vollautomatisiert versendet.
**2. IBAN ist ungültig**
Falls die Business-Logik die neue IBAN als **ungültig** erkennt (`iban_invalid`), wird eine alternative Aktion ausgeführt. Der Kunde erhält eine Rückfrage, um eine korrekte IBAN anzugeben.
```bash
Die angegebene IBAN {{newIBAN}} ist nicht gültig.
Bitte überprüfen Sie die IBAN auf eventuelle Tippfehler und senden uns die korrekte Bankverbindung, damit wir sie hinterlegen können. Vielen Dank für Ihre Unterstützung.
```
* **Aktion:** **Interaktion oder Textvorlage verwenden**
* **Bedingung:** `_action = iban_invalid`
* **Automatische Ausführung:** **Nein** → Der Nutzer entscheidet über die weitere Vorgehensweise.
**3. IBAN wurde erfolgreich hinterlegt**
Sobald die IBAN erfolgreich ins System eingetragen wurde (`enter_into_system`), wird dem Kunden eine Bestätigung gesendet:
```bash
vielen Dank für deine Nachricht.
Die Bankverbindung mit den Endziffern ...{{last4digits newIBAN}} haben wir bei uns im System hinterlegt und wird von uns
{{#if payoutOnly}}für künftige Gutschriften{{else}}für monatliche Abschläge, Rechnungen sowie eventuelle Gutschriften{{/if}} verwendet.
```
* **Aktion:** **Textvorlage verwenden**
* **Bedingung:** `_action = enter_into_system`
* **Automatische Ausführung:** **Ja** → Nachricht wird direkt versendet.
### Zusammenfassung
Die **Ausgabebehandlung verbindet die Business-Logik mit der Kommunikation**. Sie sorgt dafür, dass Entscheidungen automatisiert in Aktionen umgesetzt werden – sei es durch direkte Bestätigungen, Rückfragen oder Folgeprozesse. So werden Kundenanfragen effizient, nachvollziehbar und ohne manuelle Eingriffe abgewickelt.
---
## Beispiele
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/samples
**Description:** Beispiele
---
## SDK
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/sdk
**Description:** Enneo SDK - Dokumentation
Das Enneo SDK bietet eine umfassende Sammlung von Werkzeugen, die die Entwicklung von spezifischem Code für kundenspezifische Lösungen im Bereich des KI-gestützten Kundensupports erleichtert. Das SDK unterstützt die Implementierung regelbasierter Logik für KI-Agenten, eventbasierte Integrationen, kundenspezifische Webhooks und benutzerdefinierte Funktionen. Das SDK wird automatisch geladen und die Funktionen stehen direkt zur Verfügung.
### Einbindung des SDK im Code
Um das Enneo SDK in Ihren Code einzubinden, kann folgendes Code-Snippet verwendet werden:
### Enneo API Wrapper
Das Enneo SDK bietet Wrapper für die Enneo API Endpunkte, mit denen bequem auf die API zugegriffen werden kann:
- Laden der Vertragsdaten anhand der Vertrags-ID
- Laden der Ticket-Daten anhand der Ticket-ID
- Ausführen [benutzerdefinierter Funktionen](/docs/de/system-integration/user-defined-functions-tools/user-defined-functions-in-enneo)
- Aufrufen beliebiger Enneo-API Endpunkte (GET | POST | PATCH | PUT | DELETE)
../../../snippets/de/user-defined-functions/user-defined-function-call.mdx
### SDK Code
Die SDKs sind verfügbar unter:
- [PHP SDK](https://demo.enneo.ai/api/codeExecutor/sdk/php82.php)
- [Python SDK](https://demo.enneo.ai/api/codeExecutor/sdk/python311.py)
- [Node.JS SDK](https://demo.enneo.ai/api/codeExecutor/sdk/node20.js)
Obige URLs funktionieren ohne Authorisierung, d.h. können von Ihren Skripten direkt eingebunden werden.
../../../snippets/sdk-code.mdx
---
## Smarte Argumentationslogik
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/smart-agents
**Description:** Erstellung eines smarten KI-Agenten
### Beispiel-Prompt eines Tarifberatungs-Agenten mit benutzerdefinierten Werkzeugen
Du bist Expertin für Kündiger-Rückgewinnung bei Energieversorgern. Als Tarifberaterin möchtest du den Kunden am Telefon höflich, aber effektiv animieren, einen günstigen Tarif abzuschließen, statt die Kündigung durchzuziehen. Du hast den Kunden angerufen. Gehe wie folgt vor:
1. Wenn der Kunde sagt, dass die Kündigung nicht korrekt war, vermerke das in und nimm die Kündigung zurück.
2. Ansonsten frage nach, warum der Kunde gekündigt hat. Vermerke den Grund in .
3. Frage anschließend, ob du dem Kunden ein vorbereitetes Wechselangebot machen kannst, um bares Geld zu sparen. Gehe auf den Kündigungsgrund ein, wenn es passt. Bei Ablehnung akzeptiere das und beende den Anruf.
4. Wenn der Kunde Interesse hat, hole das Angebot mit . Stelle das Angebot kurz vor, indem du dich auf die Highlights konzentrierst. Formuliere Ziffern in Worten (z. B. 1,5 → eins Komma fünf). Nutze natürliche Sprache, keine JSON-Variablen oder Abkürzungen wie kWh. Falls der Kunde kein Interesse hat, beende den Anruf.
5. Beantworte auf Wunsch Fragen des Kunden zu diesem Tarif. Wenn der Kunde den Tarif per E-Mail zugeschickt haben möchte, nutze und bestätige den Versand unter Nennung der dort genannten E-Mail-Adresse.
6. Frage, ob der Kunde das Angebot annehmen möchte. Bei Zustimmung initiiere den Tarifwechsel mit . Andernfalls akzeptiere die Entscheidung und beende den Anruf.
7. Bestätige einen erfolgreichen Wechsel gegenüber dem Kunden und beende den Anruf.
8. Wenn der Kunde eine Berechnung der Einsparungen wünscht, verwende das Tool .
Fokussiere dich ausschließlich auf diesen Prozess und gehe nicht auf andere Themen ein. Du kennst den Kunden bereits, eine Identifikation ist nicht nötig. Sieze den Kunden in der Anrede.
### Benutzerdefinierte Werkzeuge
Im Bereich `KI-Anpassung → KI-Tools` lassen sich benutzerdefinierte Werkzeuge erstellen und später einem smarten KI-Agenten hinzufügen.
Diese Werkzeuge unterstützen den KI-Agenten dabei, Prozesse und Anweisungen effizient und zielgerichtet durchzuführen. Je nach Konfiguration werden die Aktionen des KI-Agenten ausgelöst, auf Basis der erkannten Kundenbedürfnisse angepasst und im definierten Prozessverlauf abgeschlossen.
* Ein benutzerdefiniertes Werkzeug beschreibt eine einzelne Aktion – z. B. „Kündigung zurücknehmen“ – die später vom Smart Agent aufgerufen werden kann.
* Welche Informationen das Werkzeug benötigt (z. B. eine Vertragsnummer), wird vorab festgelegt und bei der Nutzung automatisch übergeben.
* Die eigentliche Aktion kann entweder direkt per Code definiert oder an eine externe Schnittstelle weitergeleitet werden.
### Integrierte Tools
---
## KI-Nachbearbeitung
**URL:** https://richard-dev-playground.enneo.ai/docs/de/analytics/ai-insights
**Description:** Typisierte Fragen, die nach Ticketabschluss von der KI beantwortet und als AI Insights gespeichert werden.
### Was ist die KI-Nachbearbeitung?
Die KI-Nachbearbeitung ist eine nachgelagerte Klassifikation von Tickets. Nach dem Abschluss eines Tickets beantwortet die KI zuvor definierte Fragen auf Basis der Ticketkonversation und verfügbarer Metadaten.
Jede Frage besitzt einen fachlichen Namen, eine Beschreibung und einen Datentyp. Dadurch entstehen keine freien, unstrukturierten Zusammenfassungen, sondern auswertbare Werte wie Ja-Nein-Antworten, Kategorien, Zahlen oder kurze Texte.
Die Konfiguration erfolgt in den kanalspezifischen Einstellungen unter dem Punkt `KI-Nachbearbeitung`.
### Wofür wird die KI-Nachbearbeitung genutzt?
Die Funktion ist besonders hilfreich, wenn eine Information fachlich relevant ist, aber nicht zuverlässig über Status, Tags oder feste Prozessfelder abgebildet werden kann. Das betrifft vor allem Bewertungen, die erst aus dem Verlauf oder Ergebnis der Bearbeitung entstehen.
Beispiele sind:
- ob das Anliegen tatsächlich vollständig gelöst wurde
- warum ein Vorgang an einen Mitarbeiter übergeben wurde
- ob eine Automatisierung an fehlenden Daten, fehlender Berechtigung oder einer technischen Einschränkung gescheitert ist
- ob sich die ursprüngliche Kundenintention während der Konversation verändert hat
- ob ein Vorgang formal geschlossen wurde, obwohl fachlich noch Klärungsbedarf bestand
Solche Informationen sind für Auswertungen relevant, lassen sich aber häufig nicht stabil über operative Felder modellieren. Die KI-Nachbearbeitung ergänzt diese Struktur nachträglich, ohne den Bearbeitungsprozess selbst zu verändern.
### Was sind AI Insights?
AI Insights sind die gespeicherten Ergebnisse der KI-Nachbearbeitung. Sie werden am Ticket gespeichert und stehen zusätzlich im Datenexport zur Verfügung.
Der Export der AI Insights ist unter `Erweiterte Einstellungen → Datenexporte` zu finden.
Im Datenexport werden die AI Insights als strukturierte Angaben pro Ticket ausgegeben. Dazu gehören:
- die beantwortete Frage
- der typisierte Wert
- die Konfidenz
Der Wert richtet sich nach dem Datentyp der Frage. Bei einer Boolean-Frage ist das Ergebnis zum Beispiel wahr oder falsch. Bei einer Enum-Frage ist das Ergebnis eine der definierten Kategorien.
Die Konfidenz beschreibt, wie sicher die KI ihre Antwort auf Basis der vorhandenen Informationen einschätzt. Eine niedrige Konfidenz bedeutet nicht automatisch, dass das Ergebnis falsch ist. Sie zeigt an, dass die Evidenz im Ticket schwach, indirekt oder widersprüchlich sein kann.
Die kurze Begründung wird im Ticketkontext gespeichert, aber nicht als Massenangabe im Datenexport ausgegeben, da sie Freitext enthalten und Gesprächsinhalte zitieren kann.
### Bedeutung der Fragetypen
Der Fragetyp legt fest, welche Art von Ergebnis die KI liefern darf und wie gut dieses Ergebnis später ausgewertet werden kann.
_Boolean-Fragen_
- Für klare Ja-/Nein-Klassifikationen
- Geeignet, wenn eindeutig entschieden werden soll, ob etwas zutrifft
- Beispiel: „Wurde das Anliegen gelöst?“
_Enum-Fragen_
- Für vordefinierte Kategorien
- Besonders geeignet für Reporting, Filterung, Aggregation und Vergleiche
- Beispiel: „Welcher Grund liegt vor?“
_Textfragen_
- Für kurze qualitative Einordnungen oder Zusammenfassungen
- Weniger stabil für Reporting, da Freitext schwerer vergleichbar ist
_Zahlenfelder_
- Nur verwenden, wenn die Zahl eindeutig aus der Konversation oder den Metadaten ableitbar ist
- Nicht geeignet, wenn die KI schätzen oder interpretieren müsste
### Best Practices für Fragen
Fragen sollten fachlich eindeutig, eng begrenzt und aus der Ticketkonversation beantwortbar sein. Die Beschreibung ist dabei entscheidend: Sie steuert, welche Evidenz die KI berücksichtigen soll und wann kein belastbares Ergebnis vorliegt.
Eine gute Frage beschreibt nicht nur das gewünschte Ergebnis, sondern auch die Abgrenzung zu ähnlichen Fällen.
**Beispiel:**
Name: `Bearbeitungsergebnis`
Typ: `Enum`
Optionen: `vollständig_gelöst`, `teilweise_gelöst`, `nicht_gelöst`, `unklar`
Beschreibung: `Bewerte, ob das Kundenanliegen im Ticket abschließend gelöst wurde. Verwende "unklar", wenn aus der Konversation keine belastbare Aussage möglich ist.`
### Umgang mit leeren Ergebnissen
Ein AI Insight kann leer bleiben, wenn die KI keine ausreichende Grundlage für eine Antwort findet. Das ist fachlich gewollt und sollte bei Auswertungen berücksichtigt werden.
Wenn ein unbestimmtes Ergebnis analytisch relevant ist, sollte es explizit modelliert werden. Bei Enum-Fragen kann dafür eine Kategorie wie `unklar` oder `nicht_bestimmbar` verwendet werden.
### Auswirkungen von Änderungen
Änderungen an Fragen wirken sich auf zukünftige Auswertungen aus. Historische Ergebnisse bleiben erhalten.
Wenn eine Frage gelöscht wird, wird sie nicht mehr für neue Tickets verwendet. Bereits erzeugte AI Insights bleiben jedoch für Audit- und Exportzwecke erhalten.
Bei Änderungen an Frage, Beschreibung, Datentyp oder Optionen sollte berücksichtigt werden, dass alte und neue Ergebnisse fachlich nicht immer direkt vergleichbar sind. Für stabile Zeitreihen sollten Fragen und Optionswerte möglichst konsistent bleiben.
### Empfehlungen für den produktiven Einsatz
Die KI-Nachbearbeitung sollte mit wenigen, klar definierten Fragen beginnen. Eine kleine Anzahl präziser Fragen liefert meist stabilere Ergebnisse als viele breite oder überlappende Fragen.
Vor der Nutzung in Reports sollten neue Fragen anhand realer Tickets geprüft werden. Dabei ist besonders wichtig, ob die Antwort tatsächlich aus der Konversation ableitbar ist und ob die Kategorien trennscharf genug sind.
Die KI-Nachbearbeitung ist sinnvoll, wenn abgeschlossene Tickets strukturiert ausgewertet werden sollen. Sie sollte nicht als Ersatz für verbindliche Prozesslogik, Compliance-Entscheidungen oder manuelle fachliche Prüfung verwendet werden.
---
## Enneo BI-Lösung Superset
**URL:** https://richard-dev-playground.enneo.ai/docs/de/analytics/enneo-bi-solution-superset
**Description:** Enneo BI-Lösung Superset
## Zugriff auf Superset
Der Zugriff auf die Analysefunktionen wird über die Benutzereinstellung "Datenverfügbarkeit" gesteuert. Administratoren können festlegen, welche Benutzer Zugriff auf die Analysefunktionen haben und in welchem Umfang Daten sichtbar sind.
Auf Superset kann man dann über den Enneo-Menüpunkt "Analytics" zugreifen. Auf der oberen Leiste findet man in Tabs die verschiedenen Dashboards, welche angelegt wurde.
## Superset Auswertungen selbst erstellen
Enneo bietet im Standard eine Reihe von Auswertungen, welche jedoch beliebig erweitert werden können. Die Daten sind dabei stets aktuell.
Dazu muss man mit einem Enneo-Account, der volle Datenverfügbarkeits-Rechte hat, auf den Tab "Editor" klicken. Dort hat man vollen Zugriff auf alle Funktionen von Superset.
### Diagramme erstellen
Mit Superset können verschiedene Arten von Visualisierungen erstellt werden:
* Balken- und Liniendiagramme
* Tortendiagramme
* Tabellen und Pivot-Tabellen
* Heatmaps
* und viele weitere Diagrammtypen
Jedes Diagramm kann individuell angepasst werden, zum Beispiel durch:
* Filterung der Daten
* Gruppierung nach verschiedenen Dimensionen
* Anpassung von Farben und Beschriftungen
* Definition von Metriken und Berechnungen
### Zeitreihenanalyse
Besonders nützlich für Service-Organisationen ist die Zeitreihenanalyse. Damit lassen sich:
* Trends über verschiedene Zeiträume analysieren
* Vergleiche zum Vorjahr oder Vormonat ziehen
* Saisonale Muster erkennen
* Prognosen erstellen
### Dashboards erstellen
Mehrere Diagramme können zu aussagekräftigen Dashboards kombiniert werden:
* Gewünschte Diagramme auswählen
* Per Drag & Drop anordnen
* Dashboard-weite Filter definieren
* Dashboard zur weiteren Verwendung speichern
## Tipps für die Arbeit mit Superset
### Best Practices
* Aussagekräftige Namen für Diagramme und Dashboards verwenden
* Filter nutzen, um die Datenmenge überschaubar zu halten
* Häufig verwendete Diagramme als Favoriten speichern
* Nützliche Dashboards mit dem Team teilen
### Datenaktualisierung
Die Daten in Superset werden regelmäßig aktualisiert. Die Aktualisierungsintervalle sind:
* Ticketdaten: alle 5 Minuten
* Nachrichtendaten: alle 5 Minuten
* Bearbeitungsdaten: alle 5 Minuten
## Weiterführende Ressourcen
Für detaillierte Informationen zu Apacke Superset lohnt sich ein Blick in die offizielle [Dokumentation](https://superset.apache.org/docs/intro).
---
## Exporte
**URL:** https://richard-dev-playground.enneo.ai/docs/de/analytics/exports
**Description:** Exportieren von Daten aus Enneo
Es gibt drei verschiedene Möglichkeiten, Daten aus Enneo zu exportieren:
### 1. Export ausgewählter Tickets über die Benutzeroberfläche
In der Ticket-Übersicht kann über das Export-Symbol in der oberen rechten Ecke die aktuell angezeigte Ticketliste heruntergeladen werden. Dabei werden alle gesetzten Filter, wie zum Beispiel Kanal-Filter, Status und Tags, berücksichtigt.
### 2. Export von Tickets, Nachrichten und Bearbeitungen über die Benutzeroberfläche
Dieser Export ist über folgende Navigation erreichbar:
Einstellungen -> Erweiterte Einstellungen -> Exporte und Reporting-Einstellungen
Hier kann zwischen den bekannten, zentralen Datentabellen gewählt werden:
* Tickets
* Nachrichten
* Bearbeitungen
### 3. Export über die REST-API
Für automatisierte Exporte steht die Enneo REST-API zur Verfügung. Die Dokumentation der entsprechenden API-Schnittstelle `/api/mind/export/` ist [hier](/docs/de/api-reference/introduction) zu finden.
Diese Schnittstelle eignet sich besonders für automatisierte Exporte, da sie es erlaubt, Filter oder Limits zu setzen. Somit sind Anbindungen an externe BI-Systeme wie z.B. MS Power BI, Tableau, Snowflake, Google Looker Studio etc. möglich.
Über den Parameter "key" lässt sich die gewünschte Datentabelle spezifizieren:
* tickets
* messages
* worklog
Mit dem Parameter **"format"** lässt sich das gewünschte Exportformat (XLSX, CSV oder JSON) wählen. Für regelmäßige Exporte wird JSON (bevorzugt) oder CSV empfohlen, da diese Formate deutlich performanter sind als XLSX.
Weitere für automatisierte Exporte relevante Parameter, wie z.B. `limit`, `offset` oder `orderByField` sind in der Dokumentation zu finden.
### Exportformate
Für alle Exportmöglichkeiten stehen folgende Formate zur Verfügung:
* XLSX (Excel)
* CSV (Comma Separated Values)
* JSON (JavaScript Object Notation)
---
## Analytics
**URL:** https://richard-dev-playground.enneo.ai/docs/de/analytics/overview
**Description:** Datenanalyse in Enneo
### Zentrale Datentabellen
In Enneo gibt es drei zentrale Datentabellen:
**1. Ticketdaten**
Ein Ticket fasst alle Nachrichten zu einem Thema eines Kunden zusammen, vergleichbar zu einem Thread in GoogleMail. In diesem Datensatz sind nur die Tickets mit Daten wie Status (offen/geschlossen), SLA-Performance (rechtzeitig gelöst/nicht rechtzeitig gelöst) oder Skill-Kategorie enthalten. Mit diesem Datensatz erhält man, mit einem Filter auf offene Tickets, eine Übersicht über den Arbeitsbestand des Service Centers.
**2. Ein- und ausgehende Nachrichten**
Exportiert der eingehenden und ausgehenden Nachrichten. Eine Nachricht ist die ursprüngliche Nachricht eines Tickets sowie Antworten von Kunden und/oder Agenten sowie internen Notizen. Die Richtung (eingehend/ausgehend) ist durch die Spalte `direction` definiert. Dieser Datensatz gibt Einblicke in das Eingangsvolumen eines Service-Centers.
**3. Export von Bearbeitungen**
Exportiert alle Bearbeitungen. Eine manuelle Bearbeitung entsteht immer dann, wenn ein menschlicher Nutzer oder ein Enneo KI-Agent ein Ticket bearbeitet. Dieser Datensatz gibt Einblicke in das geleistete Arbeitsvolumen eines Service-Centers, von Teams oder (je nach Datenschutzeinstellung) einzelner Mitarbeiter.
Dieser Datensatz ist [hier](/docs/de/analytics/worklog) im Detail beschrieben.
### Beziehung zwischen Datentabellen
Zur Veranschaulichung der Beziehung zwischen Tickets, Nachrichten und Bearbeitungen ist hier ein Beispiel dargelegt:
| Aktivität | Tickets | Nachrichten | Bearbeitungen | Richtung | Typ | Bearbeitungsart |
| ----------------------- | ------- | ----------- | ------------- | -------- | ----- | --------------- |
| Kunde schickt E-Mail | 1 | 1 | 0 | in | Erst | |
| MA antwortet + schließt | 1 | 2 | 1 | out | Folge | Mit Antwort |
| MA schreibt Notiz | 1 | 3 | 1 | internal | Folge | |
| Kunde hat Rückfrage | 1 | 4 | 1 | in | Folge | |
| Kunde erneute Rückfrage | 1 | 5 | 1 | in | Folge | |
| MA: Status wartend | 1 | 5 | 2 | | | Wartend gesetzt |
| MA schreibt Notiz | 1 | 6 | 2 | internal | Folge | |
| MA weist Kollegen zu | 1 | 6 | 2 | | | |
| Kollege schließt Ticket | 1 | 6 | 3 | | | Ohne Antwort |
| **Summe** | **1** | **6** | **3** | | | |
---
## Bearbeitungen
**URL:** https://richard-dev-playground.enneo.ai/docs/de/analytics/worklog
**Description:** Datenexport aller Bearbeitungen
In diesem Export erfasst Enneo alle Bearbeitungen von Kundenanliegen. Er eignet sich insbesondere dazu, das im Service-Center realisierte Volumen zu messen. Dabei werden die folgenden Informationen exportiert:
## Bearbeitungszeit (`duration`)
Enneo ermittelt die Bearbeitungszeiten (AHT, "Average Handling Time") bei der Ticketbearbeitung, indem die gesamte Bildschirmzeit des Browsers an einem Ticket summiert wird. Dafür sind drei Zeitpunkte relevant:
- **Startzeitpunkt**: Zeitpunkt, zu dem der User das Ticket öffnet – entweder manuell oder per Skill-based Routing.
- **Bearbeitungszeitpunkt**: Zeitpunkt, an dem der User eine Bearbeitung am Ticket vorgenommen hat. Gibt es mehrere Bearbeitungen, wird der Zeitpunkt der ersten Bearbeitung verwendet.
- **Endzeitpunkt**: Datum des letzten Browserzugriffs auf ein Ticket.
Die Bearbeitungszeit (`duration` im Export) ist die Differenz zwischen End- und Startzeitpunkt. Die Nachbearbeitungszeit (`durationAfterWork` im Export) ist die Differenz zwischen Bearbeitungs- und Endzeitpunkt.
### Häufige Fragen zur Bearbeitungszeit:
- **Umgang mit verteilten Bearbeitungen**: Wird ein Ticket mehrmals am selben Tag bearbeitet, zum Beispiel in verschiedenen Sessions, werden die Zeiten aggregiert. Beispiel:
- User 1 schaut sich ein Ticket vormittags für 5 Minuten an und schließt es dann mittags nach weiteren 10 Minuten Bearbeitungszeit.
- User 2 schaut es sich mittags nur lesend an
- User 3 hat das Ticket abends nach 2 Minuten Bearbeitung wiedereröffnet und auf wartend gesetzt.
- -\> Enneo erfasst hier zwei Bearbeitungen: 1 Bearbeitung zu 15 Minuten von User 1, keine Bearbeitung / Erfassung für User 2 und 1 Bearbeitung zu 2 Minuten von User 3. Es ergäbe sich eine durchschnittliche Tages-AHT von (15\+2)/2=8,5min
- **Berücksichtigung von untertägigen Antworten**: Arbeitet ein User vormittags 5 Minuten an Ticket 1 und nachmittags noch einmal 7 Minuten daran, weil der Kunde mittags eine Rückfrage hatte, zählen diese beiden Zeitblöcke als zwei separate Bearbeitungen. Die AHT ist dann (5 \+ 7) / 2 = 6 Minuten. Hätte der Kunde mittags nicht geantwortet und der User würde am gleichen Fall zweimal tätig, z. B. 5 Minuten vormittags und 7 Minuten nachmittags ohne Rückfrage, würde das als eine Bearbeitung mit insgesamt 12 Minuten gezählt.
- **Parallele Bearbeitungen**: Hat ein User mehrere Tickets gleichzeitig in verschiedenen Browserfenstern offen, wird die AHT über die Tickets verteilt. Es kommt somit nie zu einer Doppelzählung. Beispiel: Bearbeitet ein User 4 Tickets parallel über 20 Minuten, ergibt sich eine AHT von 20 / 4 = 5 Minuten.
- **Status**: Nur wenn sich der User im Status "Aktiv" befindet, wird die Zeit zur AHT gezählt. Weitere Informationen dazu finden Sie im Abschnitt _Users-Status_ weiter unten.
## Bearbeitungsart (`action`)
Enneo erfasst eine „Bearbeitung“ (d. h. Arbeit eines Users) nur dann, wenn ein Ticket nicht nur lesend betrachtet, sondern tatsächlich bearbeitet wurde.
Es werden vier Bearbeitungsarten unterschieden (in Klammern die Bezeichnung im Datenexport):
- **Status auf Wartend gesetzt** (`statusAction`): Der Bearbeiter hat den Status eines Tickets auf „Wartend“ gesetzt. Beispiel: Es fehlen Informationen, die beim Kunden angefragt wurden. Sobald diese vorliegen, kann die Bearbeitung weitergehen.
- **Bearbeitung ohne Antwort** (`closeAction`): Ein Ticket wurde durch den Bearbeiter geschlossen, ohne dass eine Antwort an den Kunden verschickt wurde. Beispiel: Der Kunde will kündigen, und die Kündigungsbestätigung wird vom Abrechnungssystem versendet. Eine separate Antwort ist daher nicht nötig.
- **Bearbeitung mit Antwort** (`writeAction`): Ein Ticket wurde mit einer Antwort geschlossen. Beispiel: Ein Kunde hat eine Frage gestellt, die beantwortet wird.
- **Dunkelverarbeitung** (`autoProcessAction`): Ein Ticket wurde autonom durch einen auf Dunkelverarbeitung konfigurierten Enneo-KI-Agenten geschlossen. Beispiel: Ein Kunde möchte eine Guthabenauszahlung, und der entsprechende KI-Agent veranlasst dies automatisch.
Gab es mehrere Bearbeitungen (z. B. wenn ein Ticket zunächst geschlossen und anschließend eine Antwort versendet wurde), gilt die Bearbeitungsart mit der höheren Priorität gemäß der obigen Reihenfolge. Somit würde in diesem Fall „Bearbeitung mit Antwort“ (writeAction) erfasst.
## Fallabschließende Bearbeitung (`reOpened`)
Ist dieser Wert gesetzt (= 1), wurde das Ticket nach dem Schließen noch einmal wiedereröffnet – entweder durch eine Folgeantwort des Kunden oder durch einen Kollegen. Damit ist eine Erfassung der First-Contact-Resolution Quote möglich.
## User-Status (`status`)
In Enneo gibt es verschiedene Statusmodi für User. Standardmäßig stehen vier Statusmodi zur Verfügung:
- **Aktiv**: Nach dem Einloggen ist ein User standardmäßig „Aktiv“ (auch „Ticketbearbeitung“ genannt). In diesem Status ist die Bearbeitung von Tickets möglich, und die Zeit wird erfasst.
- **Support**: Falls unterstützende Leistungen erbracht werden müssen (z. B. Hilfe für Kollegen), kann dieser Status gewählt werden. In diesem Modus sind zwar lesende Zugriffe möglich, jegliche Bearbeitungen sind jedoch gesperrt. Auch in diesem Status wird keine Zeit erfasst.
- **Pause**: Pausenmodus. Weder lesender noch schreibender Zugriff ist möglich, und es wird keine Zeit erfasst.
- **Auto-Abwesend**: Nach einer konfigurierbaren Zeit der Inaktivität kann ein User automatisch in den Pausenmodus versetzt werden. Beim Zurückkehren erscheint ein Popup, in dem festgelegt wird, wie die Zeit verbucht werden soll. Wird „Aktiv“ ausgewählt, wird die entsprechende Zeit zur AHT gezählt.
Die User-Status-Modi und Einstellungen zur Auto-Abwesenheit sind unter **Einstellungen -\> Erweiterte Einstellungen -\> Allgemeines -\> Zeiterfassung -\> Zeiterfassung-Auswahlmöglichkeiten** frei konfigurierbar.
## Name des Bearbeiters (`name`) / Datenschutz
Im Bearbeitungsexport werden leistungsbezogene Daten wie Bearbeitungsmengen und -zeiten bereitgestellt. Auf Wunsch kann Enneo diese unzugänglich machen. Es stehen drei Datenschutzstufen zur Verfügung:
- **Anonymisierung**: Keine Rückschlüsse darauf, wer wann welche Bearbeitung vorgenommen hat. Jede Bearbeitung wird unter dem Benutzer „Anonym“ aufgeführt.
- **Pseudonymisierung**: Anstelle von Klarnamen (z. B. „Meike Mustermann“) vergibt Enneo zufällige Pseudonyme (z. B. „Hungrige Himbeere“).
- **Klarnamen**: Die Klarnamen der Bearbeiter (z. B. „Meike Mustermann“) werden dargestellt.
## Automatisierungsgrad der Bearbeitung (`aiAutomationLevel`)
Erfasst die höchste in der Bearbeitung beobachtete Automatisierungsstufe (Wertebereich 0–5). Dieses Feld unterstützt die Messung des Fortschritts hin zu Dunkelverarbeitung.
Die Stufen im Überblick:
- **L0**: Keine KI-Unterstützung, außer Kunden-/Tag-Erkennung
- **L1**: User hat KI zur Textbearbeitung genutzt
- **L2**: User hat den Vorschlag des Basis-Agenten manuell bestätigt (mit oder ohne Anpassungen)
- **L3**: User hat den Vorschlag eines anderen (nicht Basis-)Agenten manuell bestätigt
- **L4**: Autoverarbeitung mit Freigabe (Approval erforderlich)
- **L5**: Vollständig autonome Autoverarbeitung
## Korrekte Kundenerkennung (`customerIdentifiedCorrectly`)
1/0-Flag, ob der Kunde korrekt identifiziert wurde, d. h. es war keine Korrektur im Rahmen einer manuellen Anpassung nötig. Das Feld misst die Datenqualität und Reibung im Intake-Prozess und zeigt Optimierungspotenzial bei Erkennungs-Prompts oder beim Kundencode zur Kundensuche.
## Korrekte Tag‑Erkennung (`tagsIdentifiedCorrectly`)
1/0-Flag, ob die zugewiesenen Tags (z. B. Skill‑Tags, Produkt‑Tags) korrekt identifiziert wurden, d. h. ohne nachträgliche manuelle Korrektur. Eine Tag-Erkennung kann mithilfe der Erkennungs-Prompts optimiert werden.
## Qualität der Textunterstützung (`textAssistanceAccuracy`)
Numerische Ähnlichkeit als Wert zwischen 0 und 1 (z. B. 0.9843 für 98.43 %) zwischen dem vom Basis‑Agenten empfohlenen Text und dem tatsächlich gesendeten Text – sofern der Basis‑Agent verwendet wurde. Die Ähnlichkeit wird als 1 minus normalisierte Textdifferenz (z. B. sogenannte normalisierte Levenshtein-Distanz) berechnet. `NULL`, wenn kein Basis‑Agent verwendet wurde oder keine Vergleichsbasis vorliegt. Das Feld misst den Nutzwert der KI-Textvorschläge. Durch Prompt-Optimierung des Basis-Agenten, bessere Wiki-Einträge oder zusätzliche Kundendaten aus der ERP-Integration lässt sich der Wert verbessern.
## Verwendete KI‑Agenten (`aiAgentsUsed`)
JSON‑Array der in der Bearbeitung verwendeten KI‑Agenten‑Namen. Ermöglicht Adoptions‑Tracking und Wirkungsanalysen pro Agent. Kann einen oder mehrere Einträge enthalten.
## Übersprungenes Ticket (`skippedTicket`)
1/0-Flag, das angibt, ob ein vom Autopilot automatisch zugewiesenes Ticket vom User übersprungen wurde. Nützlich zur Erkennung von möglichem Cherry‑Picking oder für das Aufdecken von Routing‑Problemen.
## SLA‑Abweichung beim Schließen (`netSecondsClosedAfterSLA`)
Sekunden zwischen dem "Bearbeitungszeitpunkt aus Kundenperspektive" und SLA‑Fälligkeit – netto, d. h. unter Berücksichtigung der konfigurierten Arbeitszeiten und ohne Wochenenden/Nichtarbeitszeiten. Ein negativer Wert bedeutet fristgerecht geschlossen, ein positiver Wert verspätet. `NULL`, wenn keine SLA‑Fälligkeit ermittelt werden konnte. Siehe auch `Routing und Tags → SLAs und Arbeitszeiten`.
Der "Bearbeitungszeitpunkt aus Kundenperspektive" ist definiert als der Zeitpunkt des Antwortversandes, der Schließung oder im Falle einer Dunkelvearbeitung mittels KI der Verarbeitungszeitpunkt. Gibt es mehrere Zeitpunkte, wird der früheste genommen.
## Teams des Bearbeiters (`teams`)
JSON‑Array mit den Teamnamen des Users zum Zeitpunkt der Bearbeitung. Unterstützt Multi‑Team‑Analysen ohne String‑Parsing.
## Ticket‑Tags (`tags`)
JSON‑Array der dem Ticket zugewiesenen Tag‑Namen. Ermöglicht Analysen auf Tag‑Ebene sowie flexible Filter.
## Themenklassifikation (`topic`, `subTopic`)
Wenn konfiguriert, wird eine Themenklassifikation ausgewiesen. `topic` bildet die Hauptkategorie (z. B. „Allgemein“), `subTopic` die Unterkategorie (z. B. „RG: Abschlag/JVB“). Beide Felder können `NULL` sein, wenn keine Klassifikation vorliegt.
## Kanal (`channel`)
Kontaktkanal der Kundenanfrage (z. B. `email`, `mail`). Kann `NULL` sein, wenn nicht bestimmbar.
# Technische Felder
Diese werden nur befüllt, wenn Enneo die User nicht anonymisiert (siehe Feld `name` / Datenschutz).
- `date` - Zeitpunkt der Erfassung der Bearbeitung.
- `ticketId` - Ticket-ID des Tickets, das bearbeitet wurde.
- `conversationId` - Conversation-ID der letzten Kunden-Nachricht zum Zeitpunkt der Bearbeitung. NULL, wenn es eine initiale Anfrage war.
- `userId` - User-ID des Bearbeiters.
- `userWorklogId` - Eindeutige ID der Bearbeitung (Primärschlüssel).
# Veraltete Felder
Folgende Felder werden aktuell noch erfasst, aber in einem zukünftigen Release entfernt:
- `aiAgentId` - Name eines KI-Agents, der in der Bearbeitung verwendet wurde. Ersetzt durch `aiAgentsUsed`, da mehrere Agenten pro Bearbeitung verwendet werden können.
- `department` - Komma-separierte Liste der Abteilungen des Bearbeiters. Ersetzt durch `teams`, das dies als JSON-Array ausweist und somit leichter verarbeitbar ist.
- `allTags` - Komma-separierte Liste aller Tags, die dem Ticket zugewiesen wurden. Ersetzt durch `tags`, das dies als JSON-Array ausweist und somit leichter verarbeitbar ist.
- `email` - E-Mail-Adresse des Bearbeiters. Als Alternativen kann der Name des Bearbeiters (`name`) oder die User-ID (`userId`) verwendet werden.
- `rawData` - JSON-String des `rawData` Wertes des Tickets/Nachricht. Nicht mehr notwendig, da über `ticketId` und `conversationId` die Nachrichten eindeutig identifiziert werden können.
---
## Glossar
**URL:** https://richard-dev-playground.enneo.ai/docs/de/faq/glossar
**Description:** Glossar
### **A**
**Anonymisierungsprozess**
Ein Verfahren innerhalb von Enneo, das sicherstellt, dass sensible Kundendaten in Tickets und Kommunikationen unkenntlich gemacht werden, um Datenschutzrichtlinien einzuhalten.
### **B**
**Benutzerverwaltung**
Ein Modul in Enneo, das Administratoren ermöglicht, Benutzerkonten zu erstellen, Rollen zuzuweisen und Zugriffsrechte innerhalb der Plattform zu verwalten.
### **C**
**Customer Relationship Management (CRM)**
Ein System oder eine Strategie zur Verwaltung und Analyse von Kundeninteraktionen, das oft mit Enneo integriert wird.
### **D**
**Dunkelverarbeitung**
Ein Prozess, bei dem KI-Agenten Kundenanfragen vollständig automatisiert bearbeiten, ohne dass menschliches Eingreifen erforderlich ist.
### **E**
**Events und Webhooks**
Mechanismen, die es ermöglichen, auf bestimmte Ereignisse innerhalb der Enneo-Plattform zu reagieren und externe Systeme in Echtzeit zu benachrichtigen.
### **F**
**Freitextanalyse**
Eine Methode, bei der KI oder regelbasierte Logik genutzt wird, um unstrukturierte Texte in Kundenanfragen zu analysieren und zu klassifizieren.
### **K**
**KI-Agenten**
Künstliche Intelligenz innerhalb von Enneo, die Kundenanfragen analysiert und automatisierte Antworten oder Aktionen basierend auf vordefinierten Regeln und Lernalgorithmen bereitstellt.
**Kundenerkennung**
Funktionen in Enneo, die es ermöglichen, Kunden anhand ihrer Daten zu identifizieren und deren Anfragen entsprechend zuzuordnen.
**Kundenzufriedenheitsbewertung (CSAT - Customer Satisfaction Score)**
Ein Indikator zur Messung der Kundenzufriedenheit, der oft durch Feedback am Ende einer Ticketbearbeitung erhoben wird.
### **P**
**Partnerintegration**
Die Fähigkeit von Enneo, sich mit externen Partner-Systemen zu verbinden, um Daten auszutauschen und Prozesse zu synchronisieren.
### **R**
**Regelbasierte Logik**
Ein Ansatz innerhalb von Enneo, bei dem vordefinierte Regeln verwendet werden, um Entscheidungen zu treffen und Aktionen basierend auf bestimmten Bedingungen auszuführen.
**Routing und Tags**
Funktionen, die es ermöglichen, eingehende Tickets oder Anfragen automatisch bestimmten Teams oder Kategorien zuzuweisen, basierend auf definierten Schlagwörtern oder Kriterien.
**Response Time (Reaktionszeit)**
Die Zeitspanne, die zwischen dem Eingang einer Kundenanfrage und der ersten Antwort vergeht.
### **S**
**SDK (Software Development Kit)**
Ein Toolkit, das Entwicklern Werkzeuge und Dokumentation bereitstellt, um eigene Anwendungen oder Integrationen mit der Enneo-Plattform zu erstellen.
**SLA (Service Level Agreement)**
Eine Vereinbarung über die erwartete Reaktions- und Lösungszeit für Kundenanfragen, die oft in Enneo konfiguriert wird.
**Smarte Argumentationslogik**
Ein Feature von Enneo, das KI-Agenten ermöglicht, komplexe Kundenanfragen durch logische Schlussfolgerungen und Kontextverständnis effektiv zu bearbeiten.
### **T**
**Templates**
Vordefinierte Textbausteine, die in Enneo erstellt werden können, um konsistente und schnelle Antworten auf häufige Kundenanfragen zu gewährleisten.
**Ticketbearbeitung**
Der Prozess des Empfangens, Kategorisierens, Bearbeitens und Abschließens von Kundenanfragen innerhalb der Enneo-Plattform.
**Ticketstatus**
Der aktuelle Bearbeitungsstand eines Tickets, z. B. „Neu“, „In Bearbeitung“ oder „Abgeschlossen“.
**Transparente Weiterleitung**
Ein Feature, das es ermöglicht, ein Ticket an eine andere Abteilung weiterzuleiten, ohne dass der Kunde dies bemerkt.
### **W**
**Wissensmanagement**
Das Sammeln, Organisieren und Bereitstellen relevanter Informationen, um Kundenanfragen effizient zu beantworten – oft über das Wiki oder FAQ-Bereich in Enneo.
**Workflow-Automatisierung**
Ein Mechanismus, der bestimmte Prozesse in Enneo automatisch ausführt, basierend auf definierten Regeln oder Triggern.
**Wiki**
Ein integriertes Wissensmanagement-Tool in Enneo, das es Teams ermöglicht, Informationen, Anleitungen und FAQs zentral zu speichern und zu verwalten.
---
## Autorisierung
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/authorization
**Description:** Erfahren Sie, wie Sie sich mit der Enneo API authentifizieren
Um ein Autorisierungstoken für die Nutzung der Enneo API zu erhalten, stehen API-Nutzern je nach Anwendungsfall folgende Optionen zur Verfügung.
### 1. User-JWT-Token für die Entwicklung
Nutzer können einen persönlichen Zugriffstoken generieren, indem sie zu ihrer Profilseite navigieren und auf die Schaltfläche „API-Schlüssel erstellen“ (Create API Key) klicken. Es ist wichtig, diesen Schlüssel zu speichern, da er nur einmal angezeigt wird.
### 2. Service-Worker-JWT-Token für periodische Aufgaben
Sie können einen Service-Worker-Token verwenden, indem Sie in den Einstellungen → Benutzer → Service Worker einen bestehenden Service Worker auswählen oder einen neuen erstellen. Sobald ein Service Worker ausgewählt ist, können Nutzer durch Klicken auf die Schaltfläche „API-Schlüssel erstellen“ (Create API Key) einen API-Schlüssel erzeugen. Es ist entscheidend, diesen Schlüssel zu speichern, da er nur einmal angezeigt wird.
Diese Tokens laufen nur ab, wenn sie auf der Seite Benutzer → Service Worker widerrufen bzw. neu erstellt werden.
### 3. OAuth2-Session-Token
API-Service-Worker oder Nutzer können sich mit Single-Sign-On-(SSO)-Anmeldedaten über die `/api/auth`-Endpunkte anmelden, um ein Session-Token zu erhalten. Das SSO-Backend, typischerweise Microsoft Azure OAuth2 oder Google OAuth2, validiert anschließend gegenüber Enneo. Ist die Validierung erfolgreich, stellt Enneo ein Session-Token mit einer Gültigkeit von 24 Stunden aus, das als Zugangsdaten für API-Anfragen verwendet werden kann. Diese Methode ist komplexer und wird daher in der Regel nur in fortgeschrittenen Infrastruktur-Setups eingesetzt.
Denken Sie daran, Ihre Autorisierungstokens sicher zu speichern und zu verwalten, um die Sicherheit und Integrität Ihrer API-Interaktionen zu gewährleisten.
### Verwendung des Tokens
Sobald Sie das Token haben, können Sie es als Bearer-Token im Header übergeben, wie in diesem Beispiel:
```bash
curl --header 'Authorization: Bearer eyJhbGciOiJI...' \
'https://demo.enneo.ai/api/mind/ticket/6'
---
## OpenAPI-Spezifikation
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/endpoints
**Description:** Maschinenlesbare API-Definition
Die API-Referenz wird aus der OpenAPI-Spezifikation der Enneo Mind API generiert.
---
## Einführung
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/introduction
**Description:** Einführung zur Enneo API
## Enneo API Dokumentation
Die Enneo API bietet eine Reihe von Endpunkten für das Importieren/Manipulieren von Tickets, Benutzerverwaltung, Tag-Verwaltung und ERP-Interaktion. Diese Dokumentation skizziert die typischen Anwendungsfälle und gibt Details zur Interaktion mit jedem Endpunkt.
Die vollständige API-Spezifikation finden Sie im Swagger Format hier, inklusive Datenstrukturen, Rückgabeformate und Beispiele. Das ist ideal für Entwickler.
### Importieren/Manipulieren von Tickets
Die Enneo API ermöglicht das Importieren und Manipulieren von Tickets. Es können neue Tickets erstellt, bestehende aktualisiert und Ticketinformationen abgerufen werden. Die verfügbaren Endpunkte für die Ticketverwaltung sind:
* `POST /tickets`: Neues Ticket erstellen
* `PATCH /ticket/{id}`: Bestehendes Ticket aktualisieren, z. B. durch Zuweisen von Verträgen oder Ändern des Status
* `GET /ticket/{id}`: Ticket anhand seiner ID abrufen
### Tag-Verwaltung
Mit Tags können Daten im Enneo-System kategorisiert und organisiert werden. Die API ermöglicht die Verwaltung von Tags durch das Erstellen, Aktualisieren und Abrufen von Tag-Informationen. Tags können Fähigkeiten, aber auch Produkte oder Marken sein. Die Endpunkte für die Tag-Verwaltung sind:
* `POST /tag`: Neuen Tag erstellen
* `GET /tag`: Alle Tags auflisten
* `GET /tag/{id}`: Tag-Informationen anhand der ID abrufen
### ERP-Interaktion
Die Enneo API unterstützt auch die Integration mit ERP-Systemen, was das Suchen und Abrufen von Kundeninformationen ermöglicht. Der folgende Endpunkt steht für die ERP-Interaktion zur Verfügung:
* `GET /erp/customers`: Kundeninformationen suchen und abrufen
Bitte beziehen Sie sich auf die Enneo API-Dokumentation für detaillierte Informationen zu Anfrage- und Antwortformaten, Authentifizierung und Fehlerbehandlung.
### Benutzerverwaltung
Für die Benutzerverwaltung verwendet Enneo eine andere API-Spezifikation, die vom Autorisierungsmikrodienst stammt. Bitte beziehen Sie sich für weitere Informationen auf diese Dokumentation:
---
## Anonymisierungsprozess
**URL:** https://richard-dev-playground.enneo.ai/docs/de/legal/anonymization-process
**Description:** Anonymisierungsprozess
### 1. Verfahren des Anonymisierungsprozesses
Zu Beginn setzen wir ein hochentwickeltes Sprachmodell (LLM) ein, eine Form fortschrittlicher künstlicher Intelligenz. Dieses Modell ist speziell darauf trainiert, große Textmengen effizient zu analysieren. Es erkennt zuverlässig Muster, die auf persönliche Informationen in Kunden-E-Mails hinweisen, wie Namen oder Kontaktdaten. Durch kontinuierliche Updates und Verbesserungen stellen wir sicher, dass das LLM stets den neuesten Standards im Datenschutz entspricht und effektiv arbeitet.
### 2. Erkennung personenbezogener Daten
Das LLM durchleuchtet jede E-Mail gründlich und identifiziert personenbezogene Daten wie Namen, Adressen, Telefonnummern und E-Mail-Adressen. Es nutzt fortschrittliche Algorithmen, um Strukturen und Muster zu erkennen, die typisch für solche sensiblen Informationen sind. Dieser Schritt ist entscheidend, um sicherzustellen, dass keine persönlichen Daten ungeschützt bleiben.
### 3. Ersetzung durch Nullwerte
Nach der Identifikation werden personenbezogene Daten durch Neutralwerte wie "xxxx xxxx" ersetzt. Dieser Prozess wird zweimal durchgeführt, um maximale Sicherheit zu gewährleisten. Dadurch wird sichergestellt, dass die Originaldaten nicht mehr rekonstruiert werden können, was einen hohen Datenschutzstandard garantiert.
### 4. Benutzeroberfläche und manuelle Kontrollen
Eine speziell entwickelte Benutzeroberfläche ermöglicht den sicheren Zugriff auf die anonymisierten Daten. Diese Oberfläche ist intuitiv gestaltet und erlaubt es den Mitarbeitern, die Daten effizient zu verwalten und zu überwachen. Damit werden regelmäßige Stichprobenkontrollen durchgeführt. Diese Überprüfungen dienen der Qualitätssicherung und stellen sicher, dass der Anonymisierungsprozess effektiv und vollständig abläuft. Bei Bedarf werden Korrekturen vorgenommen, um die höchsten Datenschutzstandards einzuhalten.
### 5. Datenschutz und Sicherheit
Der gesamte Prozess ist mit dem Fokus auf maximalen Datenschutz und Sicherheit konzipiert. Die Anonymisierung von Kundendaten ist ein zentraler Bestandteil unseres Engagements für die Privatsphäre unserer Kunden. Wir stellen sicher, dass persönliche Informationen in keiner Weise unbefugt verwendet oder eingesehen werden können. Dieser Prozess ist konform mit den neuesten Datenschutzbestimmungen und -praktiken.
---
## Auftragsverarbeitungsvertrag (AVV)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/legal/avv
**Stand: Februar 2026**
[📥 Dokument herunterladen](https://admin.enneo.ai/api/files/get/public/AVV-Enneo-2026-02.pdf)
## Frühere Versionen
- [AVV (Stand: Juli 2025) - Download](https://admin.enneo.ai/api/files/get/public/AVV-Enneo-2025-07.pdf)
- [AVV (Stand: Juni 2025) - Download](https://admin.enneo.ai/api/files/get/public/AVV-Enneo-2025-06.pdf)
---
## Datenflussdiagramm
**URL:** https://richard-dev-playground.enneo.ai/docs/de/legal/datenflussdiagramm
**Stand: November 2025**
[📥 Dokument herunterladen](https://admin.enneo.ai/api/files/get/public/Datenflussdiagramm-Enneo-2025-11.pdf)
---
## Datenschutz-Folgenabschätzung (DSFA)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/legal/dsfa
**Stand: November 2025**
[📥 Dokument herunterladen](https://admin.enneo.ai/api/files/get/public/Datenschutzfolgeabschätzung-Enneo-2025-11.pdf)
---
## Konformitätserklärung zur EU AI Act & DSGVO Compliance
**URL:** https://richard-dev-playground.enneo.ai/docs/de/legal/eu-compliance
**Stand: November 2025**
[📥 Dokument herunterladen](https://admin.enneo.ai/api/files/get/public/Konformitätserklärung EU-Compliance-Enneo-2025-11.pdf)
---
## Rechtliche Informationen
**URL:** https://richard-dev-playground.enneo.ai/docs/de/legal
**Description:** Alle wichtigen rechtlichen Dokumente für ihre Enneo-Erfahrung auf einem Blick
---
## Leistungsbeschreibung
**URL:** https://richard-dev-playground.enneo.ai/docs/de/legal/leistungsbeschreibung
**Stand: Januar 2026**
[📥 Dokument herunterladen](https://admin.enneo.ai/api/files/get/public/Leistungsbeschreibung-Enneo-2026-01.pdf)
---
## Master Subscription Agreement (MSA) / Software-as-a-Service (SaaS) Vertrag
**URL:** https://richard-dev-playground.enneo.ai/docs/de/legal/msa
**Stand: Januar 2026**
[📥 Dokument herunterladen](https://admin.enneo.ai/api/files/get/public/MSA-Enneo-2026-01.pdf)
---
## Service Level Agreement (SLA)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/legal/sla
**Stand: April 2026**
[📥 Dokument herunterladen](https://admin.enneo.ai/api/files/get/public/SLA-Enneo-2026-04.pdf)
## Frühere Versionen
- [SLA (Stand: Januar 2026) - Download](https://admin.enneo.ai/api/files/get/public/SLA-Enneo-2026-01.pdf)
---
## Technische und Organisatorische Maßnahmen (TOM)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/legal/tom
**Stand: Juli 2025**
[📥 Dokument herunterladen](https://admin.enneo.ai/api/files/get/public/TOM-Enneo-2025-07.pdf)
## Frühere Versionen
- [TOM (Stand: Juni 2025) - Download](https://admin.enneo.ai/api/files/get/public/TOM-Enneo-2025-06.pdf)
---
## Qualitätsbewertung
**URL:** https://richard-dev-playground.enneo.ai/docs/de/quality/quality-assessments
### Wo Bewertungen zu sehen sind
Assessments sind direkt in der **Ticket-Ansicht** abrufbar: Über den Bewertungs-Button in der Ticket-Detailleiste öffnet sich das Worklog des jeweiligen Tickets mit allen zugehörigen Assessments. Der Button ist nur sichtbar, wenn der angemeldete Nutzer mindestens eine der Bewertungs-Ansicht-Berechtigungen besitzt (siehe unten).
Scorecards werden unter **Einstellungen → Qualitäts-Scorecards** verwaltet.
### Berechtigungen
| Berechtigung | Beschreibung |
|---|---|
| `QualityViewAssessmentOwn` | Eigene Bewertungen einsehen |
| `QualityViewAssessmentTeamMate` | Bewertungen von Teammitgliedern einsehen |
| `QualityViewAssessmentAll` | Bewertungen aller Nutzer einsehen |
| `QualityDoAssessmentsTeam` | Bewertungen für Teammitglieder erstellen und bearbeiten |
| `QualityDoAssessmentsAll` | Bewertungen für beliebige Nutzer erstellen und bearbeiten |
| `QualityDeleteAssessment` | Bewertungen löschen |
| `QualityManageScorecards` | Scorecards erstellen, bearbeiten und verwalten |
| `QualityDeleteScorecard` | Scorecards löschen |
### Entstehung und automatische Erstellung
Assessments werden nicht manuell angelegt, sondern durch einen minütlich laufenden Hintergrundjob. Dieser identifiziert Arbeitsvorgänge vom Typ `writeAction`, für die noch keine Bewertung erstellt wurde, prüft welche aktiven Scorecards anwendbar sind und legt für jede passende Scorecard ein Assessment an.
Pro Arbeitsvorgang kann es mehrere Bewertungen – eine für jede Scorecard, deren Zuweisungsregeln zutreffen.
Nach der Erstellung wird ein Event ausgelöst, das die KI-Verarbeitung startet.
### KI-Verarbeitung
Der Cortex-Dienst erhält als Bewertungsgrundlage:
- Den *Nachrichtenfluss des Tickets* – vom ersten Kundenkontakt bis zur letzten Agentenantwort (inkl. interner Notizen)
- Die *Scorecard* mit allen Kategorien, Kriterien und Bewertungsprompts
- *Worklog-Details* – Zeiterfassung, verwendete KI-Agenten, Automatisierungsgrad
- Das *Kundenerlebnis* – SLA-Einhaltung, CSAT
Cortex bewertet alle Kriterien, bei denen `autoGenerateByAi` aktiviert ist, und liefert für jedes Kriterium einen Score sowie eine Begründung zurück. Anschließend generiert die KI eine zusammenfassende Einschätzung (`aiSummary`).
KI-bewertete Kriterien erhalten den Status `aiGenerated`. Kriterien ohne KI-Bewertung bleiben `unscored` und müssen manuell bewertet werden.
### Bewertungsdaten
Ein Assessment enthält:
- *Kategorien und Kriterien* – mit Score, Begründung und Bewertungsstatus je Kriterium
- *Gesamtpunkte* – `scoredPoints`, `usedMaxPoints`, `totalMaxPoints`, `percentage`
- *KI-Zusammenfassung* (`aiSummary`) – freier Text, generiert durch die KI
- *Supervisor-Einschätzung* (`supervisorAssessment`) – freier Text, manuell eingetragen
- *Bewertungsdatum* und *Gesprächsdatum* – für Dokumentationszwecke
- *Zeiterfassung* – Bearbeitungszeit (Segmente, Nachbearbeitungszeit)
- *KI-Nutzung* – welche AI Agents involviert waren, Automatisierungsgrad
- *Kundenerlebnis* – SLA-Status, ob das Ticket wiedereröffnet wurde, CSAT-Ergebnis
- *Änderungshistorie* – lückenlose Protokollierung aller Änderungen (Score, Begründung, Status, wer hat wann geändert)
### Punkteberechnung
#### Wie wird der Prozentsatz berechnet?
Die Berechnung basiert ausschließlich auf *bewerteten* Kriterien:
- `usedMaxPoints` = Summe der Maximalpunkte aller Kriterien mit einem Score (inkl. Score = 0)
- `scoredPoints` = Summe der tatsächlich erzielten Punkte
- `totalMaxPoints` = Summe aller Maximalpunkte der Scorecard (inkl. unbewerteter Kriterien)
- `percentage` = `scoredPoints / usedMaxPoints × 100`
Unbewertete Kriterien (`unscored`) gehen nicht in die Berechnung ein. Das erlaubt eine valide Teilbewertung, wenn einzelne Kriterien mangels Datenlage nicht beurteilt werden können.
#### K.O.-Logik und ihre Auswirkung auf die Punktzahl
Kriterien können als K.O.-Kriterium für die Kategorie oder für das gesamte Assessment markiert sein.
- *Kategorie-K.O.:* Erzielt ein solches Kriterium 0 Punkte, werden alle Punkte der Kategorie auf 0 gesetzt – unabhängig von anderen Kriterien in derselben Kategorie.
- *Assessment-K.O.:* Erzielt ein solches Kriterium 0 Punkte, werden alle `scoredPoints` des gesamten Assessments auf 0 gesetzt.
Die K.O.-Logik wird bei jeder Neuberechnung der Gesamtpunkte angewendet, also nach jeder KI-Bewertung und nach jeder manuellen Änderung.
### Workflow-Zustände
Assessments durchlaufen einen definierten Workflow:
| Zustand | Bedeutung |
|---|---|
| `unprocessed` | Angelegt, KI-Verarbeitung ausstehend |
| `aiInProgress` | KI bewertet aktiv |
| `aiReady` | KI-Vorbewertung abgeschlossen, bereit zur Überprüfung |
| `reviewOngoing` | Supervisor hat mit der Überprüfung begonnen |
| `reviewedBySupervisor` | Überprüfung durch Supervisor abgeschlossen |
| `discussedWithAssessee` | Mit dem bewerteten Mitarbeiter besprochen |
| `error` | Fehler bei der KI-Verarbeitung |
*Automatische Rücksetzung:* Nimmt ein Supervisor nach Abschluss der Überprüfung (`reviewedBySupervisor`) oder nach dem Mitarbeitergespräch (`discussedWithAssessee`) noch Änderungen vor, wechselt der Status automatisch zurück auf `reviewOngoing`. Eingetragene Bewertungs- und Gesprächsdaten bleiben erhalten.
### Kriterium-Zustände
Jedes Kriterium innerhalb eines Assessments hat einen eigenen Status:
| Zustand | Bedeutung |
|---|---|
| `unscored` | Noch nicht bewertet |
| `aiGenerated` | Von der KI vorbewertet, noch nicht vom Supervisor bestätigt |
| `humanVerified` | Durch einen Supervisor manuell gesetzt oder bestätigt |
### Kontextdaten im Assessment
#### Zeiterfassung
Das Assessment enthält die Zeiterfassungsdaten des Arbeitsvorgangs: Gesamtbearbeitungszeit, Nachbearbeitungszeit und einzelne Zeitsegmente mit den durchgeführten Aktionen. Diese Daten stammen aus dem Worklog des Mitarbeiters und werden zum Zeitpunkt der Assessment-Erstellung eingefroren.
#### KI-Nutzung
Für jeden Arbeitsvorgang wird dokumentiert, welche AI Agents beteiligt waren und wie hoch der Automatisierungsgrad der Bearbeitung war. Diese Information dient als Kontext bei der Qualitätsbewertung – vollautomatisch bearbeitete Vorgänge sind anders zu bewerten als manuell bearbeitete.
#### Kundenerlebnis
Das Assessment enthält Informationen über die SLA-Einhaltung (wurde die Frist eingehalten, wie viele Sekunden nach der Frist wurde das Ticket geschlossen), ob das Ticket wiedereröffnet wurde, sowie das CSAT-Ergebnis (Kundenzufriedenheitsbefragung), sofern vorhanden. Diese Daten liefern objektive Qualitätssignale unabhängig von der Scorecard-Bewertung.
### Export
Qualitätsbewertungen lassen sich unter **Einstellungen → Datenexport** als XLSX, CSV oder JSON exportieren. Der Export enthält alle Assessment-Daten inklusive Scores, Begründungen, Zeiterfassung und Kundenerlebnis und eignet sich für externes Reporting oder die Auswertung in BI-Tools.
### Best Practices
- *Änderungshistorie nutzen:* Die lückenlose Protokollierung aller Score- und Statusänderungen macht Assessments auditierbar. Bei Rückfragen lässt sich nachvollziehen, was die KI ursprünglich bewertet hat und was manuell angepasst wurde.
- *Bewertungs- und Gesprächsdatum pflegen:* Diese Felder sind Pflichtfelder für sinnvolles Reporting – ohne sie lassen sich Bewertungszeiträume nicht korrekt auswerten.
- *KI-Zusammenfassung als Ausgangspunkt:* Die `aiSummary` ist keine finale Bewertung, sondern ein strukturierter Ausgangspunkt für die Supervisor-Überprüfung. Sie sollte nicht ungeprüft als Gesprächsgrundlage verwendet werden.
- *Error-Status überwachen:* Assessments im Status `error` werden nicht automatisch wiederholt. Sie sollten regelmäßig überprüft werden, um Bewertungslücken im Reporting zu vermeiden.
---
## Überblick
**URL:** https://richard-dev-playground.enneo.ai/docs/de/quality/quality-in-enneo
Qualitätsmanagement ist ein zentraler Bestandteil professioneller Servicecenter. Ziel ist es, die Qualität der Kundenkommunikation dauerhaft sicherzustellen, Bearbeitungsstandards messbar zu machen und Optimierungspotenziale frühzeitig zu erkennen.
Standardisierte Qualitätsbewertungen schaffen dabei eine gemeinsame Grundlage für Feedback, Coaching und kontinuierliche Verbesserung im Kundenservice. Sie helfen, Stärken sichtbar zu machen, Entwicklungspotenziale frühzeitig zu erkennen und eine konsistente Servicequalität sicherzustellen.
Enneo bietet KI-gestützte Qualitätsbewertungen zur automatisierten Analyse großer Mengen von Kundeninteraktionen anhand definierter Qualitätskriterien.
## Einstieg in Videos - Qualität in Enneo
## Qualitätssicherung im Servicecenter
Im Kundenservice entscheidet die Qualität der Bearbeitung maßgeblich über Kundenzufriedenheit, Prozessstabilität und die Wahrnehmung des Service. Gleichzeitig ist eine vollständige manuelle Prüfung aller Vorgänge in der Praxis kaum möglich, da Qualitätsbewertungen sehr zeitaufwendig und organisatorisch anspruchsvoll sind.
Viele Servicecenter arbeiten deshalb mit Stichproben und standardisierten Bewertungsbögen. Dadurch bleibt jedoch häufig nur ein kleiner Teil der tatsächlichen Kundeninteraktionen überprüfbar.
Enneo ermöglicht zusätzlich KI-gestützte Qualitätsbewertungen, mit denen große Mengen von Bearbeitungen automatisiert und anhand definierter Qualitätskriterien bewertet werden können. Dadurch lassen sich Qualitätsprüfungen deutlich skalieren, ohne den manuellen Aufwand proportional zu erhöhen.
## Manuelle und KI-gestützte Bewertungen
Qualitätsbewertungen können in Enneo sowohl durch Mitarbeiter im Qualitätsmanagement als auch automatisiert durch KI erfolgen.
Innerhalb der Qualitätsbewertung kann für einzelne Kriterien festgelegt werden, ob diese manuell oder automatisiert durch KI geprüft werden sollen. Die Steuerung erfolgt dabei über die sogenannte Scorecard, in der die jeweiligen Bewertungsanweisungen hinterlegt werden.
### KI-gestützte Analysen
KI-gestützte Analysen eignen sich insbesondere für standardisierbare Kriterien und große Mengen von Bearbeitungen. Dazu gehören beispielsweise:
- Verständlichkeit und Tonalität von Antworten
- die Frage, ob auf das konkrete Anliegen des Kunden eingegangen wurde
- Vollständigkeit und Nachvollziehbarkeit einer Rückmeldung
- die Einhaltung definierter Kommunikationsstandards
### Manuelle Qualitätsbewertungen
Kriterien, die fachliche Erfahrung, Entscheidungsspielräume oder organisatorischen Kontext erfordern, werden weiterhin manuell durch das Qualitätsmanagement beurteilt. Dazu zählen beispielsweise:
- Kulanzentscheidungen und individuelle Einzelfälle
- bewusste Abweichungen von definierten Prozessen
- die Angemessenheit einer Lösung im konkreten Kundenkontext
- fachliche oder regulatorische Sonderfälle
So lassen sich standardisierte Qualitätssicherung und menschliche Einschätzung gezielt miteinander kombinieren und deutlich breiter skalieren als in rein manuellen Prozessen.
---
## Scorecards
**URL:** https://richard-dev-playground.enneo.ai/docs/de/quality/quality-scorecards
Eine Scorecard ist eine Bewertungsvorlage, die festlegt, welche Kriterien bei der Qualitätsbewertung eines Arbeitsvorgangs geprüft werden. Sie bildet die Grundlage für jede Qualitätsbewertung (Assessment) im System.
Scorecards werden vom Qualitätsmanagement erstellt und gepflegt. Sobald eine Scorecard aktiv ist, können neue Arbeitsvorgänge automatisch damit verknüpft werden, sofern die konfigurierten Zuweisungsregeln zutreffen.
### Bereich und Berechtigungen
Scorecards werden unter **Einstellungen → Quality Scorecards** verwaltet.
Für den Zugriff gelten folgende Berechtigungen:
- **Ansehen:** Alle angemeldeten Nutzer können Scorecards einsehen.
- **Erstellen und Bearbeiten:** Erfordert die Berechtigung `qualityManageScorecards`.
- **Löschen:** Erfordert zusätzlich die Berechtigung `qualityDeleteScorecard`.
### Aufbau
Eine Scorecard besteht aus **Kategorien**, die ihrerseits **Kriterien** enthalten.
**Kategorien** fassen inhaltlich zusammengehörige Kriterien zusammen. Jede Kategorie hat eine Bezeichnung und eine Reihenfolge.
**Kriterien** definieren die eigentlichen Bewertungspunkte innerhalb einer Kategorie:
- **Bezeichnung und Beschreibung** – Was wird bewertet?
- **Maximalpunkte** – Gewichtung des Kriteriums
- **Bewertungstyp** – `metNotMet` oder `numericScale`
- **KI-Bewertung aktiviert** – Ob die KI dieses Kriterium automatisch bewertet
- **Bewertungsprompt** – Anweisung an die KI, nach welchen Maßstäben bewertet werden soll
- **K.O.-Kriterium für Kategorie** – Wird dieses Kriterium mit 0 bewertet, wird die Kategorie auf 0 gesetzt
- **K.O.-Kriterium für Bewertung** – Wird dieses Kriterium mit 0 bewertet, wird die Gesamtbewertung auf 0 gesetzt
### Zuweisung und Antwortkontext
Scorecards können auf bestimmte Arbeitsvorgänge eingeschränkt werden. Die Zuweisung erfolgt über:
- **Teams** – nur Arbeitsvorgänge von Mitgliedern bestimmter Teams
- **Ticket-Tags** – nur Tickets mit bestimmten Tags
- **Kanäle** – z. B. E-Mail, Telefon oder Brief
- **Antwortkontext** – ob die Scorecard für Antworten nach Kundennachrichten oder für proaktive Antworten gedacht ist
Beim Antwortkontext werden zwei Fälle unterschieden:
- **Nach Kundennachricht** (`afterCustomerMessage`) – klassische reaktive Qualitätssicherung: Ein Mitarbeiter beantwortet eine vorherige Kundenanfrage.
- **Ohne vorherige Kundennachricht / proaktiv** (`withoutCustomerMessage`) – für proaktive Kommunikation, bei der der Mitarbeiter eine Nachricht ohne direkte vorherige Kundenanfrage erstellt.
Wenn mehrere Zuweisungsregeln konfiguriert sind, müssen sie gemeinsam zutreffen.
### Automatische Erstellung von Bewertungen
Das System prüft regelmäßig, ob neue Arbeitsvorgänge vorhanden sind, die noch nicht bewertet wurden. Für jeden passenden Arbeitsvorgang wird ermittelt, welche aktiven Scorecards laut Zuweisungsregeln zutreffen.
Für jede passende Scorecard wird ein Assessment angelegt und zur KI-Verarbeitung eingereicht.
Ein Arbeitsvorgang kann durch mehrere Scorecards bewertet werden, wenn mehrere Scorecards zutreffen.
### Live Quality Coach
Die Option **Live Quality Coach** legt fest, ob eine Scorecard zusätzlich während der Ticketbearbeitung genutzt wird.
Ist der Live Quality Coach aktiviert, kann ein Mitarbeiter den aktuellen Antwortentwurf vor dem Versenden prüfen lassen. Die KI bewertet den Entwurf anhand der KI-bewertbaren Kriterien der passenden Scorecards.
Der Live Quality Coach liefert pro passender Scorecard:
- den erreichten Prozentwert
- den erforderlichen Mindestwert
- ob der Entwurf bestanden hat
- eine KI-Zusammenfassung
- Details pro Kategorie und Kriterium
Der Live Quality Coach ist aktuell für unterstützte Antwortkanäle wie E-Mail und Brief vorgesehen.
### Mindestwert für den Live Quality Coach
Für den Live Quality Coach kann ein **Threshold** konfiguriert werden. Dieser Wert liegt zwischen 0 und 100 Prozent und definiert den Mindestscore, den ein Antwortentwurf erreichen soll.
Der Standardwert ist 85 %.
Erreicht ein Entwurf den Mindestwert nicht, wird dies im Antwortbereich sichtbar gemacht. Die Antwort kann weiterhin versendet werden, aber die Oberfläche macht deutlich, dass der Mitarbeiter den Qualitätscheck bewusst übergeht.
### KI-gestützte Vorbewertung
Kriterien mit aktivierter KI-Bewertung werden automatisch durch die KI bewertet. Die KI orientiert sich dabei am konfigurierten Bewertungsprompt.
Das Ergebnis kann vom Supervisor überprüft und angepasst werden.
Kriterien ohne KI-Bewertung bleiben zunächst unbewertet und müssen manuell bewertet werden. Im Live Quality Coach werden nur KI-bewertbare Kriterien für die automatische Prüfung verwendet.
### K.O.-Kriterien
K.O.-Kriterien erlauben es, einzelne Anforderungen als absolut zu kennzeichnen.
- **Kategorie-Ebene:** Wird ein K.O.-Kriterium innerhalb einer Kategorie mit 0 bewertet, wird die gesamte Kategorie mit 0 Punkten gewertet.
- **Bewertungs-Ebene:** Wird ein K.O.-Kriterium für die Gesamtbewertung mit 0 bewertet, fällt die Gesamtbewertung auf 0.
### Versionierung
Scorecards sind versioniert. Jede Scorecard hat eine `baseId` und eine `revision`.
- `baseId` bleibt über alle Versionen einer Scorecard gleich.
- `revision` erhöht sich mit jeder neuen Version.
- Wird eine aktive Scorecard bearbeitet, wird die bisherige Version auf `retired` gesetzt und eine neue Revision angelegt.
Bestehende Assessments bleiben mit der Scorecard-Version verknüpft, die zum Zeitpunkt der Erstellung aktiv war. Änderungen wirken sich nur auf neu erstellte Assessments aus.
### Zustände einer Scorecard
- **Entwurf** – in Bearbeitung, noch nicht aktiv
- **Aktiv** – aktiv und für neue Bewertungen verwendbar
- **Archiviert** – durch eine neue Revision abgelöst
- **Gelöscht** – soft-gelöscht und nicht mehr sichtbar
### Bewertungsworkflow
Bewertungen können folgende Zustände durchlaufen:
1. **Nicht verarbeitet** – Bewertung wurde angelegt, KI-Verarbeitung steht aus
2. **KI-Verarbeitung läuft** – KI bewertet gerade die Kriterien
3. **KI-Bewertung bereit** – KI-Vorbewertung abgeschlossen, bereit zur Überprüfung
4. **Überprüfung läuft** – Supervisor hat mit der Überprüfung begonnen
5. **Von Supervisor geprüft** – Überprüfung abgeschlossen
6. **Mit Mitarbeiter besprochen** – Bewertung wurde mit dem bewerteten Mitarbeiter besprochen
7. **Fehler** – bei der Verarbeitung ist ein Fehler aufgetreten
8. **Gelöscht** – Bewertung wurde gelöscht
Nimmt ein Supervisor Änderungen an einem abgeschlossenen Assessment vor, wechselt der Status automatisch zurück auf `reviewOngoing`.
### Qualitätsbewertungsvorschau
Mit der Qualitätsbewertungsvorschau kann eine Scorecard getestet werden, bevor sie produktiv verwendet oder nach Änderungen aktiv angewendet wird.
Typischerweise werden dafür benötigt:
- **Ticket-ID** – liefert Kontext wie Kundenanfrage, Verlauf und relevante Ticketdaten
- **Antworttext** – der Entwurf oder Beispieltext, der geprüft werden soll
Die Vorschau erstellt keine reguläre Bewertung im Qualitätsworkflow. Sie dient dazu, Kriterien, Prompts, Gewichtungen, K.O.-Regeln und Live-Coach-Verhalten zu validieren.
### Export
Beim Bearbeiten einer Scorecard kann die aktuelle Scorecard-Konfiguration als JSON exportiert und kopiert werden. Das ist hilfreich für Reviews, technische Analyse oder den Abgleich zwischen Umgebungen.
### Best Practices
- **Kriterien eindeutig formulieren:** KI-bewertbare Kriterien sollten konkret und prüfbar sein.
- **Prompts präzise halten:** Beschreiben, woran die KI erkennen soll, ob ein Kriterium erfüllt ist.
- **K.O.-Kriterien sparsam einsetzen:** Sie haben starke Auswirkungen auf Kategorie- und Gesamtergebnis.
- **Threshold bewusst wählen:** Ein zu hoher Mindestwert kann viele Entwürfe blockieren, ein zu niedriger Wert schwächt den Live Quality Coach.
- **Proaktive und reaktive Fälle trennen:** Für Antworten nach Kundennachrichten und proaktive Kommunikation können unterschiedliche Scorecards sinnvoll sein.
- **Zuweisungsregeln gezielt konfigurieren:** Breite Zuweisungen erhöhen das Assessment-Volumen.
- **Versionierung berücksichtigen:** Für Auswertungen ist relevant, welche Revision einer Bewertung zugrunde liegt.
---
## Umfragen
**URL:** https://richard-dev-playground.enneo.ai/docs/de/quality/surveys
**Description:** Arten und Funktionsweise
### Umfragen für Kunden
**Ziel der Umfrage**
- Systematisches Sammeln von Kundenfeedback
- Ermittlung von Zufriedenheit nach Ticketabschluss
- Grundlage für Team- und Qualitätsentwicklung
**Voraussetzung**
- Benutzerrecht "Verwalten von Kunden- und Benutzerzufriedenheitsumfragen" benötigt.
**Einrichtung der CSAT-Umfrage**
1. **Aufruf des Bereichs Umfragen**
`Benutzerverwaltung → Umfragen → Umfragen` für Kunden
2. **Skala und Darstellung wählen**
"Kundenzufriedenheits-Umfrage im Footer einblenden" mit den Optionen:
- Gut / Okay / Nicht Gut (3er Skala)
- Sterne (5er Skala)
- NPS (10er Skala)
- Deaktiviert (Voreinstellung)
Die gewählte Skala gilt global – sie wird für alle aktivierten E-Mail-Konten verwendet.
3. **HTML-Template**
Nach Auswahl der Skala wird der Template-Editor angezeigt, in den via html das Layout der Umfrage implementiert werden kann.
Beispiel für eine 3er-Skala:
```html
```
Mögliche Darstellungen:
4. **Aktivierung pro E-Mail-Konto**
Auch wenn die Skala global gesetzt wird, kann für jedes E-Mail-Postfach individuell entschieden werden, ob die CSAT-Funktion aktiv sein soll oder nicht:
- Menüpunkt E-Mail-Konten aufrufen
- Gewünschtes Konto bearbeiten
- Im Bereich "Kundenzufriedenheits-Umfrage (CSAT)" Schalter aktivieren
5. **Test und Kontrolle**
Um die Konfiguration zu prüfen, kann einfach eine ausgehende E-Mail erstellt und an die eigene E-Mail-Adresse gesendet werden.
So lässt sich direkt erkennen, ob die Umfrage im Footer den Vorstellungen entspricht, oder gegebenenfalls noch etwas angepasst werden sollte.
6. **Datenabruf**
Die Ergebnisse der Umfrage können im Bereich `Erweiterte Einstellungen → Exporte und Reportingeinstellungen → "Kundenzufriedenheits-Umfragen"` als .xlsx-Datei heruntergeladen werden.
Relevante Datensätze: `Audience = customer`
### Umfragen für Benutzer
**Ziel der Umfrage**
- Bewertung der vom **KI-Agenten vorgeschlagenen Lösung**
- Verbesserung der KI-Logik basierend auf Rückmeldungen aus der Praxis
- Aufdecken von Potenzial zur Erweiterung bestehender KI-Agenten oder zur Entwicklung neuer Use Cases
**Voraussetzung**
- Benutzerrecht "Verwalten von Kunden- und Benutzerzufriedenheitsumfragen" benötigt.
**Einrichtung der Benutzerumfrage**
1. **Aufruf des Bereichs Umfragen**
`Benutzerverwaltung → Umfragen → Umfragen für Benutzer`
2. **Aktivierung**
- Im Dropdown "Umfrage nach Ticketabschluss" die Option
"Wie zufrieden warst du mit der KI? 1–5 Sterne." auswählen
- Standardmäßig ist "Keine Umfrage" gesetzt
3. **Funktionsweise**
- Die Umfrage erscheint nach Abschluss einer Ticketbearbeitung
- Sichtbar nur für Benutzer mit Rollen zur Ticketbearbeitung
- Die Umfrage enthält ein Popup "Wie zufrieden bist du mit der KI-Lösung?"
- Die Skala der Bewertung umfasst 1 bis 5 Sterne
4. **Datenabruf**
Die Ergebnisse der Umfrage können im Bereich `Erweiterte Einstellungen → Exporte und Reportingeinstellungen → "Kundenzufriedenheits-Umfragen"` als .xlsx-Datei heruntergeladen werden.
Relevante Datensätze: `Audience = user`
---
## Smart-Routing
**URL:** https://richard-dev-playground.enneo.ai/docs/de/routing-and-tags/autopilot
**Description:** Voraussetzung und Funktionsweise
### Voraussetzung
Damit das Smart-Routing aktiviert werden kann, müssen für den Benutzer Skills und/oder Kanäle (E-Mail, Brief, etc.) hinterlegt sein, z.B. Zählerstand und Bankdaten.
### Funktionsweise
Das Smart-Routing weist dem Bearbeiter automatisiert die Tickets zu, die seinen Skills entsprechen. Je nach Routing-Option wird dabei vorrangig nach Fälligkeit und/oder Priorität zugewiesen.
### Wissenswertes
Ist die Routingoption [`Last-Agent-Routing`](/docs/de/routing-and-tags/routing-options) aktiviert, weist das System beim Schließen eines Tickets automatisch den letzten Bearbeiter zu. Antwortet der Kunde erneut, erhält derselbe Bearbeiter das Ticket.
Ist für diesen jedoch eine [längere Abwesenheit](/docs/de/user-management/configure-users#längere-abwesenheit) hinterlegt, ignoriert das Routing diese Regel und routet das Ticket an ein Teammitglied oder anderen Benutzer mit entsprechenden Skills.
---
## Zugriffsbeschränkung im Ticket-Backlog
**URL:** https://richard-dev-playground.enneo.ai/docs/de/routing-and-tags/backlog-access-restriction
**Description:** Anwendungsbeispiele und Konfiguration
### Beispiel
Ein Dienstleister übernimmt den Kundenservice für mehrere Stadtwerke, darunter **Stadtwerke Voltlingen** und **Stadtwerke Stromhain**. Der Dienstleister nutzt für beide Stadtwerke die gleiche **Enneo-Instanz**. Das Team **"Stadtwerke Voltlingen"** soll ausschließlich Tickets der Stadtwerke Voltlingen sehen.
1. In den **Teameinstellungen** wird **Angezeigte Tickets mittels Tags einschränken** aktiviert.
2. Bei **Notwendige Tags für Ticketanzeige** wird der Tag `Mandant: Stadtwerke Voltlingen` ausgewählt.
**Ergebnis:** Nur Tickets mit dem Tag `Mandant: Stadtwerke Voltlingen` werden im **Backlog** angezeigt und vom **Autopilot** berücksichtigt. Die Tickets der Stadtwerke Stromhain bleiben diesem Team komplett verborgen.
### Wirkung der Einschränkung
Die Zugriffsbeschränkung wirkt ausschließlich auf die **Ticketübersicht** bzw. den **Backlog** und das **Smart-Routing**. **Benutzer**, die ihre Einstellungen vom Team **erben**, übernehmen automatisch die dort gesetzten **Einschränkungen**.
**Nicht** beschränkt werden:
* Suchfunktion in Ticket und Ticketübersicht
* Ticket-Historie im Ticket
* direkte URL-Aufrufe von Tickets
### Konfiguration im System
1. Einschränkung für ein Team oder einen Benutzer aktivieren
- Bereich `Teams oder Benutzerverwaltung`
- Einstellung aktivieren: "Angezeigte Tickets mittels Tag einschränken"
2. Tags festlegen
- Feld: "Notwendige Tags für Ticketanzeige" und/oder "Ausgeschlossene Tags für Ticketanzeige"
- Auswahl gewünschter Tags treffen
### Best Practices
- Die Verwendung von Tag-Strukturen sollte klar und einheitlich sein, z. B. `Mandant_X` oder `Projekt_Y`. Das erleichtert Pflege, Auswertung und Fehleranalyse. In den [Allgemeinen Tags](/docs/de/routing-and-tags/configure-tags#arten-von-tags) stehen eine Vielzahl an Kategorien zur Verfügung.
- Zugriffsbeschränkungen sollten dazu genutzt werden, Zuständigkeiten klar abzubilden und sensible Daten zu schützen. Es ist kein Ersatz für Rollen- oder Rechtekonzepte.
---
## Tag-Konfiguration
**URL:** https://richard-dev-playground.enneo.ai/docs/de/routing-and-tags/configure-tags
**Description:** Arten, Erkennungsmethoden und weitere Optionen
Tags ermöglichen eine präzise Organisation und automatisierte Zuweisung von Tickets. Sie können verschiedene Attribute tragen und flexibel zur Steuerung des Routings eingesetzt werden.
Sie werden im Bereich `Einstellungen → Skills & Routing` erstellt. Hier können sie hierarchisch organisiert werden, um eine strukturierte Klassifizierung zu gewährleisten.
### Arten von Tags
Tags sind die Basis für die Ticketkategorisierung. Sie ermöglichen es, Tickets nach verschiedenen Kriterien zu klassifizieren. Unterschieden wird zwischen folgenden Tags:
**Skill Tags**
Diese Tags repräsentieren spezifische Fähigkeiten oder Fachgebiete wie Abrechnung oder Wechsel. Sind sie bei einem Mitarbeiter hinterlegt, werden Tickets mit diesen Skill-Tags automatisch an die passenden Agenten oder Teams geroutet.
**Allgemeine Tags**
Neben den Skill-Tags, die sich auf die Fähigkeiten von Mitarbeitenden beziehen, stehen weitere Tag-Kategorien zur Verfügung. Mit diesen Tags lassen sich Tickets flexibel strukturieren, kennzeichnen und für die automatische Verteilung nutzen:
### Automatische Tag-Zuweisung
Wir bieten verschiedene Erkennungs-Methoden, um eingehenden Tickets bestimmte Tags zuzuweisen. Die Konfiguration dieser Zuweisungsregeln erfolgt pro Tag. Folgende Methoden stehen zur Verfügung:
### Weitere Konfigurationsoptionen
Zusätzliche Einstellungen ermöglichen eine noch präzisere Steuerung:
---
## Überblick
**URL:** https://richard-dev-playground.enneo.ai/docs/de/routing-and-tags/routing-in-enneo
**Description:** Automatische Klassifizierung und Verteilung von Kundenanfragen
Das Smart-Routing in Enneo sorgt dafür, dass eingehende Tickets automatisch
klassifiziert und an die passenden Mitarbeiter oder Teams verteilt werden. KI,
Regeln, Skill-basierte Zuweisung und SLAs greifen dabei ineinander –
kanalübergreifend und konsistent.
## Einstieg in Videos - Routing in Enneo
## Tags – fachliche Struktur für jedes Ticket
Jede eingehende Anfrage erhält in Enneo automatisch einen oder mehrere Tags
zugewiesen. Tags geben einem Ticket eine fachliche Bedeutung und bilden die Grundlage
für alle weiteren Entscheidungen im System. Sie können folgende Merkmale repräsentieren:
* Fachgebiete und Zuständigkeiten
* Produkte
* Organisationseinheiten oder Marken
* Kunden- und Vertragsmerkmale
* interne Prozesse oder Workflows
Zusätzlich lassen sich Tags mit zentralen Attributen konfigurieren:
* **Sichtbarkeit:** legt fest, ob ein Tag sichtbar, eingeschränkt sichtbar oder
deaktiviert ist
* **Priorität:** beeinflusst die Routing-Reihenfolge
* **Komplexität:** steuert die Gewichtung bei Mehrfacherkennung
* **SLA:** definiert Bearbeitungsfristen
* **Routing-Relevanz:** Ein- oder Ausschluss aus dem Skill-Matching
Die Erkennung erfolgt automatisch – per KI, regelbasierter Bedingungen (Ticket-,
Kunden- oder Vertragseigenschaften), Kanal- oder Unterkanal-Zuordnung oder einer
Kombination daraus.
Tags werden im Bereich `Einstellungen → Skills & Routing` verwaltet.
## Routing – gezielte Verteilung auf Basis von Tags
Auf Basis der gesetzten Tags entscheidet Enneo automatisch, an welches Team oder
welchen Mitarbeiter eine Anfrage weitergeleitet wird. Die Zuweisung berücksichtigt
dabei mehrere Faktoren:
* **Skill-Matching:** Abgleich zwischen Ticket-Tags und den hinterlegten Skills der
Mitarbeiter
* **Backlog-Zugriff:** Steuerung, welche Tickets Mitarbeiter sehen oder bearbeiten
dürfen
* **Reihenfolge der Zuweisung:** Priorisierung nach konfigurierbarer Sequenz
(z. B. Priorität, SLA, erster oder letzter Kundennachricht)
Routing wird im Bereich `Einstellungen → Skills & Routing` konfiguriert.
## Das Zusammenspiel
Die Klassifikation durch Tags bildet die Grundlage für das Smart-Routing. Das Ergebnis
sind nachvollziehbare, skalierbare Prozesse: Entscheidungen entstehen nicht situativ,
sondern auf Basis klar definierter Logik – ohne manuelle Eingriffe.
Das Zusammenspiel beider Konzepte geht dabei über klassische Weiterleitungsregeln
hinaus: Anfragen landen durch präzises **Skill-Matching** immer beim richtigen
Ansprechpartner – ohne manuelle Vorsortierung. Pro Tag lassen sich **SLAs**
festlegen, und das **Smart Routing** berücksichtigt Abwesenheiten, Prioritäten und Deadlines. Die Arbeit wird dadurch fair und effizient. Und dank **KI-Erkennung** setzt das
System die richtigen Tags selbstständig – auch wenn der Kunde sein Anliegen nicht
explizit nennt.
Die folgenden Artikel erläutern die Konfiguration im Detail: von SLAs und Arbeitszeiten
über Routingoptionen bis hin zur Tag-Konfiguration und dem Smart-Routing.
---
## Routingoptionen
**URL:** https://richard-dev-playground.enneo.ai/docs/de/routing-and-tags/routing-options
**Description:** Arten und Anwendungsbereiche
Die folgenden Einstellungen definieren die grundlegende Steuerungslogik des **Smart-Routings** bei der **automatischen Ticketzuweisung**. Sie steuern, welche Tickets bevorzugt bearbeitet werden, welche **Sachbearbeiter** infrage kommen und ob bestehende **Bearbeiter-Zuständigkeiten** erhalten bleiben.
Gemeinsam bilden die Optionen den Rahmen für die Ticketverteilung im operativen Alltag – insbesondere im Zusammenspiel aus **Priorisierung**, **Skill-Matching** und **Bearbeitungskontinuität**.
Die Konfiguration ermöglicht eine gezielte Anpassung an organisatorische Anforderungen, beispielsweise hinsichtlich **SLA-Einhaltung**, **Teamspezialisierung** oder konsistenter Betreuung laufender Kundenanliegen.
### Verteilungsreihenfolge
Die Verteilungsreihenfolge legt fest, nach welchem Kriterium entschieden wird, welches Ticket als nächstes einem Sachbearbeiter angeboten wird. Jede Option besteht aus einem Primär- und einem optionalen Sekundärkriterium (Tiebreaker für den Fall, dass mehrere Tickets im Primärkriterium gleichwertig sind).
Die möglichen Sortieroptionen und ihre Wirkung:
- **Priorität** — Jeder Tag kann eine Prioritätsstufe tragen: `urgent`, `high`, `medium`, `low`. Diese wird beim Tagging auf das Ticket übertragen. Tickets mit höherer Stufe kommen zuerst. Haben mehrere Tickets dieselbe Stufe, entscheidet das Sekundärkriterium.
- **SLA-Fälligkeit** — Wenn ein Tag mit einer SLA-Frist konfiguriert ist, berechnet das System daraus einen Fälligkeitszeitpunkt auf Basis von Erstellungsdatum und Geschäftszeiten. Tickets ohne SLA-Konfiguration gelten systemseitig als "fällig am 31.12.2099" — sie werden in SLA-basierten Modi immer ans Ende der Warteschlange gesetzt, unabhängig vom Alter.
- **Letzte Kundennachricht** — Zeitpunkt der jüngsten eingehenden Kundennachricht. Gibt es keine (z.B. bei intern erstellten Tickets), wird stattdessen das Erstellungsdatum verwendet.
Die vier konfigurierbaren Modi im Detail:
**1. Nach SLA-Ablaufdatum**
Nur ein Kriterium: Fälligkeit aufsteigend. Das Ticket mit der nächsten SLA-Deadline wird zuerst verteilt.
Tickets ohne SLA landen am Ende der Warteschlange — unabhängig davon, wie alt sie sind.
**2. Höchste Priorität zuerst — bei Gleichstand nach SLA-Ablaufdatum**
Primär: Priorität (urgent > high > medium > low). Sekundär: Fälligkeit aufsteigend.
Innerhalb derselben Prioritätsstufe entscheidet, welches Ticket als erstes fällig wird.
Tickets mit niedriger Priorität aber kurzem SLA werden nie vor Tickets mit hoher Priorität verteilt — auch wenn sie bereits überfällig sind.
**3. Höchste Priorität zuerst — bei Gleichstand nach letzter Kundennachricht (LIFO)**
Primär: Priorität. Sekundär: Letzte Kundennachricht absteigend.
Bei gleicher Priorität kommt das Ticket zuerst, bei dem der Kunde zuletzt geschrieben hat. Ältere Tickets derselben Prioritätsstufe rutschen weiter nach hinten, je mehr neue eintreffen.
**4. Höchste Priorität zuerst — bei Gleichstand nach frühester Kundennachricht (FIFO)**
Primär: Priorität. Sekundär: Letzte Kundennachricht aufsteigend.
Bei gleicher Priorität wird das Ticket zuerst verteilt, bei dem die letzte Kundennachricht am längsten zurückliegt — klassisches Warteschlangenprinzip innerhalb einer Prioritätsstufe.
### Tag-Matching
Diese Einstellung bestimmt, wie streng die Skill-Übereinstimmung zwischen Sachbearbeiter und Ticket beim automatischen Routing geprüft wird.
**ALLE** — Ein Ticket wird einem Sachbearbeiter nur dann angeboten, wenn er alle Tags des Tickets als Skill besitzt. Dies stellt eine genaue Kompetenzabdeckung sicher, kann jedoch die Verteilungsquote erheblich senken, wenn Tickets mehrere spezialisierte Tags tragen.
**MINDESTENS EIN** — Es genügt, wenn der Sachbearbeiter mindestens einen der Tags des Tickets als Skill besitzt. Mehr Bearbeiter kommen in Frage, die Verteilung ist breiter, aber weniger zielgenau.
Die Wahl zwischen beiden Modi hängt von der Teamstruktur ab: Kleine, generalistisch aufgestellte Teams profitieren oft von MINDESTENS EIN TAG, spezialisierte Strukturen mit klar abgegrenzten Zuständigkeiten eher von ALLE TAGS.
### Last-Agent-Routing
Wenn aktiviert, wird bei einer erneuten Kundenantwort auf ein bereits bearbeitetes Ticket versucht, dasselbe Ticket wieder dem zuletzt zuständigen Sachbearbeiter zuzuweisen. Ziel ist Kontinuität in der Bearbeitung ohne manuellen Aufwand.
Im Fall einer Abwesenheit des Bearbeiters ist eine manuelle Neuzuweisung erforderlich, sofern keine Abwesenheitsvertretung im Benutzerprofil hinterlegt ist. Die Konfiguration der Abwesenheit erfolgt in `Benutzerverwaltung → Benutzer → Persönliches Benutzerprofil`
---
## SLAs und Arbeitszeiten
**URL:** https://richard-dev-playground.enneo.ai/docs/de/routing-and-tags/slas-and-working-hours
**Description:** Optionen und Einrichtung
### Arbeitszeiten definieren
Die hinterlegten Arbeitszeiten und Feiertage bilden die Grundlage für die Berechnung von SLA-Fristen. Sie werden im Bereich `Routing und Tags → Arbeitszeiten` definiert.
### Service-Level-Agreements (SLAs)
SLAs (Service-Level-Agreement) definieren die erwartete Bearbeitungszeit für eine Kundenanfrage. Sie sind zentral für das Routing, die Priorisierung und die Überwachung der Servicequalität, und werden im Tag definiert.
Beispiele:
* Kunden-E-Mails: 8 Stunden (innerhalb eines 8-Stunden-Arbeitstages)
* Marktkommunikationsprobleme (blockierend): 4 Stunden
* Andere Marktkommunikationsthemen: 32 Stunden (4 Arbeitstage)
* VIP-Kunden: 2 Stunden
* Briefe: 40 Stunden (5 Arbeitstage)
Die Definition solcher SLAs ermöglicht die effiziente Weiterleitung und Überwachung der Servicequalität. Durch die Priorisierung von Tickets nach ihren SLAs können Kundenanforderungen erfüllt und ein angenehmes Kundenerlebnis sichergestellt werden.
---
## Übersicht
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/overview
## Systemintegration
Systemintegration umfasst alle technischen Anbindungen, über die Enneo mit bestehenden Systemen kommuniziert, relevante Daten nutzt und systemübergreifende Vorgänge ausführen kann. Dadurch wird Enneo Teil der vorhandenen Systemlandschaft und kann Bearbeitung, Automatisierung und Informationsaustausch in bestehenden Strukturen unterstützen.
## [Kontaktkanäle](/docs/de/system-integration/integration-of-contact-channels/contact-channels-overview)
Kontaktkanäle stellen die Verbindung zwischen externen Kundenanfragen und Enneo her und übertragen eingehende Nachrichten in das Ticketsystem. Damit entsteht die Grundlage für Bearbeitung und Automatisierung.
## [Kundenerkennung](/docs/de/system-integration/customer-recognition/flow)
Kundenerkennung verknüpft eingehende Tickets mit Kunden- und Vertragsdaten und ermöglicht eine fachlich korrekte, kontextbezogene Bearbeitung. Durch die Anbindung von ERP- oder CRM-Systemen werden diese Daten verfügbar.
## [Events und Webhooks](/docs/de/system-integration/events/concept-of-events-in-enneo)
Events und Webhooks übertragen relevante Ereignisse aus Enneo an externe Systeme, sodass Vorgänge dort gespeichert, weiterverarbeitet oder zur Auslösung eigener Aktionen genutzt werden können.
## [Eigener Code](/docs/de/system-integration/user-defined-functions-tools/user-defined-functions-in-enneo)
Eigener Code ermöglicht kundenindividuelle Logiken und Abläufe, die über Standardkonfigurationen hinausgehen und projektspezifische Anforderungen abbilden.
---
## KI-Agenten
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ticket-processing/ai-functions
**Description:** Beispiele und Struktur
**Hier eine Auswahl:**
**Strukturierte Informationsdarstellung:**
Relevante Kundendaten werden in übersichtlichen Infofeldern dargestellt. Kontextbezogene Hinweise erleichtern die Entscheidungsfindung.
**Automatisierte Befüllung von Parametern:**
Eingabefelder werden durch die KI ausgefüllt und auf Plausibilität geprüft. Manuelle Anpassungen sind optional möglich.
**Automatische Berechnungen und Vorschläge:**
Mindest- oder Zielwerte werden dynamisch berechnet. Hinweise oder Warnungen erscheinen bei unpassenden Eingaben.
**Kontextbezogene Meldungen:**
Unplausible Eingaben oder kritische Abweichungen lösen direkte Hinweise oder Empfehlungen aus.
**Zusatzfunktionen:**
Automatische Erstellung von Dokumenten wie Abrechnungen oder Validierungsberichten bei Bedarf.
**Handlungsaufforderungen:**
Buttons wie „Kunden informieren“ oder „Bestätigen“ führen gezielt zur abschließenden Bearbeitung.
**Flexibles Änderungsmanagement:**
Änderungen können mit einem festen Datum hinterlegt werden. Die Auswirkungen auf Verbrauch oder Kosten sind sofort ersichtlich.
---
## KI-Antwortvorschlag
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ticket-processing/ai-response-suggestion
**Description:** Infos und Nutzung
---
## KI-Textassistent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ticket-processing/ai-text-assistant
**Description:** Möglichkeiten und Anwendungsbereiche
### **Anwendungsbereiche**
Der KI-Textassistent kann in allen Bereichen genutzt werden, in denen Texte erfasst oder bearbeitet werden:
- beim **Beantworten** oder **Weiterleiten** von Kundenanliegen
- beim **Verfassen von Privatnotizen** innerhalb eines Tickets
- bei der **Erstellung von ausgehenden E-Mails**
- beim **Anlegen von internen Aufgaben**
### **Menüpunkte im Überblick**
* macht aus kurzen Notizen vollständige, höfliche Sätze
* formuliert Abkürzungen aus, z. B. „VN“ → „Vertragsnehmer“
* passt Ton, Stil und Satzbau an Kundenkommunikation an
* Aussage bleibt erhalten, die Form wird professionell
* erweitert kurze Antworten zu vollständigen, ausformulierten Passagen
* macht den Text länger, verständlicher und verbindlicher, ohne neuen Inhalt zu erfinden
* ideal, wenn der ursprüngliche Text zu knapp oder unausgewogen wirkt
* prüft auf Rechtschreibung und Grammatik
* übersetzt ins Englische und Französische
* ermöglicht feinjustierte Anpassungen, wenn Standardantworten nicht genau zur Situation passen
* adressiert abweichende Kontexte, wie etwa juristische Schreiben, Antworten an Dritte oder Behörden
* reagiert flexibel auf Anforderungen wie formelle Sprache, deeskalierender Ton oder klare Abgrenzung
* spart Zeit: der vorhandene Text wird gezielt verändert, nicht neu erstellt
* unterstützt eine passgenaue Kommunikation, auch in Ausnahmesituationen oder Eskalationen
---
## Kundenidentifikation
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ticket-processing/customer-identification
**Description:** Stufen und Überprüfung
Kunden werden anhand von Vertrags- und/oder Kundenummer und E-Mailadresse identifiziert. Je nach Anforderung können auch weitere Merkmale, z.B. die Zählernummer eingebunden werden.
Kann keine Relation zwischen Ticket und Kunden hergestellt werden, wird ein “**Unbekannter Benutzer**” sowie ein **Suchfeld** angezeigt.
---
## Wiedervorlagen
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ticket-processing/reminders
**Description:** Tickets gezielt pausieren und automatisch zur Weiterbearbeitung zurückführen.
Nicht jedes Ticket kann sofort abgeschlossen werden. Manchmal fehlen Informationen vom Kunden, ein externer Vorgang muss abgeschlossen werden, oder eine Bearbeitung soll bewusst zu einem späteren Zeitpunkt erfolgen. Wiedervorlagen bilden genau diesen Sachverhalt systemisch ab: Ein Ticket wird temporär pausiert und zu einem festgelegten Zeitpunkt automatisch wieder zur Bearbeitung bereitgestellt.
### Status und Fälligkeit
Wiedervorlagen basieren auf dem Zusammenspiel zweier Ticketattribute:
- **Status „wartend"** – Das Ticket ist aktiv, aber nicht zur sofortigen Bearbeitung vorgesehen. Es wird vom Smart Routing nicht verteilt.
- **Fälligkeit (`dueBy`)** – Der Zeitpunkt, zu dem das Ticket automatisch auf „offen" zurückgesetzt wird. Die Angabe einer Fälligkeit ist beim Setzen des Status „wartend" verpflichtend und muss in der Zukunft liegen.
Beide Felder greifen direkt ineinander: Ohne Fälligkeitsdatum kann kein Ticket auf „wartend" gesetzt werden. Das verhindert Tickets, die dauerhaft aus dem Bearbeitungsfluss herausfallen.
### Systemverhalten
Sobald ein Ticket auf „wartend" gesetzt wird, passiert Folgendes im System:
- Das Ticket wird aus der aktiven Verteilung des Smart Routings herausgenommen – es erhält keine Zuweisung, solange der Status „wartend" ist.
- Ein Reminder wird intern angelegt, der auf das Fälligkeitsdatum referenziert.
- Zum Fälligkeitszeitpunkt setzt ein automatischer Prozess den Status auf „offen" und gibt das Ticket wieder für die Bearbeitung und das Smart Routing frei.
- Das System erzeugt ein `ticketUpdated`-Event mit dem Flag `autoOpenedDueToDueDate: true`, das für externe Integrationen ausgewertet werden kann.
Wird ein Ticket manuell auf „wartend" gesetzt, markiert das System die Fälligkeit als manuell gesetzt (`dueByWasSetManually`). Automatisch berechnete Fälligkeiten – etwa durch Tag-Konfigurationen – bleiben davon getrennt nachvollziehbar.
### Einsatzszenarien
**Warten auf Kundenrückmeldung**
Eine Information wurde beim Kunden angefragt. Bis zur Antwort soll das Ticket nicht im aktiven Bestand erscheinen. Mit einer Fälligkeit – z. B. in fünf Werktagen – kehrt es automatisch zurück, falls keine Rückmeldung erfolgt.
**Abhängigkeit von einem externen Prozess**
Ein nachgelagerter Prozess (z. B. Systemverarbeitung, Rückfrage an ein Fachteam) muss abgeschlossen sein, bevor das Ticket weiterbearbeitet werden kann. Die Wiedervorlage stellt sicher, dass es zum richtigen Zeitpunkt wieder auftaucht.
**Gezielte Terminsteuerung**
Ein Ticket soll nicht sofort, sondern zu einem bestimmten Datum bearbeitet werden – etwa weil ein Tarif erst ab dem Folgemonat gilt oder ein Vertragszeitraum abgewartet werden soll.
### Auswirkungen auf Analytik und Zeiterfassung
Das Setzen des Status auf „wartend" wird im Bearbeitungsexport als Bearbeitungsart `statusAction` erfasst – auch dann, wenn keine Antwort an den Kunden gesendet wurde. Damit wird die Tätigkeit des Bearbeiters korrekt in der AHT abgebildet.
Tickets im Status „wartend" erscheinen in der Ticketübersicht und können über den Statusfilter gezielt eingesehen werden. So bleibt der Gesamtbestand transparent, auch wenn Tickets temporär nicht aktiv bearbeitet werden.
### API-Integration
Wiedervorlagen lassen sich über die Enneo-API setzen und steuern.
Voraussetzung: `dueBy` muss angegeben werden und in der Zukunft liegen. Das Zurücksetzen auf „offen" erfolgt entweder automatisch durch den zeitgesteuerten Prozess oder manuell über denselben Endpoint mit "status": "open".
```json
PATCH /api/mind/ticket/{id}
{
"status": "pending",
"dueBy": "2025-06-01 08:00:00"
}
---
## Ticketübersicht
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ticket-processing/ticket-overview-filters
### Darstellung
Auf einen Blick: **Stimmung** des Kunden, **Inhalt** und **Betreff, Priorität, Zuweisung** und **Status**. Die Ansicht kann **individuell sortiert** werden.
Über den [**Filter**](/docs/de/ticket-processing/ticket-overview-filters#filter) lassen sich gezielt über viele Kriterien hinweg bestimmte Tickets abrufen. Die [Massenaktualisierung](/docs/de/ticket-processing/ticket-overview-filters#massenaktualisierung) ermöglicht gezielte Aktionen über mehrere Tickets hinweg.
### Filter
Neben den herkömmlichen Filterfunktionen bietet der Filter zusätzliche Möglichkeiten, die über die klassische Eingrenzung von Tickets hinausgehen.
### Massenaktualisierung
Die Massenaktualisierung ermöglicht es, Attribute mehrerer Tickets gezielt und konsistent zu verändern.
Im Tagesgeschäft kommt es vor, dass vermehrt Tickets zu einem bestimmten Thema eingehen und kurzfristig priorisiert bearbeitet werden sollen.
Damit sich die Priorität bei erneuten Rückmeldungen wieder am jeweiligen Thema orientiert, empfiehlt es sich, einen Tag wie "Temporär priorisiert" mit entsprechender Priorität zu verwenden.
Dieser Tag kann den betroffenen Tickets gezielt hinzugefügt, für die Dauer der Priorisierung genutzt und anschließend ebenso gezielt wieder entfernt werden.
---
## Ticket-Aufbau
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ticket-processing/ticket-structure-ai-components
**Grundlegende Ticketinformationen**
Unterhalb des Inhalts sind die wichtigsten Metadaten übersichtlich dargestellt, darunter Betreff, Absender, Empfänger und Sendedatum.
**Interaktion mit dem Kundenanliegen**
Im oberen Bereich stehen die klassischen Bearbeitungsfunktionen zur Verfügung, zum Beispiel:
- Antworten
- Weiterleiten
- interne Notizen direkt am Ticket erfassen
**Wiki**
Über den Wiki-Bereich kann direkt auf **Anleitungen und Hintergrundinformationen** zugegriffen werden. Die Navigation erfolgt entweder über die Struktur oder über das Suchfeld.
Bei konkreten Fragestellungen fasst **Neo** die relevanten Inhalte aus passenden Artikeln automatisch zusammen. Das spart Zeit und liefert eine schnelle, übersichtliche Antwort, ohne einzelne Artikel lesen zu müssen.
Auf diese Weise greifen Status und Fälligkeit ineinander und sorgen dafür, dass wartende Tickets kontrolliert in den Bearbeitungsprozess zurückkehren.
- **Agent**
Sind Tickets einem bestimmten Agenten zugewiesen, werden sie im Autopiloten ausschließlich diesem Agenten angeboten.
Eine Ausnahme bildet die [längere Abwesenheit](/docs/de/user-management/configure-users#längere-abwesenheit).
- **Weitere Angaben**
ID, Priorität sowie – optional – das Aktivitätsprotokoll
**Kundendaten**
Dieser Abschnitt zeigt die wichtigsten **Stammdaten** verknüpfter Kunden. Die angezeigten Informationen sind individuell erweiterbar, zum Beispiel:
- Vertrags- und Kundennummer
- Tarif, monatlicher Abschlag und Verbrauch
- ggf. Guthaben oder offene Beträge
- Lieferadresse, E-Mail und Lieferstatus
**Historie**
Die Historie listet alle weiteren Tickets des Kunden inklusive Status, Eingangsdatum und Thema.
Je nach Konfiguration werden zusätzlich relevante Systemereignisse angezeigt, etwa Tarifwechsel oder Preisänderungen.
Ist kein Kunde mit dem Ticket verknüpft, werden alle zur Absenderadresse vorhandenen Tickets aufgeführt.
---
## Ticket-Erstellung
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ticket-processing/ticket_creation
**Description:** Arten und Anwendungsbereiche
### Ausgehende Nachricht
Oft ist es sinnvoll und notwendig, Kunden aktiv anzuschreiben, etwa zur Klärung im Anmeldeprozess, zum Versenden eines neuen Tarifangebots oder um nach einem Telefonat etwas zu bestätigen. Solche Tickets erscheinen im Ticketsystem als ausgehende Nachricht.
- Ticketstatus ist standardmäßig "geschlossen"
- voreingestellte Fälligkeit ist "morgen"
- Versand kann über die Kanäle "Email" oder "Brief" erfolgen, der Kanal erfordert im Feld "An" eine E-Mailadresse oder Postanschrift
### Interner Vorgang
Teilt bspw. ein Kunde sein Anliegen persönlich vor Ort mit, kann es als interner Vorgang für das Ticketsystem dokumentiert werden und bleibt so für alle nachvollziehbar. Quelle des internen Vorgangs ist in diesem Beispiel "Kundenzentrum".
- Ticketstatus ist standardmäßig "offen"
- voreingestellte Fälligkeit ist "morgen"
---
## Überblick
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ticket-processing/tickets-in-enneo
Tickets sind der zentrale Ort, an dem Kundenanfragen in Enneo bearbeitet werden. Unabhängig davon, ob eine Anfrage per E-Mail, Telefon, Brief, Chat oder über einen anderen Kanal eingeht, wird sie als Ticket erfasst und dort weiterverarbeitet.
Ein Ticket bündelt alle Informationen, die für die Bearbeitung eines Vorgangs wichtig sind. Dazu gehören Nachrichten, Kunden- und Vertragsdaten, Zuständigkeiten, Bearbeitungsstatus, Dokumente sowie Informationen zu Routing, KI-Erkennung und Automatisierung.
## Einstieg in Videos - Tickets
## Vollständige Transparenz im Bearbeitungsprozess
Ein Ticket dokumentiert nicht nur die Kommunikation mit dem Kunden, sondern auch alle Schritte, Entscheidungen und Bewertungen, die während der Bearbeitung entstehen. Dadurch wird ein Vorgang fachlich nachvollziehbar und kann später geprüft, ausgewertet oder weiterbearbeitet werden.
Je nach Prozess und Konfiguration enthält ein Ticket unter anderem:
- Kunden- und Vertragsdaten
- Eingehende und ausgehende Nachrichten
- Anhänge und Dokumente
- Bearbeitungsstatus, Prioritäten und SLAs
- Tags, erkannte Anliegen und Prozesszuordnungen
- KI-Ergebnisse und Automatisierungen
- Qualitätsauswertungen und Bewertungsergebnisse
- Aktivitätsprotokoll mit Bearbeitungsschritten und Systemereignissen
- Historie zu Änderungen, Übergaben und Folgeaktionen
So entsteht eine vollständige Sicht auf den Vorgang: Mitarbeitende sehen nicht nur, *was* mit dem Kunden kommuniziert wurde, sondern auch, *wie* das Ticket bearbeitet, bewertet, weitergeleitet und/oder automatisiert verarbeitet wurde.
## Kanalübergreifende Kommunikation
Enneo führt Anfragen aus verschiedenen Kanälen in einer einheitlichen Ticketansicht zusammen. So können E-Mails, Telefonate, Briefe, Chats oder andere Eingangskanäle konsistent bearbeitet und nachvollzogen werden.
Das unterstützt die tägliche Bearbeitung auf mehreren Ebenen:
- Nachrichten bleiben vollständig am Ticket dokumentiert
- Bearbeitungsstände sind jederzeit transparent
- Zuständigkeiten und Übergaben bleiben nachvollziehbar
- Automatisierungen können unabhängig vom Eingangskanal greifen
Die kanalübergreifende Verarbeitung bildet damit die Grundlage für ein einheitliches Service- und Prozessmanagement.
## Automatisierung und KI-Unterstützung
Enneo kann Tickets automatisch analysieren, einordnen und für die weitere Bearbeitung vorbereiten. Dadurch werden wiederkehrende Aufgaben reduziert und Mitarbeitende bei der Bearbeitung unterstützt.
Bereits beim Eingang eines Tickets können verschiedene Informationen erkannt und verarbeitet werden:
- Anliegen erkennen und passenden Prozessen zuordnen
- Tickets mit Tags oder Prioritäten versehen
- Tickets an passende Teams oder Sachbearbeiter routen
- Standardprozesse automatisch auslösen
- Mitarbeitende bei der Antworterstellung unterstützen
Das reduziert den manuellen Aufwand, insbesondere bei hohen Ticketvolumen oder standardisierten Prozessen.
Die folgenden Artikel erklären die einzelnen Bereiche im Detail – vom Aufbau eines Tickets über Kommunikation und Status bis hin zu Routing, Automatisierung und KI-Unterstützung.
---
## Frag Neo
**URL:** https://richard-dev-playground.enneo.ai/docs/de/work-resources/ask-neo
**Description:** Funktionsweise und Anwendung
### Funktionsweise
Nutzer haben die Wahl zwischen zwei Suchmethoden:
1. **Klassische Suche** – Eine Liste relevanter Artikel wird angezeigt.
2. **Frag Neo** – Die KI verarbeitet die Suchanfrage und generiert eine Antwort basierend auf Wiki-Inhalten.
Um eine Suche zu starten, wird eine Frage in die Suchleiste eingegeben. Neo versteht vollständige Fragen in natürlicher Sprache, z. B.:
*„Wie erfasse ich einen Umzug?“*
Zunächst erscheint eine Liste mit passenden Artikeln. Nutzer können entweder direkt einen Artikel auswählen oder auf "Neo fragen" klicken, um eine KI-generierte Antwort zu erhalten.
"Frag Neo" durchsucht alle Artikel im Wiki, unabhängig davon, ob sie öffentlich oder nur intern zugänglich sind. Die wichtigsten Informationen werden zusammengefasst und als verständliche Antwort dargestellt. Falls ein Artikel detaillierte Anleitungen enthält, werden diese strukturiert wiedergegeben.
### Keine Suchergebnisse?
Falls Neo keine passende Antwort generieren kann, stehen folgende Alternativen zur Verfügung:
* Nutzer können zur klassischen Artikelsuche zurückkehren.
* Die Frage kann umformuliert oder präziser gestellt werden.
* Falls ein Thema nicht im Wiki dokumentiert ist, kann Neo keine Antwort generieren. Neue Inhalte im Wiki zu erstellen, sorgt dafür, dass die Information künftig verfügbar ist.
### Funktionsrahmen
* Neo greift nur auf das Wiki zu und durchsucht keine anderen Datenquellen.
* Falls ein Thema nicht dokumentiert ist, kann Neo keine Informationen liefern.
* Die KI kann keine eigenständigen Schlussfolgerungen ziehen, sondern basiert ausschließlich auf bestehenden Wiki-Inhalten.
---
## KI-Wiki
**URL:** https://richard-dev-playground.enneo.ai/docs/de/work-resources/create-and-edit-articles
**Description:** Artikel, Website-Connector und Dateien
### Was ist eine Wissensquelle?
Eine Wissensquelle ist ein einzelner verwertbarer Wissenseintrag im KI-Wiki.
Sie kann auf unterschiedliche Arten entstehen:
* als manuell erstellter Artikel
* als Inhalt aus einer extern angebundenen Quelle, zum Beispiel über einen Website-Connector
* als hochgeladene Datei über den Files-Connector
**Manuell erstellte Artikel** eignen sich für Inhalte, die bewusst formuliert und fachlich geprüft werden sollen. Dazu gehören Arbeitsanweisungen, häufige Fragen, Prozessbeschreibungen, interne Vorgaben oder verbindliche Formulierungen.
**Extern angebundene Quellen** eignen sich, wenn bereits vorhandene Inhalte regelmäßig genutzt werden sollen. Das können zum Beispiel Hilfecenter, Dokumentationsseiten oder öffentliche Informationsseiten sein.
**Dateien** eignen sich für bestehende Dokumente, die zentral bereitgestellt und für KI-gestützte Funktionen nutzbar gemacht werden sollen, zum Beispiel PDF-Dokumente, Arbeitsanweisungen oder fachliche Unterlagen.
### Warum Struktur wichtig ist
Wissen im KI-Wiki wird nicht nur abgelegt, sondern fachlich eingeordnet. Dafür werden **Gruppen und Klassifizierungen** verwendet.
**Gruppen** bilden die thematische Struktur. Sie helfen dabei, Inhalte auffindbar zu machen und fachlich zusammengehörende Informationen zu bündeln.
**Klassifizierungen** beschreiben die Art des Inhalts. Diese Unterscheidung ist wichtig, weil verschiedene Inhalte unterschiedlich genutzt werden:
* Eine **FAQ** beantwortet eine konkrete wiederkehrende Frage.
* Eine **Arbeitsanweisung** beschreibt einen operativen Ablauf.
* Ein **Dokument** enthält Hintergrundinformationen oder verbindliche Regelungen.
* **News** informieren über aktuelle Änderungen und erscheinen auf der Homepage.
Wenn diese Inhaltsarten sauber getrennt werden, bleibt der Wissensbestand leichter prüfbar. Gleichzeitig können KI-Funktionen die Inhalte besser einordnen.
### Website-Connector
Der Website-Connector verbindet eine externe Website mit dem KI-Wiki.
Pfad in Enneo: Arbeitshilfen → KI-Wiki → Quellen
Beim Crawling liest Enneo die angebundene Website aus und übernimmt passende Inhalte als Wissenseinträge. Diese erscheinen anschließend in der Wissensstruktur.
Ein Connector wird über mehrere Einstellungen gesteuert:
* Quell-URL
* Include-Pfade
* Exclude-Pfade
* maximale Seitenanzahl
* Frequenz für erneutes Crawling
Die Quell-URL definiert, welche Website angebunden wird.
Include-Pfade legen fest, welche Bereiche der Website berücksichtigt werden sollen. Exclude-Pfade schließen Bereiche aus, die nicht relevant sind. Dazu gehören zum Beispiel Login-Seiten, Datenschutzseiten, Impressum, Blogbereiche oder technische Übersichtsseiten.
Beispiele:
* /hilfe/* berücksichtigt Inhalte im Hilfebereich.
* /faq/* berücksichtigt FAQ-Seiten.
* /login/*, /datenschutz oder /impressum können ausgeschlossen werden.
Die maximale Seitenanzahl begrenzt den Umfang der übernommenen Inhalte. Die Crawling-Frequenz bestimmt, wie regelmäßig Enneo die Quelle erneut ausliest.
Der Connector stellt Inhalte technisch bereit. Er bewertet aber nicht, ob diese Inhalte fachlich geeignet sind. Diese Prüfung bleibt Teil der redaktionellen Verantwortung.
### Crawling und Aktualität
Beim Crawling werden Inhalte aus der externen Quelle ausgelesen und in Enneo verfügbar gemacht. Der Connector zeigt dabei einen Status, zum Beispiel laufend, abgeschlossen oder fehlerhaft.
Ein erneutes Crawling aktualisiert die übernommenen Inhalte anhand der aktuellen Connector-Konfiguration. Dadurch können Änderungen auf der externen Website in Enneo übernommen werden.
Wenn Include- oder Exclude-Pfade, die Quell-URL oder andere Connector-Einstellungen geändert werden, sollte die Quelle erneut gecrawlt beziehungsweise verarbeitet werden, damit die Änderungen wirksam werden.
Gleichzeitig hängt die Qualität des Ergebnisses von der externen Quelle ab. Wenn sich URL-Strukturen, Navigation oder Inhalte der Website ändern, kann sich auch die Wissensstruktur in Enneo verändern.
Für stabile Ergebnisse sollten Connectoren möglichst präzise konfiguriert werden. Eine eng begrenzte Quelle ist leichter zu prüfen und liefert meist bessere Ergebnisse als eine sehr breit angebundene Website.
### Dateien als Wissensquelle
Neben manuell gepflegten Artikeln und angebundenen Websites können auch Dateien als Wissensquellen im KI-Wiki verwendet werden.
Pfad in Enneo: Arbeitshilfen → KI-Wiki → Quellen
Der Files-Connector dient dazu, fachlich relevante Dokumente zentral bereitzustellen und für KI-gestützte Funktionen nutzbar zu machen. Hochgeladene Dateien werden verarbeitet, in Wissenseinträge überführt und können anschließend bei Antwortvorschlägen, Chat-Kontexten oder KI-Agenten berücksichtigt werden, sofern sie dafür freigegeben sind.
Dateien lassen sich per Drag-and-drop hochladen, in Ordnern strukturieren, verwalten und bei Bedarf in der Vorschau prüfen. Eine klare Ordnerstruktur hilft dabei, größere Wissensbestände nachvollziehbar zu pflegen und später gezielt zu überprüfen.
Dateien sollten nicht als ungeprüfte Ablage genutzt werden. Entscheidend ist, dass Inhalt, Dateiname und Ablageort fachlich eindeutig sind.
Wenn sich der Inhalt einer Datei ändert, muss die Wissensquelle erneut verarbeitet werden, damit die aktualisierten Inhalte im System wirksam werden. Das erneute Indexieren stellt sicher, dass nicht nur die Datei selbst, sondern auch die daraus abgeleiteten Such- und KI-Kontexte auf dem aktuellen Stand sind.
Wie bei Website-Connectoren gilt auch hier: Der Connector stellt Inhalte technisch bereit. Die fachliche Verantwortung für Richtigkeit, Aktualität, Freigabe und Struktur bleibt bei den zuständigen Nutzern.
### Dateien verwalten, bearbeiten und erneut verarbeiten
Im Files-Connector können Dateien und Ordner verwaltet werden. Je nach Berechtigung können Nutzer Dateien hochladen, verschieben, in der Vorschau prüfen, ersetzen, bearbeiten oder archivieren.
Für Dateien stehen unter anderem folgende Aktionen zur Verfügung:
* Datei hochladen
* Datei in der Vorschau öffnen
* Datei ersetzen
* Datei bearbeiten, wenn das Format dies unterstützt
* Datei erneut indexieren
* Datei auf den Originalzustand zurücksetzen
* Datei archivieren oder wiederherstellen
Wenn eine Datei direkt in Enneo bearbeitet wurde, kann dies durch eine entsprechende Markierung sichtbar sein. Diese Markierung hilft dabei zu erkennen, dass der aktuell verwendete Inhalt nicht mehr exakt dem ursprünglich hochgeladenen Dokument entsprechen muss.
#### Aktualisieren
Mit **Aktualisieren** wird eine Datei erneut verarbeitet. Diese Aktion ist sinnvoll, wenn Inhalte für die Wissenssuche oder KI-gestützte Funktionen aktualisiert werden sollen.
Dabei wird die Datei erneut für Such- und KI-Kontexte aufbereitet. Das ist zum Beispiel relevant, wenn eine Datei ersetzt wurde oder wenn die Verarbeitung gezielt neu angestoßen werden soll.
#### Auf Original zurücksetzen
Mit **Auf Original zurücksetzen** wird eine manuell bearbeitete Datei wieder auf den ursprünglichen hochgeladenen Stand zurückgesetzt.
Diese Aktion ist sinnvoll, wenn manuelle Änderungen verworfen werden sollen oder wenn wieder der Originalinhalt der Datei als Grundlage verwendet werden soll.
### Dateien und Medien in Artikeln
Artikel können durch hochgeladene Medien ergänzt werden. Dazu gehören zum Beispiel Bilder oder Videos.
Medien sind sinnvoll, wenn sie eine fachliche Aussage besser verständlich machen. Das gilt etwa für Formularbeispiele, Prozessdarstellungen oder Screenshots bestimmter Zustände.
Wichtig ist: Medien sollten den Text ergänzen, nicht ersetzen.
Für KI-gestützte Funktionen bleibt der schriftliche Inhalt besonders relevant. Text kann eindeutig gesucht, verarbeitet und in Antwortkontexte übernommen werden. Kritische Informationen sollten daher immer auch im Artikeltext stehen und nicht ausschließlich in einem Screenshot oder Video enthalten sein.
### Sichtbarkeit für KI-Funktionen
Die Einstellung Wissensquelle öffentlich zugänglich machen steuert, ob eine Wissensquelle für KI-gestützte Funktionen verwendet werden darf.
Wenn eine Wissensquelle freigegeben ist, kann sie zum Beispiel in Antwortvorschlägen, Chat-Kontexten oder KI-Agenten berücksichtigt werden.
Wenn sie nicht freigegeben ist, bleibt sie primär Teil der internen Dokumentation im KI-Wiki.
Diese Einstellung ist fachlich relevant. Eine freigegebene Wissensquelle kann die Ergebnisse von KI-Funktionen beeinflussen. Deshalb sollten nur Inhalte freigegeben werden, die geprüft, aktuell und eindeutig formuliert sind.
Nicht freigegeben werden sollten Inhalte, die vertraulich, veraltet, unvollständig oder fachlich nicht eindeutig sind.
### Nutzung im Ticket-Kontext
Wissensquellen können im Ticket-Kontext genutzt werden, wenn sie für KI-Funktionen freigegeben und fachlich relevant sind.
Enneo kann passende Inhalte aus dem KI-Wiki heranziehen, um Antwortvorschläge, Chat-Antworten oder KI-Agenten zu unterstützen. Außerdem können relevante Wissensinhalte im Arbeitskontext eines Tickets sichtbar werden, damit Nutzer schneller passende Informationen finden.
Ob eine Wissensquelle tatsächlich berücksichtigt wird, hängt unter anderem von Inhalt, Freigabe, Aktualität und fachlicher Relevanz ab.
### Wirkung auf KI-Agenten
KI-Agenten können Wissensquellen als Kontext verwenden, wenn diese zugänglich und fachlich relevant sind.
Die Qualität der Agentenergebnisse hängt stark von der Qualität des Wissensbestands ab. Unklare Formulierungen, widersprüchliche Artikel oder ungeprüfte Connector-Inhalte können zu ungenauen Ergebnissen führen.
Das KI-Wiki ist deshalb mehr als eine Ablage für Informationen. Es steuert, welches Wissen der KI zur Verfügung steht und wie dieses Wissen fachlich eingeordnet ist.
Ein gut gepflegtes KI-Wiki verbessert die Nachvollziehbarkeit und Stabilität KI-gestützter Bearbeitung. Ein unscharfer Wissensbestand kann dagegen zu uneinheitlichen Antworten und Fehlinterpretationen führen.
### Pflege und Verantwortung
Ein guter Wissensbestand ist nicht möglichst groß, sondern verlässlich.
Bei manuellen Artikeln sollten insbesondere folgende Punkte geprüft werden:
* Ist der Inhalt fachlich korrekt?
* Ist der Artikel eindeutig formuliert?
* Passt die Klassifizierung?
* Ist die Gruppe sinnvoll gewählt?
* Darf der Inhalt für KI-Funktionen verwendet werden?
Bei Connectoren kommen weitere Fragen hinzu:
* Ist die externe Quelle fachlich belastbar?
* Sind Include- und Exclude-Pfade sinnvoll gesetzt?
* Ist die maximale Seitenanzahl passend gewählt?
* Ist die Crawling-Frequenz angemessen?
* Muss nach einer Änderung erneut gecrawlt oder indexiert werden?
Bei Dateien sollten zusätzlich folgende Punkte geprüft werden:
* Ist der Dateiname eindeutig?
* Ist die Datei im passenden Ordner abgelegt?
* Ist der Inhalt aktuell und fachlich geprüft?
* Wurde die Datei nach Änderungen erneut verarbeitet?
* Ist klar, ob die Datei im Originalzustand oder in einer manuell bearbeiteten Version verwendet wird?
Änderungen am KI-Wiki wirken nicht nur auf die Dokumentation. Sie können auch die Qualität von Antwortvorschlägen, Chat-Kontexten und KI-Agenten beeinflussen.
Deshalb sollten Artikel, Connectoren, Dateien und Sichtbarkeitseinstellungen als fachliche Systembestandteile gepflegt werden.
---
## Partner
**URL:** https://richard-dev-playground.enneo.ai/docs/de/work-resources/partners
**Description:** Anwendungsbereiche, Erstellung und Zugriff im Ticket
### Anwendungsbereiche
Die Partnerverwaltung ist ideal für die Kommunikation mit Geschäftspartnern, die regelmäßig kontaktiert werden, aber keine direkten Kunden sind. Dazu zählen beispielsweise Marktpartner oder Vertriebspartner. Durch den schnellen Zugriff auf alle relevanten Informationen und Emailadresse direkt aus einem Ticket werden Arbeitsabläufe deutlich effizienter.
### Erstellung
Im Menüpunkt **"**Partner**"** lassen sich neue Partner erstellen oder bereits vorhandene bearbeiten – ähnlich wie in einem Adressbuch. Mit Klick auf "Neuer Partner" öffnet sich die Eingabemaske, in der alle relevanten Informationen hinterlegt werden können.
Optional kann zum Partner eine URL hinterlegt werden, damit externe Systeme verknüpft werden können.
### Zugriff im Ticket
---
## Templates
**URL:** https://richard-dev-playground.enneo.ai/docs/de/work-resources/templates
**Description:** Erstellung, Konfiguration und Verwendung des Vorlagenkatalogs
### Erstellung und Konfiguration
Im Bereich `Textbausteine` lassen sich Vorlagen erstellen, bearbeiten und entfernen. Die bereits bestehende Struktur ergibt sich aus der Struktur der Skill-Tags.
* **Name:** die Bezeichnung des Templates sollte intuitiv und inhaltsbezogen sein, damit sich die Suche im Katalog leicht gestaltet
* **Thema**: das Template wird eine Ober- oder Unterkategorie der Struktur zugeordnet
Diese sog. Handlebars ermöglichen eine flexible und vielfältige Gestaltung der Templates. So wird aus dem Beispiel eines festen Textbausteins diese dynamische Variante:
[Hier](https://handlebarsjs.com/guide/) gibt es ausführliche Informationen zu Syntax und Verwendung von Handelbars.
| Helper | Signatur | Beschreibung |
| ------------------ | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| `contains` | `contains array "wert"` | Liefert `true`, wenn das Array den angegebenen String-Wert enthält. Argumentreihenfolge ist vertauschbar (`contains "wert" array`).|
| `compare` | `compare a b` | Liefert `true`, wenn beide Werte gleich sind (lose Vergleich). |
| `gt` | `gt a b` | Liefert `true`, wenn `a` gesetzt ist und `a > b`. |
| `lt` | `lt a b` | Liefert `true`, wenn `a` gesetzt ist und `a < b`. |
| `and` | `and a b c …` | Liefert das letzte Argument, wenn alle truthy sind, sonst das erste falsy Argument. |
| `or` | `or a b c …` | Liefert das erste truthy Argument, sonst das letzte. |
| `not` | `not a` | Liefert die logische Negation von `a`. |
| `formatDateDE` | `formatDateDE date` | Formatiert ein Datum im langen deutschen Format (z. B. `1. Januar 2025`). Akzeptiert `"today"`. Liefert `[unbekannt]` wenn leer. |
| `formatDateEN` | `formatDateEN date` | Formatiert ein Datum als `YYYY/MM/DD`. Akzeptiert `"today"`. Liefert `[unknown]` wenn leer. |
| `addDays` | `addDays date days` | Addiert die angegebene Anzahl Tage zum Datum und gibt es im langen deutschen Format zurück. Akzeptiert `"today"` als Datum. |
| `extractFirstName` | `extractFirstName "Max Mustermann"` | Liefert das erste Wort eines Strings. |
| `extractLastName` | `extractLastName "Max Mustermann"` | Liefert das letzte Wort eines Strings in Kleinbuchstaben. |
| `last4digits` | `last4digits "DE12 3456 7890 1234 5678"` | Entfernt Leerzeichen und liefert die letzten 4 Zeichen eines Strings (z. B. für maskierte Kontonummern). |
| `undefined` | (intern) | Rendert `{{varname}}` wörtlich, wenn eine Variable nicht gesetzt ist — als Fallback für nicht aufgelöste Platzhalter. |
Eigene Helper lassen sich mit Standard-Handlebars-Block-Helpern kombinieren, z. B.:
```handlebars
{{#if (and (contains in.tagIds "22") (gt in.amount "100"))}}
Spezielle Behandlung für hochwertige Tickets mit Tag 22.
{{/if}}
```
---
## Best Practices
**URL:** https://richard-dev-playground.enneo.ai/docs/de/user-management/best-practices
**Description:** Empfehlungen für den Aufbau von Benutzern, Teams und Rollen
Die optimale Zuordnung von Mitarbeitern zu Teams und somit zu Skills (für Skill-Based-Routing) und Rollen (für Berechtigungen) ist individuell. Basierend auf unseren Erfahrungen möchten wir im Folgenden Empfehlungen geben, wie man eine solche Struktur aufbauen kann. Die Empfehlungen richten sich primär an Energieversorgungs-Lieferanten.
## Kleine Organisationen (bis 15 Mitarbeiter)
In kleinen Organisationen kann man mit einer direkten Verteilung von Rollen und Skills an Mitarbeiter mit nur wenig Komplexität eine effektive Arbeitsweise erreichen.
Neue Agenten werden dem Team "Agent" zugewiesen, alle anderen erhalten (aufgrund der niedrigen Anzahl) eine individuell zugeordnete Rolle.
### Rollen
| Rolle | Aufgaben | Rechte |
|-------|-----------|--------|
| Administrator | Übernimmt alle Aufgaben, inkl. Verwaltung der KI-Agenten | (Standardrolle) |
| Teamleiter | Verwaltet Benutzer | Benutzerverwaltung |
| Agent | Übernimmt Aufgaben der Sachbearbeitung | (Standardrolle) |
### Teams
| Team | Aufgaben | Skills | Rechte |
|------|-----------|---------|---------|
| Sachbearbeiter | Reguläre Sachbearbeitung | Standard-Skills | Agent |
| Second Level A | Komplexe Sachbearbeitung | z.B. NNA | Agent |
| Second Level B | Komplexe Sachbearbeitung | z.B. MaKo | Agent |
| Temporäre Teams* | Einmal- oder Sonderaufgaben | Temporäre Skills | Agent |
*Beispiele für temporäre Teams:
- Schulungs-Team, welches für die Dauer der Schulung mit den zu schulenden Mitarbeitern und Schulungs-Skills besetzt wird
- Task Force Frühlingsoffensive, für die Dauer einer Kundenrückgewinnungskampagne
Mitarbeiter außerhalb der Sachbearbeitung erhalten ihre Rollen direkt zugewiesen.
## Mittlere Organisationen (15-100 Mitarbeiter)
Bei mittleren Organisationen empfiehlt sich eine differenziertere Struktur, die bereits spezialisierte Rollen vorsieht, aber noch nicht die volle Komplexität großer Organisationen benötigt.
### Rollen
| Rolle | Aufgaben | Rechte |
|-------|-----------|--------|
| Administrator | Systemkonfiguration und -wartung | (Standardrolle) |
| KI-Manager | Optimierung und Überwachung der KI-Agenten | KI-Management |
| Workforce Manager | Ressourcenplanung und Skill-Management | Team- und Benutzerverwaltung |
| Qualitätsmanager | Qualitätssicherung und -kontrolle | QM-Rechte, Monitoring |
| Teamleiter | Teamführung und Second-Level Support | Teamleiter-Rechte |
| Agent | Sachbearbeitung | (Standardrolle) |
### Teams
| Team | Aufgaben | Skills | Rechte |
|------|-----------|---------|---------|
| First Level | Standardanfragen | Basis-Skills | Agent |
| Second Level | Komplexe Fälle | Erweiterte Skills | Agent |
| Spezialisten | Fachspezifische Aufgaben | Spezial-Skills | Agent |
| Management | Verwaltungsaufgaben | Keine* | Entsprechend Rolle |
| Qualität | Qualitätssicherung | Keine* | QM-Rechte |
*Nicht nötig, da außerhalb der Sachbearbeitung
## Große Organisationen (>100 Mitarbeiter)
Große Organisationen zeichnen sich durch eine Vielzahl von Merkmalen aus, die eine flexible und anpassungsfähige Struktur erfordern. Typische Herausforderungen größerer Organisationen sind z.B.:
- Kombination aus First und Second Level Teams für effiziente Bearbeitung einfacher und komplexer Anfragen.
- Integration interner Mitarbeiter und verschiedener externer Dienstleister, oft mit eingegrenztem Einsatzprofil
- Vielfalt an Skills zur Abdeckung aller notwendigen Kompetenzen.
- Feiner zugeordnete und nur nach Notwendigkeit vergebene Zugangsrechte
- Berücksichtigung verschiedener Marken und/oder Produkte
- Spezialisten aus IT, Qualitätssicherung und anderen Bereichen welche in Enneo zusammen arbeiten.
Anders als in kleinen Teams, bei denen man nur primär eine 1:1 Zurodnung eines Mitarbeiters zu einem Team hat, bietet es sich in größeren Organisationen an Mitarbeiter meheren Teams zuzuordnen.
### Rollen
Die Rollen sind in großen Orgsanisationen feiner aufgeschlüsselt, je nach Fall bietet sich z.B. folgende Ausprägung an:
| Rolle | Aufgaben | Rechte |
|-------|-----------|--------|
| Admin | Grundsätzliche Systemkonfiguration | (Standardrolle) |
| KI Manager | Optimiert KI-Agenten | KI-Agenten |
| Workforce Manager | Verwaltet Benutzer, Teams und Skills | User+Team+Tag Management |
| Wissensmanager | Verwaltet die Wissensbasis (Wiki) | Wiki |
| Reportingmanager | Verwaltet die Enneo BI Lösung Superset | Reporting |
| Qualitätsmanager | Prüft Qualität der Mitarbeiter | Agent + QM |
| Teamleiter | Verwaltet Team, Second-Level Support | Agent + Team |
| Agent | Sachbearbeitung | (Standardrolle) |
### Teams
Hinsichtlich der Teams bietet sich es sich an eine Kombination aus verschiedenen Teams für verschiedene Aufgaben anzulegen um Komplexität zu kapseln. Hier bietet sich z.B. ein Setup aus bis zu drei verschiedenen Arten von Teams:
1. Fachliche Teams um Sachbearbeitern Skills für Skill-based-routing zuzuweisen
2. Rollen Teams um verwaltende Mitarbeiter Rechte zu geben
3. Organisatorische Teams, um ergänzende Rechte und/oder Skills zu vergeben und um eine Übersicht zu behalten wo ein Mitarbeiter organisatorisch zuzuordnen ist, z.B. für externe Dienstleister oder bestimmte Produkte
4. Ggf. temporäre Teams für Projekte oder andere Sonderaufgaben, analog zu kleinen Organisationen
### Fachliche Teams
| Team | Aufgaben | Skills | Rechte |
|------|-----------|---------|---------|
| Basis-Frontoffice | Grundlegende Frontoffice-Themen | Abrechnung, Kündigung, etc. | Agent |
| Second Level Abrechnung | Komplexe Abrechnungsfälle | Spezial-Abrechnung | Agent |
| Kundenportal | Portalbetreuung | Portal-Skills | Agent |
### Rollen Teams
Ein Team pro Rolle, wie oben aufgeführt. Mitarbeiter werden dann nicht direkt einer Rolle zugeordnet, sondern über ein Team. Dies dient ausschließlich der Übersicht, alternativ kann man natürlich auch die Rolle direkt den Mitarbeitern zuordnen.
### Organisatorische Teams
| Team | Aufgaben | Skills | Rechte |
|------|-----------|---------|---------|
| Dienstleister 1 | Zugeordnete Skills | Keine* | Agent |
| Dienstleister 1 Subteam 1 | Spezifische Aufgaben | Marktkommunikation* | Agent |
| Internes Team 1 | Interne Bearbeitung | Keine* | Agent |
| Internes Team 1 Abteilung A | Interne Bearbeitung | Keine* | Agent |
| Internes Team 1 Abteilung B | Interne Bearbeitung | Keine* | Agent |
### Beispielprofile
- **Fabian Firstlevelsupporter**
- Teams: "Dienstleister 1 Subteam 1", "Basis-Frontoffice"
- Rolle: Agent
- Resultierende Rechte: Tickets
- Resultierendes Routing: Grundlegende Frontoffice-Themen
- **Tamara Teamleiter**
- Teams: "Internes Team 1", "Teamleitung", "Second Level Abrechnung", "Kundenportal"
- Rolle: Teamleiter
- Resultierender Rechte: Tickets und auf das Analytics-Portal
- Resultierendes Routing: Second Level Abrechnung, Kundenportal-Themen
- **Karin K.I.**
- Team: "KI Manager"
- Rolle: KI Manager
- Resultierende Rechte: KI-Performance-Optimierung
### Praxistipps
1. **Skill-Zuordnung**
- Ab einer gewissen Größe der Organisation sollten Skills primär über Teams vergeben werden und nur noch in Einzelfällen individuell.
- Regelmäßige Überprüfung der Skill-Verteilung
- Neue Skills erst nach erfolgreicher Schulung zuweisen
2. **Team-Management**
- Klare Namenskonventionen für Teams etablieren
- Regelmäßige Überprüfung der Team-Strukturen
3. **Rollen-Verwaltung**
- Minimalprinzip bei der Rechtevergabe
- Regelmäßige Überprüfung der Rollen-Zuordnungen
- Prüfung über einen Zweitbenutzer, z.B. im Test-System
---
## Benutzer
**URL:** https://richard-dev-playground.enneo.ai/docs/de/user-management/configure-users
**Description:** Konzept, Erstellung und persönliches Profil
### Erstellung und Konfiguration
Ein neuer Benutzer kann im Bereich `Benutzerverwaltung → Benutzer und Teams` hinzugefügt werden.
* Benutzerprofile umfassen immer Name, E-Mail und eine [Rolle](/docs/de/user-management/roles-and-permissions), die die Berechtigungen und den Zugriff des Benutzers regelt.
* Die Zuweisung eines [Teams](/docs/de/user-management/teams) ist optional. Sie erleichtert jedoch die Verwaltung, da Eigenschaften wie bspw. Skills und Kanäle nur einmalig pro Team festgelegt werden, und nicht bei jeder Erstellung eines Benutzers. Das minimiert potentielle Fehler, sorgt für Übersichtlichkeit und effiziente Arbeitsabläufe.
### Persönliches Benutzerprofil
* Im eigenen Benutzer wird der Status eingestellt:
- **Ticketbearbeitung**: Benutzer arbeitet an einem Ticket gearbeitet; Timetracking ist aktiv
- **Pause**: Bildschirm wird gesperrt, Benutzer befindet sich in Pause
- **Support**: Benutzer ist im Meeting, unterstützt einen Kollegen o.ä., Aktionsbutton im Ticket sind ausgegraut, Timetracking ist deaktiviert
- **Länger abwesend**: Benutzer ist krank oder im Urlaub, Bildschirm wird gesperrt, Timetracking ist deaktiviert
Weitere Informationen zum Thema "Status" sind im Abschnitt [Users Status](/docs/de/analytics/worklog#user-status-status) beschrieben.
* Über das eigene Benutzerprofil können darüber hinaus die Spracheinstellung der Benutzeroberfläche sowie die Vergabe eines neuen Passworts verwaltet werden.
### Längere Abwesenheit
Bei längerer Abwesenheit eines Mitarbeiters, etwa durch Urlaub oder Krankheit, lässt sich in der Benutzerverwaltung eine Abwesenheit eintragen. Der Autopilot sorgt dann dafür, dass Antworten auf seine zuletzt bearbeiteten Tickets automatisch anderen Benutzern zugewiesen werden.
Für das Einblenden wird im Bereich `Erweiterte Einstellungen → Allgemeines → "Zeiterfassung"` ein neuer Eintrag erstellt:
**1. Grundlegende Daten eintragen**
- **ID:** `absent`
Beispielhaft:
- **Label:** `Länger abwesend`
- **Langes Label:** `Für einen längeren Zeitraum abwesend`
- **Beschreibung:** `Längere Abwesenheit, z. B. Urlaub oder Krankheit. Während dieser Zeit werden eigene Tickets an Kollegen geroutet.`
- **Icon:** `/icons/holiday.svg`
**2. Konfiguration**
| Einstellung | Wert |
|---------------------------------|--------:|
| Automatischer Aktiv-Modus | OFF |
| In Bearbeitungszeit einbeziehen | OFF |
| Verfügbar für Chats | OFF |
| Verfügbar für Anrufe | OFF |
| Schreibaktionen blockieren | OFF |
| Support-Modus | OFF |
| Interaktionen blockiert | ON ✅ |
| Automatischer Abwesend-Modus | OFF |
| Versteckt | OFF |
**3. Speichern**
Nach Erstellung des Eintrags kann sowohl im eigenen Profil, als auch in der Benutzerverwaltung eine längere Abwesenheit hinterlegt werden.
---
## Rollen
**URL:** https://richard-dev-playground.enneo.ai/docs/de/user-management/roles-and-permissions
**Description:** Arten und Erklärung
Rollen und Berechtigungen in Enneo steuern, welche Aktionen Benutzer ausführen dürfen und auf welche Daten sie zugreifen können. Eine klare Rollenstruktur sorgt für Sicherheit und Effizienz.
### Basis-Rollen
Die Nutzung der Basis-Rollen als Ausgangspunkt erleichtert die Erstellung individueller Rollen und gewährleistet eine konsistente Berechtigungsstruktur.
* **Admin**: Die Adminrolle bietet umfassende Verwaltungsrechte, einschließlich der Erstellung und Verwaltung von Benutzern, Teams und Rollen. Administratoren können alle Tickets und Berichte einsehen und verwalten, KI-Agenten und Dunkelverarbeitungen konfigurieren sowie das Wiki, Tags und Templates pflegen. Zudem haben sie Zugriff auf Systemeinstellungen, Nutzerprofile und analytische Daten und können Rollen- und Berechtigungskonzepte anpassen.
* **Agent**: Die Agentenrolle umfasst die Bearbeitung und Verwaltung von Konversationen und Tickets. Agenten können zudem Intents ausführen und bearbeiten, haben Zugriff auf ausgewählte Berichte und können ihre eigene Zeiterfassung einsehen. Auch das Anzeigen und Verwalten der Ticketübersicht sowie das Weiterleiten von Tickets gehört zu ihren Aufgaben. Auf administrative Funktionen haben Agenten in der Basis-Rolle keinen Zugriff.
### Individuelle Rollen
Individuelle Rollen können beliebig erstellt werden und basieren auf einer der Basis-Rollen. Sie können mit Berechtigungen erweitert oder beschränkt werden. Beispiel:
* **Teamleiter**: verwaltet Teammitglieder, bearbeitet Benutzerprofile und kann sie Teams zuweisen, erhält Einblick auf Zeit- und Leistungsberichte seines Teams, bearbeitet keine Tickets, hat aber vollen Zugriff darauf
* **Wissensmanager:** pflegt die Wissensdatenbank, kann Inhalte erstellen, aktualisieren und archivieren und stellt sicher, dass alle Benutzer stets auf die neuesten Informationen zugreifen können.
---
## Teams
**URL:** https://richard-dev-playground.enneo.ai/docs/de/user-management/teams
**Description:** Nutzen, Strukturen, Verwaltung und Berechtigungen
### Nutzen
Teams sorgen bspw. dafür, dass die richtigen Benutzer die passenden Tickets erhalten und ermöglichen eine klare Organisation der Verantwortlichkeiten.
So können einem Team spezifische Fähigkeiten (Skills) und Kommunikationskanäle zugewiesen werden, was ein gezieltes Routing von Kundenanliegen an qualifizierte Mitarbeiter sicherstellt.
### Teamstrukturen
Neben den regulären Teams bieten auch Unterteams vielfältige Einsatzmöglichkeiten: Von Spezialisierungen auf komplexe Themen oder auch als Trainingsumgebung für neue Mitarbeiter. Durch abgestufte Verantwortlichkeiten können sie die Servicequalität und Effizienz maßgeblich verbessern. Hier 2 Beispiele:
**1. Team „Vertragsende“**
- Das Team „Vertragsende“ hat die Skills "Kündigung", "Umzug" und "Widerruf", mit den Kanälen "E-Mail", "Chat", "Telefon" und "Brief". Alle Benutzern dieses Fachbereichs erhalten im Autopiloten Tickets zu diesen Themen.
- Das Unterteam "VE-Todesfall" hat den Skill "Todesfall" in den gleichen Kanälen. Es ist darauf spezialisiert, diesen sensiblen Spezialfall im Vertragsende angemessen abzuwickeln.
**2. Team „Vertragsrahmen“**
- Das Team „Vertragsrahmen“ hat die Skills "Dokumente", "Kundenportal", "Adressänderung" und "Vertragsdetails", mit den Kanälen "E-Mail", "Chat", "Telefon" und "Brief". Allen Benutzern dieses Fachbereichs werden im Autopilot Tickets zugewiesen, auf die diese Eigenschaften zutreffen.
- Das Unterteam "VR-Training" hat die gleichen Skills, aber nur den Kanal "E-Mail". Es besteht aus neuen Mitarbeitern, die durch die Bearbeitung schriftlicher Kundenanfragen ihre Fachkenntnisse vertiefen, bevor sie in Echtzeit-Kanälen wie Telefon oder Chat eingesetzt werden.
### Datenverfügbarkeit
Für jedes Team kann ebenfalls der Zugriff auf Analytics-Daten verwaltet werden. Das ist bspw. hilfreich für ein Team "Supervisor", das die Leistung von Agenten auswertet, oder ein Team "Vertragsende", was keinerlei Zugriff auf Analytics-Daten benötigt.
### Zuweisung von Rollen und Berechtigungen
Jedem Team wird eine individuelle oder Basis-Rolle zugewiesen, womit die Zugriffsrechte der Mitglieder klar geregelt werden.
### Routing und Rechte
Auf Team-Ebene können sowohl Routing-Konfigurationen wie Fähigkeiten/Skills, zugewiesene Kanäle sowie Zugriffsrechte per Rollenzuweisung konfiguriert werden.
Nur wenn auf Benutzerebene die Einstellung _Teameinstellungen für Routing und Zugriffsrechte übernehmen_ aktiviert ist, werden diese auf den Mitarbeiter angewendet. In diesem Fall gelten die Teameinstellungen, nicht mehr die Benutzereinstellungen.
Hier ist die vervollständigte Markdown-Beschreibung inklusive einer Tabelle mit drei sinnvollen Beispielen aus dem Kundenservice-Kontext:
Sollten einem Benutzer mehreren Teams zugeordnet sein, gelten folgende Regeln:
- Routing-Einstellungen: Mitarbeiter erhält die Summe aller Teameinstellungen (Kummulierung der Skills/Tags und Kanäle).
- Rollenauswahl: Mitarbeiter erhält die stärkste Rolle, d. h. jene Rolle, welche die höchste absolute Anzahl an Berechtigungen hat.
| Benutzer | Teams | Team-Rollen | Team-Skills | Team-Kanäle | Ergebnis (Nutzereinstellungen) |
|----------|---------------------|--------------------------------------|--------------------------------------|----------------------------------------------|---------------------------------------------------------------------|
| User 1 | experts, agents | experts: admin; agents: agent | experts: [technik]; agents: [bestellung] | experts: [E-Mail]; agents: [Chat] | Rolle: admin; Skills: [technik, bestellung]; Kanäle: [E-Mail, Chat] |
| User 2 | social, backoffice | social: supervisor; backoffice: editor | social: [community]; backoffice: [rechnung] | social: [System]; backoffice: [E-Mail] | Rolle: supervisor; Skills: [community, rechnung]; Kanäle: [System, E-Mail] |
| User 3 | hotline, vip | hotline: agent; vip: power-user | hotline: [eingang]; vip: [vip] | hotline: [Telefon]; vip: [E-Mail] | Rolle: power-user; Skills: [eingang, vip]; Kanäle: [Telefon, E-Mail] |
---
## Überblick
**URL:** https://richard-dev-playground.enneo.ai/docs/de/user-management/user-management-in-enneo
Die Benutzerverwaltung in Enneo steuert, wer im System arbeitet, welche Funktionen genutzt werden dürfen und wie organisatorische Zuständigkeiten abgebildet werden.
Benutzer, Teams und Rollen greifen dabei ineinander und bilden die Grundlage für Zusammenarbeit, Zugriff und Verantwortlichkeiten im operativen Tagesgeschäft.
## Einstieg in Videos
## Benutzer als Grundlage der Zusammenarbeit
Jeder Mitarbeiter arbeitet in Enneo über ein persönliches Benutzerprofil. Dieses Profil verbindet die Person mit organisatorischen Informationen wie Teams und Rollen.
Dadurch wird gesteuert:
- welche Funktionen genutzt werden dürfen
- welche Bereiche im System sichtbar sind
- welche Verantwortlichkeiten ein Benutzer übernimmt
- wie Aktionen im System nachvollzogen werden
Benutzer und Teams werden im Bereich `Einstellungen → Benutzerverwaltung → Benutzer und Teams` verwaltet.
## Teams und organisatorische Zuständigkeiten
Teams bilden die organisatorische Struktur innerhalb von Enneo ab. Sie können beispielsweise Fachbereiche, Standorte oder Dienstleister repräsentieren.
Die Teamstruktur beeinflusst unter anderem:
- Zusammenarbeit im Tagesgeschäft
- Sichtbarkeit von Tickets
- organisatorische Zuständigkeiten
- Verteilung von Arbeit
## Rollen und Berechtigungen
Rollen definieren, welche Funktionen ein Benutzer in Enneo nutzen darf. Sie steuern beispielsweise den Zugriff auf Einstellungen, Verwaltungsbereiche oder spezielle Systemfunktionen.
Dadurch lässt sich klar festlegen, welche Verantwortung einzelne Benutzer innerhalb des Systems übernehmen.
Rollen werden im Bereich `Einstellungen → Benutzerverwaltung → Rollen` verwaltet.
## Das Zusammenspiel
Die Benutzerverwaltung in Enneo verbindet organisatorische Struktur und Berechtigungen miteinander:
- Benutzer definieren, wer im System arbeitet
- Teams bilden organisatorische Zuständigkeiten ab
- Rollen steuern den Zugriff auf Funktionen
Gemeinsam sorgen diese Elemente dafür, dass Mitarbeiter genau die Bereiche und Funktionen nutzen können, die für ihre Aufgaben relevant sind.
---
## AI Agents in Enneo
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/ai-agents-for-enneo
**Description:** Utilization, Types, and Benefits
### Various Applications
By default, Enneo offers twelve specialized AI agents that operate across all channels. These include:
* **Instalment Agent:** Assists customers with instalment adjustments and their management.
* **Basic Agent:** Performs basic tasks and forwards complex inquiries.
* **Bank Data Agent:** Helps customers update their bank details.
* **Due Date Agent:** Provides information on due dates and updates payment deadlines.
* **Credit Balance Agent:** Assists in the management of credit balances and their offsetting.
* **Resignation Agent:** Assists with contract terminations and next steps.
* **Direct Debit Revocation Agent:** Revokes a SEPA direct debit mandate at the customer's request.
* **Master Data Agent:** Helps customers change their master data.
* **Tariff Consultation Agent:** Advises customers wishing to switch to attractive tariffs.
* **Switching Agent:** Supports customers during the switching process.
* **Advertising Consent Agent:** Helps manage marketing requests and opt-ins.
* **Revocation Agent:** Supports in revoking contracts and answers related questions.
### Two Types of AI Agents
Enneo offers **two flexible approaches** to optimally adjust automation to the needs of customer service:
**1. Smart AI Agents:** These AI agents work independently and make decisions based on existing data, previous requests, and the respective context. They constantly learn and adapt to new requirements. Setting up and using smart AI agents requires no technical knowledge. The setup is done via natural language, is simple and user-friendly, so that people without IT experience can easily control automation.
**2. Rule-Based AI Agents:** These AI agents work according to firmly defined rules and workflows that are precisely tailored to the respective processes. They offer maximum control and flexibility, as each step can be precisely defined. This solution is particularly suitable for clearly structured tasks and deterministic processes. However, the setup requires a bit more time and technical understanding to optimally design the workflows.
### Benefits at a Glance
The use of AI agents offers several advantages:
* **Increased Efficiency:** Repetitive tasks are automated, significantly reducing processing time.
* **Relieving Employees:** Service teams can focus on more demanding tasks.
* **Better Customer Experience:** Requests are processed faster and more accurately - around the clock.
* **Easy Customization:** AI agents can be expanded with company-specific content and individually configured.
### Conclusion
With Enneo's AI agents, customer service can be made more efficient, flexible, and customer-oriented. Whether a smart or rule-based agent - the right solution can be implemented according to needs and continuously developed.
---
## Key Role of the Base Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/base-agent
**Description:** Application possibilities, functionality, and configuration
### Basic Configuration
The basic configuration of the Base Agent is based on the same principle as for AI agents with [Smarter Argumentation Logic](https://docs.enneo.ai/de/ai-functions-agents/smart-agents).
The central component is the Prompt: It determines how the Base Agent proceeds and which tools it can access.
### Individual Prompt Settings
The Prompt of the Base Agent describes the **basic behavior**: how a request is processed, which tools are used and the structure that is used. It is the shared, reusable logic for all use cases.
In addition, **additional instructions** can be stored in the `AI Customization → Miscellaneous → Individual Prompts` section. These are considered in addition to the Prompt of the Base Agent when generating a response.
They allow for the appropriate representation of technical special rules, linguistic details or client-specific peculiarities without having to modify the Base Agent itself.
### Assignment to Communication Channels
The Base Agent can be linked directly with a communication channel, for example a specific e-mail inbox, a chat or phone channel. The assignment is made in the settings of the respective sub-channels in the `Communication Channels` section and allows for a precise, client-specific configuration.
This means that different variants of the Base Agent can be operated in parallel, each with individual tonality in the response suggestions, its own toolset and wiki access.
**Example:**
*The **Voltlingen Base Agent** is linked to the email account service[at]sw-voltlingen.de. It formulates the response suggestions casually in the second person, draws on FAQ articles specially for Stadtwerke Voltlingen and is familiar with the product specifics there.*
*At the same time, the **Stromhain Base Agent** works under service[at]sw-stromhain.de with formal second-person plural address, a different selection of knowledge database categories and its own rules for dealing with certain topics.*
Both Base Agents are based on the same technical foundation but are fully adapted to the respective client.
---
## Rule-based Logic
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/rule-based-agents
**Description:** Functioning, Implementation and Example
### Parameter management
#### 1. Input parameters and their sources
Input parameters can be obtained from various sources:
* **Ticket data**: Information from the original ticket
* **Customer data**: Base customer data
* **Contract data**: Information on the customer's contract
* **Extraction by AI**: Automatic AI analysis of the customer request to detect relevant information
* **Manual setting**: A fixed value defined by a user
#### 2. Parameter values and mandatory fields
Each parameter needs a value, which can be automatically adopted, extracted by AI, or entered manually depending on the source. Mandatory fields ensure that certain information is available before the AI agent can execute a processing operation.
#### 3. Parameter attributes
The following fields are available when configuring a parameter:
| **Field** | **Description** |
|---|---|
| **Reference to source key** | Technical key for identification in the data object, e.g., `channel` |
| **Variable name in business logic** | Internal identifier for processing in logic and actions |
| **Designation for users** | Display name in the UI, if the parameter is visible to users |
| **Format** | Data type, e.g., `String`, `Boolean`, `Number`, `Date` or `Enum` |
| **Options** | Selection values for parameters of the type `Enum` |
| **Internal description** | Explanation of the function or usage; serves as a recognition hint for AI extraction |
| **Required** | Determines whether the parameter must be set compulsorily |
| **Visibility for users** | Control of UI display: `Visible`, `Hidden`, `Read-only` |
| **Display options** | Additional display settings for visible string parameters |
#### 4. Visibility and editing restrictions
* **Visible**: The parameter is visible to editors and can be edited, unless otherwise restricted.
* **Hidden**: The parameter is processed in the background, but not displayed.
* **Read-only**: The value is visible, but cannot be changed.
#### 5. Display options for visible text parameters
For parameters with the format **String** and visibility **Visible**, additional display options can be configured:
* **Multiline**: The parameter is displayed as a multiline input field.
* **Lines**: Defines the height of the multiline input field.
* **Automatically send**: Specifies whether an input is automatically adopted/sent.
These display options are only available for visible string parameters. They are not shown for hidden, read-only or differently formatted parameters.
#### 6. Requirement of a parameter
* **Yes**: The parameter must be provided compulsorily for the processing by or with the help of the AI agent to take place.
* **No**: The parameter is optional and can be left blank.
Parameters can be removed at any time.
### Example Bank Data
To process customer concerns regarding bank data adjustments, the bank data agent needs a **combination** of specific **information and checks**. It obtains relevant information via the input parameters, while the checks are defined in the business logic.
Therefore, the following input parameters are configured for this AI agent:
* **`contractId`** *(Source: Contract data)* → The customer's contract number in order to assign the modification to the correct contract.
* **`newIBAN`** *(Source: Extraction from customer request with AI)* → The new bank account details that the customer wants to provide.
* **`oldIBAN`** *(Source: Contract data)* → The current recorded IBAN to compare it with the new one.
* **`accountHolder`** *(Source: Extraction from the customer request with AI)* → The name of the account holder to verify the identity. If no name is given, the value remains empty.
* **`date`** *(Source: Extraction from the customer request with AI)* → If specified, the date from which the new bank details should be valid.
### Summary
The pre-configured input parameters allow rule-based AI agents to efficiently process customer concerns. In conjunction with the business logic, data is structured, checked, appropriately displayed in the UI, and automatically processed. This results in precise processing with minimal manual effort.
### Working
After the relevant **input parameters** have been recorded, the **Business Logic** takes over the **processing**. This includes:
* Completeness and plausibility checks
* Validation of data based on predefined rules
* Determining additional values if necessary
* Initiation of actions based on the results of the tests
### Technical implementation
The business logic can be implemented in:
* PHP (8.2)
* Python (3.11)
* JavaScript (Node 20)
The implementation follows a structured processing pipeline:
**1. Initialization and input validation**
* Input parameters are taken from the context and converted into a standardized format.
* Mandatory fields are checked, missing values if necessary replaced by defaults.
* Type conversions (e.g., `bool`, `int`, `float`) occur to ensure consistent processing.
**2. Rule-based Processing**
* The business logic validates the inputs based on defined rules (e.g., format checks, plausibility checks).
* If required, external API calls or database queries are made to supplement additional information.
* Calculations and decision processes are based on the parameters (e.g., branching in case of deviating inputs).
**3. Actions and results output**
* The business logic controls the further process by:
* Making automatic changes in the system
* Calling external APIs (e.g., for data storage)
* Generating inquiries or confirmations
* The return is standardized as **response object**, which can contain **confirmation, error messages or interaction options** depending on the context.
The business logic delivers results, which are further processed via **output handling**. There it is determined how the AI agent reacts to certain scenarios – be it through confirmations, inquiries or interaction possibilities.
### Example: Business Logic for processing an IBAN change
An AI agent processes requests for changing a bank connection. The business logic ensures that the change is carried out correctly and all relevant checks are made.
**1. Validate inputs**
First, the inputs are standardized and checked:
* Remove spaces in the IBAN
* If no account holder is indicated, it is supplemented from contract data
```php
$this->input->newIBAN = str_replace(' ', '', $this->input->newIBAN);
$this->input->oldIBAN = $this->input->oldIBAN ?? '';
$this->input->oldIBAN = str_replace(' ', '', $this->input->oldIBAN);
// If no account holder is indicated, take from contract data
```php
if (!($this->input->accountHolder ?? null)) {
$this->input->accountHolder = sprintf(
'%s %s',
$this->contractData->firstname,
$this->contractData->lastname
);
}
```
**2. Validating Input**
The business logic checks if the new IBAN is correct:
* **IBAN Validation:** Format and checksum verification
* **Contract Exists:** The change must be assigned to a valid contract
```php
// Retrieve contract
$this->contractData = ApiEnneo::getContract($this->input->contractId);
if (!$this->contractData) {
throw new Exception('Contract not found.');
}
// Format and checksum validation of the IBAN
if (!$this->validateIbanFormatting($this->input->newIBAN) || !$this->validateIbanChecksum($this->input->newIBAN)) {
$this->interaction->infos[] = new IntentInfo(
type: 'warning',
message: 'IBAN not in correct format or checksum invalid',
);
$this->interaction->options[] = new IntentOption(
type: self::ACTION_IBAN_INVALID,
name: 'Ask customer for correct IBAN',
recommended: true,
);
throw new ChangeBankDataException();
}
```
**3. Output result and determine next action**
Depending on the outcome of the checks, the business logic decides the next steps:
* If the checks are successful → **IBAN is saved**
* If errors were detected → **The customer is asked to respond or given the chance to correct**
```php
if ($this->input->_action === self::ACTION_ENTER_INTO_SYSTEM) {
$this->saveBankData();
foreach ($this->form->fields as $field) {
$field->readonly = true;
}
} else {
$this->interaction->options[] = new IntentOption(
type: self::ACTION_ENTER_INTO_SYSTEM,
name: 'Store bank details in the system',
recommended: true,
);
}
```
**4. Interaction design with the SDK**
Interactions are Enneo's main tool for providing agents with structured feedback. An interaction consists of four elements:
1. **Info:** What notifications or warnings should be displayed to the agent?
2. **Form:** What input fields should be displayed, e.g., text fields or dropdown menus?
3. **Data:** What values do the input fields have?
4. **Options:** Which buttons should be displayed to the user?
An interaction can be created using the Enneo SDK, a library with object definitions. The above interaction can be created with the following code:
Instead of the SDK, the JSON object for the interaction can also be created directly. Here is a complete example of the interaction for the termination AI functionality shown above:
```json
{
"data": {
"date": "2023-12-08",
"type": "regular",
"dryRun": "true",
"_action": "null",
"contractId": 756852,
"dateReceived": "2023-12-08",
"proofIncluded": false
},
"form": {
"fields": [
{
"id": "contractId",
"type": "integer",
"label": "Contract number",
"fields": null,
"hidden": true,
"options": null,
"readonly": false,
"valueRef": "data.contractId",
"validation": null,
"placeholder": null,
"defaultValue": null
},{
"id": "date",
"type": "date",
"label": "Termination date",
"fields": null,
"hidden": false,
"options": null,
"readonly": false,
"valueRef": "data.date",
"validation": null,
"placeholder": null,
"defaultValue": null
},{
"id": "type",
"type": "select",
"label": "Type of termination",
"fields": null,
"hidden": false,
"options": [
{
"id": "regular",
"label": "Regular",
"value": "regular"
},
{
"id": "priceAdjustment",
"label": "Price adjustment",
"value": "priceAdjustment"
},
{
"id": "relocation",
"label": "Relocation",
"value": "relocation"
},
{
"id": "death",
"label": "Death",
"value": "death"
},
{
"id": "custom",
"label": "Other",
"value": "custom"
}
],
"readonly": false,
"valueRef": "data.type",
"validation": null,
"placeholder": null,
"defaultValue": null
},
{
"id": "_action",
"type": "text",
"label": "_action",
"fields": null,
"hidden": true,
"options": null,
"readonly": false,
"valueRef": "data._action",
"validation": null,
"placeholder": null,
"defaultValue": null
},
{
"id": "proofIncluded",
"type": "checkbox",
"label": "Proof included",
"fields": null,
"hidden": false,
"options": null,
"readonly": false,
"valueRef": "data.proofIncluded",
"validation": null,
"placeholder": null,
"defaultValue": null
},
{
"id": "dryRun",
"type": "checkbox",
"label": "(actually perform write access)",
"fields": null,
"hidden": true,
"options": null,
"readonly": false,
"valueRef": "data.dryRun",
"validation": null,
"placeholder": null,
"defaultValue": null
},
{
"id": "dateReceived",
"type": "date",
"label": "Receipt of termination",
"fields": null,
"hidden": true,
"options": null,
"readonly": false,
"valueRef": "data.dateReceived",
"validation": null,
"placeholder": null,
"defaultValue": null
},
{
"id": "sourceCode-0",
"type": "dict",
"label": "Source code executor response",
"fields": null,
"hidden": false,
"options": null,
"readonly": false,
"valueRef": "data.sourceCode-0",
"validation": null,
"placeholder": null,
"defaultValue": null
}
]
},
"infos": [
{
"code": null,
"type": "warning",
"message": "Contract was cancelled before the start of delivery and therefore cannot be terminated.",
"extraInfo": null
}
],
"options": [
{
"icon": "check",
"name": "Inform customer about this",
"type": "termination_already_processed",
"order": 1,
"handler": "",
"recommended": true
}
]
}
```
### Summary
The business logic defines how an AI agent processes input parameters and makes decisions based on this processing. It ensures that customer requests are structured, checked, validated, and processed accordingly. Automated rules and procedures efficiently control processes and ensure they are carried out transparently, minimizing manual interventions.
### Basic Functionality
Output handling is based on **predefined rules** that build on the results of the business logic. It controls, among other things:
* **Text Templates:** Automated messages to the user, such as confirmations or queries.
* **Interactions:** Provision of buttons or forms for further processing.
* **API Calls:** Transfer of results to other systems.
* **Automated ticket actions:** Entries in the system or completion of operations.
In Enneo, there are several **types of actions** that can trigger a response:
* **AI's Suggestion for Reply:** The AI generates a response to the customer based on the context.
* **Using Text Template:** A defined message is sent directly.
* **Interaction:** The user is given options for further processing.
* **Close Ticket Without Responding:** The request is automatically concluded.
* **Send Text Template and Close Ticket:** A confirmation is sent, and the ticket is closed.
### Example: Output handling in Bank Data Agent
The business logic of the Bank Data Agent makes decisions based on the input parameters. The **output handling builds on this and controls the response**.
**1. IBAN is already in the system**
If the new IBAN is already stored in the system (`iban_already_in_system`), a **text template** is automatically sent to the customer:
```bash
Thank you for providing us with the bank details.
The bank account ending in ...{{last4digits newIBAN}} is already stored in our system and will be used by us
{{#if payoutOnly}}for future credits{{else}}for monthly installments, invoices as well as possible credits{{/if}}.
```
* **Action:** **Use text template**
* **Condition:** `_action = iban_already_in_system`
* **Automatic execution:** **Yes** → Message is sent fully automatically.
**2. IBAN is invalid**
If the business logic identifies the new IBAN as **invalid** (`iban_invalid`), an alternative action is executed. The customer is asked to provide a correct IBAN.
```bash
The provided IBAN {{newIBAN}} is not valid.
Please check the IBAN for any typing errors and send us the correct bank details so that we can store them. Thank you for your support.
```
* **Action:** **Use interaction or text template**
* **Condition:** `_action = iban_invalid`
* **Automatic execution:** **No** → The user decides on the further procedure.
**3. IBAN was successfully stored**
As soon as the IBAN was successfully entered into the system (`enter_into_system`), a confirmation is sent to the customer:
```bash
Thank you very much for your message.
We have stored the bank account ending in ...{{last4digits newIBAN}} in our system and will be used by us
{{#if payoutOnly}}for future credits{{else}}for monthly installments, invoices as well as possible credits{{/if}}.
```
* **Action:** **Use text template**
* **Condition:** `_action = enter_into_system`
* **Automatic execution:** **Yes** → Message is directly sent.
### Summary
The **output handling connects the business logic with the communication**. It ensures that decisions are automatically transformed into actions – be it by direct confirmations, queries or subsequent processes. Thus, customer inquiries are processed efficiently, transparently and without manual intervention.
---
## Examples
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/samples
**Description:** Examples
---
## SDK
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/sdk
**Description:** Enneo SDK - Documentation
The Enneo SDK provides a comprehensive collection of tools that facilitate the development of specific code for custom solutions in the field of AI-powered customer support. The SDK supports the implementation of rule-based logic for AI agents, event-based integrations, custom webhooks, and user-defined functions. The SDK is loaded automatically and features are immediately available.
### Integrating the SDK in Code
To incorporate the Enneo SDK into your code, the following code snippet can be used:
### Enneo API Wrapper
The Enneo SDK provides wrappers for the Enneo API endpoints, allowing convenient access to the API:
- Load contract data by contract ID
- Load ticket data by ticket ID
- Execution of [user-defined functions](/docs/en/system-integration/user-defined-functions-tools/user-defined-functions-in-enneo)
- Call of any Enneo API endpoints (GET | POST | PATCH | PUT | DELETE)
../../../snippets/en/user-defined-functions/user-defined-function-call.mdx
### SDK Code
The SDKs are available at:
- [PHP SDK](https://demo.enneo.ai/api/codeExecutor/sdk/php82.php)
- [Python SDK](https://demo.enneo.ai/api/codeExecutor/sdk/python311.py)
- [Node.JS SDK](https://demo.enneo.ai/api/codeExecutor/sdk/node20.js)
The above URLs work without authorization, i.e., they can be directly included in your scripts.
../../../snippets/sdk-code.mdx
---
## Smart Argumentation Logic
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/smart-agents
**Description:** Creation of a smart AI agent
### Example prompt of a rate counseling agent with custom tools
Assume the role of a retention specialist for a utility company. As a rate consultant, you aim to politely but effectively encourage the customer by telephone to opt for a more economical tariff instead of going through with the cancellation. You have initiated a call to the customer. Please proceed as follows:
1. If the customer states that the cancellation was incorrect, note this in and revoke the cancellation.
2. Otherwise, ask why the customer has chosen to cancel. Document the reason in .
3. Following that, inquire if you can offer the customer a pre-made switch offer to save them money. Address the reason for cancellation where it applies. If they decline, accept it and end the call.
4. If the customer indicates interest, retrieve the offer with . Briefly introduce the offer, focusing on the highlights. Express numbers in words (e.g. 1.5 → one point five). Use natural language, no JSON variables or abbreviations like kWh. If the customer shows no interest, end the call.
5. Answer any questions the customer may have about this tariff. If they want the tariff emailed, use and confirm the sending mentioning the referred email address.
6. Ask whether the customer wants to accept the offer. If they agree, initiate the tariff switch with . Otherwise, accept the decision and end the call.
7. Confirm a successful switch to the customer and end the call.
8. If the customer requests a calculation of potential savings, use the tool .
Solely focus on this process and do not digress into other topics. No need for customer identification as you are already familiar with the customer. Address the customer formally.
### Custom Tools
In the `AI Customization → AI Tools` section, custom tools can be created and later added to a smart AI agent.
These tools support the AI agent in executing processes and instructions efficiently and purposefully. Depending on the configuration, the actions of the AI agent are triggered, adjusted based on recognized customer needs, and completed in the defined process flow.
* A custom tool describes a single action – e.g. "rescind cancellation" – that can be later invoked by the Smart Agent.
* What information the tool needs (e.g., a contract number) is determined beforehand and automatically passed on when used.
* The actual action can either be directly defined by code or forwarded to an external interface.
### Integrated Tools
---
## AI Post-Processing
**URL:** https://richard-dev-playground.enneo.ai/docs/en/analytics/ai-insights
**Description:** Typed questions that AI answers after the ticket is closed and are stored as AI Insights.
### What is AI post-processing?
AI post-processing is a downstream classification of tickets. After a ticket is completed, AI answers previously defined questions based on the ticket conversation and available metadata.
Each question has a professional name, description, and data type. This prevents free, unstructured summaries and instead creates evaluable values such as yes-no answers, categories, numbers, or short texts.
The configuration is done in the channel-specific settings under the point `AI post-processing`.
### What is the AI post-processing used for?
The function is particularly useful when information is technically relevant but cannot reliably be represented by status, tags, or fixed process fields. This primarily affects assessments that only arise from the course or result of processing.
Examples include:
- whether the concern was actually fully resolved
- why a process was handed over to an employee
- whether automation has failed due to missing data, missing approval, or technical limitations
- whether the original customer intention has changed during the conversation
- whether a process was formally closed, although clarification was still needed
Such information is relevant for evaluations but is often not stable to model over operational fields. The AI post-processing supplement this structure subsequently, without changing the editing process itself.
### What are AI Insights?
AI Insights are the stored results of AI post-processing. They are stored on the ticket and are also available in the data export.
The export of AI Insights can be found under `Advanced Settings → Data Exports`.
In data export, the AI Insights are output as structured information per ticket. These include:
- the answered question
- the typed value
- the confidence
The value depends on the data type of the question. For a Boolean question, the result is, for example, true or false. For an Enum question, the result is one of the defined categories.
The confidence describes how confident the AI is in its answer based on the available information. A low confidence does not necessarily mean that the result is wrong. It indicates that the evidence in the ticket can be weak, indirect, or contradictory.
The brief justification is saved in the ticket context but is not output as a bulk entry in the data export, as it may contain free text and can quote conversation contents.
### Importance of question types
The type of question determines what kind of result the AI can deliver and how well this result can be evaluated later.
_Boolean questions_
- For clear yes / no classifications
- Suitable if it should be clearly decided whether something applies
- Example: "Has the concern been resolved?"
_Enum questions_
- For predefined categories
- Especially suitable for reporting, filtering, aggregation, and comparisons
- Example: "What is the reason?"
_Text questions_
- For brief qualitative classifications or summaries
- Less stable for reporting, as free text is harder to compare
_Number fields_
- Only use if the number can be clearly derived from the conversation or the metadata
- Not suitable if the AI would have to estimate or interpret
### Best practices for questions
Questions should be technically unambiguous, narrowly limited, and answerable from the ticket conversation. The description is crucial in this context: It controls which evidence the AI should consider and when no reliable result is available.
A good question not only describes the desired result but also the demarcation to similar cases.
**Example:**
Name: `Processing result`
Type: `Enums`
Options: `completely_resolved`, `partially resolved`, `unresolved`, `unclear`
Description: `Evaluate whether the customer's request in the ticket was finally resolved. Use "unclear" if no reliable statement can be made from the conversation.`
### Dealing with empty results
An AI Insight may remain empty if the AI does not find a sufficient basis for an answer. This is technically desired and should be considered in evaluations.
If an indeterminate result is analytically relevant, it should be explicitly modeled. An `unclear` or `unquantifiable` category can be used for Enum questions.
### Implications of changes
Changes to questions affect future evaluations. Historical results remain preserved.
If a question is deleted, it will no longer be used for new tickets. However, previously generated AI Insights continue to be available for audit and export purposes.
When changing the question, description, data type, or options, it should be taken into account that old and new results may not always be technically directly comparable. For stable time series, questions, and option values should be as consistent as possible.
### Recommendations for productive use
AI post-processing should start with a few, clearly defined questions. A small number of precise questions usually provide more stable results than many broad or overlapping questions.
Before using in reports, new questions should be checked using real tickets. It is particularly important whether the answer can actually be derived from the conversation and whether the categories are sharply differentiated enough.
AI post-processing makes sense if completed tickets need to be evaluated in a structured way. It should not be used as a substitute for binding process logic, compliance decisions, or manual technical reviews.
---
## Enneo BI Solution Superset
**URL:** https://richard-dev-playground.enneo.ai/docs/en/analytics/enneo-bi-solution-superset
**Description:** Enneo BI Solution Superset
## Access to Superset
Access to the analysis functions is controlled via the user setting "Data Availability". Administrators can determine which users have access to the analysis functions and to what extent data is visible.
Superset can then be accessed via the Enneo menu item "Analytics". On the top bar, the different dashboards that have been created can be found in tabs.
## Creating Superset Evaluations Yourself
In the standard, Enneo offers a range of evaluations, which can however be expanded as desired. The data is always up to date.
For this, you need to click on the "Editor" tab with an Enneo account that has full data availability rights. There, you have full access to all functions of Superset.
### Creating Diagrams
Superset allows for the creation of various types of visualizations:
* Bar and line charts
* Pie charts
* Tables and pivot tables
* Heatmaps
* And many other types of diagrams
Each diagram can be customized individually, for example, through:
* Data filtering
* Grouping by different dimensions
* Adjusting colors and labels
* Definition of metrics and calculations
### Time Series Analysis
Time-series analysis is particularly useful for service organizations. It allows for:
* Analyzing trends over different time periods
* Make comparisons to the previous year or previous month
* Recognize seasonal patterns
* Make forecasts
### Creating Dashboards
Multiple diagrams can be combined into meaningful dashboards:
* Select desired diagrams
* Arrange by drag & drop
* Define dashboard-wide filters
* Save dashboard for further use
## Tips for Working with Superset
### Best Practices
* Use meaningful names for diagrams and dashboards
* Use filters to keep the amount of data manageable
* Save frequently used diagrams as favorites
* Share useful dashboards with the team
### Data Updates
The data in Superset is updated regularly. The update intervals are:
* Ticket data: every 5 minutes
* Message data: every 5 minutes
* Processing data: every 5 minutes
## Further Resources
For detailed information on Apache Superset, it's worth taking a look at the official [documentation](https://superset.apache.org/docs/intro).
---
## Exports
**URL:** https://richard-dev-playground.enneo.ai/docs/en/analytics/exports
**Description:** Exporting data from Enneo
There are three different ways to export data from Enneo:
### 1. Export selected tickets via the user interface
In the ticket overview, the currently displayed ticket list can be downloaded via the export symbol in the upper right corner. All set filters, such as channel filters, status and tags, are taken into account.
### 2. Export of tickets, messages and processing via the user interface
This export can be accessed via the following navigation:
Settings -> Advanced Settings -> Exports and Reporting Settings
Here you can choose between the known, central data tables:
* Tickets
* Messages
* Processing
### 3. Export via the REST-API
The Enneo REST API is available for automated exports. The documentation of the corresponding API interface `/api/mind/export/` can be found [here](/docs/en/api-reference/introduction).
This interface is particularly suitable for automated exports as it allows setting filters or limits. Thus, connections to external BI systems such as MS Power BI, Tableau, Snowflake, Google Looker Studio etc. are possible.
The desired data table can be specified using the "key" parameter:
* tickets
* messages
* worklog
The **"format"** parameter can be used to select the desired export format (XLSX, CSV or JSON). For regular exports, JSON (preferred) or CSV are recommended, as these formats are significantly more performant than XLSX.
Further parameters relevant for automated exports, such as `limit`, `offset` or `orderByField` can be found in the documentation.
### Export formats
The following formats are available for all export options:
* XLSX (Excel)
* CSV (Comma Separated Values)
* JSON (JavaScript Object Notation)
---
## Analytics
**URL:** https://richard-dev-playground.enneo.ai/docs/en/analytics/overview
**Description:** Data analysis in Enneo
### Central Data Tables
There are three central data tables in Enneo:
**1. Ticket Data**
A ticket consolidates all messages on a topic from a customer, similar to a thread in GoogleMail. In this dataset, only the tickets with data such as status (open/closed), SLA performance (resolved in time/not resolved in time), or skill category are included. With this dataset, a filter on open tickets provides an overview of the work inventory of the Service Centers.
**2. Incoming and Outgoing Messages**
Exports the incoming and outgoing messages. A message is the original message of a ticket as well as responses from customers and/or agents and internal notes. The direction (incoming/outgoing) is defined by the `direction` column. This dataset provides insights into the inbound volume of a service center.
**3. Export of Edits**
Exports all edits. A manual edit is created whenever a human user or an Enneo AI agent edits a ticket. This dataset provides insights into the work volume performed by a service center, by teams or (depending on privacy settings) individual employees.
This dataset is described in detail [here](/docs/en/analytics/worklog).
### Relationship Between Data Tables
Here is an example to illustrate the relationship between tickets, messages, and edits:
| Activity | Tickets | Messages | Edits | Direction | Type | Type of Edit |
| --------------------- | ------- | --------- | ------- | -------- | ---- | ------------ |
| Customer sends email | 1 | 1 | 0 | in | First| |
| Employee responds + closes | 1 | 2 | 1 | out | Follow-up | With response |
| Employee writes note | 1 | 3 | 1 | internal | Follow-up | |
| Customer has follow-up question | 1 | 4 | 1 | in | Follow-up | |
| Customer has another follow-up question | 1 | 5 | 1 | in | Follow-up | |
| Employee: Status pending | 1 | 5 | 2 | | | Status set to pending |
| Employee writes note | 1 | 6 | 2 | internal | Follow-up | |
| Employee assigns to colleague | 1 | 6 | 2 | | | |
| Colleague closes ticket | 1 | 6 | 3 | | | Without response |
| **Total** | **1** | **6** | **3** | | | |
---
## Processing
**URL:** https://richard-dev-playground.enneo.ai/docs/en/analytics/worklog
**Description:** Data export of all processing
In this export, Enneo captures all customer processing activities. It is particularly well-suited for measuring the volume achieved in the service center. The following information is exported:
## Processing time (`duration`)
Enneo determines the processing times (AHT, "Average Handling Time") during ticket handling by summing up the entire screen time of the browser on a ticket. Three points in time are relevant for this:
- **Start time**: Point in time when the user opens the ticket - either manually or via skill-based routing.
- **Processing time**: Point in time when the user made a modification on the ticket. If there are several changes, the time of the first change is used.
- **End time**: Date of the last browser access to a ticket.
The processing time (`duration` in the export) is the difference between the end and start time. The post-processing time (`durationAfterWork` in the export) is the difference between the processing and end time.
### Frequently asked questions about processing time:
- **Handling distributed processing**: If a ticket is processed several times in one day, for instance, in different sessions, the times are aggregated. Example:
- User 1 views a ticket in the morning for 5 minutes and then closes it at noon after an additional 10 minutes of processing time.
- User 2 only views it at noon.
- User 3 reopened the ticket in the evening after 2 minutes of processing and set it to waiting.
- -\> Enneo records two processes here: 1 processing at 15 minutes by User 1, no processing / recording for User 2 and 1 processing at 2 minutes by User 3. This results in an average daily AHT of (15+2)/2=8.5min
- **Consideration of intraday responses**: If a user works 5 minutes on Ticket 1 in the morning and another 7 minutes in the afternoon because the customer had a query at noon, these two time blocks are counted as two separate processes. The AHT is then (5 + 7) / 2 = 6 minutes. If the customer had not responded at noon and the user works on the same case twice, for example, 5 minutes in the morning and 7 minutes in the afternoon without a query, this would be counted as one processing with a total of 12 minutes.
- **Parallel processing**: If a user has several tickets open simultaneously in different browser windows, the AHT is distributed over the tickets. Thus, there is never a double counting. Example: If a user processes 4 tickets concurrently over 20 minutes, the result is an AHT of 20 / 4 = 5 minutes.
- **Status**: The time is only counted towards the AHT if the user is in "Active" status. More information on this can be found in the _User Status_ section below.
## Processing type (`action`)
Enneo records a "processing" (i.e., work of a user) only when a ticket was not just viewed, but actually edited.
There are four types of processing (in brackets the designation in the data export):
- **Status set to Waiting** (`statusAction`): The processor has set the status of a ticket to "Waiting." Example: Information is missing, requested from the customer. Once available, the processing can continue.
- **Processing without answer** (`closeAction`): A ticket was closed by the processor without sending an answer to the customer. Example: The customer wants to quit, and the cancellation confirmation is sent by the billing system. A separate answer is thus not necessary.
- **Processing with answer** (`writeAction`): A ticket has been closed with a response. Example: A customer has asked a question that is being answered.
- **Dark processing** (`autoProcessAction`): A ticket has been autonomously closed by an Enneo AI agent configured for dark processing. Example: A customer wants a credit payout, and the corresponding AI agent automatically initiates this.
If there were several processes (e.g., if a ticket was first closed and then an answer was sent), the type of processing with the higher priority according to the order above applies. Thus, in this case, "Processing with answer" (writeAction) would be recorded.
## Case closing process (`reOpened`)
If this value is set (= 1), the ticket was reopened after closing — either due to a follow-up response from the customer or by a colleague. This allows recording the First Contact Resolution quota.
## User status (`status`)
In Enneo, there are different status modes for users. By default, four status modes are available:
- **Active**: After logging in, a user is defaultly "Active" (also called "Ticket Processing"). In this status, processing of tickets is possible, and time is recorded.
- **Support**: If support services need to be provided (e.g., help for colleagues), this status can be chosen. Reading permissions are possible in this mode, but any processing is blocked. Also, in this status, no time is recorded.
- **Pause**: Pause mode. Neither reading nor writing access is possible, and no time is recorded.
- **Auto-Absent**: After a configurable period of inactivity, a user can automatically be put into pause mode. Upon returning, a popup appears, specifying how the time should be posted. If "Active" is selected, the corresponding time is counted towards AHT.
User status modes and auto-absence settings are freely configurable under **Settings -> Advanced Settings -> General -> Time Tracking -> Time Tracking Options**.
## Operator's name (`name`) / Data protection
The processing export provides performance-related data such as processing volumes and times. If desired, Enneo can make these inaccessible. There are three levels of data protection available:
- **Anonymization**: No conclusions about who made which processing at what time. Each process is listed under the user "Anonymous."
- **Pseudonymization**: Instead of real names (e.g., "Meike Mustermann"), Enneo assigns random pseudonyms (e.g., "Hungry Raspberry").
- **Real names**: The real names of the processor (e.g., "Meike Mustermann") are displayed.
## Degree of level of processing automation (`aiAutomationLevel`)
Records the highest level of automation observed in processing (range 0-5). This field supports measuring the progress towards dark processing.
The levels at a glance:
- **L0**: No AI support, except for customer/tag detection
- **L1**: User has used AI for text editing
- **L2**: User has manually confirmed the proposal of the base agent (with or without modifications)
- **L3**: User has manually confirmed the proposal of another (non-base) agent
- **L4**: Auto-processing with release (approval required)
- **L5**: Completely autonomous auto-processing
## Correct customer recognition (`customerIdentifiedCorrectly`)1/0 flag indicating whether the customer was correctly identified, i.e., no correction was needed as part of a manual adjustment. This field measures data quality and friction in the intake process and shows potential for optimization in detection prompts or customer code for customer search.
## Correct Tag Recognition (`tagsIdentifiedCorrectly`)
1/0 flag indicating whether the assigned tags (e.g., skill tags, product tags) were correctly identified, i.e., without subsequent manual correction. Tag recognition can be optimized using detection prompts.
## Quality of Text Support (`textAssistanceAccuracy`)
Numeric similarity as a value between 0 and 1 (e.g., 0.9843 for 98.43%) between the text recommended by the basic agent and the text actually sent - provided the basic agent was used. The similarity is calculated as 1 minus the normalized text difference (e.g., so-called normalized Levenshtein distance). `NULL` if no basic agent was used or there is no basis for comparison. This field measures the utility of the AI text suggestions. The value can be improved by optimizing the base agent's prompts, better wiki entries, or additional customer data from the ERP integration.
## AI Agents Used (`aiAgentsUsed`)
JSON array of the AI agent names used in the processing. Allows for adoption tracking and effect analyses per agent. It can contain one or more entries.
## Skipped Ticket (`skippedTicket`)
1/0 flag indicating whether a ticket automatically assigned by the autopilot was skipped by the user. Useful for detecting potential cherry-picking or uncovering routing problems.
## SLA Deviation at Closure (`netSecondsClosedAfterSLA`)
Seconds between the "Processing time from customer's perspective" and SLA due date - net, i.e., taking into account the configured working hours and excluding weekends/non-working times. A negative value means timely closure, a positive value delayed. `NULL` if no SLA due date could be determined. Also see `Routing and Tags → SLAs and Working Hours`.
The "Processing time from customer's perspective" is defined as the time of sending the reply, closing, or in case of dark processing using AI, the processing time. If there are several time points, the earliest is taken.
## Editor's Teams (`teams`)
JSON array with the team names of the user at the time of processing. Supports multi-team analyses without string parsing.
## Ticket Tags (`tags`)
JSON array of the tag names assigned to the ticket. Enables tag-level analysis and flexible filtering.
## Topic Classification (`topic`, `subTopic`)
If configured, a topic classification is specified. `topic` represents the main category (e.g., "General"), `subTopic` the subcategory (e.g., "RG: Instalment/JVB"). Both fields can be `NULL` if no classification exists.
## Channel (`channel`)
Contact channel of the customer's request (e.g., `email`, `mail`). Can be `NULL` if not determinable.
# Technical Fields
These are only filled out if Enneo does not anonymize the user (see field `name` / Privacy).
- `date` - Time of recording the processing.
- `ticketId` - Ticket ID of the ticket that was processed.
- `conversationId` - Conversation ID of the last customer message at the time of processing. NULL if it was an initial request.
- `userId` - User ID of the processor.
- `userWorklogId` - Unique ID of the processing (Primary key).
# Deprecated Fields
The following fields are still being recorded but will be removed in a future release:
- `aiAgentId` - Name of an AI agent used in the processing. Replaced by `aiAgentsUsed`, as multiple agents per processing can be used.
- `department` - Comma-separated list of the processor's departments. Replaced by `teams`, which lists this as a JSON array and is thus easier to process.
- `allTags` - Comma-separated list of all tags assigned to the ticket. Replaced by `tags`, which lists this as a JSON array and is thus easier to process.
- `email` - Email address of the processor. Alternatives can be the processor's name (`name`) or the user ID (`userId`).
- `rawData` - JSON string of the `rawData` value of the ticket/message. No longer necessary as the messages can be uniquely identified via `ticketId` and `conversationId`.
---
## Authorization
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/authorization
**Description:** Learn how to authenticate with the Enneo API
To obtain an authorization token for the use of the Enneo API, API users have the following options, depending on the use case.
### 1. User-JWT-Token for development
Users can generate a personal access token by navigating to their profile page and clicking on the "Create API Key" button. It is important to save this key, as it will only be displayed once.
### 2. Service Worker JWT-Token for periodic tasks
A Service Worker token can be used by selecting an existing Service Worker or creating a new one in the settings → Users → Service Worker. Once a Service Worker is chosen, users can generate an API key by clicking on the "Create API Key" button. It is crucial to save this key, as it will only be displayed once.
These tokens will only expire if they are revoked or recreated on the Users → Service Worker page.
### 3. OAuth2 Session Token
API Service Workers or users can log in with Single-Sign-On (SSO) credentials via the `/api/auth` endpoints to obtain a session token. The SSO backend, typically Microsoft Azure OAuth2 or Google OAuth2, then validates against Enneo. If the validation is successful, Enneo issues a session token valid for 24 hours that can be used as access data for API requests. This method is more complex and is typically used only in advanced infrastructure setups.
Remember to securely store and manage your authorization tokens to ensure the security and integrity of your API interactions.
### Using the Token
Once you have the token, it can be passed as a Bearer token in the header, as in this example:
```bash
curl --header 'Authorization: Bearer eyJhbGciOiJI...' \
'https://demo.enneo.ai/api/mind/ticket/6'
```
---
## OpenAPI specification
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/endpoints
**Description:** Machine-readable API definition
The API reference is generated from the OpenAPI specification of the Enneo Mind API.
---
## Introduction
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/introduction
**Description:** Introduction to the Enneo API
## Enneo API Documentation
The Enneo API offers a series of endpoints for importing/manipulating tickets, user management, tag management, and ERP interaction. This documentation outlines the typical use cases and provides details on how to interact with each endpoint.
The complete API specification can be found in Swagger format here, including data structures, return formats, and examples. This is ideal for developers.
### Importing/Manipulating Tickets
The Enneo API allows importing and manipulating tickets. New tickets can be created, existing ones updated, and ticket information can be retrieved. The available endpoints for ticket management are:
* `POST /tickets`: Create a new ticket
* `PATCH /ticket/{id}`: Update an existing ticket, e.g., by assigning contracts or changing the status
* `GET /ticket/{id}`: Retrieve a ticket based on its ID
### Tag Management
With tags, data in the Enneo system can be categorized and organized. The API allows managing tags by creating, updating, and retrieving tag information. Tags can be capabilities, but also products or brands. The endpoints for tag management are:
* `POST /tag`: Create a new tag
* `GET /tag`: List all tags
* `GET /tag/{id}`: Retrieve tag information based on the ID
### ERP Interaction
The Enneo API also supports integration with ERP systems, enabling the searching and retrieving of customer information. The following endpoint is available for ERP interaction:
* `GET /erp/customers`: Search and retrieve customer information
Please refer to the Enneo API documentation for detailed information on request and response formats, authentication, and error handling.
### User Management
For user management, Enneo uses a different API specification that originates from the authorization microservice. Please refer to this documentation for further information:
---
## Smart-Routing
**URL:** https://richard-dev-playground.enneo.ai/docs/en/routing-and-tags/autopilot
**Description:** Prerequisites and operating principle
### Prerequisites
In order for Smart Routing to be activated, skills and/or channels (email, letter, etc.) must be stored for the user, e.g. Meter reading and bank details.
### Operating principle
Smart Routing assigns the tickets to the agent automatically, matching his/her skills. Depending on the routing option, assignment is primarily by due date and/or priority.
### Essential information
If the routing option [`Last-Agent-Routing`](/docs/de/routing-and-tags/routing-options) is activated, the system automatically assigns the last agent when a ticket is closed. Should the customer respond again, the same agent receives the ticket.
If, however, a [lengthy absence](/docs/en/user-management/configure-users#longer-absence) is listed for this individual, the routing ignores this rule and routes the ticket to a team member or another user with corresponding skills.
---
## Access restriction in ticket backlog
**URL:** https://richard-dev-playground.enneo.ai/docs/en/routing-and-tags/backlog-access-restriction
**Description:** Application examples and configuration
### Example
A service provider handles customer service for several municipal utilities, including **Stadtwerke Voltlingen** and **Stadtwerke Stromhain**. The service provider uses the same **Enneo instance** for both utilities. The team **"Stadtwerke Voltlingen"** should only see tickets from Stadtwerke Voltlingen.
1. In the **team settings**, **Restrict displayed tickets by tags** is activated.
2. For **Necessary tags for ticket display**, the tag `Client: Stadtwerke Voltlingen` is selected.
**Result:** Only tickets with the tag `Client: Stadtwerk Voltlingen` are displayed in the **backlog** and considered by the **autopilot**. The tickets from Stadtwerke Stromhain remain completely hidden from this team.
### Effect of the limitation
The access restriction only affects the **ticket overview** or the **backlog** and the **smart routing**. **Users**, who inherit their settings from the team, automatically adopt the **restrictions** set there.
The following are **not** restricted:
* Search function in ticket and ticket overview
* Ticket history in the ticket
* direct URL calls of tickets
### System Configuration
1. Activate restriction for a team or a user
- Under `Teams or User Management`
- Activate setting: "Restrict displayed tickets by tag"
2. Set tags
- Field: "Necessary tags for ticket display" and/or "Excluded tags for ticket display"
- Select desired tags
### Best Practices
- The use of tag structures should be clear and consistent, for example `Client_X` or `Project_Y` to facilitate maintenance, evaluation, and error analysis. A variety of categories are available in the [General Tags](/docs/en/routing-and-tags/configure-tags#types-of-tags).
- Access restrictions should be used to clearly depict responsibilities and protect sensitive data. It is not a substitute for role or rights concepts.
---
## Tag Configuration
**URL:** https://richard-dev-playground.enneo.ai/docs/en/routing-and-tags/configure-tags
**Description:** Types, detection methods, and other options
Tags allow for precise organization and automated assignment of tickets. They can carry various attributes and be flexibly used for controlling the routing.
They are created in the `Settings → Skills & Routing` section. They can be organized hierarchically here to ensure structured classification.
### Types of Tags
Tags are the basis for ticket categorization. They allow for classifying tickets according to various criteria. The following types of tags are distinguished:
**Skill Tags**
These tags represent specific skills or areas of expertise such as billing or switching. If they are stored with an employee, tickets with these skill tags are automatically routed to the appropriate agents or teams.
**General Tags**
In addition to the skill tags, which refer to the capabilities of employees, there are more tag categories available. These tags allow tickets to be flexibly structured, labeled, and used for automatic distribution:
### Automatic Tag Assignment
Different detection methods are offered to assign certain tags to incoming tickets. The configuration of these assignment rules is done per tag. The following methods are available:
### Additional Configuration Options
Additional settings allow for even more precise control:
---
## Overview
**URL:** https://richard-dev-playground.enneo.ai/docs/en/routing-and-tags/routing-in-enneo
**Description:** Automated classification and distribution of customer inquiries
Enneo's smart routing ensures that incoming tickets are automatically
classified and distributed to the appropriate employees or teams. AI,
rules, skill-based assignment, and SLAs interact in this process –
across all channels, consistently.
## Introduction videos - Routing in Enneo
## Tags – specialized structure for every ticket
Every incoming request in Enneo is automatically assigned one or more tags.
These tags give a ticket a specialized meaning and form the basis
for all further decisions in the system. They can represent the following attributes:
* Fields of expertise and responsibilities
* Products
* Organizational units or brands
* Customer and contract characteristics
* Internal processes or workflows
In addition, tags can be configured with central attributes:
* **Visibility:** determines whether a tag is visible, limited visible, or
disabled
* **Priority:** influences the routing order
* **Complexity:** controls the weighting in case of multiple recognition
* **SLA:** defines processing deadlines
* **Routing relevance:** Inclusion or exclusion from skill matching
The recognition occurs automatically – by AI, rule-based conditions (ticket,
customer or contract properties), channel or sub-channel assignment or a
combination of these.
Tags are managed in the `Settings → Skills & Routing` section.
## Routing – targeted distribution based on tags
Based on the set tags, Enneo automatically decides which team or
employee an inquiry is forwarded to. The assignment factors in
several factors:
* **Skill Matching:** Matching between ticket tags and the stored skills of the
employees
* **Backlog Access:** Control which tickets employees can see or process
* **Order of Assignment:** Prioritization according to configurable sequence
(e.g. priority, SLA, first or last customer message)
Routing is configured in the section `Settings → Skills & Routing`.
## The Interplay
The classification through tags forms the basis for smart routing. The result
is comprehensible, scalable processes: decisions arise not situationally,
but based on clearly defined logic – without manual interventions.
The interplay of these two concepts goes beyond classic forwarding rules:
requests always land with the right contact person through precise **skill matching** – without manual pre-sorting. **SLAs** can be fixed per tag, and the **Smart routing** takes into account absences, priorities, and deadlines. This makes work fair and efficient. And thanks to **AI detection**, the
system automatically sets the right tags – even if the customer does not
explicitly mention their issue.
The following articles explain the configuration in detail: from SLAs and working hours
over routing options to tag configuration and the smart routing.
---
## Routing Options
**URL:** https://richard-dev-playground.enneo.ai/docs/en/routing-and-tags/routing-options
**Description:** Types and Areas of Application
The following settings define the basic control logic of **smart routing** for **automatic ticket assignment**. They control which tickets are prioritized, which **processors** are considered, and whether existing **processor responsibilities** are maintained.
Together, these options form the framework for ticket distribution in everyday operations - especially in the interplay of **prioritization**, **skill matching**, and **processing continuity**.
The configuration allows targeted adaptation to organizational requirements, for example with regard to **SLA compliance**, **team specialization** or consistent support of ongoing customer concerns.
### Distribution sequence
The distribution order determines the criteria used to decide which ticket is next offered to a processor. Each option consists of a primary and an optional secondary criterion (tiebreaker in case several tickets have equivalent primary criterion).
The possible sorting options and their effects:
- **Priority** — Each tag may carry a priority level: `urgent`, `high`, `medium`, `low`. This is transferred to the ticket at the time of tagging. Tickets with a higher level come first. If several tickets have the same level, the secondary criterion decides.
- **SLA Due Date** — If a tag is configured with an SLA deadline, the system calculates a due date from it based on the creation date and business hours. Tickets without an SLA configuration are systemically considered "due on 31.12.2099" — they are always put at the end of the queue in SLA-based modes, regardless of age.
- **Last customer message** — Time of the most recent incoming customer message. If there isn't one (e.g., for internally created tickets), the creation date is used instead.
The four configurable modes in detail:
**1. By SLA expiry date**
Only one criterion: due date ascending. The ticket with the next SLA deadline is distributed first.
Tickets without an SLA end up at the end of the queue — regardless of how old they are.
**2. Highest priority first — in case of a tie by SLA due date**
Primary: Priority (urgent > high > medium > low). Secondary: due date ascending.
Within the same priority level, it is decided which ticket is due first.
Tickets with a low priority but short SLA are never distributed before tickets with a high priority — even if they are already overdue.
**3. Highest priority first — in case of a tie by last customer message (LIFO)**
Primary: Priority. Secondary: Latest customer message, descending.
With the same priority, the ticket in which the customer last wrote will come first. Older tickets of the same priority level are pushed further back as more new ones arrive.
**4. Highest priority first — in case of a tie by earliest customer message (FIFO)**
Primary: Priority. Secondary: Latest customer message, ascending.
At the same priority, the ticket in which the last customer message was the longest time ago is distributed first — classic queueing principle within a priority level.
### Tag Matching
This setting determines how strictly the skill match between ticket processor and ticket is checked during automatic routing.
**ALL** — A ticket is only offered to a processor if they possess all of the ticket's tags as their skill. This ensures accurate coverage of competencies, but may significantly decrease the distribution rate if tickets carry multiple specialized tags.
**AT LEAST ONE** — It is sufficient for the processor to possess at least one of the ticket's tags as their skill. This broadens the range of processors considered, making distribution wider, but less targeted.
The choice between the two modes depends on team structure: small, generalist teams often benefit from AT LEAST ONE TAG, while specialized structures with clear responsabilities tend to benefit from ALL TAGS.
### Last-Agent-Routing
If activated, upon a renewed customer response to an already processed ticket, an attempt is made to reassign the same ticket to the last responsible processor. The goal is continuity in processing, without requiring manual effort.
In the case of absence of the processor, a manual reassignment is necessary, unless there is a deputy registered in the user profile. The configuration of the absence is done in `UserAdministration → User → Personal User Profile`.
---
## SLAs and Working Hours
**URL:** https://richard-dev-playground.enneo.ai/docs/en/routing-and-tags/slas-and-working-hours
**Description:** Options and Setup
### Define Working Hours
The specified working hours and holidays form the basis for the calculation of SLA deadlines. They are defined in the `Routing and Tags → Working Hours` section.
### Service-Level Agreements (SLAs)
SLAs (Service-Level Agreement) define the expected processing time for a customer request. They are central to routing, prioritization, and service quality monitoring, and are defined in the tag.
Examples:
* Customer Emails: 8 hours (within an 8-hour workday)
* Market communication issues (blocking): 4 hours
* Other market communication issues: 32 hours (4 working days)
* VIP customers: 2 hours
* Letters: 40 hours (5 working days)
The definition of such SLAs enables the efficient forwarding and monitoring of service quality. By prioritizing tickets according to their SLAs, customer requirements can be met and a pleasant customer experience can be ensured.
---
## Glossary
**URL:** https://richard-dev-playground.enneo.ai/docs/en/faq/glossar
**Description:** Glossary
### **A**
**Anonymization Process**
A procedure within Enneo that ensures sensitive customer data in tickets and communications are rendered unrecognizable to comply with data protection policies.
### **B**
**User Management**
A module in Enneo that allows administrators to create user accounts, assign roles and manage access rights within the platform.
### **C**
**Customer Relationship Management (CRM)**
A system or strategy for managing and analyzing customer interactions, often integrated with Enneo.
### **D**
**Dark Processing**
A process in which AI agents fully automatically handle customer inquiries without the need for human intervention.
### **E**
**Events and Webhooks**
Mechanisms that allow responses to specific events within the Enneo platform and notify external systems in real time.
### **F**
**Free Text Analysis**
A method in which AI or rule-based logic is used to analyze and classify unstructured texts in customer inquiries.
### **K**
**AI Agents**
Artificial intelligence within Enneo that analyzes customer inquiries and provides automated responses or actions based on predefined rules and learning algorithms.
**Customer Recognition**
Features in Enneo that allow customers to be identified based on their data and their inquiries to be assigned accordingly.
**Customer Satisfaction Score (CSAT)**
An indicator for measuring customer satisfaction, often obtained through feedback at the end of a ticket processing.
### **P**
**Partner Integration**
Enneo's ability to connect with external partner systems to exchange data and synchronize processes.
### **R**
**Rule-based Logic**
An approach within Enneo in which predefined rules are used to make decisions and perform actions based on certain conditions.
**Routing and Tags**
Features that allow incoming tickets or inquiries to be automatically assigned to certain teams or categories, based on defined tags or criteria.
**Response Time**
The span of time that passes between the receipt of a customer inquiry and the first response.
### **S**
**SDK (Software Development Kit)**
A toolkit that provides developers with tools and documentation to create their own applications or integrations with the Enneo platform.
**SLA (Service Level Agreement)**
An agreement on the expected response and resolution time for customer inquiries, often configured in Enneo.
**Smart Argumentation Logic**
A feature of Enneo that enables AI agents to effectively handle complex customer inquiries through logical conclusions and context understanding.
### **T**
**Templates**
Predefined blocks of text that can be created in Enneo to ensure consistent and fast responses to frequent customer inquiries.
**Ticket Processing**
The process of receiving, categorizing, processing, and closing customer inquiries within the Enneo platform.
**Ticket Status**
The current state of a ticket, e.g. "New", "In Process", or "Completed".
**Transparent Forwarding**
A feature that allows a ticket to be forwarded to another department without the customer noticing.
### **W**
**Knowledge Management**
The collection, organization, and provision of relevant information to efficiently answer customer inquiries - often via the Wiki or FAQ section in Enneo.
**Workflow Automation**
A mechanism that automatically executes certain processes in Enneo, based on defined rules or triggers.
**Wiki**
An integrated knowledge management tool in Enneo that allows teams to centrally store and manage information, instructions, and FAQs.
---
## Overview
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/overview
## System Integration
System integration refers to all technical connections whereby Enneo communicates with existing systems, uses relevant data, and can execute cross-system processes. This makes Enneo part of the existing system landscape and can support processing, automation, and information exchange in existing structures.
## [Contact Channels](/docs/en/system-integration/integration-of-contact-channels/contact-channels-overview)
Contact channels establish the connection between external customer inquiries and Enneo and transfer incoming messages into the ticket system. This creates the basis for processing and automation.
## [Customer Recognition](/docs/en/system-integration/customer-recognition/flow)
Customer recognition links incoming tickets with customer and contract data and enables a technically correct, context-related processing. These data become available through the connection of ERP or CRM systems.
## [Events and Webhooks](/docs/en/system-integration/events/concept-of-events-in-enneo)
Events and webhooks transmit relevant events from Enneo to external systems so that processes can be stored there, further processed, or used to trigger their own actions.
## [User-Defined Code](/docs/en/system-integration/user-defined-functions-tools/user-defined-functions-in-enneo)
User-defined code enables customer-specific logics and sequences that go beyond standard configurations and represent project-specific requirements.
---
## Anonymization Process
**URL:** https://richard-dev-playground.enneo.ai/docs/en/legal/anonymization-process
**Description:** Anonymization Process
### 1. Anonymization Process Procedure
At the beginning, a highly advanced language model (LLM) is implemented, a form of advanced artificial intelligence. This model is specifically trained to efficiently analyze large quantities of text. It reliably recognizes patterns that indicate personal information in customer e-mails, such as names or contact details. Continuous updates and improvements ensure that the LLM is always up to the latest data protection standards and operates effectively.
### 2. Identification of Personal Data
The LLM thoroughly scrutinizes each email and identifies personal data such as names, addresses, telephone numbers, and email addresses. It uses advanced algorithms to recognize structures and patterns typical of such sensitive information. This step is crucial to ensure that no personal data remain unprotected.
### 3. Substitution with Null Values
Upon identification, personal data are replaced with neutral values such as "xxxx xxxx". This process is carried out twice to ensure maximum security. This ensures that the original data cannot be reconstructed, guaranteeing a high standard of data protection.
### 4. User Interface and Manual Controls
A specially designed user interface permits secure access to the anonymized data. This interface is intuitively designed and allows employees to efficiently manage and monitor the data. Regular spot checks are carried out accordingly. These checks serve as quality assurance and ensure that the anonymization process is effectively and completely carried out. If necessary, corrections are made to uphold the highest data protection standards.
### 5. Data Protection and Security
The entire process is designed with a focus on the highest data protection and safety. The anonymization of customer data is a key component of our commitment to our customers' privacy. We ensure that personal information cannot be used or viewed unauthorized in any way. This process complies with the latest data protection regulations and practices.
---
## Data Processing Agreement (DPA)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/legal/avv
**As of: February 2026**
[📥 Download Document](https://admin.enneo.ai/api/files/get/public/AVV-Enneo-2026-02.pdf)
## Previous versions
- [DPA (As of: July 2025) - Download](https://admin.enneo.ai/api/files/get/public/AVV-Enneo-2025-07.pdf)
- [DPA (As of: June 2025) - Download](https://admin.enneo.ai/api/files/get/public/AVV-Enneo-2025-06.pdf)
---
## Data Flow Diagram
**URL:** https://richard-dev-playground.enneo.ai/docs/en/legal/datenflussdiagramm
**As of: November 2025**
[📥 Download Document](https://admin.enneo.ai/api/files/get/public/Datenflussdiagramm-Enneo-2025-11.pdf)
---
## Data Protection Impact Assessment (DPIA)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/legal/dsfa
**Date: November 2025**
[📥 Download Document](https://admin.enneo.ai/api/files/get/public/Datenschutzfolgeabschätzung-Enneo-2025-11.pdf)
---
## Declaration of Conformity for the EU AI Act & GDPR Compliance
**URL:** https://richard-dev-playground.enneo.ai/docs/en/legal/eu-compliance
**As of: November 2025**
[📥 Download Document](https://admin.enneo.ai/api/files/get/public/Declaration-of-Conformity EU-Compliance-Enneo-2025-11.pdf)
---
## Legal Information
**URL:** https://richard-dev-playground.enneo.ai/docs/en/legal
**Description:** All important legal documents for your Enneo experience at a glance
---
## Service Description
**URL:** https://richard-dev-playground.enneo.ai/docs/en/legal/leistungsbeschreibung
**Date: January 2026**
[📥 Download Document](https://admin.enneo.ai/api/files/get/public/Leistungsbeschreibung-Enneo-2026-01.pdf)
---
## Master Subscription Agreement (MSA) / Software-as-a-Service (SaaS) Agreement
**URL:** https://richard-dev-playground.enneo.ai/docs/en/legal/msa
**Date: January 2026**
[📥 Download document](https://admin.enneo.ai/api/files/get/public/MSA-Enneo-2026-01.pdf)
---
## Service Level Agreement (SLA)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/legal/sla
**Date: April 2026**
[📥 Download Document](https://admin.enneo.ai/api/files/get/public/SLA-Enneo-2026-04.pdf)
## Previous Versions
- [SLA (Date: January 2026) - Download](https://admin.enneo.ai/api/files/get/public/SLA-Enneo-2026-01.pdf)
---
## Technical and Organizational Measures (TOM)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/legal/tom
**As of: July 2025**
[📥 Download Document](https://admin.enneo.ai/api/files/get/public/TOM-Enneo-2025-07.pdf)
## Previous Versions
- [TOM (As of: June 2025) - Download](https://admin.enneo.ai/api/files/get/public/TOM-Enneo-2025-06.pdf)
---
## AI Agents
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ticket-processing/ai-functions
**Description:** Examples and Structure
**Here are a few examples:**
**Structured information display:**
Relevant customer data is presented in clear information fields. Context-related hints facilitate decision-making.
**Automated filling of parameters:**
Input fields are filled in by the AI and checked for plausibility. Manual adjustments can optionally be made.
**Automatic calculations and suggestions:**
Minimum or target values are calculated dynamically. Tips or warnings appear for unsuitable inputs.
**Context-related messages:**
Implausible inputs or critical deviations trigger direct tips or recommendations.
**Additional features:**
Automatic creation of documents such as billing or validation reports as needed.
**Calls to action:**
Buttons such as "Inform customer" or "Confirm" guide to the final processing.
**Flexible change management:**
Changes can be tagged with a fixed date. The impact on consumption or costs is immediately apparent.
---
## AI Response Proposal
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ticket-processing/ai-response-suggestion
**Description:** Information and Usage
---
## AI Text Assistant
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ticket-processing/ai-text-assistant
**Description:** Options and Application Areas
### **Application Areas**
The AI Text Assistant can be used in all areas where texts are captured or edited:
- When **answering** or **forwarding** customer requests
- When **writing private notes** within a ticket
- In the **creation of outgoing emails**
- When **setting up internal tasks**
### **Menu Items at a Glance**
* Transforms brief notes into complete, polite sentences
* Expands abbreviation, e.g. "contract partner" instead of "vn"
* Adapts tone, style, and sentence structure to customer communication
* Keeps the message while making the form professional
* Expands brief responses into complete, formulated sections
* Extends text to be longer, more understandable and binding without inventing new content
* Ideal when the original text is too brief or unbalanced
* Checks for spelling and grammar
* Translates into English and French
* Allows fine-tuning adjustments when standard responses do not exactly fit the situation
* Addresses divergent contexts, like legal writings, responses to third parties, or authorities
* Flexibly responds to requirements such as formal language, deescalating tone, or clear boundaries
* Saves time: the existing text is specifically modified, not rewritten
* Supports precise communication, even in exceptional situations or escalations
---
## Customer Identification
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ticket-processing/customer-identification
**Description:** Steps and Verification
Customers are identified by contract and/or customer number and email address. Depending on the requirement, other features, e.g. the meter number can also be integrated.
If no relation between the ticket and the customer can be established, an "**Unknown User**" and a **search field** are displayed.
---
## Deferral
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ticket-processing/reminders
**Description:** Pausing tickets deliberately and automatically returning them for further processing.
Not every ticket can be closed immediately. Sometimes information is missing from the customer, an external process needs to be completed, or processing is intentionally delayed for a later point in time. Deferrals systemically map exactly this situation: A ticket is temporarily paused and automatically made available for processing at a predetermined time.
### Status and Due Date
Deferrals are based on the interaction of two ticket attributes:
- **Status "pending"** – The ticket is active but not intended for immediate handling. It is not distributed by the smart routing.
- **Due By (`dueBy`)** – The point in time at which the ticket is automatically reset to "open". Specifying a due date is mandatory when setting the status to "pending" and it must be set in the future.
Both fields directly interlock: Without a due date, no ticket can be set to "pending". This prevents tickets that permanently fall out of the processing flow.
### System Behavior
As soon as a ticket is set to "pending", the following occurs in the system:
- The ticket is removed from the active distribution of smart routing – it does not receive an assignment as long as the status is "pending".
- An internal reminder is created that references the due date.
- An automatic process resets the status to "open" at the due date and releases the ticket for processing and smart routing.
- The system generates a `ticketUpdated` event with the flag `autoOpenedDueToDueDate: true`, which can be evaluated for external integrations.
If a ticket is manually set to "pending", the system marks the due date as manually set (`dueByWasSetManually`). Automatically calculated due dates - for example, through tag configurations - remain separately traceable.
### Use cases
**Waiting for customer feedback**
Information has been requested from a customer. Until a response is received, the ticket should not appear in the active inventory. With a due date – e.g., in five days – it automatically returns if no response has been received.
**Dependency on an external process**
A downstream process (e.g., system processing, consultation with a specialist team) must be completed before the ticket can be further processed. The deferral ensures that it reappears at the right time.
**Targeted date control**
A ticket should not be processed immediately, but at a specific date - for example, because a rate only applies from the next month or a contract period should be waited out.
### Impacts on Analytics and Time Recording
Setting the status to "pending" is reflected in the handling export as the handling category `statusAction` even if no response has been sent to the customer. This correctly reflects the activity of the processor in the AHT.
Tickets with the status "pending" appear in the ticket overview and can be viewed specifically using the status filter. This keeps the total stock transparent, even if tickets are not actively being processed temporarily.
### API Integration
Deferrals can be set and controlled via the Enneo API.
Requirement: `dueBy` must be specified and be set in the future. The reset to "open" is done either automatically by the time-controlled process or manually via the same endpoint with "status": "open".
```json
PATCH /api/mind/ticket/{id}
{
"status": "pending",
"dueBy": "2025-06-01 08:00:00"
}
```
---
## Ticket Overview
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ticket-processing/ticket-overview-filters
### Display
At a glance: the **mood** of the customer, **content** and **subject, priority, assignment**, and **status**. The view can **be sorted individually**.
The [**Filter**](/docs/en/ticket-processing/ticket-overview-filters#filter) allows for the specific retrieval of certain tickets across many criteria. The [Bulk Update](/docs/en/ticket-processing/ticket-overview-filters#bulk-update) allows targeted actions across multiple tickets.
### Filter
In addition to conventional filter functions, the filter offers additional features that go beyond the classic limitation of tickets.
### Bulk Update
The bulk update allows for the targeted and consistent changing of attributes of several tickets.
In day-to-day operations, it happens that an increased number of tickets on a certain topic are submitted and need to be prioritized for short-term processing.
To make sure that the priority is again dictated by the respective topic for renewed feedback, it is recommended to use a tag like "Temporary prioritized" with the appropriate priority.
This tag can be specifically added to the affected tickets, used for the duration of the prioritization, and then equally specifically removed again.
---
## Ticket Structure
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ticket-processing/ticket-structure-ai-components
**Basic ticket information**
The most important metadata is clearly displayed below the content, including subject, sender, recipient, and sending date.
**Interaction with the customer request**
The classical processing functions are available in the upper area, for example:
- Reply
- Forward
- Record internal notes directly on the ticket
**Wiki**
The wiki area allows direct access to **instructions and background information**. Navigation occurs either via the structure or via the search field.
For specific questions, **Neo** automatically summarizes the relevant content from matching articles. This saves time and provides a quick, clear answer without having to read individual articles.
In this way, status and due date interlock and ensure that waiting tickets return controlled to the processing process.
- **Agent**
If tickets are assigned to a specific agent, they are only offered to this agent in autopilot.
An exception is [longer absence](/docs/en/user-management/configure-users#longer-absence).
- **Further information**
ID, priority, and - optionally - the activity log
**Customer data**
This section shows the most important **master data** of linked customers. The displayed information can be individually expanded, for example:
- Contract and customer number
- Tariff, monthly down payment, and consumption
- possibly credit or open amounts
- Delivery address, e-mail, and delivery status
**History**
The history lists all further tickets of the customer including status, receipt date, and topic.
Depending on the configuration, relevant system events are also displayed, such as tariff changes or price changes.
If no customer is linked with the ticket, all tickets available to the sender address are listed.
---
## Ticket Creation
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ticket-processing/ticket_creation
**Description:** Types and Application Areas
### Outgoing message
Often it is useful and necessary to actively write to customers, e.g. to clarify in the registration process, to send a new tariff offer or to confirm something after a phone call. Such tickets appear in the ticket system as outgoing messages.
- Ticket status is by default "closed"
- Pre-set due date is "tomorrow"
- Dispatch can occur via the channels "Email" or "Letter", the channel requires an email address or postal address in the "To" field
### Internal process
For example, if a customer shares his concern in person on site, it can be documented as an internal process for the ticket system and thus remains traceable for everyone. The source of the internal process in this example is the "Customer center".
- Ticket status is by default "open"
- Pre-set due date is "tomorrow"
---
## Overview
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ticket-processing/tickets-in-enneo
Tickets are the central place where customer inquiries in Enneo are processed. Regardless of whether a request comes in via email, telephone, letter, chat, or through another channel, it is captured as a ticket and further processed there.
A ticket bundles all the information that is important for processing an operation. This includes messages, customer and contract data, responsibilities, processing status, documents, as well as information about routing, AI detection, and automation.
## Getting Started Videos - Tickets
## Complete Transparency in the Processing Process
A ticket not only documents the communication with the customer but also all steps, decisions, and evaluations that arise during processing. This makes an operation technically comprehensible and can be reviewed, evaluated, or further processed later.
Depending on the process and configuration a ticket includes among others:
- Customer and contract data
- Incoming and outgoing messages
- Attachments and documents
- Processing status, priorities and SLAs
- Tags, identified concerns, and process assignments
- AI results and automations
- Quality evaluations and evaluation results
- Activity log with processing steps and system events
- History of changes, handovers, and subsequent actions
This creates a complete view of the operation: Employees not only see *what* was communicated with the customer, but also *how* the ticket was processed, evaluated, forwarded, and/or automated.
## Cross-channel Communication
Enneo combines requests from different channels in a unified ticket view. This way, emails, phone calls, letters, chats, or other input channels can be consistently processed and comprehended.
This supports daily processing on several levels:
- Messages are fully documented on the ticket
- Processing statuses are always transparent
- Responsibilities and handovers remain comprehensible
- Automations can take effect regardless of the input channel
Cross-channel processing thus forms the basis for uniform service and process management.
## Automation and AI Support
Enneo can automatically analyze, classify, and prepare tickets for further processing. This reduces recurring tasks and supports employees during processing.
As soon as a ticket is received, various information can be recognized and processed:
- Identify concerns and assign to appropriate processes
- Tag or prioritize tickets
- Route tickets to appropriate teams or staff
- Automatically trigger standard processes
- Support employees in creating responses
This reduces manual effort, especially with high ticket volumes or standardized processes.
The following articles explain the individual areas in detail - from the structure of a ticket to communication and status to routing, automation, and AI support.
---
## Best Practices
**URL:** https://richard-dev-playground.enneo.ai/docs/en/user-management/best-practices
**Description:** Recommendations for structuring users, teams, and roles
The optimal allocation of employees to teams and thus to skills (for skill-based-routing) and roles (for permissions) depends on each individual case. Based on our experience, we would like to provide recommendations on how to construct such a structure. These recommendations are mainly intended for energy supply providers.
## Small Organizations (up to 15 employees)
In small organizations, it can be relatively straightforward to distribute roles and skills directly to employees with little complexity.
New agents are assigned to the "Agent" team, while all others (due to the low number) receive individually assigned roles.
### Roles
| Role | Tasks | Rights |
|------|--------|--------|
| Administrator | Performs all tasks, including the management of AI agents | (default role) |
| Team Leader | Manages users | User management |
| Agent | Performs administrative tasks | (default role) |
### Teams
| Team | Tasks | Skills | Rights |
|-------|-------|---------|--------|
| Clerk | Regular administrative work | Standard skills | Agent |
| Second Level A | Complex administrative work | e.g. NNA | Agent |
| Second Level B | Complex administrative work | e.g. MaKo | Agent |
| Temporary Teams* | One-time or special tasks | Temporary skills | Agent |
*Examples of temporary teams:
- Training team, staffed with employees to be trained and training skills for the duration of the training
- Task Force Spring Offensive, for the duration of a customer win-back campaign
Employees outside of clerical work are directly assigned their roles.
## Medium-Sized Organizations (15-100 employees)
For medium-sized organizations, a more differentiated structure is recommended, which already provides specialized roles but does not yet require the full complexity of large organizations.
### Roles
| Role | Tasks | Rights |
|-------|-------|---------|--------|
| Administrator | System configuration and maintenance | (default role) |
| AI Manager | Optimization and monitoring of AI agents | AI management |
| Workforce Manager | Resource planning and skill management | Team and user management |
| Quality Manager | Quality assurance and control | QM Rights, Monitoring |
| Team Leader | Team leadership and second-level support | Team Leader Rights |
| Agent | Administrative tasks | (default role) |
### Teams
| Team | Tasks | Skills | Rights |
|-------|-------|---------|---------|
| First Level | Standard inquiries | Basic skills | Agent |
| Second Level | Complex cases | Advanced skills | Agent |
| Specialists | Subject-specific tasks | Special skills | Agent |
| Management | Administrative tasks | None* | According to Role |
| Quality | Quality assurance | None* | QM Rights |
*Not necessary, as they are outside of administrative tasks
## Large Organizations (>100 employees)
Large organizations are characterized by a multitude of features that require a flexible and adaptable structure. Typical challenges of larger organizations include:
- Combination of first and second level teams for efficient processing of simple and complex inquiries.
- Integration of internal employees and various external service providers, often with a confined profile
- Variety of skills to cover all necessary competences.
- More finely assigned and granted access rights only when necessary
- Consideration of different brands and/or products
- Specialists from IT, quality assurance, and other areas working together in Enneo.
Unlike in small teams, where there is primarily a 1:1 assignment of an employee to a team, it is advisable in larger organizations to assign employees to multiple teams.
### Roles
The roles in large organizations are finely divided. For example, the following aspect can be suggested:
| Role | Tasks | Rights |
|------|-------|--------|
| Admin | Basic system configuration | (default role) |
| AI Manager | Optimizes AI agents | AI agents |
| Workforce Manager | Manages users, teams, and skills | User, Team, & Tag Management |
| Knowledge Manager | Manages the knowledge base (wiki) | Wiki |
| Reporting Manager | Manages the Enneo BI solution Superset | Reporting |
| Quality Manager | Checks employee quality | Agent + QM |
| Team Leader | Manages team, second-level support | Agent + Team |
| Agent | Administrative tasks | (default role) |
### Teams
It is advisable to set up a combination of different teams for different tasks to encapsulate complexity. Here, for example, a setup from up to three different types of teams is a good idea:
1. Technical teams to assign skills to clerks for skill-based routing
2. Role teams to give managing employees rights
3. Organizational teams to assign additional rights and/or skills and to keep track of where an employee is organizationally assigned, e.g. for external service providers or certain products
4. If necessary, temporary teams for projects or other special tasks, analogous to small organizations
### Technical Teams
| Team | Tasks | Skills | Rights |
|------|--------|---------|--------|
| Basic Front Office | Basic Front Office Topics | Billing, Termination, etc. | Agent |
| Second Level Billing | Complex Billing Cases | Special Billing | Agent |
| Customer Portal | Portal Care | Portal Skills | Agent |
### Role Teams
One team per role, as listed above. Employees are then not directly assigned a role, but through a team. This serves exclusively for overview, alternatively, you can of course also directly assign the role to the employees.
### Organizational Teams
| Team | Tasks | Skills | Rights |
|-------|-------|---------|--------|
| Contractor 1 | Assigned Skills | None* | Agent |
| Contractor 1 Subteam 1 | Specific tasks | Market communication* | Agent |
| Internal Team 1 | Internal processing | None* | Agent |
| Internal Team 1 Department A | Internal processing | None* | Agent |
| Internal Team 1 Department B | Internal processing | None* | Agent |
### Example Profiles
- **Fabian First-Level-Support**
- Teams: "Contractor 1 Subteam 1", "Basic Front-Office"
- Role: Agent
- Resulting Rights: Tickets
- Resulting Routing: Basic Front-Office Topics
- **Tamara Team Leader** - Teams: "Internal Team 1", "Team Leadership", "Second Level Billing", "Customer Portal"
- Role: Team Leader
- Resulting Rights: Tickets and access to the Analytics Portal
- Resulting Routing: Second Level Billing, Customer Portal Topics
- **Karin K.I.**
- Team: "AI Manager"
- Role: AI Manager
- Resulting Rights: AI Performance Optimization
### Practical Tips
1. **Skill Assignment**
- Starting at a certain organizational size, skills should primarily be assigned through teams and only in individual cases.
- Regular check of the skill distribution
- Assign new skills only after successful training
2. **Team Management**
- Establish clear naming conventions for teams
- Regular review of team structures
3. **Role Administration**
- Minimalist principle in granting rights
- Regular review of role assignments
- Check by a secondary user, for example in the test system
---
## Users
**URL:** https://richard-dev-playground.enneo.ai/docs/en/user-management/configure-users
**Description:** Concept, creation, and personal profiles
### Creation and configuration
A new user can be added in the `User Management → Users and Teams` section.
* User profiles always include the name, email, and a [role](/docs/en/user-management/roles-and-permissions) that governs the user's permissions and access.
* Assigning a [team](/docs/en/user-management/teams) is optional. However, it simplifies management, as properties like skills and channels only need to be defined once per team, and not for each user created. This minimizes potential errors, ensures clarity, and efficient workflows.
### Personal user profile
* In their own user profile, users can set their status:
- **Ticket handling**: User is working on a ticket; time tracking is active
- **Break**: Screen is locked, user is taking a break
- **Support**: User is in a meeting, supporting a colleague, etc., action buttons in the ticket are grayed out, time tracking is deactivated
- **Longer absence**: User is sick or on vacation, screen is locked, time tracking is deactivated
Further information on the topic of "status" can be found in the [Users Status](/docs/de/analytics/worklog#user-status-status) section.
* Through their own user profile, they can manage the language setting of the user interface and the assignment of a new password.
### Longer Absence
In case of a longer absence of an employee, such as due to vacation or sickness, an absence can be recorded in the user management. The autopilot then ensures that responses to his last handled tickets are automatically assigned to other users.
For the display, a new entry is created in the `Advanced Settings → General → "Time Tracking"` section:
**1. Enter basic data**
- **ID:** `absent`
Example:
- **Label:** `Longer absent`
- **Long Label:** `Absent for an extended period`
- **Description:** `Longer absence, e.g., vacation or illness. During this time, own tickets are routed to colleagues.`
- **Icon:** `/icons/holiday.svg`
**2. Configuration**
| Setting | Value |
|--------------------------------|-------:|
| Automatic Active Mode | OFF |
| Include in Processing Time | OFF |
| Available for Chats | OFF |
| Available for Calls | OFF |
| Block Writing Actions | OFF |
| Support Mode | OFF |
| Blocked Interactions | ON ✅ |
| Automatic Absence Mode | OFF |
| Hidden | OFF |
**3. Save**
After creating the entry, a longer absence can be recorded both in the own profile and in the user management.
---
## Roles
**URL:** https://richard-dev-playground.enneo.ai/docs/en/user-management/roles-and-permissions
**Description:** Types and Explanation
Roles and permissions in Enneo control which actions users can perform and what data they can access. A clear role structure ensures security and efficiency.
### Basic Roles
Using the basic roles as a starting point simplifies the creation of individual roles and ensures a consistent permission structure.
* **Admin**: The admin role provides comprehensive administrative rights, including creating and managing users, teams, and roles. Administrators can view and manage all tickets and reports, configure AI agents and dark processing, and maintain the wiki, tags, and templates. They also have access to system settings, user profiles, and analytical data and can adjust role and permission concepts.
* **Agent**: The agent role includes processing and managing conversations and tickets. Agents can also execute and edit intents, have access to selected reports, and can see their own time tracking. Viewing and managing a ticket overview as well as forwarding tickets are also part of their tasks. Agents in the basic role do not have access to administrative functions.
### Individual Roles
Individual roles can be created as needed and are based on one of the basic roles. They can be extended or restricted with permissions. Examples:
* **Team Leader**: Manages team members, edits user profiles and can assign them to teams, gains insight into time and performance reports of his team, does not handle tickets, but has full access to them.
* **Knowledge Manager**: Maintains the knowledge database, can create, update and archive content, and ensures that all users can always access the latest information.
---
## Teams
**URL:** https://richard-dev-playground.enneo.ai/docs/en/user-management/teams
**Description:** Use, Structures, Administration, and Permissions
### Use
For instance, teams ensure that the right users receive appropriate tickets and enable clear organization of responsibilities.
Specific skills and communication channels can be assigned to a team, allowing targeted routing of customer concerns to qualified employees.
### Team Structures
In addition to regular teams, sub-teams also offer various application possibilities: from specializations on complex topics to training environments for new employees. Graduated responsibilities can significantly improve service quality and efficiency. Here are two examples:
**1. "Contract Termination" Team**
- The "Contract Termination" team has Skills "Cancellation", "Relocation", and "Revocation", with channels "Email", "Chat", "Telephone", and "Letter". All users in this department receive tickets for these topics in Autopilot.
- The sub-team "CT-Death" has the Skill "Death" in the same channels. It is specialized in handling this sensitive special case during contract termination appropriately.
**2. "Contract Framework" Team**
- The "Contract Framework" team has Skills "Documents", "Customer Portal", "Address Change", and "Contract Details", with channels "Email", "Chat", "Telephone", and "Letter". All users in this department are assigned tickets in Autopilot that match these attributes.
- The sub-team "CF-Training" has the same skills, but only the channel "Email". It consists of new employees who deepen their technical knowledge by processing written customer inquiries before they are used in real-time channels like phone or chat.
### Data Availability
Access to analytic data can also be managed for each team. This can be helpful for a "Supervisor" team that evaluates the performance of agents or a "Contract Termination" team that does not need any access to analytic data.
### Assignment of Roles and Permissions
Each team is assigned an individual or base role, regulating the access rights of the team members clearly.
### Routing and Rights
On the team level, routing configurations such as skills, assigned channels, and access rights per role assignment can be configured.
Only when the _Adopt team settings for routing and access rights_ setting is active at the user level are these applied to the employee. In this case, the team settings apply, not the user settings anymore.
Here is the completed Markdown description including a table with three meaningful examples from the customer service context:
If a user is assigned to several teams, the following rules apply:
- Routing settings: Employee receives the sum of all team settings (Cumulation of skills/tags and channels).
- Role selection: Employee receives the stronger role, i.e., the role with the highest absolute number of permissions.
| User | Teams | Team Roles | Team Skills | Team Channels | Result (User Settings) |
|----------|---------------------|----------------------------------------|----------------------------------------|-----------------------------------------------|----------------------------------------------------------------------------|
| User 1 | experts, agents | experts: admin; agents: agent | experts: [tech]; agents: [order] | experts: [Email]; agents: [Chat] | Role: admin; Skills: [tech, order]; Channels: [Email, Chat] |
| User 2 | social, backoffice | social: supervisor; backoffice: editor | social: [community]; backoffice: [invoice] | social: [System]; backoffice: [Email] | Role: supervisor; Skills: [community, invoice]; Channels: [System, Email] |
| User 3 | hotline, vip | hotline: agent; vip: power-user | hotline: [entry]; vip: [vip] | hotline: [Phone]; vip: [Email] | Role: power-user; Skills: [entry, vip]; Channels: [Phone, Email] |
---
## Overview
**URL:** https://richard-dev-playground.enneo.ai/docs/en/user-management/user-management-in-enneo
The user administration in Enneo controls who works in the system, which functions can be used, and how organizational responsibilities are represented.
Users, teams, and roles intertwine and form the foundation for collaboration, access, and responsibilities in daily operations.
## Introduction in Videos
## User as the Basis for Collaboration
Each employee works in Enneo via a personal user profile. This profile connects the person with organizational information such as teams and roles.
It controls:
- which functions can be used
- which areas of the system are visible
- what responsibilities a user undertakes
- how actions in the system can be traced
Users and teams are managed in the area `Settings → User Administration → Users and Teams`.
## Teams and Organizational Responsibilities
Teams represent the organizational structure within Enneo. For example, they can represent departments, locations, or service providers.
The team structure influences among other things:
- collaboration in daily operations
- visibility of tickets
- organizational responsibilities
- distribution of work
## Roles and Permissions
Roles define which functions a user can use in Enneo. For example, they control access to settings, administrative areas, or special system functions.
This way, it is clearly determined which responsibility individual users take within the system.
Roles are managed in the area `Settings → User Administration → Roles`.
## The Interaction
User administration in Enneo combines organizational structure and permissions:
- Users define who works in the system
- Teams represent organizational responsibilities
- Roles control access to functions
Together, these elements ensure that employees can use exactly those areas and functions that are relevant for their tasks.
---
## Ask Neo
**URL:** https://richard-dev-playground.enneo.ai/docs/en/work-resources/ask-neo
**Description:** Functionality and Application
### Functionality
Users have the choice between two search methods:
1. **Classic Search** – A list of relevant articles is displayed.
2. **Ask Neo** – The AI processes the search query and generates an answer based on Wiki contents.
To start a search, a question is entered into the search bar. Neo understands complete questions in natural language, such as:
*"How do I handle a move?"*
First, a list of matching articles appears. Users can either select an article directly or click on "Ask Neo" to receive an AI-generated answer.
"Ask Neo" searches all articles in the Wiki, regardless of whether they are publicly accessible or internally accessible only. The most important information is summarized and presented as a comprehensible answer. If an article contains detailed instructions, these will be displayed in a structured manner.
### No search results?
If Neo cannot generate a suitable answer, the following alternatives are available:
* Users can return to the classic article search.
* The question can be reformulated or made more precise.
* If a topic is not documented in the Wiki, Neo cannot generate an answer. Creating new content in the Wiki ensures that the information will be available in the future.
### Function Frame
* Neo only accesses the Wiki and does not search any other data sources.
* If a topic is not documented, Neo cannot provide information.
* The AI cannot draw independent conclusions but is based entirely on existing Wiki content.
---
## AI-Wiki
**URL:** https://richard-dev-playground.enneo.ai/docs/en/work-resources/create-and-edit-articles
**Description:** Articles, Website Connector, and Files
### What is a Knowledge Source?
A knowledge source is a single valuable knowledge entry in the AI-Wiki.
It can be created in different ways:
* as a manually created article
* as content from an externally connected source, for instance, via a website connector
* as an uploaded file through the Files-connector
**Manually created articles** are suited for content that should be consciously formulated and technically reviewed. This includes operating instructions, frequently asked questions, process descriptions, internal guidelines, or binding formulations.
**Externally connected sources** are suitable when already existing content should be utilized regularly. These can, for example, be help centers, documentation pages, or public information pages.
**Files** are suitable for existing documents that should be centrally provided and made accessible for AI-supported functions, such as PDF documents, operating instructions, or technical documents.
### Why Structure is Important
Knowledge in the AI-Wiki is not only stored but also cataloged. For this purpose, **groups and classifications** are used.
**Groups** form the thematic structure. They aid in making content discoverable and bundling technically related information.
**Classifications** describe the type of content. This distinction is important because different types of content are used differently:
* An **FAQ** answers a specific recurring question.
* An **operating instruction** describes a procedural sequence.
* A **document** contains background information or binding regulations.
* **News** informs about current changes and appears on the homepage.
If these types of content are cleanly separated, the knowledge stock remains easily verifiable. At the same time, AI functions can better classify the content.
### Website-Connector
The Website-Connector connects an external website to the AI-Wiki.
Path in Enneo: Tools → AI-Wiki → Sources
During the crawl, Enneo reads the linked website and adopts suitable content as knowledge entries. These then appear in the knowledge structure.
A connector is controlled via several settings:
* Source URL
* Include paths
* Exclude paths
* Maximum page number
* Frequency for re-crawling
The source URL defines which website is linked.
Include paths determine which areas of the website should be taken into account. Exclude paths exclude areas that are not relevant. These can be, for example, login pages, privacy policy pages, impressum, blog areas, or technical survey pages.
Examples:
* /help/* includes contents in the help area.
* /faq/* includes FAQ pages.
* /login/*, /privacy or /impressum can be excluded.
The maximum page number limits the scope of the adopted content. Crawling frequency determines how regularly Enneo re-reads the source.
The connector technically provides content. However, it doesn't evaluate whether this content is technically suitable. This examination remains part of the editorial responsibility.
### Crawling and Up-To-Dateness
During the crawl, content is read from the external source and made available in Enneo. The connector displays a status, for example, running, completed, or faulty.
Re-crawling updates the adopted content based on the current connector configuration. This can incorporate changes on the external website into Enneo.
If include or exclude paths, the source URL, or other connector settings are changed, the source could be crawled or processed again so that the changes take effect.
At the same time, the quality of the outcome depends on the external source. If URL structures, navigation, or website content change, the knowledge structure in Enneo can also change.
For stable results, connectors should be configured as precisely as possible. A narrowly limited source is easier to check and usually delivers better results than a very broadly linked website.
### Files as Knowledge Sources
In addition to manually maintained articles and linked websites, files can also be used as knowledge sources in the AI-Wiki.
Path in Enneo: Tools → AI-Wiki → Sources
The Files-Connector is used to centrally provide technically relevant documents and to make them accessible for AI-supported functions. Uploaded files are processed, transformed into knowledge entries and can then be considered in suggested responses, chat contexts, or AI agents, provided they are approved for this.
Files can be uploaded using drag-and-drop, structured in folders, managed, and if necessary, checked in the preview. A clear folder structure helps maintain comprehensible larger knowledge stocks and later check them specifically.
Files should not be used as unchecked storage. What's critical is that the content, file name, and storage location are technically clear.
If the content of a file changes, the knowledge source must be reprocessed so that the updated content becomes effective in the system. The re-indexing ensures that not only the file itself, but also the search and AI contexts derived from it, are up to date.
As with website connectors, the connector technically provides content. The technical responsibility for accuracy, timeliness, approval, and structure remains with the responsible users.
### Manage, Edit, and Reprocess Files
Inside the Files-Connector, files and folders can be managed. Depending on authorization, users can upload files, move them, check them in the preview, replace, edit, or archive them.
For files, the following actions are available, among others:
* Upload file
* Open file in preview
* Replace file
* Edit file, if the format supports this
* Re-index file
* Reset file to the original state
* Archive or restore file
If a file has been edited directly in Enneo, this could be visible through an appropriate marking. This marker helps to recognize that the currently used content may not exactly match the originally uploaded document.
#### Refresh
With **Refresh**, a file is reprocessed. This action is useful when content for knowledge search or AI-supported functions should be updated.
The file is then prepared again for search and AI contexts. This is relevant, for example, when a file was replaced or when the processing should be deliberately triggered again.
#### Reset to Original
With **Reset to Original**, a manually edited file is reset to the originally uploaded condition.
This action is useful when manual changes should be discarded or when the original content of the file should be used as a basis again.
### Files and Media in ArticlesArticles can be supplemented by uploaded media. This includes images or videos, for example.
Media is useful when it makes a technical statement clearer. This applies to form examples, process presentations or screenshots of certain states.
It is important to note that media should supplement the text, not replace it.
For AI-supported functions, the written content remains particularly relevant. Text can be precisely searched, processed and adopted into response contexts. Therefore, critical information should always be included in the article text and not contained solely in a screenshot or video.
### Visibility for AI Functions
The setting 'Make Knowledge Source Publicly Available' controls whether a knowledge source can be used for AI-supported functions.
If a knowledge source is released, it can be considered, for example, in response suggestions, chat contexts or AI agents.
If it is not released, it remains primarily part of the internal documentation in the AI wiki.
This setting is technically relevant. A released knowledge source can influence the results of AI functions. Therefore, only contents that are checked, current, and clearly formulated should be released.
Contents that are confidential, outdated, incomplete, or technically ambiguous should not be released.
### Use in Ticket Context
Knowledge sources can be used in the ticket context if they are released for AI functions and technically relevant.
Enneo can draw on suitable content from the AI wiki to support response suggestions, chat responses, or AI agents. Furthermore, relevant knowledge content can become visible in the work context of a ticket, enabling users to find suitable information more quickly.
Whether a knowledge source is actually considered depends, among other things, on content, release, currentness, and technical relevance.
### Impact on AI Agents
AI agents can use knowledge sources as context if they are accessible and technically relevant.
The quality of the agent results strongly depends on the quality of the knowledge stock. Ambiguous formulations, contradictory articles or untested connector contents can lead to inaccurate results.
Therefore, the AI wiki is more than just a repository for information. It controls what knowledge is available to the AI and how this knowledge is technically classified.
A well-maintained AI wiki improves the traceability and stability of AI-supported processing. In contrast, a blurred knowledge base can lead to inconsistent responses and misinterpretations.
### Maintenance and Responsibility
A good knowledge base is not necessarily large but reliable.
For manual articles, the following points should be checked in particular:
* Is the content technically correct?
* Is the article clearly formulated?
* Does the classification fit?
* Is the group selected sensibly?
* May the content be used for AI functions?
With connectors, additional questions arise:
* Is the external source technically robust?
* Are Include and Exclude paths sensibly set?
* Is the maximum page number selected appropriately?
* Is the crawling frequency appropriate?
* Is re-crawling or re-indexing required after a change?
For files, the following points should be checked additionally:
* Is the file name unique?
* Is the file stored in the appropriate folder?
* Is the content current and technically checked?
* Has the file been reprocessed after changes?
* Is it clear whether the file is used in the original state or in a manually edited version?
Changes to the AI wiki not only affect the documentation. They can also affect the quality of response suggestions, chat contexts, and AI agents.
Therefore, articles, connectors, files and visibility settings should be maintained as technical system components.
---
## Partner
**URL:** https://richard-dev-playground.enneo.ai/docs/en/work-resources/partners
**Description:** Application areas, creation, and access in tickets
### Application areas
Partner management is ideal for communication with business partners who are frequently contacted, but are not direct customers. This includes, for example, market partners or sales partners. With quick access to all relevant information and email addresses directly from a ticket, work processes become significantly more efficient.
### Creation
In the menu item **"**Partner**"**, new partners can be created or existing ones edited - similar to an address book. Clicking on "New Partner" opens the input screen, where all relevant information can be stored.
Optionally, a URL can be stored with the partner, so external systems can be linked.
### Access in tickets
---
## Templates
**URL:** https://richard-dev-playground.enneo.ai/docs/en/work-resources/templates
**Description:** Creation, configuration, and use of the template catalog
### Creation and Configuration
In the `Text modules` area, templates can be created, edited and removed. The existing structure is derived from the structure of the Skill Tags.
* **Name:** the designation of the template should be intuitive and content-related to facilitate search in the catalog
* **Theme**: the template is assigned to either a super- or subcategory of the structure
These so-called handlebars enable a flexible and diverse design of the templates. This dynamic version results from, for example, a fixed text module:
[Here](https://handlebarsjs.com/guide/) you can find detailed information on the syntax and usage of Handelbars.
| Helper | Signature | Description |
| ------------------ | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| `contains` | `contains array "value"` | Returns `true` if the array contains the given string value. Argument order is interchangeable (`contains "value" array`). |
| `compare` | `compare a b` | Returns `true` if both values are equal (loose comparison). |
| `gt` | `gt a b` | Returns `true` if `a` is set and `a > b`. |
| `lt` | `lt a b` | Returns `true` if `a` is set and `a < b`. |
| `and` | `and a b c …` | Returns the last argument if all are truthy, otherwise the first falsy argument. |
| `or` | `or a b c …` | Returns the first truthy argument, otherwise the last. |
| `not` | `not a` | Returns the logical negation of `a`. |
| `formatDateDE` | `formatDateDE date` | Formats a date in the long German format (for example, `1. January 2025`). Accepts `"today"`. Returns `[unknown]` if empty. |
| `formatDateEN` | `formatDateEN date` | Formats a date as `YYYY/MM/DD`. Accepts `"today"`. Returns `[unknown]` if empty. |
| `addDays` | `addDays date days` | Adds the indicated number of days to the date and returns it in the long German format. Accepts `"today"` as a date. |
| `extractFirstName` | `extractFirstName "Max Mustermann"` | Returns the first word of a string. |
| `extractLastName` | `extractLastName "Max Mustermann"` | Returns the last word of a string in lowercase. |
| `last4digits` | `last4digits "DE12 3456 7890 1234 5678"` | Removes spaces and returns the last 4 characters of a string (e.g., for masked account numbers). |
| `undefined` | (internal) | Renders `{{varname}}` verbatim if a variable is not set - used as a fallback for unresolved placeholders. |
Own Helpers can be combined with Standard Handlebars Block Helpers, e.g.:
```handlebars
{{#if (and (contains in.tagIds "22") (gt in.amount "100"))}}
Special treatment for high-value tickets with Tag 22.
{{/if}}
```
---
## Quality Assessment
**URL:** https://richard-dev-playground.enneo.ai/docs/en/quality/quality-assessments
### Where to view assessments
Assessments are directly available in the **Ticket view**: The assessment button in the ticket detail bar opens the worklog of the respective ticket with all associated assessments. The button is only visible if the logged-in user possesses at least one of the assessment view permissions (see below).
Scorecards are managed under **Settings → Quality Scorecards**.
### Permissions
| Permission | Description |
|---|---|
| `QualityViewAssessmentOwn` | View your own assessments |
| `QualityViewAssessmentTeamMate` | View team members' assessments |
| `QualityViewAssessmentAll` | View all users' assessments |
| `QualityDoAssessmentsTeam` | Create and edit assessments for team members |
| `QualityDoAssessmentsAll` | Create and edit assessments for any user |
| `QualityDeleteAssessment` | Delete assessments |
| `QualityManageScorecards` | Create, edit, and manage scorecards |
| `QualityDeleteScorecard` | Delete scorecards |
### Creation and Automatic Generation
Assessments are not manually created, but by a background job that runs every minute. This identifies `writeAction` type work processes for which no assessments have been made yet, checks which active scorecards are applicable, and generates an assessment for each suitable scorecard.
There can be multiple assessments per work process - one for each scorecard that meets the assignment rules.
After creation, an event is triggered that starts AI processing.
### AI Processing
The Cortex service receives as a basis for evaluation:
- The *flow of messages of the ticket* - from the first customer contact to the last agent reply (including internal notes)
- The *Scorecard* with all categories, criteria, and assessment prompts
- *Worklog details* - timework, AI agents used, level of automation
- The *customer experience* - SLA adherence, CSAT
Cortex evaluates all criteria where `autoGenerateByAi` is activated and provides a score and a rationale for each criterion. Subsequently, the AI generates a summary assessment (`aiSummary`).
AI-assessed criteria receive the status `aiGenerated`. Criteria without AI assessment remain `unscored` and must be manually assessed.
### Assessment Data
An assessment includes:
- *Categories and criteria* - with score, rationale, and evaluation status per criterion
- *Total points* - `scoredPoints`, `usedMaxPoints`, `totalMaxPoints`, `percentage`
- *AI Summary* (`aiSummary`) - free text, generated by the AI
- *Supervisor assessment* (`supervisorAssessment`) - free text, manually entered
- *Assessment date* and *conversation date* - for documentation purposes
- *Time recording* - processing time (segments, follow-up time)
- *AI use* - which AI agents were involved, degree of automation
- *Customer experience* - SLA status, whether the ticket was reopened, CSAT result
- *Change history* - complete logging of all changes (Score, rationale, status, who changed when)
### Points Calculation
#### How is the percentage calculated?
The calculation is based solely on *rated* criteria:
- `usedMaxPoints` = sum of the maximum points of all criteria with a score (including Score = 0)
- `scoredPoints` = sum of the actual points achieved
- `totalMaxPoints` = sum of all maximum points of the scorecard (including unrated criteria)
- `percentage` = `scoredPoints / usedMaxPoints × 100`
Unrated criteria (`unscored`) are not included in the calculation. This allows a valid part rating if individual criteria cannot be evaluated due to lack of data.
#### K.O. logic and its effect on the score
Criteria can be marked as K.O. criteria for the category or for the entire assessment.
- *Category K.O.:* If such a criterion scores 0 points, all points of the category are set to 0 - regardless of other criteria in the same category.
- *Assessment K.O.:* If such a criterion scores 0 points, all `scoredPoints` of the entire assessment are set to 0.
The K.O. logic is applied every time the total points are recalculated, i.e., after each AI assessment and after each manual change.
### Workflow States
Assessments go through a defined workflow:
| Status | Meaning |
|---|---|
| `unprocessed` | Created, AI processing pending |
| `aiInProgress` | AI actively evaluates |
| `aiReady` | AI pre-evaluation completed, ready for review |
| `reviewOngoing` | Supervisor has started the review |
| `reviewedBySupervisor` | Review by supervisor completed |
| `discussedWithAssessee` | Discussed with the evaluated employee |
| `error` | Error in AI processing |
*Automatic reset:* If a supervisor makes changes after the review (`reviewedBySupervisor`) or after the employee conversation (`discussedWithAssessee`), the status automatically reverts to `reviewOngoing`. Entered assessment and conversation data are retained.
### Criterion States
Each criterion within an assessment has its own status:
| Status | Meaning |
|---|---|
| `unscored` | Not yet rated |
| `aiGenerated` | Pre-rated by AI, not yet confirmed by supervisor |
| `humanVerified` | Manually set or confirmed by supervisor |
### Context Data in the Assessment
#### Time recording
The assessment includes the time recording data of the work process: total processing time, post-processing time, and individual time segments with the actions performed. This data comes from the employee's worklog and is frozen at the time of the assessment creation.
#### AI use
For each work process, it is documented which AI agents were involved and how high the degree of automation in the handling was. This information serves as context in the quality assessment - fully automated processes are evaluated differently than those handled manually.
#### Customer experience
The assessment includes information about the SLA adherence (was the deadline met, how many seconds after the deadline the ticket was closed), whether the ticket was reopened, and the CSAT result (customer satisfaction survey), if available. These data provide objective quality signals independent of the scorecard assessment.
### Export
Quality assessments can be exported under **Settings → Data export** as XLSX, CSV or JSON. The export includes all assessment data including scores, justifications, time tracking, and customer experience, and is suitable for external reporting or evaluation in BI tools.
### Best Practices
- *Use change history:* The complete logging of all score and status changes makes assessments auditable. If there are any queries, it can be traced back to what the AI originally evaluated and what was manually adjusted.
- *Maintain assessment and conversation date:* These fields are mandatory for meaningful reporting - without them, assessment periods cannot be correctly evaluated.
- *Use AI Summary as a starting point:* The `aiSummary` is not a final evaluation, but a structured starting point for the supervisor review. It should not be used as a basis for discussion without checking.- *Monitoring Error Status:* Assessments in the `error` status are not automatically repeated. They should be regularly checked to avoid assessment gaps in reporting.
---
## Overview
**URL:** https://richard-dev-playground.enneo.ai/docs/en/quality/quality-in-enneo
Quality management is a central part of professional service centers. The aim is to ensure the quality of customer communication permanently, make processing standards measurable, and identify optimization potentials early on.
Standardized quality assessments create a common basis for feedback, coaching, and continuous improvement in customer service. They help to make strengths visible, identify development potentials early on, and ensure consistent service quality.
Enneo offers AI-supported quality ratings for automated analysis of large volumes of customer interactions based on defined quality criteria.
## Video Introduction - Quality in Enneo
## Quality Assurance in the Service Center
In customer service, the quality of handling significantly determines customer satisfaction, process stability, and the perception of the service. At the same time, a complete manual check of all operations is hardly possible in practice, as quality assessments are very time-consuming and organizationally demanding.
Many service centers, therefore, work with samples and standardized evaluation sheets. However, this often only leaves a small part of the actual customer interactions open for review.
Enneo additionally offers AI-supported quality assessments, with which large amounts of processing can be automated and evaluated based on defined quality criteria. This allows quality checks to be significantly scaled without proportionally increasing the manual effort.
## Manual and AI-assisted Evaluations
In Enneo, quality evaluations can be carried out both by employees in quality management and automatically by AI.
Within the quality evaluation, it can be determined for individual criteria whether they should be checked manually or automatically by AI. The control is done via the so-called scorecard, in which the respective assessment instructions are deposited.
### AI-assisted Analyses
AI-assisted analyses are particularly suitable for standardizable criteria and large amounts of processing. These include, for example:
- Comprehensibility and tonality of responses
- Whether the specific concern of the customer has been addressed
- Completeness and traceability of feedback
- Compliance with defined communication standards
### Manual Quality Assessments
Criteria that require professional experience, decision-making latitude, or organizational context are still evaluated manually by quality management. These include, for example:
- Decisions made out of goodwill and individual special cases
- Deliberate deviations from defined processes
- The appropriateness of a solution in a specific customer context
- Technical or regulatory special cases
This approach allows standard quality assurance and human judgement to be specifically combined and scaled much more broadly than in purely manual processes.
---
## Scorecards
**URL:** https://richard-dev-playground.enneo.ai/docs/en/quality/quality-scorecards
A scorecard is an evaluation template specifying the criteria to be examined in the quality evaluation of a work process. It forms the basis for every quality evaluation (assessment) in the system.
Scorecards are created and maintained by the quality management team. As soon as a scorecard is active, new work processes can automatically be linked to it if the configured assignment rules apply.
### Scope and Permissions
Scorecards are managed under **Settings → Quality Scorecards**.
The following privileges apply for access:
- **View:** All registered users can view scorecards.
- **Create and edit:** Requires the `qualityManageScorecards` permission.
- **Delete:** Additionally requires the `qualityDeleteScorecard` permission.
### Structure
A scorecard consists of **categories**, which in turn contain **criteria**.
**Categories** group together related criteria. Each category has a name and an order.
**Criteria** define the actual evaluation points within a category:
- **Name and description** - What is being evaluated?
- **Maximum points** - Weighting of the criterion
- **Evaluation type** - `metNotMet` or `numericScale`
- **AI evaluation enabled** - Whether AI evaluates this criterion automatically
- **Evaluation prompt** - Instructions to the AI on which standards to evaluate
- **Knockout criterion for category** - If this criterion is scored 0, the category is set to 0
- **Knockout criterion for evaluation** - If this criterion is scored 0, the overall score is set to 0
### Allocation and Response Context
Scorecards can be restricted to certain work processes. Assignment is based on:
- **Teams** - only work processes by members of specific teams
- **Ticket tags** - only tickets with specific tags
- **Channels** - e.g., Email, phone, or letter
- **Response context** - whether the scorecard is intended for responses to customer messages or for proactive responses
Two cases are distinguished in the response context:
- **After customer message** (`afterCustomerMessage`) - classic reactive quality assurance: an employee responds to a previous customer inquiry.
- **Without prior customer message / proactive** (`withoutCustomerMessage`) - for proactive communication, where the employee creates a message without direct previous customer inquiry.
If multiple allocation rules are configured, they need to apply collectively.
### Automatic Creation of Assessments
The system regularly checks whether there are new work routines that have not yet been evaluated. For each matching work process, it determines which active scorecards apply according to assignment rules.
For each matching scorecard, an assessment is created and submitted for AI processing.
A work process can be evaluated by multiple scorecards if multiple scorecards apply.
### Live Quality Coach
The **Live Quality Coach** option determines whether a scorecard is also used while handling the ticket.
If the Live Quality Coach is enabled, an employee can have the current draft response checked before sending. The AI evaluates the draft based on the AI-evaluable criteria of the matching scorecards.
For each matching scorecard, the Live Quality Coach provides:
- the achieved percentage score
- the required minimum score
- whether the draft has passed
- an AI summary
- details per category and criterion
The Live Quality Coach is currently planned for supported response channels such as Email and letter.
### Minimum Value for the Live Quality Coach
A **Threshold** can be configured for the Live Quality Coach. This value is between 0 and 100 percent and defines the minimum score a draft response should achieve.
The default value is 85%.
If a draft does not reach the minimum value, this is made visible in the response area. The response can still be sent, but the interface makes it clear that the employee is knowingly skipping the quality check.
### AI-assisted Preliminary Scoring
Criteria with AI evaluation enabled are automatically evaluated by the AI. The AI follows the configured evaluation prompt.
The result can be reviewed and adjusted by the supervisor.
Criteria without AI evaluation remain initially unscored and must be manually scored. In the Live Quality Coach, only AI-evaluable criteria are used for the automatic check.
### Knockout Criteria
Knockout criteria allow marking individual requirements as absolute.
- **Category level:** If a knockout criterion within a category is scored 0, the entire category is scored with 0 points.
- **Evaluation level:** If a knockout criterion for the overall evaluation is scored 0, the overall evaluation falls to 0.
### Versioning
Scorecards are versioned. Each scorecard has a `baseId` and a `revision`.
- `baseId` remains the same across all versions of a scorecard.
- `revision` increases with each new version.
- If an active scorecard is edited, the previous version is set to `retired`, and a new revision is created.
Existing assessments remain linked with the scorecard version that was active at the time of creation. Changes only affect newly created assessments.
### States of a scorecard
- **Draft** – in progress, not yet active
- **Active** – active and usable for new evaluations
- **Archived** – superseded by a new revision
- **Deleted** – soft-deleted and no longer visible
### Evaluation Workflow
Assessments can go through the following states:
1. **Unprocessed** – Assessment was created, AI processing pending
2. **AI processing in progress** – AI is currently evaluating the criteria
3. **AI evaluation ready** – AI pre-evaluation completed, ready for review
4. **Review in progress** – Supervisor has started the review
5. **Reviewed by Supervisor** – Review completed
6. **Discussed with employee** – Assessment has been discussed with the evaluated employee
7. **Error** – An error occurred during processing
8. **Deleted** – Assessment was deleted
If a supervisor makes changes to a completed assessment, the status automatically reverts to `reviewOngoing`.
### Quality Evaluation Preview
The Quality Evaluation Preview can be used to test a scorecard before it is used in production or after changes are actively applied.
Typically required for this are:
- **Ticket ID** – provides context such as customer inquiry, history, and relevant ticket data
- **Response text** – the draft or sample text to be checked
The preview does not create a regular evaluation in the quality workflow. It is used to validate criteria, prompts, weights, knockout rules, and live coach behavior.
### Export
When editing a Scorecard, the current Scorecard configuration can be exported and copied as JSON. This is useful for reviews, technical analysis, or sync between environments.
### Best Practices
- **Clearly formulate criteria:** AI-evaluable criteria should be concrete and verifiable.- **Maintain precise prompts:** Describe how the AI should identify whether a criterion is met.
- **Use knock-out criteria sparingly:** They have strong effects on category and overall results.
- **Deliberately choose thresholds:** Too high a minimum value can block many drafts, while a lower value weakens Live Quality Coach.
- **Separate proactive and reactive cases:** Different scorecards may be useful for responses after customer messages and proactive communication.
- **Configure assignment rules intentionally:** Broad assignments increase the assessment volume.
- **Take versioning into account:** For evaluations, it is relevant which revision of an assessment is the basis.
---
## Surveys
**URL:** https://richard-dev-playground.enneo.ai/docs/en/quality/surveys
**Description:** Types and Functionality
### Customer Surveys
**Purpose of the survey**
- Systematic collection of customer feedback
- Determination of satisfaction after ticket closure
- Basis for team and quality development
**Requirements**
- User right "Manage customer and user satisfaction surveys" is required.
**Setting up the CSAT survey**
1. **Accessing the survey section**
`User Administration → Surveys → Customer Surveys`
2. **Choosing scale and representation**
"Display customer satisfaction survey in the footer" with the options:
- Good / Okay / Not Good (3-scale)
- Stars (5-scale)
- NPS (10-scale)
- Deactivated (default setting)
The chosen scale applies globally – it is used for all activated email accounts.
3. **HTML Template**
After selecting the scale, the template editor is displayed, in which the layout of the survey can be implemented via HTML.
Example of a 3-scale:
```html
```
Possible representations:
4. **Activation per email account**
Although the scale is set globally, it can be individually decided for each email mailbox whether the CSAT function should be active or not:
- Go to Email Accounts
- Edit the desired account
- Activate the toggle in the section "Customer Satisfaction Survey (CSAT)"
5. **Testing and checking**
To check the configuration, simply create an outgoing email and send it to your own email address.
This allows a direct check to see if the survey in the footer meets the expectations or needs to be adjusted.
6. **Data Retrieval**
The survey results can be downloaded as an .xlsx file in the `Advanced Settings → Exports and Reporting Settings → "Customer Satisfaction Surveys"` section.
Relevant datasets: `Audience = customer`
### User Surveys
**Purpose of the survey**
- Evaluation of the **solution proposed by the AI-agent**
- Improvement of AI-logic based on feedback from practical experience
- Uncovering potential for expanding existing AI-agents or developing new use cases
**Requirements**
- User right "Manage customer and user satisfaction surveys" is required.
**Setting up the user survey**
1. **Accessing the survey section**
`User Administration → Surveys → User Surveys`
2. **Activation**
- Select the option
"How satisfied were you with the AI? 1–5 Stars." from the dropdown "Survey after ticket closure"
- By default, "No survey" is set
3. **Functionality**
- The survey appears after the completion of a ticket processing
- Only visible to users with ticket processing roles
- The survey contains a popup "How satisfied are you with the AI solution?"
- The rating scale ranges from 1 to 5 stars
4. **Data Retrieval**
The survey's results can be downloaded as an .xlsx file in the `Advanced Settings → Exports and Reporting Settings → "Customer Satisfaction Surveys"` section.
Relevant datasets: `Audience = user`
---
## Erster Überblick
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/ai-control-centre/aicc-summary
**Description:** Einstieg, Benutzung und Best Practise
### Voraussetzungen zur Ansicht und Nutzung
- **Genereller Zugriff**: Berechtigung im Bereich `Daten und Berichte → KI-Kontrollzentrum`
- **Automatisierungseinstellungen**: Berechtigungen im Bereich `Dunkelverarbeitung` wird der Zugriff für Konfiguration, Ticket-Erkennung und Auslösung gesteuert
- **Qualitätsprüfung**: Berechtigung im Bereich `KI-Qualitätsprüfung`, wird der Zugriff auf Ansicht, Ausführung von Testläufen und deren Bearbeitung gesteuert
- **Live-Übersicht**: Berechtigung im Bereich `Tickets → Ticket-Übersichtsseite`
- **KI-Agenten-Team**: Berechtigung im Bereich `KI-Agentenverwaltung` wird der Zugriff auf Ansicht, Erstellung und Bearbeitungsmöglichkeit gesteuert
### Werkzeuge im Überblick
Mit dem KI-Kontrollzentrum werden die wichtigsten Werkzeuge für Automatisierung an einem Ort zusammengefasst:
- **Live Übersicht & Metriken**: Überblick über Live-Kennzahlen, Automatisierungsgrad und KI-Agentenleistung → [mehr erfahren](/docs/de/ai-functions-agents/ai-control-centre/dashboard_metrics)
- **Qualitätsprüfung**: Verwaltung von Testfällen und Auswertung von Testläufen → [mehr erfahren](/docs/de/ai-functions-agents/ai-control-centre/quality-check/test-cases-and-runs)
- **Automatisierungs-Einstellungen**: Steuerung der Automatisierungsstufen mit und ohne Freigabe → [mehr erfahren](/docs/de/ai-functions-agents/ai-control-centre/dark-processing/types-of-release)
### Stufen der Automatisierung
Das Ziel ist die **vollautonome Verarbeitung** von Geschäftsvorfällen durch KI-Agenten.
Der Weg dorthin erfolgt über mehrere Stufen:
1. **Manuelle Bearbeitung**
Der KI-Agent erkennt das Anliegen vollständig, liest die relevanten Daten korrekt aus, leitet passende Bearbeitungsoptionen ab und stellt sie bereit. Ein Mensch entscheidet über die weitere(n) Aktion(en).
2. **Dunkelverarbeitung mit Freigabe**
Der KI-Agent übernimmt alle Schritte der Bearbeitung: Er erkennt das Anliegen, liest die Daten aus, leitet die richtige Aktion ab und wählt die passende Bearbeitungsoption.
Der Prüfer braucht nur noch die vom KI-Agenten getroffene Auswahl mit einem Klick freizugeben, oder den Vorgang auf manuelle Bearbeitung zurücksetzen, wenn Abweichungen erkennbar sind.
3. **Dunkelverarbeitung ohne Freigabe**
Der KI-Agent übernimmt die Bearbeitung vollautonom: Er erkennt das Anliegen, liest die Daten aus, leitet die passende Aktion ab, wählt die richtige Bearbeitungsoption und führt sie selbstständig aus.
### Beispiel: Bankdaten-Agent
Ein **regelbasierter KI-Agent** wurde erstellt zu dem Zweck, Kundenanliegen zu Änderungen von Bankverbindungen zu verarbeiten.
Er soll prüfen, ob die vom Kunden angegebene IBAN bereits im System hinterlegt ist, ob sie ungültig ist oder ob sie als neue, gültige Bankverbindung übernommen werden kann.
Zunächst entscheidet ein Bearbeiter manuell über die Performance des KI-Agenten:
- Wird das **Anliegen des Kunden richtig erkannt** (Änderung der Bankverbindung)?
- Werden alle **relevanten Parameter korrekt ausgelesen** (IBAN, Gültigkeitsdatum, Kontoinhaber)?
- Sind die **typischen Use Cases** korrekt abgedeckt? (IBAN gültig, IBAN ungültig, IBAN bereits vorhanden, Gültigkeitsdatum in der Vergangenheit)
- Werden die **richtigen Bearbeitungsoptionen** angeboten? (IBAN übernehmen, Kunde über Fehler in der IBAN informieren, Gültigkeitsdatum anpassen)
Stellt der Bearbeiter fest, dass einzelne Punkte der Checkliste nicht zuverlässig erfüllt sind, ist das ein Hinweis darauf, dass der Bankdaten-Agent angepasst werden muss.
Dazu gehören bspw. Anpassungen bei der **Erkennung von Eingabeparametern**, die Optimierung der **Businesslogik** oder Ergänzungen zur **Ausgabebehandlung**. Erst wenn diese Rückmeldungen umgesetzt und die Ergebnisse stabil sind, kann der nächste Automatisierungsschritt erfolgen.
Zeigt der Bankdaten-Agent dauerhaft korrekte Ergebnisse, kann er auf [**Dunkelverarbeitung mit Freigabe**](/docs/de/ai-functions-agents/ai-control-centre/dark-processing/types-of-release) gestellt werden.
Bestätigen sich auch hier zuverlässige Ergebnisse, folgt die Umstellung auf [**Dunkelverarbeitung ohne Freigabe**](/docs/de/ai-functions-agents/ai-control-centre/dark-processing/types-of-release), also die vollautonome Verarbeitung.
### Voraussetzungen und Risiken
Bevor ein KI-Agent in höhere Automatisierungsstufen überführt wird, müssen bestimmte Bedingungen erfüllt sein:
- **Zuverlässige Kundenerkennung**
- **Akkurate Anliegenerkennung**
- **Niedrige Fehlerraten** beim Erkennen und Auslesen von Parametern
- **Erfolgreiche Testläufe** in der Qualitätsprüfung
Risiken entstehen vor allem, wenn falsche Entscheidungen unbemerkt in die Dunkelverarbeitung gelangen. Das Dashboard und die Qualitätsprüfung helfen, diese Risiken zu minimieren und Fehler rechtzeitig zu erkennen.
### Rolle der Anwender im Kontrollzentrum
Nutzer des KI-Kontrollzentrums haben verschiedene Aufgaben:
- **Testfälle erstellen** und pflegen, um die Zuverlässigkeit der KI-Agenten zu überprüfen
- **Ergebnisse beobachten** und Auffälligkeiten dokumentieren und/oder kommunizieren
- **Einschätzung abgeben**, ob ein KI-Agent in die nächste Automatisierungsstufe überführt werden kann
---
## Dashboard und Metriken
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/ai-control-centre/dashboard_metrics
**Description:** Erläuterung und weitere Schritte
### Grundlegende KI-Metriken
Diese Kennzahlen geben Aufschluss darüber, **wie zuverlässig die KI im täglichen Betrieb arbeitet**.
- **Kunde korrekt identifiziert**
Anteil der Arbeitssitzungen, bei denen der Kunde eindeutig und ohne manuelles Eingreifen zugeordnet werden konnte.
- **Korrekt mit Tags kategorisiert**
Anteil der Arbeitssitzungen, bei denen die KI die **richtigen Tags gesetzt** hat. Ein manueller Eingriff war nicht erforderlich.
- **Text-Assistent-Genauigkeit**
Durchschnittliche **Genauigkeit des Textassistenten**, berechnet über alle Arbeitssitzungen im ausgewählten Zeitraum.
### KI-Leistungsmetriken
Hier wird die **operative Wirksamkeit** der Automatisierung sichtbar:
- **Automatische Verarbeitung**
Zeigt die Anzahl der Tickets, die automatisch verarbeitet wurden, unterschieden nach **Mit Genehmigung (L4)** und **vollständig autonom (L5)**.
- **Automatisierungsgrad**
Bewertet, wie stark Tickets insgesamt durch die KI unterstützt wurden:
- **L0**: Keine KI, außer Identifizierung/Kategorisierung
- **L1**: KI zur Textüberarbeitung genutzt
- **L2**: Textvorschlag des Basis-Agenten übernommen
- **L3**: Vorschlag eines Spezial-Agenten bestätigt
- **L4**: Dunkelverarbeitung mit Freigabe
- **L5**: Vollständige Dunkelverarbeitung
### Agentenübersicht
Die Tabellenansicht listet **die KI-Agenten mit aktiver Automatisierung** auf, also solche, die Tickets **mit Freigabe (L4)** oder **vollständig autonom (L5)** verarbeiten.
Für jeden dieser KI-Agenten werden angezeigt:
- **Verarbeitet**: Anzahl der bearbeiteten Tickets im Zeitraum
- **Wartet auf Genehmigung**: Fälle, die aktuell zur manuellen Freigabe vorliegen
- **Automatisch bearbeitete Fälle (L4+L5)**: Summe aller erfolgreich **automatisch** abgeschlossenen Tickets
- **Dunkelverarbeitungsrate (L5)**: Anteil der Fälle, die **ohne menschliche Eingriffe** abgeschlossen wurden
- **Menschliche Genehmigungsrate (L4)**: Anteil der Fälle, bei denen ein Mitarbeiter den KI-Vorschlag **freigegeben** hat
- **Fehlerrate**: Anteil der Fälle, die **korrigiert** oder **zurückgenommen** werden mussten
---
## API-basierte Agenten
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/default-agents/api-agent
**Description:** Business-Logik flexibel auslagern und erweitern
API-basierte Agenten bilden die Brücke zwischen der Enneo-Plattform und Ihrer individuellen IT-Landschaft. Sie ermöglichen es, die gesamte Business-Logik in externe Dienste auszulagern und dabei die volle Kontrolle über Datenflüsse und Verarbeitungsschritte zu behalten. Durch die standardisierte Kommunikation über HTTP können beliebige Systeme angebunden werden – von internen Microservices bis hin zu externen SaaS-Lösungen.
Im Gegensatz zu regelbasierten Agenten, deren Logik direkt in Enneo implementiert wird, setzen API-basierte Agenten auf eine klare Trennung zwischen der Enneo-Plattform und der eigentlichen Geschäftslogik. Dies ermöglicht nicht nur eine höhere Skalierbarkeit und bessere Wartbarkeit, sondern auch die Wiederverwendung bestehender Dienste und Infrastrukturen.
../../../../snippets/default-agents/default_api.mdx
---
## Bankdaten-Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/default-agents/bankdata-agent
**Description:** Automatisierte Bearbeitung von Bankverbindungsänderungen
### Zentrale Funktionen
Der Bankdaten-Agent übernimmt den kompletten Prozess der Bankdatenaktualisierung und bietet dabei folgende Kernfunktionalitäten:
* **IBAN-Validierung:** Automatische Prüfung der Format- und Prüfsummenkonformität neuer Bankverbindungen
* **Identitätsprüfung:** Abgleich des Kontoinhabers mit Vertragsinformationen zur Sicherstellung der Legitimität
* **Systemintegration:** Nahtlose Aktualisierung der Bankdaten in allen relevanten Systemen
* **Kundenkommunikation:** Automatisierte Bestätigungen über erfolgreiche Änderungen oder Rückfragen bei Unklarheiten
### Prozessablauf
Der Agent arbeitet nach einem klar definierten Prozess, der maximale Sicherheit bei gleichzeitig hoher Benutzerfreundlichkeit gewährleistet:
1. **Extraktion relevanter Daten** aus der Kundenanfrage (neue IBAN, Kontoinhaber, gewünschtes Datum)
2. **Validierung der neuen Bankverbindung** anhand internationaler Standards
3. **Prüfung der Berechtigung** zur Änderung der Bankdaten
4. **Durchführung der Änderung** in allen verknüpften Systemen
5. **Bestätigung an den Kunden** mit den relevanten Informationen zur neuen Bankverbindung
Durch die regelbasierte Logik werden alle Eingaben systematisch geprüft und verarbeitet, sodass Fehler minimiert und gleichzeitig der manuelle Bearbeitungsaufwand deutlich reduziert wird.
../../../../snippets/default-agents/default_bankdata.mdx
---
## Abschlags-Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/default-agents/deposit-agent
**Description:** Effiziente Verwaltung und Anpassung von Abschlagszahlungen
### Kernfunktionalitäten
Der Abschlags-Agent übernimmt den gesamten Prozess der Abschlagsanpassung und bietet dabei folgende zentrale Leistungen:
* **Bedarfsanalyse:** Bewertung der gewünschten Änderung im Kontext des tatsächlichen Verbrauchs
* **Plausibilitätsprüfung:** Automatische Validierung, ob die angeforderte Änderung innerhalb sinnvoller Grenzen liegt
* **Umsetzung:** Direkte Anpassung der Abschlagshöhe in allen relevanten Systemen
* **Kommunikation:** Automatisierte Bestätigung der Änderung mit Angabe des Gültigkeitszeitpunkts
### Prozessablauf
Der Agent folgt einem strukturierten Ablauf, der sowohl Kundenzufriedenheit als auch finanzielle Stabilität sicherstellt:
1. **Erkennung des Anliegens** und Extraktion relevanter Informationen (gewünschte Abschlagshöhe, Zeitpunkt)
2. **Abgleich mit Verbrauchsdaten** zur Prüfung der Angemessenheit der angeforderten Änderung
3. **Bewertung des Änderungswunsches** anhand vordefinierter Regeln und Grenzwerte
4. **Durchführung der Anpassung** bei positiver Bewertung oder Vorschlag alternativer Beträge
5. **Transparente Kommunikation** mit dem Kunden über das Ergebnis und weitere Schritte
Durch die Kombination aus Datenanalyse und klaren Entscheidungsregeln ermöglicht der Abschlags-Agent eine schnelle, konsistente und kundenorientierte Bearbeitung von Änderungswünschen bei gleichzeitiger Entlastung des Kundenservice-Teams.
../../../../snippets/default-agents/default_deposit.mdx
---
## Zählerstand-Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/default-agents/reading-agent
**Description:** Automatisierte Erfassung und Verarbeitung von Zählerständen mit OCR-Technologie
### Kernfunktionen
Der Zählerstand-Agent übernimmt den gesamten Prozess der Zählerstandserfassung und bietet dabei folgende wesentliche Funktionen:
* **Intelligente Datenerkennung:** Automatische Identifikation von Zählerständen und zugehörigen Zählernummern in Kundenanfragen
* **OCR-Bildanalyse:** Erkennung und Extraktion von Zählerstandsdaten aus E-Mail-Anhängen wie Fotos oder gescannten Dokumenten
* **Plausibilitätsprüfung:** Validierung der gemeldeten Stände im Vergleich zu historischen Werten und typischen Verbrauchsmustern
* **Systemintegration:** Nahtlose Übertragung validierter Zählerstände in die Abrechnungssysteme
* **Kundenkommunikation:** Automatisierte Bestätigung der erfassten Daten oder Rückfragen bei Unklarheiten
### Prozessablauf
Der Agent arbeitet nach einem strukturierten Verfahren, das Genauigkeit und Effizienz kombiniert:
1. **Extraktion der Zählerinformationen** aus der Kundenanfrage oder durch OCR-Analyse von Anhängen
2. **Abgleich mit Stammdaten** zur Zuordnung zum richtigen Vertrag und Zähler
3. **Durchführung von Plausibilitätsprüfungen** zur Sicherstellung realistischer Verbrauchswerte
4. **Übermittlung der validierten Daten** an die Abrechnungssysteme
5. **Rückmeldung an den Kunden** mit Bestätigung der erfolgreichen Verarbeitung
Die Kombination aus intelligenter Textanalyse und moderner OCR-Technologie macht den Zählerstand-Agenten besonders leistungsfähig. Er verarbeitet Zählerstände nicht nur aus strukturierten Eingaben, sondern erkennt diese auch in Bildern von Zählern, die Kunden als E-Mail-Anhänge übermitteln - ohne dass diese manuell erfasst werden müssen.
../../../../snippets/default-agents/default_reading.mdx
---
## Evaluate an AI agent prompt
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agents/post-ai-agent-prompt-eval
**Description:** POST /aiAgent/{id}/prompt-eval
## `POST /aiAgent/{id}/prompt-eval`
Run the LLM prompt that belongs to the given AI agent against a sample input and return the
raw model output. Used by the prompt editor in ops-fe to iterate on prompt wording without
deploying the agent.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid input
**`403`** — Unauthorized
---
## Delete an existing AI Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agent/delete-delete-ai-agent
**Description:** DELETE /aiAgent/{id}
## `DELETE /aiAgent/{id}`
### Path parameters
### Responses
**`200`** — Intent description deleted
**`403`** — Unauthorized
**`404`** — Intent description not found
**`500`** — Internal error
---
## Get an AI Agent by id
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agent/get-get-ai-agent
**Description:** GET /aiAgent/{id}
## `GET /aiAgent/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Intent description not found
**`500`** — Internal error
---
## List of all available AI agents as an tree based on associated tag
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agent/get-get-ai-agents-tree
**Description:** GET /aiAgents/tree
## `GET /aiAgents/tree`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## List of all available AI agents as an array
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agent/get-get-ai-agents
**Description:** GET /aiAgents
## `GET /aiAgents`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get list of available enneo default AI Agents
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agent/get-get-available-default-ai-agents
**Description:** GET /aiAgents/availableDefaults
## `GET /aiAgents/availableDefaults`
Retrieve all available enneo default AI agents that can be imported. Shows which agents are already imported and which are available for import.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get a sample AI agent by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agent/get-get-sample-ai-agent
**Description:** GET /aiAgents/samples/{id}
## `GET /aiAgents/samples/{id}`
Returns a single sample AI agent from the enneo admin portal by its ID. The response includes additional `includedInSeeds` and `category` metadata fields.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Sample AI agent not found
**`500`** — Internal error
---
## Get similar tickets for an AI Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agent/get-get-similar-tickets
**Description:** GET /aiAgent/{id}/similarTickets
## `GET /aiAgent/{id}/similarTickets`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Intent description not found
**`500`** — Internal error
---
## List all sample AI agents
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agent/get-list-sample-ai-agents
**Description:** GET /aiAgents/samples
## `GET /aiAgents/samples`
Returns all sample AI agents from the enneo admin portal, without any environment or category filtering. Each agent includes additional `includedInSeeds` and `category` metadata fields.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Update an existing AI Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agent/patch-update-ai-agent
**Description:** PATCH /aiAgent/{id}
## `PATCH /aiAgent/{id}`
### Path parameters
### Request body
The new updated AI agent
### Responses
**`200`** — Intent description updated
**`403`** — Unauthorized
**`404`** — Intent description not found
**`422`** — AI agent definition contains invalid parameter references
**`500`** — Internal error
---
## Create a new aiAgent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agent/post-create-ai-agent
**Description:** POST /aiAgent
## `POST /aiAgent`
This API creates a new AI Agent and returns the newly created id
### Request body
The new AI Agent that should be created. If not defined, then a blank "new ai agent" will be created
### Responses
**`200`** — New intent created
**`403`** — Unauthorized
**`422`** — AI agent definition contains invalid parameter references
**`500`** — Internal error
---
## Get the outcome of an AI Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agent/post-get-ai-agent-outcome
**Description:** POST /aiAgent/outcome
## `POST /aiAgent/outcome`
### Request body
The new updated AI agent
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Preview an AI Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agent/post-get-ai-agent-preview
**Description:** POST /aiAgent/{id}/preview
## `POST /aiAgent/{id}/preview`
### Path parameters
### Query parameters
### Request body
The new updated AI agent
### Responses
**`200`** — Successful operation
---
## Load enneo default AI Agents
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-agent/post-load-default-ai-agents
**Description:** POST /aiAgents/loadDefaults
## `POST /aiAgents/loadDefaults`
Load all the enneo default AI agents, e.g. for meter reading, bank data, etc., and saves them in the client DB. If the client is configured to not use enneo's default AI agents, then nothing is written.
### Responses
**`200`** — Loaded successfully
**`403`** — Unauthorized
**`412`** — Client is configured to not use AI agents in his settings
**`500`** — Internal error
---
## Delete a test case by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/delete-delete-ai-quality-test-case
**Description:** DELETE /aiQualityCheck/testCase/{id}
## `DELETE /aiQualityCheck/testCase/{id}`
Delete a specific test case using its numeric test case ID. Here `{id}` is a test case id
(numeric only). The Dispatcher pins this method to the `\d+` regex constraint so AI-agent
`all` requests cannot reach this handler.
### Path parameters
### Responses
**`200`** — Successful operation
---
## Delete a specific test run by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/delete-delete-ai-quality-test-run
**Description:** DELETE /aiQualityCheck/testRun/{testRunId}
## `DELETE /aiQualityCheck/testRun/{testRunId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Test run not found
**`500`** — Internal error
---
## Get all AI agents for which test runs can be triggered
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/get-ai-quality-test-ai-agent
**Description:** GET /aiQualityCheck/testAiAgent
## `GET /aiQualityCheck/testAiAgent`
### Responses
**`200`** — Successful operation
---
## Get test cases for a specific AI agent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/get-get-ai-quality-test-cases-by-ai-agent-id
**Description:** GET /aiQualityCheck/testCase/{id}
## `GET /aiQualityCheck/testCase/{id}`
Get all test cases associated with the specified AI agent ID. Here `{id}` is treated as an
AI agent id (digits, or `all` to list across every agent). This is a different overload of
`{id}` than the `DELETE`/`PATCH` variants below, which take a numeric test case id.
### Path parameters
### Responses
**`200`** — Successful operation
---
## Get a specific test run by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/get-get-ai-quality-test-run
**Description:** GET /aiQualityCheck/testRun/{testRunId}
## `GET /aiQualityCheck/testRun/{testRunId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get all test runs with pagination
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/get-get-ai-quality-test-runs
**Description:** GET /aiQualityCheck/testRun
## `GET /aiQualityCheck/testRun`
### Query parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## List all test cases
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/get-list-ai-quality-test-cases
**Description:** GET /aiQualityCheck/testCase
## `GET /aiQualityCheck/testCase`
### Responses
**`200`** — Successful operation
---
## Accept the expected result of a test ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/patch-accept-expected-result-ai-quality-test-ticket
**Description:** PATCH /aiQualityCheck/testRun/{testRunId}/acceptExpectedResult/{ticketId}
## `PATCH /aiQualityCheck/testRun/{testRunId}/acceptExpectedResult/{ticketId}`
Set the expected value for specific ticket in a run to the observed value. This also updates the expected results for all future runs, and updates the statistics of the test run.
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Cancel a specific test run by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/patch-cancel-ai-quality-test-run
**Description:** PATCH /aiQualityCheck/testRun/{testRunId}/cancel
## `PATCH /aiQualityCheck/testRun/{testRunId}/cancel`
Cancels a test run that is currently in 'scheduled' or 'processing' state. All pending test tickets will be cancelled and the test run will be set to 'cancelled' state.
### Path parameters
### Responses
**`200`** — Successful operation
**`400`** — Test run cannot be cancelled in its current state
**`404`** — Test run not found
**`500`** — Internal error
---
## Update a test case by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/patch-update-ai-quality-test-case
**Description:** PATCH /aiQualityCheck/testCase/{id}
## `PATCH /aiQualityCheck/testCase/{id}`
Update a specific test case using its numeric test case ID. As with `DELETE`, `{id}` here is
a test case id and is pinned to `\d+` by the Dispatcher.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
---
## Update the expected result of a test ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/patch-update-expected-result-ai-quality-test-ticket
**Description:** PATCH /aiQualityCheck/testRun/{testRunId}/updateExpectedResult/{ticketId}
## `PATCH /aiQualityCheck/testRun/{testRunId}/updateExpectedResult/{ticketId}`
Update the expected value for specific ticket in a run to a value passed in the payload. This also updates the expected results for all future runs, and updates the statistics of the test run.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Accept ALL the expected results of for a test run
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/post-accept-all-expected-results-ai-quality-test-run
**Description:** POST /aiQualityCheck/testRun/{testRunId}/acceptAllExpectedResults
## `POST /aiQualityCheck/testRun/{testRunId}/acceptAllExpectedResults`
Set the expected values for all tickets in a run to their observed values. This also updates the expected results for all future runs, and updates the statistics of the test run.
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Add test cases for an AI agent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/post-add-ai-quality-test-cases
**Description:** POST /aiQualityCheck/testCase/{id}
## `POST /aiQualityCheck/testCase/{id}`
Add multiple test cases (tickets) to the specified AI agent. Here `{id}` is the AI agent id —
see the note on `GET` above for the dual meaning of `{id}` on this path.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
---
## Create an AI quality test case
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/post-create-ai-quality-test-case
**Description:** POST /aiQualityCheck/testCase
## `POST /aiQualityCheck/testCase`
Create a new test case (an AI-agent-bound ticket whose expected result is locked in) so it
can be replayed by future test runs. The body specifies the ticket id, target AI agent and
the expected result.
### Request body
### Responses
**`200`** — Created
---
## Re-run a previously executed test run
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/post-rerun-ai-quality-test-run
**Description:** POST /aiQualityCheck/testRun/{testRunId}/rerun
## `POST /aiQualityCheck/testRun/{testRunId}/rerun`
Re-executes the same set of test tickets that the original test run used. The new run is
created in `scheduled` state and processed asynchronously. Compare its result against the
original to measure regressions across AI agent versions.
### Path parameters
### Responses
**`200`** — Re-run scheduled
**`404`** — Original test run not found
---
## Schedule a new AI quality check
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-quality-check/post-schedule-ai-quality-check
**Description:** POST /aiQualityCheck/testRun
## `POST /aiQualityCheck/testRun`
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get a specific custom tool
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-tools/get-get-tool-2
**Description:** GET /tools/{identifier}
## `GET /tools/{identifier}`
Get details of a specific custom tool by its ID or slug. These are user-defined functions marked as tools.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Tool not found
**`500`** — Internal error
---
## Get available tools
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-tools/get-get-tools
**Description:** GET /tools
## `GET /tools`
Get a list of available tools that can be used by AI agents. This includes both built-in tools and user-defined functions marked as tools.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Execute a tool
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ai-tools/post-execute-tool
**Description:** POST /tools/{identifier}/run
## `POST /tools/{identifier}/run`
Execute a specific custom tool by its ID or slug. The request body should contain the parameters the tool expects. Required parameters are validated before execution.
### Path parameters
### Request body
### Responses
**`200`** — Tool executed successfully
**`400`** — Validation error (missing required parameters or type mismatch) or tool execution failed
**`403`** — Unauthorized - missing runExecutors permission or tool is private
**`404`** — Tool not found
**`500`** — Internal error
---
## Clear cache
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/cache/get-clear-cache
**Description:** GET /internal/cache/clear
## `GET /internal/cache/clear`
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get cache entries
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/cache/get-get-cache
**Description:** GET /internal/cache/get/{key}
## `GET /internal/cache/get/{key}`
Get cache entries.
- If no key is provided (or key='all'), all cache items are returned.
- If a key with wildcard characters (* or %) is provided, all keys matching the pattern are returned.
- If a specific key is provided, only that cache item is returned.
- Can filter results with q parameter to find entries where value contains the search string.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Invalidate user cache
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/cache/get-invalidate-user-cache
**Description:** GET /internal/cache/invalidateUser/{userId}
## `GET /internal/cache/invalidateUser/{userId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — User not found
**`500`** — Internal error
---
## Invalidate cache entries by key pattern
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/cache/post-invalidate-internal-cache
**Description:** POST /internal/invalidateCache
## `POST /internal/invalidateCache`
Drops cache entries matching the supplied keys/patterns. Use sparingly — `clearCache` is the
blunter alternative.
### Request body
### Responses
**`200`** — Successful operation
---
## Get contract by id
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/contract/get-get-contract-by-id
**Description:** GET /contract/{contractId}
## `GET /contract/{contractId}`
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Contract not found
**`500`** — Internal error
---
## Get ticket history for a contract
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/contract/get-get-contract-history
**Description:** GET /contract/{contractId}/history
## `GET /contract/{contractId}/history`
Returns the list of tickets ever opened against the given contract, oldest first.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Contract not found
---
## Search for contracts
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/contract/get-search-contracts
**Description:** GET /contract/search
## `GET /contract/search`
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Bad request
---
## Dry-run customer legitimation check
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/contract/post-contract-legitimation-preview
**Description:** POST /contract/legitimation/preview
## `POST /contract/legitimation/preview`
Evaluates the configured legitimation rules (`customerLegitimationRuleAsyncChannels` /
`customerLegitimationRuleSyncChannels`) against a synthetic ticket built from the supplied
fields. No data is written. Useful for testing legitimation settings without a real ticket.
### Request body
### Responses
**`200`** — Legitimation check result
**`400`** — Missing required field
**`403`** — Unauthorized
**`404`** — Contract not found
---
## Delete a persisted value
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/delete-delete-app-data
**Description:** DELETE /app/{appId}/data/{key}
## `DELETE /app/{appId}/data/{key}`
### Path parameters
### Responses
**`200`** — Deleted
---
## Delete an app
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/delete-delete-app
**Description:** DELETE /app/{appId}
## `DELETE /app/{appId}`
### Path parameters
### Responses
**`200`** — Deleted
**`403`** — Unauthorized.
---
## Get metadata for a persisted value
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/get-get-app-data-meta
**Description:** GET /app/{appId}/data/{key}/meta
## `GET /app/{appId}/data/{key}/meta`
Returns size, timestamps and ownership information for the given key.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Key not found.
---
## Get a persisted value
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/get-get-app-data
**Description:** GET /app/{appId}/data/{key}
## `GET /app/{appId}/data/{key}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Key not found.
---
## Get app store entry
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/get-get-app-store-entry
**Description:** GET /app/store/{storeId}
## `GET /app/store/{storeId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Store entry not found.
---
## Get an app by id or slug
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/get-get-app
**Description:** GET /app/{appId}
## `GET /app/{appId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — App not found.
---
## List persisted keys for an app
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/get-list-app-data
**Description:** GET /app/{appId}/data
## `GET /app/{appId}/data`
### Path parameters
### Responses
**`200`** — Successful operation
---
## List app revisions
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/get-list-app-revisions
**Description:** GET /app/{appId}/revisions
## `GET /app/{appId}/revisions`
### Path parameters
### Responses
**`200`** — Successful operation
---
## List app store entries
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/get-list-app-store-apps
**Description:** GET /app/store
## `GET /app/store`
Returns the curated list of installable apps available in the app store.
### Responses
**`200`** — Successful operation
**`500`** — Internal error.
---
## List apps
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/get-list-apps
**Description:** GET /app
## `GET /app`
Return all installed/created apps the caller can read.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized — missing `readApps` permission.
**`500`** — Internal error.
---
## Run an app
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/get-run-app
**Description:** GET /app/{appId}/run
## `GET /app/{appId}/run`
Executes the app in the code-executor sandbox and returns the rendered HTML. Same handler is mounted on POST.
### Path parameters
### Responses
**`200`** — Rendered HTML
**`404`** — App not found.
---
## Update an app
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/patch-update-app
**Description:** PATCH /app/{appId}
## `PATCH /app/{appId}`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized.
---
## Create app
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/post-create-app
**Description:** POST /app
## `POST /app`
Create a new app. Requires `appCreator` permission.
### Request body
### Responses
**`201`** — Created
**`400`** — Missing `name` or invalid payload.
**`403`** — Unauthorized — missing `appCreator` permission.
---
## Import app
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/post-import-app
**Description:** POST /app/import
## `POST /app/import`
Import an app from an exported bundle. Requires `appCreator` permission.
### Request body
### Responses
**`201`** — Imported
**`400`** — Invalid bundle.
**`403`** — Unauthorized.
---
## Install an app from the store
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/post-install-app-from-store
**Description:** POST /app/store/{storeId}/install
## `POST /app/store/{storeId}/install`
### Path parameters
### Responses
**`200`** — Installed
**`403`** — Unauthorized.
---
## Preview an app without persisting changes
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/post-preview-app
**Description:** POST /app/{appId}/preview
## `POST /app/{appId}/preview`
Render the supplied app code in the sandbox and return the resulting HTML. Used by the editor's preview pane.
### Path parameters
### Request body
### Responses
**`200`** — Rendered HTML
---
## Roll back an app to a previous revision
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/post-rollback-app
**Description:** POST /app/{appId}/rollback/{revision}
## `POST /app/{appId}/rollback/{revision}`
### Path parameters
### Responses
**`200`** — Rolled back
**`404`** — Revision not found.
---
## Run an app (with POST body)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/post-run-app-with-body
**Description:** POST /app/{appId}/run
## `POST /app/{appId}/run`
Same as `GET /app/{appId}/run`, but accepts a JSON body forwarded to the app as input.
### Path parameters
### Request body
### Responses
**`200`** — Rendered HTML
---
## Uninstall a previously store-installed app
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/post-uninstall-app-from-store
**Description:** POST /app/store/{storeId}/uninstall
## `POST /app/store/{storeId}/uninstall`
### Path parameters
### Responses
**`200`** — Uninstalled
**`403`** — Unauthorized.
---
## Save a persisted value
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/apps/put-save-app-data
**Description:** PUT /app/{appId}/data/{key}
## `PUT /app/{appId}/data/{key}`
### Path parameters
### Request body
### Responses
**`200`** — Saved
---
## Delete a conversation
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/conversation/delete-delete-conversation
**Description:** DELETE /ticket/{ticketId}/conversation/{conversationId}
## `DELETE /ticket/{ticketId}/conversation/{conversationId}`
Delete an existing conversation (only private conversations can be deleted)
### Path parameters
### Responses
**`200`** — Successful operation
**`400`** — Bad request - Cannot delete public conversation or user doesn't have permission
**`403`** — Unauthorized
**`404`** — Ticket or conversation not found
**`500`** — Internal error
---
## Get a specific conversation by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/conversation/get-get-conversation-by-id
**Description:** GET /ticket/{ticketId}/conversation/{conversationId}
## `GET /ticket/{ticketId}/conversation/{conversationId}`
Retrieve a specific conversation by its ID within a ticket
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Bad request - Conversation does not belong to this ticket
**`403`** — Unauthorized
**`404`** — Ticket or conversation not found
**`500`** — Internal error
---
## Get conversations for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/conversation/get-get-conversations
**Description:** GET /ticket/{ticketId}/conversation
## `GET /ticket/{ticketId}/conversation`
Retrieve all conversations associated with a specific ticket
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Update a conversation
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/conversation/patch-update-conversation
**Description:** PATCH /ticket/{ticketId}/conversation/{conversationId}
## `PATCH /ticket/{ticketId}/conversation/{conversationId}`
Update an existing conversation (internal notes and drafts can be updated; drafts can also be published by changing isDraft to false)
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Bad request - Can only update internal notes or user doesn't own the note
**`403`** — Unauthorized
**`404`** — Ticket or conversation not found
**`500`** — Internal error
---
## Reply to a ticket thread
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/conversation/post-reply-to-ticket
**Description:** POST /ticket/{ticketId}/conversation/reply
## `POST /ticket/{ticketId}/conversation/reply`
Create a new conversation by replying to a ticket thread. This actually sends out an email (for email tickets), triggers sending of a letter (for letter tickets) or a message (for chat tickets). Can also create drafts that require supervisor approval before sending.
### Path parameters
### Query parameters
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Bad request - Invalid input
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Store a new conversation
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/conversation/post-store-conversation
**Description:** POST /ticket/{ticketId}/conversation/store
## `POST /ticket/{ticketId}/conversation/store`
Store a new conversation without sending any messages
### Path parameters
### Request body
### Responses
**`201`** — Conversation created successfully
**`400`** — Bad request - Invalid input
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Get a customer by contract id
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/customer/get-get-customer-by-contract-id
**Description:** GET /customer/byContractId/{contractId}
## `GET /customer/byContractId/{contractId}`
Get a customer and associated contracts
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Contract not found
**`500`** — Internal error
---
## Get a customer by customer id
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/customer/get-get-customer-by-customer-id
**Description:** GET /customer/byCustomerId/{customerId}
## `GET /customer/byCustomerId/{customerId}`
Get a customer and associated contracts
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## Get a customer by ticket id
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/customer/get-get-customer-by-ticket-id
**Description:** GET /customer/byTicketId/{ticketId}
## `GET /customer/byTicketId/{ticketId}`
Get a customer and associated contracts by ticket id. Tickets are mapped to customer using enneo.MIND's AI, or when manually assigned by a user
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — No customer id associated with ticket (yet)
**`500`** — Internal error
---
## Search a customer
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/customer/get-search-customer
**Description:** GET /customer/search
## `GET /customer/search`
Search a customer by firstname, lastname contractId
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## Get a customer by customer id
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/customer/patch-update-customer-by-customer-id
**Description:** PATCH /customer/{customerId}
## `PATCH /customer/{customerId}`
Get a customer and associated contracts
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — No customer id associated with ticket (yet)
**`500`** — Internal error
---
## Invalidate cache for a contract or customer
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/customer/post-invalidate-cache
**Description:** POST /customer/invalidateCache
## `POST /customer/invalidateCache`
This endpoint invalidates the cache for a given contract or customer by their IDs.
### Responses
**`200`** — Cache invalidated successfully.
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## Submit request to cortex for ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/debugging-for-ai-microservice-cortex/post-trigger-cortex-for-ticket
**Description:** POST /experimental/cortex/ticket/{ticketId}/trigger
## `POST /experimental/cortex/ticket/{ticketId}/trigger`
Manually trigger Cortex processing for a ticket.
**Deprecated** — this endpoint will be removed in the 2026-06-14 release.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Get deferrer for contract
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/deferrer/get-get-deferrer-for-contract
**Description:** GET /deferrer/contract/{contractId}
## `GET /deferrer/contract/{contractId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get deferrer for PC
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/deferrer/get-get-deferrer-for-pc
**Description:** GET /deferrer/pc
## `GET /deferrer/pc`
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get an event trace by id
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/event/get-get-event-trace
**Description:** GET /eventTrace/{id}
## `GET /eventTrace/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Event trace not found
---
## Get available event types
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/event/get-get-event-types
**Description:** GET /event/getEventTypes
## `GET /event/getEventTypes`
Returns the catalogue of supported event types with their subtypes and human-readable labels.
### Responses
**`200`** — Successful operation
---
## Get an event by id
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/event/get-get-event
**Description:** GET /event/{id}
## `GET /event/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Event not found
---
## Update an event trace
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/event/patch-update-event-trace
**Description:** PATCH /eventTrace/{id}
## `PATCH /eventTrace/{id}`
### Path parameters
### Request body
### Responses
**`200`** — Updated
**`404`** — Event trace not found
---
## Update an event
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/event/patch-update-event
**Description:** PATCH /event/{id}
## `PATCH /event/{id}`
Patch metadata on an event — usually `status`, `outcome`, or `hookOutcome`. The body contains the partial object to merge.
### Path parameters
### Request body
### Responses
**`200`** — Updated
**`404`** — Event not found
---
## Create an event trace
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/event/post-create-event-trace
**Description:** POST /eventTrace
## `POST /eventTrace`
Persist a single event trace attached to a parent event.
### Request body
### Responses
**`200`** — Created
**`400`** — Invalid payload
**`403`** — Unauthorized
---
## Create event traces in batch
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/event/post-create-event-traces-batch
**Description:** POST /eventTrace/batch
## `POST /eventTrace/batch`
Same as `POST /eventTrace`, but accepts an array of trace payloads. Used by Cortex and other
services that buffer traces and flush them periodically to reduce request overhead.
### Request body
### Responses
**`200`** — Created
**`400`** — Invalid payload
**`403`** — Unauthorized
---
## Create an event
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/event/post-create-event
**Description:** POST /event
## `POST /event`
Manually emit a Mind event. The created event is enqueued for processing by the standard
event pipeline (event hooks, automation, traces).
### Request body
### Responses
**`200`** — Created
**`400`** — Invalid payload
**`403`** — Unauthorized
---
## Search events with filtering and pagination
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/event/post-search-events
**Description:** POST /event/search
## `POST /event/search`
For technical personnel to search and analyze events across the system. Allows searching, filtering, and paginating through events independent of ticket ID. Technical information is always included in the results.
### Query parameters
### Request body
Filters for searching events
### Responses
**`200`** — Successful operation
**`403`** — Forbidden - Insufficient permissions
---
## Execute executor
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/executor-sandbox/post-execute-executor
**Description:** POST /executor/execute/{name}
## `POST /executor/execute/{name}`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get local execution command
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/executor-sandbox/post-get-local-execution-command
**Description:** POST /executor/localExecutionCommand
## `POST /executor/localExecutionCommand`
### Request body
### Responses
**`200`** — Successful execution
**`403`** — Unauthorized
**`500`** — Internal error
---
## Preview executor
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/executor-sandbox/post-preview-executor
**Description:** POST /executor/preview
## `POST /executor/preview`
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Export AI agent performance
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/export/get-export-ai-agent-performance
**Description:** GET /export/aiAgentPerformance
## `GET /export/aiAgentPerformance`
Export per-AI-agent performance metrics (executions, success rate, latency, …) for a time range.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized.
**`500`** — Internal error.
---
## Export AI insights (one row per ticket, one column per question)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/export/get-export-ai-insights
**Description:** GET /export/aiInsights
## `GET /export/aiInsights`
Wide-format export. For each active question the export carries two columns: alias
`insight_<id>` for the value and `confidence_<id>` for the LLM's 0–1 confidence. The
question's human-readable name is used as the XLSX/CSV header. The `reasoning` column
is intentionally excluded from bulk export — it contains free-form AI text that quotes
conversation content; it remains visible per ticket via the ticket-AI-insights endpoint.
Large ranges are handed off to the `exportBigList` async pipeline.
### Query parameters
### Responses
**`200`** — Export file (sync) or async scheduling message
**`403`** — Unauthorized (requires exportData)
---
## Export call log
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/export/get-export-call-log
**Description:** GET /export/callLog
## `GET /export/callLog`
Export the call log as a downloadable file (xlsx/csv/json).
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized.
**`500`** — Internal error.
---
## Export conversations
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/export/get-export-conversations-list
**Description:** GET /export/conversations
## `GET /export/conversations`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal server error
---
## Export custom client reports
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/export/get-export-custom-data
**Description:** GET /export/customData
## `GET /export/customData`
Export data using custom SQL queries with dynamic parameters. This endpoint allows you to execute
pre-configured SQL queries with customizable parameters that replace placeholders in the query.
This endpoint should only be used if standard export endpoints (for tickets, messages, worklog, survey, etc.) do not suffice. It is an adanced feature and every query requires prior approval by your Enneo account manager.
## How Parameters Work
1. **SQL Query Placeholders**: Custom exports contain SQL queries with placeholders like `{limit}`, `{offset}`, `{customerId}`
2. **Parameter Resolution**: Parameters are resolved in this order:
- GET query parameters (highest priority)
- Default values from export configuration
- Required parameters will throw an error if missing
3. **Security**: All parameters are safely bound using prepared statements
## Example Custom Export Configuration
```json
{
"label": "Customer Events Report",
"sqlQuery": "SELECT id, type, createdAt FROM event WHERE customerId = {customerId} ORDER BY id DESC LIMIT {limit} OFFSET {offset}",
"parameters": [
{
"key": "customerId",
"label": "Customer ID",
"description": "The customer to export events for",
"defaultValue": null
},
{
"key": "limit",
"label": "Limit",
"description": "Maximum number of records to return",
"defaultValue": "100"
},
{
"key": "offset",
"label": "Offset",
"description": "Number of records to skip",
"defaultValue": "0"
}
]
}
```
## Example Usage
```
GET /api/mind/export/customData?exportId=0&format=json&customerId=12345&limit=50&offset=0
```
This would execute:
```sql
SELECT id, type, createdAt FROM event WHERE customerId = ? ORDER BY id DESC LIMIT ? OFFSET ?
```
With parameters: `[12345, 50, 0]`
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Bad request - required parameter missing or invalid export configuration
**`403`** — Unauthorized
**`500`** — Internal server error
---
## Export GDPR private data for a customer
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/export/get-export-gdpr-private-data
**Description:** GET /export/gdprPrivateData
## `GET /export/gdprPrivateData`
Export all personally identifiable data tied to a given customer/contract for GDPR data-portability
and right-to-access requests. The call requires the requesting user to hold the relevant GDPR
permission.
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Missing `contractId`/`customerId` or invalid parameters.
**`403`** — Unauthorized — caller lacks GDPR export permission.
**`500`** — Internal error.
---
## Export knowledge sources
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/export/get-export-knowledge-sources
**Description:** GET /export/knowledgeSources/{type}
## `GET /export/knowledgeSources/{type}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal server error
---
## Export training data that is used by the AI's default text answer
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/export/get-export-message-samples
**Description:** GET /export/messageSamples
## `GET /export/messageSamples`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal server error
---
## Export quality assessments
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/export/get-export-quality-assessments
**Description:** GET /export/qualityAssessments
## `GET /export/qualityAssessments`
Export quality assessments with all criterion scores for a given scorecard.
Each row represents one assessment with the following columns:
- Date (createdAt - when the assessment was created)
- Assessment Date (when the supervisor completed the assessment, null for AI-only assessments)
- Reviewed Agent (name of the assessed user)
- Reviewer (name of the reviewer or "AI" for AI-generated assessments)
- State (translated to readable labels: "Ready for Review", "Reviewed", etc.)
- Ticket ID
- Total Score (absolute scored points as integer)
- Total Score (%) (percentage score)
- One column per criterion score (e.g., "Communication Quality - Clarity & Readability")
**Default Scorecard Behavior:**
If `scorecardId` is omitted, the scorecard from the most recent valid assessment is used as default.
**Multi-Sheet XLSX Export:**
When format is `xlsx` and `scorecardId` is omitted, the export generates one Excel sheet per scorecard
that has assessments. Each sheet is named after the scorecard.
**Excluded States:**
Assessments in states `unprocessed`, `aiInProgress`, `deleted`, and `error` are excluded from the export.
Example requests:
```
GET /api/mind/export/qualityAssessments?format=json
GET /api/mind/export/qualityAssessments?format=xlsx&scorecardId=1
GET /api/mind/export/qualityAssessments?format=xlsx&from=2024-01-01&to=2024-12-31
```
### Query parameters
### Responses
**`200`** — Export returned successfully.
**`403`** — Unauthorized – user lacks `qualityViewAssessmentAll` permission.
**`500`** — Internal server error
---
## Export user profiles and their permissions
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/export/get-export-users
**Description:** GET /export/users
## `GET /export/users`
Export all user profiles and their associated data including permissions.
Used primarily by workforce managers to quickly view all profiles.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized - User doesn't have permission to export user profiles
**`500`** — Internal server error
---
## Preview a generic export by key
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/export/get-generic-export-preview
**Description:** GET /export/{key}/preview
## `GET /export/{key}/preview`
Returns a preview of the data that `GET /export/{key}` would produce — the first rows and
column metadata, used to power the export-overview UI in ops-fe.
### Path parameters
### Responses
**`200`** — Successful operation
**`400`** — Unknown or invalid export key.
**`403`** — Unauthorized.
**`500`** — Internal error.
---
## Generic export by key
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/export/get-generic-export
**Description:** GET /export/{key}
## `GET /export/{key}`
Dispatches to the per-key export handler that matches `key`. Use this endpoint for keys that
don't have a dedicated path on this page (e.g. `reporting_tickets`, `reporting_messages`,
`reporting_worklog`, `survey`). The accepted query parameters and response shape depend on
the chosen key — see the dedicated schema blocks (`exportReportingTickets`,
`exportReportingMessages`, `exportReportingWorklog`, `exportSurveyResponses`) in
`endpoints/export.yaml` for the per-key contract.
Large result sets are queued asynchronously and delivered to the current user's email; small
sets stream the file in the response body.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation — file body or async-confirmation payload.
**`400`** — Unknown or invalid export key.
**`403`** — Unauthorized.
**`500`** — Internal error.
---
## Delete a file
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/file-manager/delete-delete-managed-file
**Description:** DELETE /files/manager/file
## `DELETE /files/manager/file`
### Request body
### Responses
**`200`** — File deleted successfully
**`403`** — Permission denied
**`409`** — File is in use and cannot be deleted
**`500`** — Internal error
---
## Delete a folder and its contents
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/file-manager/delete-delete-managed-folder
**Description:** DELETE /files/manager/folder
## `DELETE /files/manager/folder`
### Request body
### Responses
**`200`** — Folder deleted successfully
**`403`** — Permission denied
**`404`** — Folder not found
**`409`** — Folder contains files that are in use
**`500`** — Internal error
---
## Get file usage information
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/file-manager/get-get-managed-file-usages
**Description:** GET /files/manager/usages
## `GET /files/manager/usages`
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Bad request
**`403`** — Permission denied
**`500`** — Internal error
---
## List files and folders in managed-files storage
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/file-manager/get-list-managed-files
**Description:** GET /files/manager/list
## `GET /files/manager/list`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Permission denied
**`500`** — Internal error
---
## Rename or move a file
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/file-manager/patch-update-managed-file
**Description:** PATCH /files/manager/file
## `PATCH /files/manager/file`
### Request body
### Responses
**`200`** — File renamed successfully
**`403`** — Permission denied
**`404`** — File not found
**`409`** — Target file already exists
**`500`** — Internal error
---
## Rename or move a folder
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/file-manager/patch-update-managed-folder
**Description:** PATCH /files/manager/folder
## `PATCH /files/manager/folder`
### Request body
### Responses
**`200`** — Folder renamed successfully
**`403`** — Permission denied
**`404`** — Folder not found
**`500`** — Internal error
---
## Upload a file to managed-files storage
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/file-manager/post-create-managed-file
**Description:** POST /files/manager/file
## `POST /files/manager/file`
### Request body
### Responses
**`200`** — File uploaded successfully
**`400`** — Bad request
**`403`** — Permission denied
**`409`** — File already exists
**`500`** — Internal error
---
## Create a folder
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/file-manager/post-create-managed-folder
**Description:** POST /files/manager/folder
## `POST /files/manager/folder`
### Request body
### Responses
**`200`** — Folder created successfully
**`403`** — Permission denied
**`409`** — Folder already exists
**`500`** — Internal error
---
## Delete a folder
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/files-connector/delete-delete-files-connector-folder
**Description:** DELETE /knowledgeSource/filesConnector/folders/{id}
## `DELETE /knowledgeSource/filesConnector/folders/{id}`
Deletes a folder and all its contents recursively. For each contained file article, calls `KnowledgeSource::delete()` and emits a `knowledgeSourceChanged action=delete` event so Cortex removes the vectors. Sub-folders are also deleted.
### Path parameters
### Responses
**`200`** — Folder deleted successfully
**`404`** — Folder not found
---
## Download original file
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/files-connector/get-get-files-connector-file-original
**Description:** GET /knowledgeSource/filesConnector/{id}/original
## `GET /knowledgeSource/filesConnector/{id}/original`
Returns a 302 redirect to the internal storage URL of the original uploaded binary. The storage endpoint performs regular-vs-archive lookup.
### Path parameters
### Responses
**`302`** — Redirect to the original file URL
**`404`** — File not found or no original URL stored
---
## Get files connector
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/files-connector/get-get-files-connector
**Description:** GET /knowledgeSource/filesConnector
## `GET /knowledgeSource/filesConnector`
Returns the files connector row (auto-created if missing), including all folder structure rows and file knowledge_source rows underneath. The connector is a singleton per installation.
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Move a file to a different folder
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/files-connector/patch-move-files-connector-file
**Description:** PATCH /knowledgeSource/filesConnector/{id}/move
## `PATCH /knowledgeSource/filesConnector/{id}/move`
Moves a file article to a new folder and rebuilds its `source` path. Fires a `knowledgeSourceChanged action=update` event.
### Path parameters
### Request body
### Responses
**`200`** — File moved successfully
**`404`** — File or folder not found
---
## Rename or move a folder
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/files-connector/patch-update-files-connector-folder
**Description:** PATCH /knowledgeSource/filesConnector/folders/{id}
## `PATCH /knowledgeSource/filesConnector/folders/{id}`
Renames and/or moves a folder. After the change, rebuilds the `source` column for all descendant files and emits one `knowledgeSourceChanged action=update` event per descendant. Cortex handles these via `update_properties` (no re-embedding).
### Path parameters
### Request body
### Responses
**`200`** — Folder updated successfully
**`404`** — Folder or parent folder not found
---
## Create a folder
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/files-connector/post-create-files-connector-folder
**Description:** POST /knowledgeSource/filesConnector/folders
## `POST /knowledgeSource/filesConnector/folders`
Creates a new folder under the files connector hierarchy.
### Request body
### Responses
**`200`** — Folder ensured (created or already existed)
**`404`** — Parent folder not found
**`422`** — Folder name is required
---
## Refresh the index for a file
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/files-connector/post-refresh-files-connector-file-index
**Description:** POST /knowledgeSource/filesConnector/{id}/refreshIndex
## `POST /knowledgeSource/filesConnector/{id}/refreshIndex`
Forces Cortex to re-embed the file's current `text` without re-parsing the original binary. Preserves manual Markdown edits. Bumps `modifiedAt` unconditionally and fires `knowledgeSourceChanged action=update`. Use this when the AI search seems stale or after an embedding-model change; use `reindex` to discard manual edits and re-parse the original.
### Path parameters
### Responses
**`200`** — Index refresh queued successfully
**`404`** — File not found
---
## Replace the binary of a file
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/files-connector/post-replace-files-connector-file
**Description:** POST /knowledgeSource/filesConnector/{id}/replace
## `POST /knowledgeSource/filesConnector/{id}/replace`
Replaces the binary backing an existing file knowledge_source. The KS id is preserved
(so embeddings keep their identity in downstream stores); the row's `name`, `title`,
`source` and `data.original*` fields are refreshed to match the new file.
The new file may have a different filename and extension from the previous one — replace
is keyed by KS id, not by filename. A 422 is returned if the new filename collides with
another active file in the same folder.
Side-effects mirror an initial upload: the old S3 object is removed, the new binary is
stored under the same KS id, Markdown is re-parsed (Firecrawl / Cortex vision / plaintext
depending on extension), page thumbnails are regenerated, and `data.hasManualMarkdownEdits`
is reset to `false`. A `knowledgeSourceChanged action=update` event is emitted so Cortex
re-embeds the new content.
### Path parameters
### Responses
**`200`** — File replaced successfully
**`400`** — Incomplete upload (partial transfer)
**`404`** — File knowledge source not found
**`413`** — File size exceeds limit
**`422`** — No file provided, unsupported type, MIME spoofing, archived file, or the new filename
collides with another active file in the same folder.
**`500`** — Internal error
---
## Reset file to original (re-parse)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/files-connector/post-reset-files-connector-file-to-original
**Description:** POST /knowledgeSource/filesConnector/{id}/resetToOriginal
## `POST /knowledgeSource/filesConnector/{id}/resetToOriginal`
Re-downloads the original binary from storage, re-converts it to Markdown, and updates the knowledge_sources row. **Destructive** — discards any manual Markdown edits and clears `hasManualMarkdownEdits`. If the embedding hash is unchanged, skips firing the `knowledgeSourceChanged` event (saves a needless Weaviate upsert) but still bumps `modifiedAt`. Use `refreshIndex` to re-embed the current text non-destructively.
### Path parameters
### Responses
**`200`** — File re-indexed successfully
**`404`** — File not found
**`500`** — Could not download original file
---
## Upload a file (or batch of files)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/files-connector/post-upload-files-connector-file
**Description:** POST /knowledgeSource/filesConnector/upload
## `POST /knowledgeSource/filesConnector/upload`
Uploads one or more files to the files connector. Each file is:
1. Validated (extension allowlist + 50 MB per-file cap + MIME-type sniff)
2. Stored in MinIO under the `knowledgeSources/` prefix
3. Converted to Markdown (Firecrawl for office/PDF, Cortex vision LLM for images, direct read for .md/.txt)
4. Saved as a `knowledge_sources` row with `type='file'`
5. Triggers a `knowledgeSourceChanged` event for Cortex indexing
**Single-file mode** (backward-compatible): send `name="file"` — response is `{success, id}`.
**Batch mode**: send `name="files[]"` with multiple parts — response is `{successful: [{id, name}], failed: [{name, error}]}`. Max 20 files and 50 MB total per request. Files are processed in parallel via Amp futures. Per-file errors land in `failed` without aborting the batch.
### Responses
**`200`** — Single-file: `{success: true, id: N}`.
Batch: `{successful: [{id, name}], failed: [{name, error}]}` — HTTP 200 even when some files failed.
**`400`** — Incomplete upload (partial transfer)
**`413`** — File or total batch size exceeds limit
**`422`** — No file provided, unsupported type, MIME spoofing, or too many files in batch
**`500`** — Internal error
---
## Get agent queue status
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/general/get-get-agents-queue
**Description:** GET /agents/queue
## `GET /agents/queue`
Get information about agent availability and expected waiting times for customer service
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get documentation
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/general/get-get-documentation
**Description:** GET /docs/{path}
## `GET /docs/{path}`
Serves the Mind documentation index or a specific document at the given path.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Documentation not found
**`500`** — Internal error
---
## Get merged OpenAPI spec
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/general/get-get-open-api-spec
**Description:** GET /docs/open-api
## `GET /docs/open-api`
Returns the fully merged OpenAPI YAML document with all `$ref` references resolved.
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get version
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/general/get-get-version
**Description:** GET /version
## `GET /version`
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Run cron job
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/general/get-run-cron-job
**Description:** GET /cron/{interval}
## `GET /cron/{interval}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Render a customer survey form
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/general/get-show-customer-survey
**Description:** GET /survey/{id}
## `GET /survey/{id}`
Renders the customer-facing survey form. The numeric `id` resolves to the survey row that was
generated when the originating ticket was closed; the public link in the closing email points
here.
### Path parameters
### Responses
**`200`** — Survey HTML
**`404`** — Survey not found or expired
---
## Create a reminder
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/general/post-create-reminder
**Description:** POST /reminder
## `POST /reminder`
### Request body
### Responses
**`201`** — Reminder created
**`403`** — Unauthorized
**`500`** — Internal error
---
## Submit a customer survey
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/general/post-submit-customer-survey
**Description:** POST /survey/{id}
## `POST /survey/{id}`
Submit the response payload generated by the rendered survey form.
### Path parameters
### Request body
### Responses
**`200`** — Submitted (or already submitted — idempotent)
**`404`** — Survey not found or expired
---
## Submit a survey response
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/general/post-submit-survey
**Description:** POST /survey/{reference}-{ticketId}
## `POST /survey/{reference}-{ticketId}`
### Path parameters
### Request body
The survey response
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Validate a value of the given type
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/general/post-validate
**Description:** POST /validation/{type}
## `POST /validation/{type}`
Validates a value against the rules of the specified validation type. Supported types are `email` and `letterAddress`.
### Path parameters
### Request body
The value to validate
### Responses
**`200`** — Validation result
**`400`** — Bad request — missing required field or unsupported type
**`500`** — Internal error
---
## Get health status of cron jobs
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/health/get-get-health-cron
**Description:** GET /health/cron
## `GET /health/cron`
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get health status
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/health/get-get-health
**Description:** GET /health
## `GET /health`
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Container-level health probe
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/health/get-health-containers
**Description:** GET /health/containers
## `GET /health/containers`
Detailed health check that reports the status of each container Mind depends on (Auth, Cortex,
io-proxy, ACD, code-executor). Used by uptime monitors that need a more granular signal than
`/health`.
### Responses
**`200`** — Successful operation
**`500`** — At least one dependency is unhealthy
---
## Delete an intent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/intent/delete-delete-intent
**Description:** DELETE /intent/{intentId}
## `DELETE /intent/{intentId}`
Delete an intent. This is only possible if the intent is not yet executed
### Path parameters
### Responses
**`200`** — Intent was deleted
**`403`** — Unauthorized
**`404`** — Intent not found
**`500`** — Internal error
---
## Get an intent by id
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/intent/get-get-intent-by-id
**Description:** GET /intent/{intentId}
## `GET /intent/{intentId}`
An intent defines in a structured and machine-processable way what the customer wanted, e.g. *save my meter reading of 265 kWh* or *send me a bill*
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## Get intent(s) detected/assigned for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/intent/get-get-intent-by-ticket-id
**Description:** GET /intent/byTicketId/{ticketId}
## `GET /intent/byTicketId/{ticketId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## List of all available intents and categories
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/intent/get-get-intent-list
**Description:** GET /intent/list
## `GET /intent/list`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## Get a preview of an intent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/intent/get-get-intent-preview
**Description:** GET /intent/preview/{aiAgentId}
## `GET /intent/preview/{aiAgentId}`
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## Execute an option for a specific intent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/intent/post-execute-intent
**Description:** POST /intent/{intentId}/execute
## `POST /intent/{intentId}/execute`
### Path parameters
### Request body
Optional additional parameters to override/validate the existing data in the intent or trigger a response to the customer
### Responses
**`200`** — Option was processed
**`403`** — Unauthorized
**`404`** — Intent not found
**`500`** — Internal error
---
## Update an intent with new, modified input data
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/intent/put-update-intent
**Description:** PUT /intent/{intentId}
## `PUT /intent/{intentId}`
### Path parameters
### Request body
Parameters to override/validate the existing data in the intent
### Responses
**`200`** — Intent was updated
**`403`** — Unauthorized
**`404`** — Intent not found
**`500`** — Internal error
---
## Explain time-tracking decisions
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/internal-enneo-only/get-explain-time-tracking
**Description:** GET /internal/explainTimeTracking
## `GET /internal/explainTimeTracking`
Diagnostic endpoint that returns the time-tracking computation breakdown for the current user
or a given user/window. Used to debug worklog disputes.
### Query parameters
### Responses
**`200`** — Successful operation
---
## List Superset users
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/internal-enneo-only/get-get-superset-users
**Description:** GET /internal/getSupersetUsers
## `GET /internal/getSupersetUsers`
Returns the user list provisioned in the Superset analytics tenant for this client. Used by
the Settings UI when wiring Superset SSO.
### Responses
**`200`** — Successful operation
---
## Get a telemetry trace
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/internal-enneo-only/get-get-telemetry-trace
**Description:** GET /internal/telemetry/trace/{traceId}
## `GET /internal/telemetry/trace/{traceId}`
Proxies the admin portal telemetry endpoint
(`admin.enneo.ai/api/telemetry/clients/{CLIENT_ID}/traces/{traceId}`) for the current
environment's client. Restricted to enneo and partner users (HTTP 403 for all other profile types).
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Forbidden — caller is not an enneo or partner user
**`502`** — Upstream failure — admin portal returned an error
---
## Get worker status
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/internal-enneo-only/get-get-worker-status
**Description:** GET /internal/workerStatus
## `GET /internal/workerStatus`
Returns liveness + progress information for all Mind workers (`worker_*.log`).
### Responses
**`200`** — Successful operation
---
## Initialise message samples (dev)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/internal-enneo-only/get-init-message-samples
**Description:** GET /internal/initMessageSamples
## `GET /internal/initMessageSamples`
Loads canned message-sample fixtures into the local DB. Dev-only.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized / disabled in this environment
---
## Load seed tickets (dev)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/internal-enneo-only/get-load-seed-tickets
**Description:** GET /internal/loadSeedTickets
## `GET /internal/loadSeedTickets`
Loads a curated set of seed tickets into the local DB for development and demos.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized / disabled in this environment
---
## Reset the local environment
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/internal-enneo-only/get-reset
**Description:** GET /internal/reset
## `GET /internal/reset`
Wipes data tables and reseeds dev fixtures. Available only in non-production environments.
### Responses
**`200`** — Reset complete
**`403`** — Unauthorized / disabled in this environment
---
## Run an ad-hoc read-only query
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/internal-enneo-only/get-run-internal-query
**Description:** GET /internal/query
## `GET /internal/query`
Diagnostic SQL endpoint — accepts a SQL string in `q` and returns the rows. Locked down to
Enneo staff and never enabled on customer-facing deployments.
### Query parameters
### Responses
**`200`** — Successful operation
---
## Sync phone numbers from the telephony provider (read)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/internal-enneo-only/get-sync-phone-numbers-get
**Description:** GET /internal/syncPhoneNumbers
## `GET /internal/syncPhoneNumbers`
Pulls the current list of phone numbers configured at the telephony provider and reconciles
them with `subchannel` rows in Mind. Mounted on both GET (preview) and POST (apply).
### Responses
**`200`** — Successful operation
---
## Receive processed ticket response from Cortex
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/internal-enneo-only/post-callback-from-cortex-for-ticket
**Description:** POST /internal/cortex/ticket/{ticketId}/callback
## `POST /internal/cortex/ticket/{ticketId}/callback`
Internal endpoint called by the Cortex microservice to deliver AI processing results for a ticket.
Requires the `x-internal-communication-token` header — regular user tokens are rejected.
### Path parameters
### Request body
The response from Cortex
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Convert a PDF to an image
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/internal-enneo-only/post-convert-pdf-to-image
**Description:** POST /internal/helpers/convertPdfToImage
## `POST /internal/helpers/convertPdfToImage`
Internal helper used by various Mind flows (e.g. document previews, intent input). Accepts a PDF file
reference (storage path or base64 payload) and returns the rendered page(s) as image(s).
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid PDF input
**`403`** — Unauthorized
---
## Sync phone numbers from the telephony provider (apply)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/internal-enneo-only/post-sync-phone-numbers-post
**Description:** POST /internal/syncPhoneNumbers
## `POST /internal/syncPhoneNumbers`
Same as `GET /internal/syncPhoneNumbers`, but persists the diff.
### Responses
**`200`** — Successful operation
---
## Get knowledge source dashboard
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/knowledge-sources/get-get-knowledge-source-dashboard
**Description:** GET /knowledgeSource/dashboard
## `GET /knowledgeSource/dashboard`
Returns aggregated KPIs for the knowledge base: total entries per type/structure node,
processing status, and recent ingestion errors. Used to power the dashboard widget on the
Knowledge Sources landing page.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
---
## Get one NEO session
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-sessions/get-get-neo-session
**Description:** GET /sessions/{id}
## `GET /sessions/{id}`
Returns a single session with its `ticketId` — the session→ticket lookup used on a cold-start when only the session id is known. Caller must be a participant of the session, or have `accessTechnicalEvents` permission.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Not a participant of this session
**`404`** — Session not found
---
## Get session transcript
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-sessions/get-list-neo-session-messages
**Description:** GET /sessions/{id}/messages
## `GET /sessions/{id}/messages`
Returns all messages for a session, ordered by createdAt ascending. Caller must be a participant of the session, or have `accessTechnicalEvents` permission. `costUsd`, `usageJson`, and `model` are only included when the caller has `reportAiPerformance`.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Not a participant of this session
**`404`** — Session not found
---
## List NEO sessions
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-sessions/get-list-neo-sessions
**Description:** GET /sessions
## `GET /sessions`
Returns sessions the caller participates in. With `?ticketId=` and `accessTechnicalEvents` permission: returns all sessions on that ticket. With `?ticketId=` as a plain human agent (ticket must be accessible): returns the caller's own sessions on that ticket **plus** the ticket's unclaimed (owner-less) cortex warm-start sessions — the discover-and-continue path, so the human agent picks up cortex's pre-work and continues the same session. `costUsd`/`model` are only included when the caller has `reportAiPerformance`.
### Query parameters
### Responses
**`200`** — Successful operation
**`401`** — Unauthorized
---
## Update session participants
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-sessions/patch-patch-neo-session
**Description:** PATCH /sessions/{id}
## `PATCH /sessions/{id}`
Add or remove participants from a session. The caller must already be a participant of the session. A future `title` field is accepted but ignored.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Not a participant of this session
**`404`** — Session not found
---
## Append a message to a session
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-sessions/post-create-neo-session-message
**Description:** POST /sessions/{id}/messages
## `POST /sessions/{id}/messages`
Append a message to a session. On the first message the session is lazily created and the initiator is recorded as a participant.
A human agent who is not yet a participant may append to an **unclaimed** (owner-less) cortex warm-start session on a ticket they can access — this **claims** it (they become its first participant), the discover-and-continue path. Posting to a session already claimed by another human returns `403`.
**Auth rules:** - Cookie/JWT (human agent): sender = {id, name, email}, direction = 'in' - Internal token (cortex/NEO): sender = null, direction = 'out';
`costUsd`, `usageJson`, `model` accepted only from the internal caller.
The `to` field is stamped by Mind from the current participant set — never read from the request body.
### Path parameters
### Request body
### Responses
**`201`** — Message created
**`400`** — Missing or invalid fields
**`401`** — Unauthorized
---
## Create a NEO session
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-sessions/post-create-neo-session
**Description:** POST /sessions
## `POST /sessions`
Create a session with a **server-minted** UUID — the BE-owned id-generation path. Always creates a new session (a ticket may have many; the UI decides how many). This is an additional path, not a replacement: a client may still lazily create a session by POSTing its first message with a self-minted UUID (see `POST /sessions/{id}/messages`).
The human agent caller is recorded as a participant; an internal (cortex) caller creates an unowned session. `costUsd`/`model` in the response are only included when the caller has `reportAiPerformance`.
### Request body
### Responses
**`201`** — Session created
**`401`** — Unauthorized
---
## Soft-delete a NEO tool
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-tools/delete-delete-tool
**Description:** DELETE /tool/{id}
## `DELETE /tool/{id}`
Soft-deletes the tool and appends a delete snapshot to its history.
### Path parameters
### Responses
**`200`** — Deleted
**`404`** — Tool not found
---
## NEO tool change history
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-tools/get-get-tool-history
**Description:** GET /tool/{id}/history
## `GET /tool/{id}/history`
Append-only version history (newest first), never pruned.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Tool not found
---
## Get a NEO tool
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-tools/get-get-tool
**Description:** GET /tool/{id}
## `GET /tool/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Tool not found
---
## List NEO tools
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-tools/get-list-tools
**Description:** GET /tool
## `GET /tool`
Returns live (non-deleted) tools. With `?aiAgentId=N`, returns shared tools (`aiAgentId` null) plus that agent's private tools.
### Query parameters
### Responses
**`200`** — Successful operation
**`401`** — Unauthorized
---
## Update a NEO tool
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-tools/patch-update-tool
**Description:** PATCH /tool/{id}
## `PATCH /tool/{id}`
Updates `name`, `description`, `definition` and/or `aiAgentId`. `slug` is immutable and ignored. Re-validated via an ephemeral agent; an update snapshot is appended to history.
### Path parameters
### Request body
### Responses
**`200`** — Updated
**`404`** — Tool not found
**`422`** — Invalid definition (validation violations returned)
---
## Create a NEO tool
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-tools/post-create-tool
**Description:** POST /tool
## `POST /tool`
Creates a tool. `slug` is the cortex reference name; it defaults to a slug of `name` and is immutable after creation. The definition is validated via an ephemeral agent before saving; a create snapshot is appended to the tool history.
### Request body
### Responses
**`201`** — Created
**`400`** — Missing name or invalid slug
**`409`** — A tool with this slug already exists
**`422`** — Invalid definition (validation violations returned)
---
## Delete partner
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/partner/delete-delete-partner
**Description:** DELETE /partner/{id}
## `DELETE /partner/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get partner
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/partner/get-get-partner-by-id
**Description:** GET /partner/{id}
## `GET /partner/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get all partner
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/partner/get-get-partners
**Description:** GET /partner/list
## `GET /partner/list`
### Query parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Update partner
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/partner/patch-update-partner
**Description:** PATCH /partner/{id}
## `PATCH /partner/{id}`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Create partner
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/partner/post-create-partner
**Description:** POST /partner
## `POST /partner`
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Soft-delete a NEO skill
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-skills/delete-delete-skill
**Description:** DELETE /skill/{id}
## `DELETE /skill/{id}`
Soft-deletes the skill and appends a delete snapshot to its history.
### Path parameters
### Responses
**`200`** — Deleted
**`404`** — Skill not found
---
## NEO skill change history
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-skills/get-get-skill-history
**Description:** GET /skill/{id}/history
## `GET /skill/{id}/history`
Append-only version history (newest first), never pruned.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Skill not found
---
## Get a NEO skill
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-skills/get-get-skill
**Description:** GET /skill/{id}
## `GET /skill/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Skill not found
---
## List NEO skills
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-skills/get-list-skills
**Description:** GET /skill
## `GET /skill`
Returns live (non-deleted) skills. With `?aiAgentId=N`, returns shared skills (`aiAgentId` null) plus that agent's private skills.
### Query parameters
### Responses
**`200`** — Successful operation
**`401`** — Unauthorized
---
## Update a NEO skill
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-skills/patch-update-skill
**Description:** PATCH /skill/{id}
## `PATCH /skill/{id}`
Updates `name`, `description`, `content` and/or `aiAgentId`. `slug` is immutable and ignored. Re-validated via an ephemeral agent; an update snapshot is appended to history.
### Path parameters
### Request body
### Responses
**`200`** — Updated
**`404`** — Skill not found
**`422`** — Invalid skill (validation violations returned)
---
## Create a NEO skill
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/neo-skills/post-create-skill
**Description:** POST /skill
## `POST /skill`
Creates a skill. `slug` is the cortex reference name; it defaults to a slug of `name` and is immutable after creation. `content` is the `skill.md` markdown body. Validated via an ephemeral agent before saving; a create snapshot is appended to the skill history.
### Request body
### Responses
**`201`** — Created
**`400`** — Missing name or invalid slug
**`409`** — A skill with this slug already exists
**`422`** — Invalid skill (validation violations returned)
---
## Check whether worklogs exist for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality/get-ticket-worklog-exists
**Description:** GET /ticket/{ticketId}/worklog/exists
## `GET /ticket/{ticketId}/worklog/exists`
Lightweight existence probe used by the UI to decide whether to show the worklog tab. Cheaper
than `GET /ticket/{ticketId}/worklog` because it skips loading the worklog entries.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Ticket not found
---
## Delete specific profile
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/delete-delete-specific-profile
**Description:** DELETE /profile/{id}
## `DELETE /profile/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get a JWT for a user (browser-friendly)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/get-get-jwt-for-profile
**Description:** GET /jwt/{id}
## `GET /jwt/{id}`
Returns a JWT scoped to the given user. The GET form is intended for browser navigation
during dev / impersonation flows — `POST` is the canonical form used by tooling.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Profile not found
---
## Get profile image
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/get-get-profile-image
**Description:** GET /profile/{id}/image
## `GET /profile/{id}/image`
Returns the profile image for a user. If the user has the permission 'readUserNamesOfNonTeamMates' or the requested user is in the same team, returns the actual image from Auth service. Otherwise returns a stub image.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Image not found
**`500`** — Internal error
---
## Get currently logged in user's profile
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/get-get-profile
**Description:** GET /profile
## `GET /profile`
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Concurrent users + telephony/chat counters (admin polling)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/get-get-profiles-online-summary
**Description:** GET /profiles/onlineSummary
## `GET /profiles/onlineSummary`
Compact summary of users who were active in the last 10 minutes, broken
down by user type, plus current live-call and in-queue counters from ACD
and the number of ongoing chats (open chat tickets with a message in the
last 5 minutes).
Used by the admin portal for concurrent-user monitoring; replaces the
deprecated `?lastSeen=online` summary fast-path on `GET /profiles`.
Requires `readUserLastSeenDate` or `readAnyUserProfile`.
### Responses
**`200`** — Successful operation
**`403`** — Permission denied
**`500`** — Internal error
---
## Search profiles
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/get-get-profiles
**Description:** GET /profiles
## `GET /profiles`
### Query parameters
### Responses
**`200`** — Successful operation
---
## Get specific profile
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/get-get-specific-profile
**Description:** GET /profile/{id}
## `GET /profile/{id}`
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get available options for analytics roles
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/get-get-superset-roles
**Description:** GET /profile/{id}/supersetRoles
## `GET /profile/{id}/supersetRoles`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get special time tracking status options
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/get-get-time-tracking-status-options
**Description:** GET /profile/timeTrackingStatusOptions
## `GET /profile/timeTrackingStatusOptions`
Returns the key time tracking status options configured in the system:
- `active`: First status with autoActiveMode set to true
- `away`: First status with autoAwayMode set to true
- `absent`: First status with both allowTicketDelegation and interactionsBlocked set to true,
or if none exist, the first status with only allowTicketDelegation set to true
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Explain routing priorities for a user
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/get-get-user-routing
**Description:** GET /profile/{id}/routing
## `GET /profile/{id}/routing`
Explain the ticket routing considering the routing priorities. Useful when a user wants to know why they are being pushed a certain ticket.
The response format is controlled by `limit`:
- **`limit=1` (short format)**: returns `{"details":[{"routingPriority":<int|string>,"id":<int>}]}`.
`routingPriority` is an integer when the ticket will be routed to this user, or a localized human-readable string reason when it will not.
An empty `details` array means the ticket is not in the routing queue (closed, AI-only, or non-existent).
- **`limit>1` or default (full format)**: returns full routing metadata including `routingPriority` (ordered ticket IDs), `details` (all fields), `total`, and `query`.
Permission: `updateUserProfileSkills` is required, EXCEPT for a single-ticket self-check —
`limit=1` + numeric `q` (ticket id) + own profile — where the permission check is bypassed.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Ping endpoint to track user activity
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/get-ping-profile
**Description:** GET /profile/ping
## `GET /profile/ping`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Show the current access token
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/get-show-access-token
**Description:** GET /profile/showAccessToken
## `GET /profile/showAccessToken`
Returns the access token the user is currently using to authenticate. No specific permissions required, the user just needs to be logged in.
### Responses
**`200`** — Successful operation
**`401`** — Not authenticated
**`500`** — Internal error
---
## Bulk-update routing status
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/patch-bulk-update-routing-status
**Description:** PATCH /profiles/routingStatus
## `PATCH /profiles/routingStatus`
Update routing status (calls / chats) for multiple profiles in a single call. The body lists
profile ids and the routing-status object to apply to each.
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Permission denied
---
## Update multiple profiles at once
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/patch-bulk-update-specific-profiles
**Description:** PATCH /profiles
## `PATCH /profiles`
Bulk update multiple user profiles. Each profile update can include settings and auth service fields.
Requires 'updateSpecificProfile' permission. For enneo users, also requires 'enneoAdmin' permission.
### Request body
### Responses
**`200`** — Results of bulk update operation
**`400`** — Invalid request format
**`403`** — Insufficient permissions
---
## Update profile routing status
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/patch-update-routing-status
**Description:** PATCH /profile/{id}/routingStatus
## `PATCH /profile/{id}/routingStatus`
Update the routing status for calls and chats for a specific profile. Necessary to manually control which agents should be able to take calls or chats when integrating a custom telephony solution. Requires having 'updateSpecificProfile' permission.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized - user does not have permission to update this profile's routing status
---
## Update specific profile
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/patch-update-specific-profile
**Description:** PATCH /profile/{id}
## `PATCH /profile/{id}`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Create a new user
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/post-create-specific-profile
**Description:** POST /profile
## `POST /profile`
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Build a polished portrait prompt from four selections
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/post-generate-portrait-prompt
**Description:** POST /profile/generatePortraitPrompt
## `POST /profile/generatePortraitPrompt`
Takes four playful dropdown selections (person, style, mood, setting) and
uses an LLM to turn them into a polished image-generation prompt. The
resulting string is intended to be shown in an editable textarea in the
UI and then submitted to `/profile/generatePortrait`.
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Generate a portrait image from a prompt
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/post-generate-portrait
**Description:** POST /profile/generatePortrait
## `POST /profile/generatePortrait`
Calls the image-generation backend (Grok via the LiteLLM proxy)
using the provided prompt to produce a single 512x512 portrait. The
generated image is fetched into Mind's storage so the response never
leaks the provider URL. Use `/profile/generatePortraitPrompt` first to
build a polished prompt from descriptive selections.
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Missing or empty prompt
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get a JWT for a user
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/profile/post-post-jwt-for-profile
**Description:** POST /jwt/{id}
## `POST /jwt/{id}`
Returns a JWT scoped to the given user. Use this form from tooling; GET exists for browser
access in dev.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Profile not found
---
## Top-performing AI agents across the time window
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/reports/get-get-top-ai-agents-performance
**Description:** GET /report/topAiAgentsPerformance
## `GET /report/topAiAgentsPerformance`
Ranked list of AI agents by execution volume and quality metrics for the requested period.
Powers the "Top AI agents" widget on the reporting dashboard.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
---
## Delete a role
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/role/delete-delete-role
**Description:** DELETE /roles/{id}
## `DELETE /roles/{id}`
### Path parameters
### Responses
**`200`** — Role deleted successfully
**`403`** — Unauthorized
**`404`** — Role not found
**`500`** — Internal error
---
## Get role by id
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/role/get-get-role
**Description:** GET /roles/{id}
## `GET /roles/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Role not found
**`500`** — Internal error
---
## Get roles
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/role/get-get-roles
**Description:** GET /roles
## `GET /roles`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Update a role
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/role/patch-update-role
**Description:** PATCH /roles/{id}
## `PATCH /roles/{id}`
### Path parameters
### Request body
### Responses
**`200`** — Role updated successfully
**`403`** — Unauthorized
**`404`** — Role not found
**`500`** — Internal error
---
## Add a new role
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/role/post-create-role
**Description:** POST /roles
## `POST /roles`
### Request body
### Responses
**`200`** — Role added successfully
---
## Get AI performance metrics for a specific AI agent
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/report/get-get-ai-agent-performance
**Description:** GET /report/aiAgentPerformance/{aiAgentId}
## `GET /report/aiAgentPerformance/{aiAgentId}`
Returns performance metrics scoped to a specific AI agent for a selected time window.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Invalid filter parameters
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get overall AI performance metrics
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/report/get-get-ai-performance
**Description:** GET /report/aiPerformance
## `GET /report/aiPerformance`
Returns overall AI performance metrics across the workspace for a selected time window.
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Invalid filter parameters
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get dashboard structure
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/report/get-get-report-structure
**Description:** GET /report/structure
## `GET /report/structure`
Returns dashboard structure based on user's role and permissions.
Structure contains widget layout and configuration.
All available components and their configurations are described in the enneo documentation.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get report data
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/report/get-get-report
**Description:** GET /report/{reportCode}
## `GET /report/{reportCode}`
Returns the data for a specific report type
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Invalid filter parameters
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get telephony agent call insights
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/report/get-get-telephony-agent-call-insights
**Description:** GET /report/telephonyAgentCallInsights/{agentId}
## `GET /report/telephonyAgentCallInsights/{agentId}`
Returns detected intents data for a specific telephony agent.
Shows distribution of customer intents identified in the agent's calls.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony agent not found
**`500`** — Internal error
---
## Get telephony agent details
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/report/get-get-telephony-agent-details
**Description:** GET /report/telephonyAgent/{agentId}
## `GET /report/telephonyAgent/{agentId}`
Returns detailed information about a specific telephony agent including their status and team assignments.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony agent not found
**`500`** — Internal error
---
## Get telephony agent performance metrics
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/report/get-get-telephony-agent-performance
**Description:** GET /report/telephonyAgentPerformance/{agentId}
## `GET /report/telephonyAgentPerformance/{agentId}`
Returns performance metrics for a specific telephony agent over time.
Similar to telephonyPerformance, returns 5 metrics: answered calls, missed calls, answer rate, average wait time, and average handling time.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony agent not found
**`500`** — Internal error
---
## Get telephony AI agent call insights
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/report/get-get-telephony-ai-agent-call-insights
**Description:** GET /report/telephonyAiAgentCallInsights/{aiAgentId}
## `GET /report/telephonyAiAgentCallInsights/{aiAgentId}`
Returns hourly breakdown of call outcomes for a specific telephony AI agent.
Shows how calls were handled throughout the day (0-23 hours).
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony AI agent not found
**`500`** — Internal error
---
## Get telephony AI agent details
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/report/get-get-telephony-ai-agent-details
**Description:** GET /report/telephonyAiAgent/{aiAgentId}
## `GET /report/telephonyAiAgent/{aiAgentId}`
Returns detailed information about a specific telephony AI agent.
Includes AI agent ID and live overview statistics.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony AI agent not found
**`500`** — Internal error
---
## Get telephony AI agent performance metrics
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/report/get-get-telephony-ai-agent-performance
**Description:** GET /report/telephonyAiAgentPerformance/{aiAgentId}
## `GET /report/telephonyAiAgentPerformance/{aiAgentId}`
Returns performance metrics for a specific telephony AI agent over time.
Returns 5 metrics: answered calls, missed calls, service level, average wait time, and average handling time.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony AI agent not found
**`500`** — Internal error
---
## Get telephony line details
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/report/get-get-telephony-line-details
**Description:** GET /report/telephonyLine/{lineId}
## `GET /report/telephonyLine/{lineId}`
Returns detailed information about a specific telephony line (subchannel) including voicebot configuration and connected phone numbers.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony line not found
**`500`** — Internal error
---
## Delete an event hook
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/delete-delete-event-hook
**Description:** DELETE /settings/event-hook/{id}
## `DELETE /settings/event-hook/{id}`
### Path parameters
### Responses
**`200`** — Deleted
**`404`** — Event hook not found
---
## Delete a Subchannel
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/delete-delete-subchannel
**Description:** DELETE /settings/subchannel/{id}
## `DELETE /settings/subchannel/{id}`
### Path parameters
### Responses
**`200`** — Subchannel deleted successfully
**`403`** — Unauthorized
**`500`** — Internal error
---
## Delete a User Defined Function
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/delete-delete-user-defined-function
**Description:** DELETE /settings/user-defined-function/{id}
## `DELETE /settings/user-defined-function/{id}`
### Path parameters
### Responses
**`200`** — User Defined Function deleted successfully
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get a single setting by name
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-get-setting
**Description:** GET /settings/{name}
## `GET /settings/{name}`
### Path parameters
### Query parameters
### Responses
**`200`** — The requested setting object.
**`403`** — Unauthorized
**`404`** — Setting not found
**`500`** — Internal error
---
## Get settings of a client in a grouped way for a category
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-get-settings-category
**Description:** GET /settings/category/{category}
## `GET /settings/category/{category}`
### Path parameters
### Responses
**`200`** — List of client-specific configruation settings.
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get settings of a client and return the results in a compact form
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-get-settings-compact
**Description:** GET /settings/compact
## `GET /settings/compact`
### Query parameters
### Responses
**`200`** — List of client-specific configruation settings in a compact key-value format.
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get UI overview of settings sections
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-get-settings-ui-overview
**Description:** GET /settings/uiOverview
## `GET /settings/uiOverview`
Returns the sections-and-categories tree that powers the Settings landing page in ops-fe.
The response is filtered by the caller's permissions: categories whose `requiredPermissions`
/ `requiredPermissionsAny` don't match are omitted. Labels are translated to the caller's
locale.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized — missing `settingsUiOverview` permission
---
## Get settings of a client
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-get-settings
**Description:** GET /settings
## `GET /settings`
### Query parameters
### Responses
**`200`** — List of client-specific configruation settings.
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get Subchannels
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-get-subchannels
**Description:** GET /settings/subchannel
## `GET /settings/subchannel`
A subchannel is a further differentiation of the channel, and is - For emails, they are the mailboxes, e.g. support@enneo.ai and sales@enneo.ai - For chat, they are the chatbots, e.g. the chatbot on the website and the chatbot on the customer portal - For voice, they are the phone numbers, e.g. the phone number for support and the phone number for sales.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get User Defined Functions
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-get-user-defined-functions
**Description:** GET /settings/user-defined-function
## `GET /settings/user-defined-function`
A user-defined function (UDF) is a function that you can define yourself and use in your queries. It is a way to extend the functionality of the database.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Callback for Google authorization
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-google-authorization-callback
**Description:** GET /settings/mailbox/google/authorization/callback
## `GET /settings/mailbox/google/authorization/callback`
Google OAuth callback. Persists the issued tokens against the mailbox subchannel.
### Query parameters
### Responses
**`302`** — Redirect to the post-callback success page
**`400`** — Bad request
**`403`** — Unauthorized
---
## Redirect to Google authorization page
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-google-authorization
**Description:** GET /settings/mailbox/google/authorization
## `GET /settings/mailbox/google/authorization`
Starts the OAuth flow for the Google (Gmail) mailbox integration.
### Responses
**`302`** — Redirect to Google authorization page
**`400`** — Bad request
**`403`** — Unauthorized
---
## List event hooks
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-list-event-hooks
**Description:** GET /settings/event-hook
## `GET /settings/event-hook`
Returns all event hooks (outbound webhooks fired on Mind events) configured for this client.
### Responses
**`200`** — Successful operation
---
## Callback for Microsoft authorization
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-microsoft-authorization-callback
**Description:** GET /settings/mailbox/microsoft/authorization/callback
## `GET /settings/mailbox/microsoft/authorization/callback`
### Responses
**`200`** — Operation successful
**`302`** — Redirect to /success page
**`400`** — Bad request
**`403`** — Unauthorized
---
## Redirect to Microsoft authorization page
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-microsoft-authorization
**Description:** GET /settings/mailbox/microsoft/authorization
## `GET /settings/mailbox/microsoft/authorization`
### Responses
**`200`** — Operation successful
**`302`** — Redirect to Microsoft authorization page
**`400`** — Bad request
**`403`** — Unauthorized
---
## Redirect to Microsoft Graph authorization page
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-microsoft-graph-authorization
**Description:** GET /settings/mailbox/microsoft/graph/authorization
## `GET /settings/mailbox/microsoft/graph/authorization`
Starts the OAuth flow for the modern Microsoft Graph mailbox integration (`/api/mind/settings/mailbox/microsoft/graph/...`).
The user is redirected to Microsoft to grant Graph mailbox scopes; on success Microsoft calls
back to `microsoftGraphCallback`.
### Responses
**`302`** — Redirect to Microsoft authorization page
**`400`** — Bad request
**`403`** — Unauthorized
---
## Callback for Microsoft Graph authorization
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-microsoft-graph-callback
**Description:** GET /settings/mailbox/microsoft/graph/callback
## `GET /settings/mailbox/microsoft/graph/callback`
Microsoft Graph OAuth callback. Persists the issued tokens against the mailbox subchannel.
### Query parameters
### Responses
**`302`** — Redirect to the post-callback success page
**`400`** — Bad request — missing or invalid code
**`403`** — Unauthorized
---
## Search settings
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-search-settings
**Description:** GET /settings/search
## `GET /settings/search`
Search through settings by name, description, or category
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Bad request - No search term provided
**`403`** — Unauthorized
**`500`** — Internal error
---
## Test receive on a mailbox subchannel
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/get-test-receive-mailbox
**Description:** GET /settings/mailbox/{subchannelId}/test/receive
## `GET /settings/mailbox/{subchannelId}/test/receive`
Triggers a one-off mailbox fetch for the given subchannel to verify that authentication and
mailbox connectivity are working. Returns the count and metadata of messages that would be
pulled, but does not persist them as tickets.
### Path parameters
### Responses
**`200`** — Operation successful
**`400`** — Bad request
**`403`** — Unauthorized
**`500`** — Internal error
---
## Create an event hook
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/post-create-event-hook
**Description:** POST /settings/event-hook
## `POST /settings/event-hook`
Create a new outbound event hook bound to one or more Mind events.
### Request body
### Responses
**`200`** — Created
**`403`** — Unauthorized
---
## Add a new Subchannel
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/post-create-subchannel
**Description:** POST /settings/subchannel
## `POST /settings/subchannel`
### Request body
The new Subchannel that should be created. The ID does not need to be included in the payload, as it will be generated automatically.
### Responses
**`200`** — Subchannel added successfully
**`403`** — Unauthorized
**`500`** — Internal error
---
## Add a new User Defined Function
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/post-create-user-defined-function
**Description:** POST /settings/user-defined-function
## `POST /settings/user-defined-function`
### Request body
The new User Defined Function that should be created. The ID does not need to be included in the payload, as it will be generated automatically.
### Responses
**`200`** — User Defined Function added successfully
**`403`** — Unauthorized
**`500`** — Internal error
---
## Update multiple settings at once
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/post-update-settings
**Description:** POST /settings
## `POST /settings`
Update multiple settings in a single request.
**Special setting formats:**
- Tag properties: Use `_tag[{id}].{property}` format (e.g., `_tag[123].name`, `_tag[456].visibility`)
- See Tag schema for available properties
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Update setting
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/settings/put-update-setting
**Description:** PUT /settings/{name}
## `PUT /settings/{name}`
Update a single setting value.
**Special setting formats:**
- Tag properties: Use `_tag[{id}].{property}` format (e.g., `_tag[123].name`, `_tag[123].visibility`)
- See Tag schema for available properties
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get file from storage
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/storage/get-get-file-from-storage
**Description:** GET /storage/{path}
## `GET /storage/{path}`
### Path parameters
### Responses
**`200`** — Binary file
**`403`** — Unauthorized
**`404`** — File not found
**`500`** — Internal error
---
## Get a file from the tmp namespace
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/storage/get-get-tmp-file-from-storage
**Description:** GET /storage/tmp/{path}
## `GET /storage/tmp/{path}`
Returns a file from the short-lived `tmp/` namespace in storage. The tmp namespace is used
for files that are produced server-side and immediately offered for download (e.g. generated
exports). Files there expire after a short TTL.
### Path parameters
### Responses
**`200`** — Binary file
**`404`** — File not found or expired
---
## Test storage
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/storage/get-test-storage
**Description:** GET /storage/test
## `GET /storage/test`
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Upload a file
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/storage/post-upload-storage-file
**Description:** POST /storage
## `POST /storage`
Upload a file to storage. The body is sent as `multipart/form-data`.
### Responses
**`200`** — Successful operation
**`400`** — Missing file
**`403`** — Unauthorized
---
## Delete a quality assessment
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality-management/delete-delete-quality-assessment
**Description:** DELETE /quality/assessment/{id}
## `DELETE /quality/assessment/{id}`
Soft-delete a quality assessment. Requires qualityDeleteAssessment permission.
### Path parameters
### Responses
**`200`** — Assessment deleted successfully
**`403`** — Unauthorized (missing qualityDeleteAssessment permission)
**`404`** — Assessment not found
**`500`** — Internal error
---
## Delete a quality scorecard
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality-management/delete-delete-quality-scorecard
**Description:** DELETE /quality/scorecard/{id}
## `DELETE /quality/scorecard/{id}`
Soft-delete a quality scorecard. Requires qualityDeleteScorecard permission.
### Path parameters
### Responses
**`200`** — Scorecard deleted successfully
**`403`** — Unauthorized (missing qualityDeleteScorecard permission)
**`404`** — Scorecard not found
**`500`** — Internal error
---
## Get a specific quality assessment
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality-management/get-get-quality-assessment
**Description:** GET /quality/assessment/{id}
## `GET /quality/assessment/{id}`
Retrieve a quality assessment in full format. User must have permission to view this assessment.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized (no permission to view this assessment)
**`404`** — Assessment not found
**`500`** — Internal error
---
## Get a specific quality scorecard
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality-management/get-get-quality-scorecard
**Description:** GET /quality/scorecard/{id}
## `GET /quality/scorecard/{id}`
Retrieve full details of a quality scorecard by ID
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Scorecard not found
**`500`** — Internal error
---
## Get all worklogs for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality-management/get-get-ticket-worklogs
**Description:** GET /ticket/{ticketId}/worklog
## `GET /ticket/{ticketId}/worklog`
Retrieve all worklog entries associated with a specific ticket, including their linked assessments and detailed worklog information.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## List quality assessments
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality-management/get-list-quality-assessments
**Description:** GET /quality/assessment
## `GET /quality/assessment`
Get a list of quality assessments with optional filters. Respects view permissions.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## List quality scorecards
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality-management/get-list-quality-scorecards
**Description:** GET /quality/scorecard
## `GET /quality/scorecard`
Get a list of all quality scorecards with optional state filter
### Query parameters
### Responses
**`200`** — List of quality scorecards
**`403`** — Unauthorized
**`500`** — Internal error
---
## Check if Live Quality Coach is configured for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality-management/get-ticket-quality-exists
**Description:** GET /ticket/{ticketId}/quality/exists
## `GET /ticket/{ticketId}/quality/exists`
Fast pre-flight check used by the FE to decide whether to expose the Live Quality
Coach Check action in the answer panel. Returns `exists: true` when at least one
applicable scorecard has `liveCoach.enabled=true` AND has at least one AI-evaluable
criterion (i.e. running `quality/check` would actually return a result).
Does not call cortex.
### Path parameters
### Responses
**`200`** — Live coach availability for this ticket
**`404`** — Ticket not found
---
## Update a quality assessment
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality-management/patch-update-quality-assessment
**Description:** PATCH /quality/assessment/{id}
## `PATCH /quality/assessment/{id}`
Update an assessment including scores, reasons, supervisor notes, and dates.
User must have permission to edit this assessment (qualityDoAssessmentsTeam or qualityDoAssessmentsAll).
Automatically transitions state from aiReady to reviewOngoing when edits are made.
### Path parameters
### Request body
### Responses
**`200`** — Assessment updated successfully
**`403`** — Unauthorized (no permission to edit this assessment)
**`404`** — Assessment not found
**`500`** — Internal error
---
## Update a quality scorecard
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality-management/patch-update-quality-scorecard
**Description:** PATCH /quality/scorecard/{id}
## `PATCH /quality/scorecard/{id}`
Update an existing quality scorecard. Requires qualityManageScorecards permission.
### Path parameters
### Request body
### Responses
**`200`** — Scorecard updated successfully
**`403`** — Unauthorized
**`404`** — Scorecard not found
**`500`** — Internal error
---
## Create a new quality scorecard
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality-management/post-create-quality-scorecard
**Description:** POST /quality/scorecard
## `POST /quality/scorecard`
Creates a new quality scorecard. Requires qualityManageScorecards permission.
### Request body
Provide the complete scorecard payload as JSON.
### Responses
**`200`** — Scorecard created successfully
**`400`** — Bad request (e.g., missing required fields)
**`403`** — Unauthorized (missing qualityManageScorecards permission)
**`500`** — Internal error
---
## Re-run AI processing for a quality assessment
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality-management/post-refresh-quality-assessment
**Description:** POST /quality/assessment/{id}/refresh
## `POST /quality/assessment/{id}/refresh`
Re-runs the AI processing of an existing assessment, regenerating AI-scored criteria
and the AI summary.
By default, the assessment is upgraded to the latest active scorecard revision
(resolved by `baseId`). To pin processing to a specific revision, pass `scorecardId`
in the request body — it must belong to the same scorecard family (same `baseId`)
as the assessment's current revision.
The user must have permission to edit this assessment. Cannot be called when the
assessment is in `discussedWithAssessee` or `reviewedBySupervisor` state.
### Path parameters
### Request body
### Responses
**`200`** — Assessment re-processed successfully
**`400`** — Assessment is in a state that does not allow re-running AI processing, or the requested scorecard revision belongs to a different scorecard
**`403`** — Unauthorized (no permission to edit this assessment)
**`404`** — Assessment not found
**`500`** — Internal error
---
## Live Quality Coach check on a draft reply
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/quality-management/post-ticket-quality-check
**Description:** POST /ticket/{ticketId}/quality/check
## `POST /ticket/{ticketId}/quality/check`
Score an unsent draft reply against every applicable scorecard whose
`liveCoach.enabled` is true. Nothing is persisted. Used by the Quality Coach
panel to render live scores per scorecard.
One ticket may match multiple live-enabled scorecards (e.g. Compliance, Empathy,
Tone) — every match is scored and returned in `scorecards`, ordered by
`scorecardId` ascending so the FE can rely on positional rendering.
Scorecards without any AI-evaluable criteria are silently skipped. When no
applicable scorecard has Live Coach enabled for this ticket, `scorecards` is empty.
Either every applicable scorecard is scored successfully, or — if cortex fails on
any of them — the whole request fails with 502; no partial results are returned.
### Path parameters
### Request body
### Responses
**`200`** — Live coach evaluation results
**`400`** — Missing or invalid `draftText`, or requested `scorecardId` is not active
**`404`** — Requested explicit `scorecardId` does not exist
**`502`** — Cortex evaluation endpoint unreachable or returned a validation error for one of
the scorecards. The error message includes the scorecard name that failed.
---
## Delete a Tag
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/tag/delete-delete-tag
**Description:** DELETE /tag/{id}
## `DELETE /tag/{id}`
### Path parameters
### Responses
**`200`** — Tag deleted successfully
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get tag tree structure
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/tag/get-get-tag-tree
**Description:** GET /tag/tree
## `GET /tag/tree`
Retrieve a hierarchical tree structure of all tags
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get a Tag
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/tag/get-get-tag
**Description:** GET /tag/{id}
## `GET /tag/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Tag not found
**`500`** — Internal error
---
## List all tags
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/tag/get-list-all-tags
**Description:** GET /tag
## `GET /tag`
Get all tags (skills, products, brands) available
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Add a new tag
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/tag/post-create-tag
**Description:** POST /tag
## `POST /tag`
### Request body
The new tag that should be created. The only mandatory parameters are name, refernce and type. If the other parameters are not provided, they will revert to defaults.
### Responses
**`200`** — Tag added successfully
**`403`** — Unauthorized
**`500`** — Internal error
---
## Detect a Tag
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/tag/post-detect-tag
**Description:** POST /tag/{id}/detect
## `POST /tag/{id}/detect`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Tag not found
**`500`** — Internal error
---
## Delete a team
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/team/delete-delete-team
**Description:** DELETE /team/{id}
## `DELETE /team/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get team by id
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/team/get-get-team-by-id
**Description:** GET /team/{id}
## `GET /team/{id}`
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get all teams
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/team/get-get-team-list
**Description:** GET /team/list
## `GET /team/list`
### Query parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get all teams
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/team/get-get-teams
**Description:** GET /team/tree
## `GET /team/tree`
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Update a team
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/team/patch-update-team
**Description:** PATCH /team/{id}
## `PATCH /team/{id}`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Create a new team
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/team/post-create-team
**Description:** POST /team
## `POST /team`
### Request body
### Responses
**`200`** — Created
**`500`** — Internal error
---
## Get ACD configuration
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/telephony/get-get-acd-config
**Description:** GET /telephony/acd/config
## `GET /telephony/acd/config`
Returns configuration for the ACD microservice including:
- ACD-enabled phone channels with their workflows
- SIP trunk configurations
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get routing status
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/telephony/get-get-routing
**Description:** GET /telephony/getRouting
## `GET /telephony/getRouting`
Returns the routing status of a specific ticket in the routing queue.
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Invalid input - missing required parameters
**`403`** — Unauthorized
**`404`** — Queue entry not found
**`500`** — Internal error
---
## Get routing availability for all users
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/telephony/get-routing-availability
**Description:** GET /telephony/routingAvailability
## `GET /telephony/routingAvailability`
Returns the routing availability for all users. Used by a dispatcher to check which agents are currently available to pick up a ticket.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized - user does not have permission to read user status
**`500`** — Internal error
---
## Test outbound call
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/telephony/get-test-outbound-call
**Description:** GET /telephony/testOutboundCall
## `GET /telephony/testOutboundCall`
Makes a test outbound call using configured settings. Used for testing the telephony integration.
### Responses
**`200`** — Successful operation
**`400`** — Invalid input or missing settings
**`401`** — Unauthorized
**`500`** — Internal error
---
## Call received
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/telephony/post-call-received
**Description:** POST /telephony/callReceived
## `POST /telephony/callReceived`
Called when a call is received (inbound) or initiated (outbound).
For inbound calls (direction=in, default): creates a ticket, attempts customer identification from phone number, and returns the ticket ID. Routing happens later via getRouting.
For outbound calls (direction=out): creates a ticket, creates a queue entry (no routing needed), and links customer/contract data if available. Requires 'to'. No human initiator is required — the call can be fully autonomous/callflow-driven. If a human initiator is provided ('agentId'/'userId'), they are set to 'interacting' and the ticket is assigned to them. For bot/callflow-driven calls with no human on the line, omit 'agentId'/'userId' — presence is not touched and the queue is created as Unknown (out of routing).
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid input
**`500`** — Internal error
---
## Complete call and store transcript
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/telephony/post-complete-call
**Description:** POST /telephony/callCompleted
## `POST /telephony/callCompleted`
Called when a call is completed to store the final transcript and call details
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid input
**`404`** — Ticket not found
**`500`** — Internal error
---
## Connect agent to call
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/telephony/post-connect-agent-to-call
**Description:** POST /telephony/agentConnected
## `POST /telephony/agentConnected`
Called whenever the telephony system has connected a agent (user) with a call that was previously sent to enneo via the /telephony/callReceived endpoint. Upon receiept, the specified agent's browser window is then redirected to the previously created ticket id (specified via ticket id or channel id)
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid input
**`404`** — Ticket not found
**`500`** — Internal error
---
## Test outbound call (POST)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/telephony/post-test-outbound-call-post
**Description:** POST /telephony/testOutboundCall
## `POST /telephony/testOutboundCall`
Same as `GET /telephony/testOutboundCall`, but accepts a JSON body to override the configured target phone number or subchannel.
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid input or missing settings
**`401`** — Unauthorized
**`500`** — Internal error
---
## GDPR-clean attachment deletion
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/delete-delete-ticket-attachment
**Description:** DELETE /ticket/{ticketId}/attachment/{attachmentId}
## `DELETE /ticket/{ticketId}/attachment/{attachmentId}`
Permanently removes a single attachment from a ticket or its conversations:
deletes the S3 object, the `files` row, and strips the entry from the
ticket/conversation `attachments` JSON.
The attachment is identified by its numeric `id` field inside the JSON array.
Search covers both ticket-level and conversation-level attachments.
Requires the `updateTechnicalTicketFields` permission (admin / role 1 only).
This action is irreversible.
### Path parameters
### Responses
**`200`** — Attachment deleted successfully
**`403`** — Unauthorized — requires updateTechnicalTicketFields permission
**`404`** — Ticket or attachment not found
**`500`** — Internal error
---
## GDPR-clean ticket deletion
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/delete-delete-ticket
**Description:** DELETE /ticket/{ticketId}
## `DELETE /ticket/{ticketId}`
Permanently deletes a ticket and **all** associated data: conversations,
intents, tag links, queue entries, quality assessments, surveys, reminders,
reporting rows, worklog, time-tracking, S3 attachments, and `files` rows.
Requires the `deleteTicket` permission (admin / role 1 only).
This action is irreversible.
### Path parameters
### Responses
**`200`** — Ticket deleted successfully
**`403`** — Unauthorized — requires deleteTicket permission
**`404`** — Ticket not found
**`500`** — Internal error
---
## Get ticket activity
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/get-get-ticket-activity
**Description:** GET /ticket/{ticketId}/activity
## `GET /ticket/{ticketId}/activity`
Get ticket activity by ticketId
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Get a tickets history
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/get-get-ticket-history
**Description:** GET /ticket/{ticketId}/history
## `GET /ticket/{ticketId}/history`
Get a history of created tickets and other relevant actions from a customer/contract
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Get ticket stats
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/get-get-ticket-stats
**Description:** GET /ticket/stats
## `GET /ticket/stats`
### Responses
**`200`** — Successful operation
---
## Get ticket variables
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/get-get-ticket-variables
**Description:** GET /ticket/{ticketId}/variables
## `GET /ticket/{ticketId}/variables`
Get ticket variables by ticketId
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Get a ticket (full data)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/get-get-ticket
**Description:** GET /ticket/{ticketId}
## `GET /ticket/{ticketId}`
Get a single ticket by ticketId with FULL data.
Unlike POST /ticket/search (which returns compact data), this endpoint includes:
- body, bodyPlain, bodyClean (full content)
- attachments (complete list)
- intents (full details)
- template (email template)
- workitem (for system tickets only)
- customer (full object with all properties)
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Ping a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/get-ping-ticket
**Description:** GET /ticket/{ticketId}/ping
## `GET /ticket/{ticketId}/ping`
Ping a ticket to keep time tracking for agent and to refresh the list of
currently-active agents on this ticket. The FE polls this every 30s and
uses `workedOnBy` to overwrite its cached list, so the "another agent
is working on this ticket" warning becomes two-sided (both the first and
the second agent see it).
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Update a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/patch-update-ticket
**Description:** PATCH /ticket/{ticketId}
## `PATCH /ticket/{ticketId}`
Update a ticket by ticketId
### Path parameters
### Query parameters
### Request body
A JSON object containing changes
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Update a few tickets at once
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/patch-update-tickets
**Description:** PATCH /ticket
## `PATCH /ticket`
Update a few tickets at once.
**Tags handling:**
- Use `tagIds` to replace all tags
- Use `addTagIds`/`removeTagIds` to modify existing tags
- Cannot combine `tagIds` with `addTagIds`/`removeTagIds`
**Special flags:**
- `refreshMode`: Schedule a selective AI re-run (`full`, `summaryAndText`, `customer`, `tags`, `agents`). Skips saving and webhooks.
- `refresh` (deprecated — use `refreshMode=full`): Skips saving and webhooks, used for refreshing data without changes.
- `refreshTags` (deprecated — use `refreshMode=tags`): Performs only AI tag detection (faster), skips saving and webhooks.
### Query parameters
### Request body
A JSON object containing changes
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Auto-execute a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/post-auto-execute-ticket
**Description:** POST /ticket/{ticketId}/autoexecute
## `POST /ticket/{ticketId}/autoexecute`
Automatically process a ticket that was previously marked as auto-executable. Optionally, specify an AI agent to force-execute even if the agent is not configured for auto-execution.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Create a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/post-create-ticket
**Description:** POST /ticket
## `POST /ticket`
Create a new ticket.
Required fields:
- channel (only required field!)
Auto-generated if not provided:
- direction (default: 'in')
- status (default: 'open')
- priority (default: 'low')
- interface (default: 'internal')
- to, ccEmails, bccEmails (default: [])
- createdAt (default: current timestamp)
- aiSupportLevel (default: 'unprocessed')
- id (auto-generated by database)
Agent assignment:
- If `agentId` is set in the request, it is used as-is.
- Otherwise the ticket is auto-assigned to the calling profile only when the `lastAgentRouting` setting is enabled AND the caller is a human profile (`user`, `enneo`, or `enneoPartner`). Service workers, code executors, and system users never trigger auto-assignment.
- When `lastAgentRouting` is disabled, the ticket stays unassigned regardless of direction.
### Query parameters
### Request body
Ticket object to create
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Forward a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/post-forward-ticket
**Description:** POST /ticket/{ticketId}/forward
## `POST /ticket/{ticketId}/forward`
Forward a ticket to free typed email address
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Get next ticket id to work on
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/post-get-latest-ticket
**Description:** POST /ticket/getLatest
## `POST /ticket/getLatest`
### Request body
Parameters for getting the next ticket
### Responses
**`200`** — Successful operation
---
## Get a list of tickets
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/post-get-tickets
**Description:** POST /ticket/search
## `POST /ticket/search`
Get a list of tickets in compact format for performance.
⚠️ IMPORTANT: This endpoint returns a COMPACT version of tickets. The following fields are EXCLUDED from the response:
- body, bodyPlain, bodyClean
- attachments
- template
- workitem
Also note:
- customer: Only includes {tagIds: [], tags: []} structure, NOT the full customer object
- `ticketScope=skills` activates routing context: spam tickets (`spamStatus` in `auto_spam`, `auto_programmatic`, `manual_spam`) are excluded automatically. Backlog spam filter (both whitelist `in`): spam → those statuses; not spam → `null`, `auto_clean`, `manual_clean`.
To get the full ticket data including these fields, use GET /ticket/{id}.
### Request body
Search parameters for tickets
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Apply an AI-driven text transformation
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket/post-ticket-text-update
**Description:** POST /ticket/textUpdate
## `POST /ticket/textUpdate`
Runs an AI text-modification operation on the supplied text and returns the transformed result.
Used by ops-fe's compose box (rephrase, shorten, translate, …).
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid input
**`403`** — Unauthorized
**`500`** — Internal error
---
## Delete a template
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/template/delete-delete-template
**Description:** DELETE /template/{id}
## `DELETE /template/{id}`
Soft-deletes the template. Requires the `manageTemplates` permission.
### Responses
**`200`** — Template deleted successfully
**`400`** — Template cannot be deleted (e.g., used as generic template)
**`403`** — Unauthorized / missing permission
**`404`** — Template not found
**`500`** — Internal error
---
## Get template details
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/template/get-get-template
**Description:** GET /template/{id}
## `GET /template/{id}`
Returns the template including the underlying generic wrapper and merged HTML. Example ticket IDs are filtered to existing tickets.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Template not found
**`500`** — Internal error
---
## List response templates
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/template/get-list-templates
**Description:** GET /template
## `GET /template`
Returns the paginated list of response templates that agents can insert into tickets. When no template matches the provided filters the API responds with HTTP 404.
### Query parameters
### Responses
**`200`** — Templates found
**`403`** — Unauthorized
**`404`** — No templates match the provided filters
**`500`** — Internal error
---
## Update a template
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/template/patch-update-template
**Description:** PATCH /template/{id}
## `PATCH /template/{id}`
Requires the `manageTemplates` permission.
### Request body
### Responses
**`200`** — Template updated successfully
**`400`** — Validation error
**`403`** — Unauthorized / missing permission
**`404`** — Template not found
**`500`** — Internal error
---
## Create a response template
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/template/post-create-template
**Description:** POST /template
## `POST /template`
Requires the `manageTemplates` permission.
### Request body
### Responses
**`200`** — Template created successfully
**`400`** — Validation error (e.g., invalid handlebars syntax)
**`403`** — Unauthorized / missing permission
**`500`** — Internal error
---
## Preview a template with ticket data
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/template/post-preview-template
**Description:** POST /template/preview
## `POST /template/preview`
Renders a template fragment using the optional ticket or contract data. When `ticketId` is provided, AI extracted intent data is injected before rendering. The response returns HTML with `<br>` tags to preserve formatting in downstream clients.
### Request body
### Responses
**`200`** — Template preview rendered successfully
**`400`** — Invalid template or missing required data
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get AI insights for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket-ai-insights/get-get-ticket-ai-insights
**Description:** GET /ticket/{ticketId}/aiInsight
## `GET /ticket/{ticketId}/aiInsight`
Active questions of the ticket's subchannel, each paired with its stored insight (or `null`).
### Path parameters
### Responses
**`200`** — Question + insight pairs
**`404`** — Ticket not found
---
## Manually re-run AI insights for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/ticket-ai-insights/post-refresh-ticket-ai-insights
**Description:** POST /ticket/{ticketId}/aiInsight/refresh
## `POST /ticket/{ticketId}/aiInsight/refresh`
### Path parameters
### Responses
**`200`** — Refresh scheduled
**`400`** — No active questions or system channel
**`403`** — Unauthorized
**`404`** — Ticket not found
---
## AuthSync webhook
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/webhook/post-auth-sync-webhook
**Description:** POST /webhook/authSync
## `POST /webhook/authSync`
Sync auth data from auth.users to mind.users
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Contract not found
**`500`** — Internal error
---
## Trigger mailbox fetch
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/webhook/post-fetch-emails-webhook
**Description:** POST /webhook/fetchEmails/{subchannelId}
## `POST /webhook/fetchEmails/{subchannelId}`
External trigger that asks Mind to poll the given mailbox subchannel for new messages and
convert them into tickets. Without `subchannelId` all configured mailboxes are polled.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Lynqtech webhook
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/webhook/post-lynqtech-webhook
**Description:** POST /webhook/lynqtech
## `POST /webhook/lynqtech`
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Contract not found
**`500`** — Internal error
---
## PowerCloud webhook
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/webhook/post-power-cloud-webhook
**Description:** POST /webhook/powercloud
## `POST /webhook/powercloud`
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Firecrawl webhook receiver
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/webhook/post-website-connector-webhook
**Description:** POST /webhook/websiteConnector/{id}
## `POST /webhook/websiteConnector/{id}`
Receives crawl events from Firecrawl. Authenticated via x-webhook-token header (per-connector secret).
Handles crawl.page (upsert/delete pages), crawl.completed, and crawl.failed events.
### Path parameters
### Request body
### Responses
**`200`** — Event processed
**`401`** — Invalid webhook token
**`404`** — Connector not found
---
## Delete knowledgeSource
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/wiki-knowledge-source/delete-delete-knowledge-source
**Description:** DELETE /knowledgeSource/{id}
## `DELETE /knowledgeSource/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get archived knowledge sources
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/wiki-knowledge-source/get-get-archived-knowledge-sources
**Description:** GET /knowledgeSource/archived
## `GET /knowledgeSource/archived`
Retrieves a paginated list of archived knowledge sources
### Query parameters
### Responses
**`200`** — Successful operation
**`401`** — Unauthorized
**`403`** — Forbidden - User doesn't have the 'viewArchivedKnowledge' permission
---
## Get knowledgeSource by id
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/wiki-knowledge-source/get-get-knowledge-source-by-id
**Description:** GET /knowledgeSource/{id}
## `GET /knowledgeSource/{id}`
Returns a single knowledge source. **Excluded website pages** (whose source URL matches the
parent connector's `sourceConfig.excludePaths`) return `404 Not Found` — this matches the
bulk list filter so Cortex sync stays consistent.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Not found, or the page is an excluded website page
**`500`** — Internal error
---
## Get knowledgeSource
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/wiki-knowledge-source/get-get-knowledge-source
**Description:** GET /knowledgeSource
## `GET /knowledgeSource`
Returns a list of knowledge sources. **Excluded website pages** (whose source URL matches
the parent connector's `sourceConfig.excludePaths`) are filtered out of the response —
this is required so Cortex's `sync_knowledge_base` does not re-index excluded pages.
**Folder listing** (`parent` present): paginated. `limit` defaults to 50, maximum 500.
Response includes `total`, `offset`, and `limit` for cursor-free pagination.
**Global / search** (`parent` absent, or `q` present): not paginated. `limit` defaults
to 1000 and is not capped. `total`/`offset`/`limit` are not returned.
### Query parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Update knowledgeSource
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/wiki-knowledge-source/patch-update-knowledge-source
**Description:** PATCH /knowledgeSource/{id}
## `PATCH /knowledgeSource/{id}`
For file-type rows (uploaded via the files connector) only `name`, `status`, and `text`
are accepted — other fields return 422. Editing `text` sets `data.hasManualMarkdownEdits = true`
so the FE can warn before a re-upload would overwrite manual edits. The `embeddingHash`
is intentionally NOT recomputed on text-only edits — it represents the parse hash of the
original binary and stays stable until a real reindex / replace.
Website-type pages cannot be edited through this endpoint.
**Teams (per-article ACL):** sending `teams: [1,2]` replaces the full team-restriction set;
omitting `teams` entirely leaves the existing set unchanged. An empty array (`teams: []`)
removes all restrictions and makes the article visible to everyone.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Create knowledgeSource
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/wiki-knowledge-source/post-create-knowledge-source
**Description:** POST /knowledgeSource
## `POST /knowledgeSource`
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Delete a website connector
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/website-connector/delete-delete-website-connector
**Description:** DELETE /knowledgeSource/websiteConnector/{id}
## `DELETE /knowledgeSource/websiteConnector/{id}`
Cancels any active crawl, soft-deletes all child pages (with knowledgeSourceChanged events), and marks the connector as deleted.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Connector not found
**`500`** — Internal error
---
## Get a website connector
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/website-connector/get-get-website-connector
**Description:** GET /knowledgeSource/websiteConnector/{id}
## `GET /knowledgeSource/websiteConnector/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Connector not found
**`500`** — Internal error
---
## List website connectors
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/website-connector/get-get-website-connectors
**Description:** GET /knowledgeSource/websiteConnector
## `GET /knowledgeSource/websiteConnector`
Returns all website connectors (excluding deleted ones). Each connector includes its page count and data (with webhookSecret removed).
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Update a website connector
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/website-connector/patch-update-website-connector
**Description:** PATCH /knowledgeSource/websiteConnector/{id}
## `PATCH /knowledgeSource/websiteConnector/{id}`
Updates a website connector. The `excludePaths` field has three mutually compatible inputs:
- `excludePaths` — full replace (operator-edit form).
- `addExcludePaths` — append to the current excludePaths (set-union, deduped server-side).
- `removeExcludePaths` — remove from the current excludePaths (set-difference).
`excludePaths` is **mutually exclusive** with `addExcludePaths`/`removeExcludePaths` —
sending both in the same request returns 422. `addExcludePaths` and `removeExcludePaths`
can be combined in one request (add applied first, then remove).
Whenever excludePaths actually changes, Mind diffs old-vs-new and emits
`knowledgeSourceChanged` events: `delete` for newly-matching pages (now excluded),
`create` for newly-unmatching pages (now included). This keeps Cortex's Weaviate index
in sync immediately rather than waiting for the next periodic resync.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`404`** — Connector not found
**`422`** — Invalid frequency value, or excludePaths combined with addExcludePaths/removeExcludePaths
**`500`** — Internal error
---
## Create a website connector
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/website-connector/post-create-website-connector
**Description:** POST /knowledgeSource/websiteConnector
## `POST /knowledgeSource/websiteConnector`
Creates a new website connector with the given URL and configuration. Generates a webhook secret automatically.
### Request body
### Responses
**`200`** — Created
**`422`** — Validation error (missing URL or unconfigured webhook URL)
**`500`** — Internal error
---
## Trigger a crawl
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/website-connector/post-start-website-connector-crawl
**Description:** POST /knowledgeSource/websiteConnector/{id}/crawl
## `POST /knowledgeSource/websiteConnector/{id}/crawl`
Triggers a Firecrawl crawl for the specified connector. Resets crawl stats and sets status to running.
### Path parameters
### Responses
**`200`** — Crawl started
**`404`** — Connector not found
**`422`** — Firecrawl settings not configured
**`500`** — Internal error
---
## Stop a running crawl
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/website-connector/post-stop-website-connector-crawl
**Description:** POST /knowledgeSource/websiteConnector/{id}/stop
## `POST /knowledgeSource/websiteConnector/{id}/stop`
Cancels the active Firecrawl job and sets the connector status to idle.
### Path parameters
### Responses
**`200`** — Crawl stopped
**`404`** — Connector not found
**`500`** — Internal error
---
## Delete a knowledge source structure
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/wiki-knowledge-source-structure/delete-delete-knowledge-source-structure
**Description:** DELETE /knowledgeSourceStructure/{id}
## `DELETE /knowledgeSourceStructure/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get the knowledge source structure
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/wiki-knowledge-source-structure/get-get-knowledge-source-structure
**Description:** GET /knowledgeSourceStructure
## `GET /knowledgeSourceStructure`
Returns the knowledge source structure tree. By default, website tree nodes whose `source` URL
matches the parent connector's `sourceConfig.excludePaths` (`fnmatch` patterns) are omitted —
this is the sidebar view. Pass `withExcluded=true` to include those nodes (each website
node then carries `excluded: true|false`); used by the connector configuration view.
### Query parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Create a new knowledge source structure
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/wiki-knowledge-source-structure/post-create-knowledge-source-structure
**Description:** POST /knowledgeSourceStructure
## `POST /knowledgeSourceStructure`
### Request body
### Responses
**`200`** — Created
**`500`** — Internal error
---
## Set team ACL for a structure node
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/wiki-knowledge-source-structure/put-set-knowledge-source-structure-teams
**Description:** PUT /knowledgeSourceStructure/{id}/teams
## `PUT /knowledgeSourceStructure/{id}/teams`
Replace-set the team access list for a structure node (folder, file-connector root,
or website connector — any type). Passing an empty array removes all restrictions
and makes the node visible to everyone. When non-empty, only users whose
`actualTeamIds` intersect with this list (or users with no teams at all) can see
the node and all its descendants.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`404`** — Structure node not found
**`500`** — Internal error
---
## Update a knowledge source structure
**URL:** https://richard-dev-playground.enneo.ai/docs/de/api-reference/wiki-knowledge-source-structure/put-update-knowledge-source-structure
**Description:** PUT /knowledgeSourceStructure/{id}
## `PUT /knowledgeSourceStructure/{id}`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Apps
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/apps/apps-overview
**Description:** Eigene HTML-Anwendungen erstellen und in Enneo integrieren
## Überblick
Apps sind benutzerdefinierte Anwendungen, die **HTML** zurückgeben und direkt in Enneo als eigene Seite
angezeigt werden. Jede App wird in einer Sandbox ausgeführt und hat Zugriff auf die Enneo-API.
**Typische Anwendungsfälle:**
- **Individuelle Dashboards** — Echtzeitdaten aus dem ERP oder CRM visualisieren
- **Berichte und Auswertungen** — Maßgeschneiderte Reports mit eigener Logik
- **Interne Tools** — Formulare, Kalkulatoren oder Workflow-Helfer
- **Datenabfragen** — Vertragsdaten, Kundenstatus oder Statistiken anzeigen
## Aufbau einer App
Jede App besteht aus:
| Bestandteil | Beschreibung |
|---|---|
| **Name** | Anzeigename in der Seitenleiste und in den Einstellungen |
| **Slug** | Eindeutiger technischer Bezeichner (z.B. `mein-dashboard`). Wird in der URL verwendet |
| **Beschreibung** | Optionale Beschreibung des Zwecks der App |
| **Anbieter** | Optional: Wer die App erstellt hat |
| **Executor** | Der Code, der bei Aufruf ausgeführt wird (Python, Node.js oder PHP) |
### Executor
Der Executor verwendet das Standard-Executor-Format von Enneo (gleicher Aufbau wie bei Einstellungen und KI-Agenten).
Er unterstützt aktuell den Typ **Quellcode** mit den Sprachen Python 3.11, Node.js 20 und PHP 8.2.
Die Ausgabe auf `stdout` wird als HTML an den Browser zurückgegeben.
### Eingabeparameter
Bei jedem Aufruf erhält der Code automatisch Metadaten als Parameter über STDIN:
```json
{
"_metadata": {
"userId": 1,
"clientId": "1",
"appId": "a1b2c3d4-...",
"appRevision": 3,
"userAuthToken": "Bearer ..."
}
}
```
Zusätzliche GET- oder POST-Parameter werden automatisch übergeben und stehen im Code zur Verfügung.
### Umgebungsvariablen
Folgende Umgebungsvariablen stehen im App-Code zur Verfügung:
| Variable | Beschreibung |
|---|---|
| `ENNEO_API_URL` | Basis-URL der Enneo-API |
| `ENNEO_SESSION_TOKEN` | Session-Token für API-Aufrufe |
| `ENNEO_USER_AUTH_HEADER` | Auth-Header des aufrufenden Benutzers |
| `ENNEO_APP_ID` | UUID der App |
| `ENNEO_APP_SLUG` | Slug der App |
| `ENNEO_APP_VERSION` | Version der App (z.B. `1.0.0`) |
| `SDK` | Pfad zur SDK-Datei |
## Apps nutzen
### Seitenleiste
Sobald mindestens eine App existiert und der Benutzer die Berechtigung `readApps` hat, erscheint
in der Seitenleiste der Menüpunkt **Apps**. Hier werden alle verfügbaren Apps als Tabs angezeigt.
Die App-URL im Browser verwendet den **Slug** der App:
```
/apps/mein-dashboard
```
### App aufrufen
Jede App wird in einem iFrame innerhalb von Enneo ausgeführt. Die API-URL akzeptiert sowohl UUID als auch Slug:
```
/api/mind/app/{slug}/run
/api/mind/app/{appId}/run
```
GET-Parameter können direkt angehängt werden:
```
/api/mind/app/mein-dashboard/run?param1=wert1¶m2=wert2
```
## App Storage
Apps können persistente Daten speichern und lesen. Der **App Storage** ist ein Key-Value-Store,
der pro App isoliert ist. Die Werte werden als JSON gespeichert.
### SDK-Zugriff
### App-Info
Über die Klasse `AppInfo` können App-Metadaten abgerufen werden:
### Unterstützte Werttypen
| Typ | Beispiel |
|---|---|
| String | `"hello world"` |
| Zahl | `42`, `3.14` |
| Boolean | `true`, `false` |
| Null | `null` |
| Objekt | `{"key": "value"}` |
| Array | `[1, "two", 3.0]` |
## Apps verwalten
Die Verwaltung erfolgt unter **Einstellungen → Erweiterte Einstellungen → Apps**.
### Neue App erstellen
1. Navigieren Sie zu **Einstellungen → Apps**
2. Klicken Sie auf **App erstellen**
3. Geben Sie Name, Slug und optional Beschreibung ein
4. Schreiben Sie den Executor-Code
5. Nutzen Sie die **Vorschau**, um die Ausgabe zu prüfen
6. Klicken Sie auf **Speichern**
### App bearbeiten
Jede Änderung erstellt automatisch eine neue **Revision**. So können Sie jederzeit zu einer
früheren Version zurückkehren.
Ungespeicherte Änderungen werden durch ein **Entwurf**-Tag in der Seitenleiste angezeigt.
Beim Navigieren mit ungespeicherten Änderungen erscheint eine Warnung.
### Export und Import
Apps können als JSON exportiert und importiert werden. Der Export-Button befindet sich
im Tab **Spezifikationen**. Dies ermöglicht den Transfer zwischen Umgebungen.
### Revisionen und Rollback
Apps unterstützen Versionierung:
- Jede Speicherung erstellt eine neue Revision
- Über die Revisions-Übersicht können Sie zu jeder früheren Version zurückkehren
- Die aktive Revision wird den Benutzern angezeigt
## Berechtigungen
| Berechtigung | Beschreibung | Standard-Rollen |
|---|---|---|
| `readApps` | Apps ansehen und ausführen | Admin, Agent |
| `appCreator` | Apps erstellen, bearbeiten und Vorschau | Admin |
| `manageApps` | Apps importieren und löschen | Admin |
## Beispiele
### Dashboard mit Vertragsdaten
```python
# SDK laden
file_path = os.getenv('SDK', 'sdk.py')
spec = importlib.util.spec_from_file_location('sdk', file_path)
sdk = importlib.util.module_from_spec(spec)
spec.loader.exec_module(sdk)
# Eingabedaten laden
input_data = sdk.load_input_data()
metadata = input_data.get('_metadata', {})
# Vertragsdaten laden (Beispiel)
contract_id = input_data.get('contractId', '715559')
try:
contract = sdk.ApiEnneo.get_contract(contract_id)
name = f"{contract.get('firstname', '')} {contract.get('lastname', '')}"
status = contract.get('status', 'Unbekannt')
except Exception:
name = "Nicht gefunden"
status = "-"
# HTML ausgeben
print(f"""
')",
"type": "sourceCode",
"language": "python311",
"packages": null,
"parameters": [],
"parameterDefinitions": []
}
```
---
## Legitimierung von Kunden
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/customer-recognition/contract-legitimation
Sobald ein Kunde, bzw. genauer gesagt ein Vertrag, erkannt worden ist, startet Enneo eine Prüfung ob die Erkennung ausreichend konkret ist für eine weitere Verarbeitung. Dieses Konzept ist die "Legitimierung" in Enneo.
Erkannte, aber nicht legitimierte Kunden werden dem User vorgeschlagen, aber mit einer entsprechenden Warnmeldung, so dass der User besonders prüfen kann, ob die KI-Erkennung korrekt war und alle notwendigen Merkmale genannt wurden.
Ist ein Kunde legitimiert, erlischt diese Warnmeldung. Eine Dunkelverarbeitung ohne menschliche Interaktion ist auch nur für Kunden möglich, welche legitimiert wurden.
Typische Legitimierungsregeln bestehen aus 2 unabhängigen Merkmalen, die zueinander passen müssen. So kann man sicherstellen, dass es zu keiner Fehlidentifikation gekommen ist. Beispiele für reale Identifikationsmethoden sind weiter unten aufgeführt.
Eine Legitiation erfolgt stets auf Vertrags- und nicht auf Kundenebene, wobei dafür auch Merkmale aus den Kundendaten verwendet werden können. So stellt Enneo sicher, das vertragsbezogene Änderungen auch für den korrekten Vertrag durchgeführt werden.
## **Die 4 Stufen der Legitimierung**
Die Kundenerkennung in Enneo die folgenden Stufen der Legitmierung:
| Beschreibung | Bedeutung (E-Mail) | Bedeutung (Chatbot/Voicebot) | Beispiel | Level | Dunkelverarbeitung |
| -------------------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----: | ------------------ |
| Kein Kunde identifiziert | Sachbearbeiter sieht keinen Kunden | Keine Erkennung | Kunde nennt weder Vertrags- noch Kundennummer, genutzte E-Mail ist zudem nirgends hinterlegt | 0 | Nein |
| Kunde erkannt, aber nicht legitimiert | Sachbearbeiter sieht Kunden in rechter Leister, aber mit Warnmeldung | Wie keine Erkennung | KI hat Kunde 123 erkannt, dessen Unterlagen die E-Mail [tom@smith.com](mailto:tom@smith.com) ausweisen. Die E-Mail stammt jedoch von [michael@jackson.com](mailto:michael@jackson.com) | 10-19 | Nein |
| Kunde von der KI erkannt und Daten stimmen überein | Sachbearbeiter sieht Kunde in rechter Leiste | Erkennung, volle ausführung von KI-Agenten | KI hat Kunde 123 erkannt, dessen Unterlagen die E-Mail [tom@smith.com](mailto:tom@smith.com) ausweisen. Die E-Mail stammt von [tom@smith.com](mailto:tom@smith.com) | 20 | Ja |
| Kunde manuell bestätigt | Sachbearbeiter sieht Kunde in rechter Leiste | Entfällt | Kunde wurde von Enneo nur ohne Legitimation erkannt (Level 10), aber vom User bestätigt | 30 | (Entfällt) |
## Erkennung der Legitimierungs-Levels im Standard von Enneo:
- Bei **Chat und Voice** erfolgt die Festlegung, ab wann Level 20 erreicht wird über die Einstellung _Assistant authentication instructions_ im jeweiligen Chat-/Voicebot. Die Einstellung ist standardmäßig Vertragsnummer (`contractId`) und Postleitzahl (`zip`) ist. Nur wenn die Kombination aus beiden genannt wird, ist der Kunde legitimiert.
- Bei **E-Mails und Briefen** erfolgt die Einstellung, ab wann Level 20 erreicht wird über einen Regeleditor für Legitimierungen. Mit diesem lassen sich komplexe Sicherheitsniveaus festlegen.
## Regeleditor für Legitimierungen bei E-Mails und Briefen
_[Der Regeleditor befindet sich aktuell in der Entwicklung]_
Mit diesem Regeleditor lassen sich komplexe Geschäftsregeln abbilden, welche definieren wann ein Kunde sich ausreichend legitimiert hat um sein Anliegen zu bearbeiten. Auch kann so sichergestellt werden, dass nur dann eine Dunkelverarbeitung statt findet wenn der Kunde eindeutig und ausreichend identifiziert wurde.
Beispiele für Regeln, welche mit diesem Editor abgebildet werden können:
- Vertragsnummer ODER Kundennummer erwähnt UND Absender-E-Mail stimmt mit ERP
- Vor- UND Nachname erwähnt UND (Vertrags- ODER Kunden- ODER Zählernummer erwähnt) UND (Rechnungs-/Lieferadresse ODER E-Mail stimmt mit Daten aus ERP überein
- Insgesamt 4 Markmale genannt; davon mindestens 1 Pflichtmerkmal (Vertrags-, Kunden- oder Bestell-ID).
Für die konkrete Implementierung dieser Beispiele bitte hier aufklappen:
### Vorgehen
So konfigurieren Sie Regeln in zwei Schritten:
1. Matching-Gruppen anlegen
- Eine Regel besteht aus einer oder mehreren Matching-Gruppen.
- Ein Kunde gilt nur dann als legitimiert, wenn alle Matching-Gruppen erfolgreich erfüllt sind.
- Jede Matching-Gruppe hat:
- Eine Bezeichnung (z. B. “Identifikation per ID”)
- Eine Mindestanzahl an Kriterien, die innerhalb dieser Gruppe erfüllt sein müssen
- Eine Auswahl an Kriterien (Standardkriterien von enneo und optional eigene Kriterien)
2. Kriterien je Matching-Gruppe wählen
- Innerhalb einer Matching-Gruppe wählen Sie die Kriterien, die geprüft werden sollen.
- Die Gruppe gilt als erfüllt, wenn mindestens so viele Kriterien zutreffen, wie unter “Mindestanzahl” festgelegt ist.
#### Verfügbare Kriterien
Für die typischen Kriterien, z.B. die Nennung von Vertrags- oder Kundennummer hat Enneo bereits Prüfkriterien vorentwickelt. Diese können einfach angeklickt werden.
Die jeweiligen Datenfelder, also z.B. die konkrete Vertragsnummer bei einer Prüfung auf Nennung der Vertragsnummer, müssen dafür natürlich wie in /de/system-integration/customer-recognition/flow definiert definiert zur Verfügug gestellt werden. Die entsprechende Name der Variable ist in folgender Tabelle ebenfalls genannt.
#### Standardkriterien
| Standardkriterium | Verwendete Datenfelder für das Matching |
| ---------------------------------------------------------------- | ---------------------------------------- |
| Absender-E-Mail stimmt mit Daten im ERP überein | email in einem der Verträge eines Kunden |
| In der Nachricht erwähnte E-Mail stimmt mit Daten im ERP überein | email in einem der Verträge eines Kunden |
| Telefonnummer stimmt mit Daten im ERP überein | phone in Kunden- oder Vertragsdaten |
| Vertrags-ID erwähnt | Vertrags-ID (aus ERP/Vertragsdaten) |
| Kunden-ID erwähnt | Kunden-ID (aus ERP/Kundendaten) |
| Vorname erwähnt | firstname in Kunden- oder Vertragsdaten |
| Vorname oder Initial von Vorname erwähnt | firstname in Kunden- oder Vertragsdaten |
| Nachname erwähnt | lastname in Kunden- oder Vertragsdaten |
| Lieferadresse exakt erwähnt | deliveryAddress |
| Rechnungsadresse exakt erwähnt | billingAddress |
| Lieferadresse ähnlich erwähnt (≥ 80% Übereinstimmung) | deliveryAddress |
| Rechnungsadresse ähnlich erwähnt (≥ 80% Übereinstimmung) | billingAddress |
#### Eigene (benutzerdefinierte) Kriterien
Wenn Sie zusätzlich zu den Standardkriterien eigene Merkmale aus Ihrem ERP verwenden möchten (z. B. Bestellnummer, Zählernummer), können Sie benutzerdefinierte Kriterien anlegen.
Dafür definieren Sie:
- Namen des Kriteriums (z. B. “Bestellnummer angegeben”)
- Datenpfad/Variable, nach der enneo suchen soll (muss einem Feld in Ihren Kunden-/Vertragsdaten entsprechen; Punkt-Notation wie rawData.orderData.number wird unterstützt)
- Anzeigetext bei Nichterfolg (z. B. “Bestellnummer 0 wurde nicht gefunden.”; 0 wird durch den gesuchten Wert ersetzt)
## Individuelle Fetslegung von Legitimierungs-Levels
Abweichend vom Regel-Editor kunden können auch nach einer vollständig freien Logik Regeln festlegen, ab wann ein bestimmtes Level erreicht werden soll, um damit kundenindividuelle Regeln abzubilden. Im Zuge dessen können beispielsweise auch ergänzende Legitimierungsinformationen via API eingeholt werden.
Dazu muss unter ERP-Integration im User-Code für \*\*Merkmalbasierte Suche von Verträgen \*\*nicht nur die Kunden- und Vertragsnummer zurück gegeben werden, sondern zusätzlich das Feld
```php
customerLegitimation
```
Hier ein Beispiel für eine Rückgabe des User-Codes bei einem legitimierten Kunden:
```
{
"contractId":"1234"
"customerId":"Cust-1232131"
"customerLegitimation": 20 // Kunde ist sicher legitimiert: Dunkelverarbeitung für E-Mail ist möglich; Bei Chat und Voice ist voller Zugriff auf KI-Agenten möglich
}
```
Hier ein Beispiel für eine Rückgabe des User-Codes bei einem nicht Kunden. Hier wird für Sachbearbeiter eine Warnmeldung erscheinen.
```
{
"contractId":"1234"
"customerId":"Cust-1232131"
"customerLegitimation": 10 // Kunde vermutet, aber nicht sicher
"customerLegitimationMessage": "Kunde hat richtige Vertragsnummer genannt, aber der Name stimmt nicht überein"
}
```
Das Feld `customerLegitimation` definiert welche Warnmeldung einem User angezeigt werden soll.
---
## Ablauf der Kundenerkennung
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/customer-recognition/flow
**Description:** Wie Enneo Kunden und Verträge aus E-Mails, Chats und Telefonaten identifiziert
Enneo führt für jedes eingehende Ticket — unabhängig vom Kanal — eine Kundenerkennung durch. Ziel ist es, den passenden **Vertrag** und **Kunden** in Ihrem stammdatenführenden System (ERP/CRM) zu finden und die Erkennung gemäß den hinterlegten Regeln zu **legitimieren**, bevor Anliegen weiter verarbeitet oder dunkelverarbeitet werden. Enneo ist dabei selbst **nicht** das führende System, sondern ruft die Daten in Echtzeit über User-Code aus Ihrem Quellsystem ab.
## Ablauf bei E-Mails und Briefen
## Ablauf bei Chat und Voicebot
Der Ablauf ist weitgehend identisch zur E-Mail-Verarbeitung — der Unterschied liegt darin, **wann** und **wie** Merkmale erhoben werden.
## Manuelle Suche durch Sachbearbeiter
Unabhängig von der automatischen Kundenerkennung können Sachbearbeiter Verträge jederzeit über das Suchfeld in der UI manuell finden. Dafür ruft Enneo den User-Code für die [Freitextsuche](/docs/de/system-integration/customer-recognition/search-by-free-text) auf, der Suchanfragen nach Name, E-Mail oder anderen relevanten Feldern unterstützen sollte.
## Beispiele
### E-Mail
### Voicebot
---
## Suche nach Merkmalen
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/customer-recognition/search-by-attributes
**Description:** Suche nach Merkmalen
### Daten welche Enneo an ihren Code übergibt (Input)
```json
{
"customerId": "C-abcd-123",
"contractId": "123",
"my-custom-parameter": "abcd", // to be configured in enneo settings
"any-other-parameter-the-ai-found": "abcd",
"ticketId": 123, // always provided natively by enneo, regardless of AI search results
}
```
Die Variabelnamen, z.B. `customerId` oder `my-custom-parameter`, können durch Sie unter Einstellungen -\> Kunden- und Vertragssuche -\> Kundenerkennung mittels KI -\> Suchparameter Kundenidentifikation selbst festgelegt werden, incl. des zur Erkennung verwendeten Prompts. Obige Werte sind Beispiele.
### Datenstruktur welche Enneo als Rückgabewert erwartet (Output)
```json
{
"contractId": "100001", // contract id of the found contract. cannot be null
"customerId": "200001", // customer id associated to the found contract. cannot be null
}
```
Anmerkungen:
- Enneo erwartet immer genau einen oder keinen Vertrag. Wenn die Suchparameter mehr als ein Ergebnis liefern, müssen Sie die Suche so einschränken, dass genau ein Ergebnis vorliegt, bevor Sie Enneo aufrufen.
- Falls die Suche keine Ergebnisse liefert, erwartet Enneo ein leeres Objekt (`{}`) oder ein Null-Ergebnis (`null`).
- Falls Sie die Enneo-Legitimation überschreiben möchten, können Sie die Eigenschaften `customerLegitimation` und `customerLegitimationMessage` hinzufügen. Weitere Informationen finden Sie auf der entsprechenden Dokumentationsseite ([/de/system-integration/customer-recognition/contract-legitimation]).
### Beispielimplementierung
---
## Suche nach Vertragsnummer
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/customer-recognition/search-by-contract-number
**Description:** Datenstruktur
### Daten welche Enneo an ihren Code übergibt (Input)
```json
{
"contractId": "VN-00001"
}
```
### Datenstruktur welche Enneo als Rückgabewert erwartet (Output)
```json
{
// Mandatory properties. Must be defined or enneo to work
"id": "VN-00001", // must be integer or string up to 50 chars
"customerId": "C-abcd-123", // must be integer or string up to 50 chars
"business": false, // boolean, if the customer is a company or private person
"lastname": "Smith", // last name of customer, can be null ONLY if business is true
"company": null, // company name, e.g. "ACME Corp.", can be null ONLY if business is false
// Recommended properties. Should be defined if possible and is used by Enneo's AI and customer identification logic. Default to null if not set
"firstname": "John", // first name of customer, can be null
"email": "john@smith.com",
"deliveryAddress": "Horst-Kohl-Str. 15a, 12157 Berlin", // address of customer
"billingAddress": null, // Optional separate billing address. If null, then billing address is the same as delivery address
"phone": "+49190332332",
"zip": "12157", // Used by the default call/phone identifaction based on contract id and zip code
// Optional preview section for the agent that is shown in top right corner on ticket page
"agentPreview": [
{
"url": "https://my-erp/customers/1234#tab=billing",
"type": "string",
"label": "Abschlag",
"value": "39 €",
"tooltip": null
},
{
"url": null,
"type": "string",
"label": "Verbrauch",
"value": "1085 kWh",
"tooltip": "Abschlagsrelevant: 1085 kWh NB-JVP: 1637 kWh Vorjahr: 1637 kWh Lt. Kd.: 3500 kWh"
}
],
// Links to any systems holding client data you want your agents to have quick access to
"erpUrls": [
{
"url": "https://my-erp.com/contract-details/1234",
"icon": "/icons/powercloud.svg"
},
{
"url": "https://my-marketing-crm.com/customer-details/c123",
"icon": "/icons/link.svg"
}
],
// You may define any other properties you want enneo to be aware of here.
// See below some examples as inspiration from the energy sector
"iban": "DE0000000000000000",
"energy": "electricity",
"status": "expired",
"endDate": "2021-10-28",
"orderId": 752050,
"vatRate": 0.19,
"basePrice": 49.41
}
```
### Beispielimplementierung
---
## Suche nach Kundennummer
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/customer-recognition/search-by-customer-number
**Description:** Datenstruktur
### Daten welche Enneo an ihren Code übergibt (Input)
```json
{
"customerId": "C-abcd-123"
}
```
### Datenstruktur welche Enneo als Rückgabewert erwartet (Output)
```json
{
// Mandatory properties. Must be defined or enneo to work
"id": "C-abcd-123", // must be integer or string up to 50 chars
"business": false, // boolean, if the customer is a company or private person
"lastname": "Smith", // last name of customer, can be null ONLY if business is true
"company": null, // company name, e.g. "ACME Corp.", can be null ONLY if business is false
"contractIds": ["VN-00001", "VN-00002"], // array of contracts this customer has. Must be at least one contract (otherwise it's not a "customer")
// Recommended properties. Should be defined if possible and is used by Enneo's AI and customer identification logic. Default to null if not set
"firstname": "John", // first name of customer, can be null
"email": "john@smith.com",
"deliveryAddress": "Horst-Kohl-Str. 15a, 12157 Berlin", // address of customer
"billingAddress": null, // Optional separate billing address. If null, then billing address is the same as delivery address
"phone": "+49190332332",
// You may define any other properties you want enneo to be aware of here.
// See below some examples as inspiration from the energy sector
"salutation": "Mrs."
}
```
### Beispielimplementierung
---
## Suche nach Freitext
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/customer-recognition/search-by-free-text
**Description:** Suche nach Freitext
### Daten welche Enneo an ihren Code übergibt (Input)
```json
{
"q": "John Smith", // this is the value the user typed into the search field
"limit": 10, // in case of pagination, not currently used
"offset": 0 // in case of pagination, not currently used
}
```
### Datenstruktur welche Enneo als Rückgabewert erwartet (Output)
```json
[
{
"id": "100020" // customer id (not contract id) of first contract that was found
},
{
"id": "200001" // second id
},
{
"id": "200002" // third id
},
{
"id": "200003" // n-th id. Enneo accepts up to 10 search results, any additional results will be ignored.
}
]
```
### Beispielimplementierung
---
## Konzept von Events in Enneo
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/events/concept-of-events-in-enneo
**Description:** Mit der Event-Architektur von Enneo Prozesse effizient gestalten und intelligente Automatisierungen schaffen
### Prozessintegration
Events in Enneo ermöglichen einen effizienten und automatisierten Kundenservice, der auf unterschiedliche Ereignisse reagiert. Dadurch lassen sich bestehende Systeme und Workflows nahtlos integrieren.
### Asynchrone Reaktion auf Events
Durch maßgeschneiderte Konfiguration lässt sich auf Events mit kundenspezifischem Code asynchron reagieren. Das ermöglicht eine Reaktion auf ausgelöste Events, ohne den Hauptprozess zu unterbrechen. So können Aktionen wie die Weiterleitung von Daten an Analyse- oder Reporting-Tools oder die Synchronisation mit anderen Ticketsystemen automatisiert werden.
### Konfiguration von Events
Event-basierte Integrationen können im Bereich der Einstellungen konfiguriert werden unter **Einstellungen -> Integration in Umsysteme -> Events**. Es stehen folgende Events zur Verfügung:
* **AutoProcessIntent**: Der KI-Agent des Tickets wird automatisch verarbeitet.
* **ConversationCreated**: Der Agent antwortete mit einer Nachricht oder einer internen Notiz.
* **CronDay**: Wird jeden Montag bis Freitag um 2 Uhr morgens ausgelöst (0 2 \* \* 1-5).
* **CronHour**: Wird jede Stunde zur ersten Minute ausgelöst (1 \* \* \* \*).
* **CronMinute**: Wird werktags alle 5 Minuten ausgelöst (\*/5 \* \* \* 1-5).
* **CronWeek**: Wird jeden Samstag um 2 Uhr nachts ausgelöst (0 2 \* \* 6).
* **EmailAutoresponder**: Eine automatische Antwort wird dem Kunden gesendet, um ihn darüber zu informieren, dass seine E-Mail eingegangen ist.
* **NotifySurroundingSystems**: Benachrichtigungen an umliegende Systeme hinzufügen.
* **ProfileCreated**: In dem System wurde ein neues Benutzerprofil erstellt.
* **ProfileDeleted**: Ein Benutzerprofil wurde aus dem System gelöscht.
* **ProfileUpdated**: Ein Benutzerprofil wurde aktualisiert, z. B. wurde der Name, die Einstellungen oder andere Eigenschaften geändert.
* **SendEmail**: Sendet eine E-Mail an den Kunden mit einer angegebenen Vorlage und Daten.
* **TestTicketAiQuality**: Führt eine Qualitätsprüfung der KI auf das Ticket durch.
* **TicketClosedDueToInactivity**: Ein Ticket wurde aufgrund von Inaktivität geschlossen.
* **TicketCreated**: Ein neues Ticket wurde empfangen und die KI-Verarbeitung wurde abgeschlossen.
* **TicketForwarded**: Der Agent hat das Ticket an eine andere E-Mail-Adresse oder einen Subchannel weitergeleitet.
* **TicketResponse**: Eine Antwort auf einen Ticket-Thread von einer externen Partei (nicht vom Agenten) wurde empfangen.
* **TicketRouted**: Ein Ticket wurde mit dem Enneo-Routingsystem an einen Agenten weitergeleitet.
* **TicketUpdated**: Eine Ticketeigenschaft wurde von einem Agenten aktualisiert, z. B. wurde es einem Benutzer zugewiesen oder der Status wurde geändert.
Nach der Auswahl eines Events kann über die entsprechende Konfiguration das Handling festgelegt werden. Je nach Szenario kann zwischen der Ausführung von kundenspezifischem Code und einem API-Aufruf entschieden werden. Beim kundenspezifischen Code sind auch API-Aufrufe von Drittsystemen möglich.
* **Kundenspezifischer Code**: Ermöglicht das Ausführen von benutzerdefinierten Skripten, die auf das spezifische Event reagieren. Innerhalb dieses Codes können API-Aufrufe integriert werden, um mit Drittsystemen zu interagieren. Im Code kann Enneo SDK genutzt werden.
* **API-Aufruf**: Bietet die Möglichkeit, einen direkten API-Aufruf auszuführen, um nahtlos mit anderen Systemen zu kommunizieren und die Integration zu verbessern.
Über die Parameterdefinition kann festgelegt werden, welche Eigenschaften des Events im Code bzw. im API-Aufruf verwendet werden.
Um die Datenstruktur der Events besser nachvollziehen zu können, bietet es sich an, diese am Beispiel von Tickets zu betrachten:
1. Ein Ticket öffnen.
2. Oben rechts auf **Ticketdetails** klicken.
3. **Aktivitätsprotokoll** auswählen.
4. Auf **Technische Infos anzeigen** klicken.
Nach dem Klick werden die Events und die darin enthaltenen Daten angezeigt, was ein besseres Verständnis der verfügbaren Eigenschaften eines Events ermöglicht.
### Anwendungsbeispiele
* **Analyse & Reporting:** Konfigurationen können erstellt werden, die bei bestimmten Events automatisch Daten an das bevorzugte Analysetool senden. So stehen immer die neuesten Daten zur Verfügung.
* **Ticketsystem-Synchronisation:** Die Synchronisation mit anderen Ticketsystemen kann automatisiert werden, um sicherzustellen, dass alle Teams auf dem gleichen Stand sind und keine Anfrage verloren geht.
---
## Konzept von Webhooks in Enneo
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/events/concept-of-webhooks-in-enneo
**Description:** Mit Webhook Enneo Prozesse in Echtzeit beeinflussen
Neben den Events, die eine asynchrone Verarbeitung ermöglichen, bietet Enneo auch Webhooks, die eine synchrone
Bearbeitung von Prozessen unterstützen. Webhooks sind besonders nützlich, wenn es darum geht, den Prozessfluss in
Echtzeit zu beeinflussen und externe Systeme direkt einzubinden.
### Webhooks bei E-Mail Empfang / Versand
Mit Webhooks kann eigener Code oder externe APIs aufgerufen werden, sobald bestimmte Ereignisse auftreten,
beispielsweise wenn eine E-Mail empfangen oder versendet wird. Der Aufruf ist synchron, das heißt, bei einem Fehlschlag
wird der Benutzer benachrichtigt.
Um Webhooks für E-Mail Ereignisse zu aktivieren, im Bereich der Einstellungen unter **Kommunikationskanäle**
-> **E-Mail Konten** ein E-Mail Konto auswählen und den Switch **Webhooks** aktivieren.
Anschließend können zwei Webhook-Arten definiert werden:
- **Webhook bei Ticket-Updates:** Wird aufgerufen, wenn sich Eigenschaften eines Tickets ändern, beispielsweise
Status (offen/geschlossen), Priorität, Frist, Zuweisung etc.
- **Webhook bei neuen E-Mails:** Wird bei jeder eingehenden oder ausgehenden E-Mail aufgerufen, ebenso bei internen
Notizen. Wenn die E-Mail eine Antwort auf eine bestehende ist oder ausgeht, wird das `conversationId` Feld gesetzt,
ansonsten ist es `null`.
### Webhooks im Bereich der ERP-Integration
Durch die Integration von Webhooks können externe APIs angebunden werden, um Kundendaten live abzufragen.
Immer wenn Enneo Kundendaten benötigt, wird die Anfrage über den konfigurierten Individualcode an die hinterlegte API
weitergeleitet. Enneo speichert Abfragen zudem zwischen.
Konfiguration erfolgt unter **Einstellungen** -> **Integration der Umsysteme** -> **ERP-Integration**.
Folgende Webhook-Arten sind verfügbar:
- **Suche Vertrag nach ID:** Enneo kann Verträge anhand der Vertrags-ID suchen. Dieser Webhook wird genutzt,
um die Vertragsdaten zu laden.
- **Suche Kunde nach ID:** Enneo kann Kunden anhand der Kunden-ID suchen. Dieser Webhook wird genutzt,
um die Kundendaten zu laden.
- **Merkmalbasierte Suche von Verträgen:** Enneo kann Verträge anhand spezifischer Merkmale durchsuchen.
Dieser Code wird ausgeführt, wenn die Enneo-KI bestimmte Merkmale, z. B. Namen oder Adressen in der Kundenkommunikation
erkennt und darauf basierend Verträge sucht.
- **Freitextsuche von Kunden:** Enneo ermöglicht die Suche nach Kunden mittels einer Freitextsuche. Dieser Code wird
ausgeführt, wenn Agenten die Freitextsuchleiste oben rechts verwenden.
---
## Beispiel: Mehrere KI-Agenten und/oder Folgeantworten dunkelverarbeiten
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/events/example-auto-execute-on-customer-reply
**Description:** Ansatz zur automatischen Ausführung mehrerer KI-Agenten und/oder bei Folgeantworten des Kunden
### Szenario
Enneo führt standardmäßig die automatische Ausführung (Dunkelverarbeitung) von KI-Agenten nur bei der ersten eingehenden E-Mail eines Tickets durch und nur wenn genau ein KI-Agent erkannt wurde. In zwei Situationen greift die Standard-Dunkelverarbeitung daher nicht:
1. **Mehrere KI-Agenten erkannt:** Ein Kunde stellt in einer E-Mail mehrere Anliegen gleichzeitig, z. B. eine Kündigung und einen Widerruf. Enneo erkennt zwar beide KI-Agenten, führt aber aus Sicherheitsgründen keinen automatisch aus.
2. **Folgeantworten:** Ein Kunde antwortet erneut auf ein bestehendes Ticket. Die KI-Verarbeitung läuft zwar (Tags, KI-Agenten-Erkennung, Parameterextraktion), aber die automatische Ausführung wird nicht erneut ausgelöst.
In beiden Fällen wird das Ticket stattdessen einem menschlichen Bearbeiter zugewiesen. Mit einem Event Hook lässt sich dieses Verhalten anpassen.
### Lösungsmöglichkeit
Ein Event Hook reagiert auf eingehende Tickets bzw. Kundenantworten, prüft die erkannten KI-Agenten und löst die automatische Ausführung für jeden einzelnen aus.
### Schritt 1: Event Hook anlegen
Unter **Einstellungen -> Integration in Umsysteme -> Events** einen oder beide der folgenden Event Hooks erstellen:
- **TicketCreated** — wird nach dem Empfang eines neuen Tickets und Abschluss der KI-Verarbeitung ausgelöst. Verwenden, wenn mehrere KI-Agenten auf der initialen E-Mail automatisch ausgeführt werden sollen.
- **TicketResponse** — wird ausgelöst, wenn eine Antwort auf ein bestehendes Ticket vom Kunden empfangen und die KI-Verarbeitung abgeschlossen wurde. Verwenden, wenn KI-Agenten auch bei Folgeantworten automatisch ausgeführt werden sollen.
Der folgende Code kann für beide Events verwendet werden. Er lädt alle erkannten KI-Agenten (Intents) im Status `ready` und führt jeden einzeln aus:
```
POST /api/mind/ticket/:ticketId/autoexecute?executeAgentId=:aiAgentId&allowMultipleIntents=true&allowWithReplies=true
```
### Schritt 2: Automatische Verarbeitung durch Enneo
Nach jedem Aufruf des Autoexecute-Endpunkts führt Enneo folgende Schritte automatisch aus:
1. Die vom KI-Agenten erstellte Antwort wird an den Kunden gesendet.
2. Das Ticket wird geschlossen.
3. Das Ticket wird als vollautomatisiert verarbeitet markiert (L5).
Bei mehreren KI-Agenten wird jeder separat ausgeführt und die Ergebnisse werden nacheinander verarbeitet.
### Hinweise
- Das **TicketCreated**-Event eignet sich für die initiale E-Mail mit mehreren Anliegen. Das **TicketResponse**-Event eignet sich für Folgeantworten. Beide Events können gleichzeitig mit demselben Code konfiguriert werden.
- Der Parameter `allowWithReplies=true` ist notwendig, weil Enneo standardmäßig die automatische Ausführung blockiert, sobald eine eingehende Kundenantwort auf dem Ticket existiert. Für das **TicketCreated**-Event ist dieser Parameter wirkungslos, da es noch keine Antworten gibt.
- Der Parameter `allowMultipleIntents=true` ist notwendig, weil ohne ihn die Ausführung bei mehreren erkannten Agenten aus Sicherheitsgründen abgelehnt wird.
- Der Parameter `executeAgentId` stellt sicher, dass pro Aufruf nur der gewünschte KI-Agent ausgeführt wird.
- Es empfiehlt sich, im Code eine Positivliste (`allowedAgentIds`) der KI-Agenten zu pflegen, die für die automatische Ausführung freigegeben sind.
---
## Beispiel: Smarte KI-Agenten automatisch ausführen
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/events/example-auto-execute-smart-agents
**Description:** Ansatz zur automatischen Ausführung smarter KI-Agenten basierend auf eigenen Sicherheitskriterien
### Szenario
Enneo verarbeitet standardmäßig bei E-Mails und Briefe nur Regelbasierte KI-Agenten per Dunkelverarbeitung, nicht aber rein prompt-basierte. Hintergrund ist das die Zuverlässigkeit von rein per KI erzeugtem Text weniger planbar ist als bei einem Regelwertk.
Es gibt aber bestimmte Kundenanfragen – z. B. Passwort-Rücksetzungsanleitungen oder Login-Probleme mit der Android- oder Apple-App – welche mit gewisser Zuverlässigkeit vollautomatisch beantwortet werden können. Anstatt die Standard-Dunkelverarbeitung zu nutzen, soll der smarte KI-Agent selbst entscheiden, ob eine Antwort sicher genug ist, um automatisch versendet zu werden.
### Lösungsmöglichkeit
Der Ansatz besteht aus vier Schritten: Ein benutzerdefiniertes KI-Tool kennzeichnet sichere Antworten, ein Event Hook prüft die Kennzeichnung und löst die automatische Ausführung aus.
### Schritt 1: Benutzerdefiniertes KI-Tool erstellen
Unter **Einstellungen -> KI-Anpassung -> KI-Tools** ein neues Werkzeug erstellen, z.B. mit dem Namen `mark_answer_as_safe`. Dieses Tool wird vom smarten KI-Agenten aufgerufen, wenn er sich sicher ist, dass die Antwort automatisch versendet werden kann.
Im Prompt des smarten KI-Agenten muss auf das Tool verwiesen werden, z. B.:
> Die folgenden Arten von Anfragen sollen als sicher markiert werden: (a) Passwort zurücksetzen oder (b) Login-Probleme mit der Android- oder Apple-App. Rufe in diesen Fällen das Tool `mark_answer_as_safe` auf.
### Schritt 2: Ticket im Tool als automatisch ausführbar kennzeichnen
Im Code des Tools `mark_answer_as_safe` wird das Ticket per API als automatisch ausführbar markiert, z.B. mit folgendem Code:
### Schritt 3: Event Hook für TicketCreated anlegen
Unter **Einstellungen -> Integration in Umsysteme -> Events** einen neuen Event Hook für das Event **TicketCreated** erstellen. Dieses Event wird ausgelöst, nachdem ein neues Ticket empfangen und die KI-Verarbeitung abgeschlossen wurde.
Im kundenspezifischen Code wird geprüft, ob das Ticket als sicher markiert wurde. Bei Bedarf können zusätzliche Prüfungen durchgeführt werden, z. B. ob bestimmte Tags gesetzt oder der Kunde eindeutig erkannt wurde.
Wenn alle Kriterien erfüllt sind, wird die automatische Ausführung ausgelöst:
```
POST /api/mind/ticket/:ticketId/autoexecute?executeAgentId=:aiAgentId
```
Der Parameter `executeAgentId` ist die numerische ID des KI-Agenten, der ausgeführt werden soll. Alle anderen ggf. erkannten KI-Agenten werden ignoriert.
### Schritt 4: Automatische Verarbeitung durch Enneo
Nach dem Aufruf des Autoexecute-Endpunkts führt Enneo folgende Schritte automatisch aus:
1. Die vom KI-Agenten erstellte Antwort wird an den Kunden gesendet.
2. Das Ticket wird geschlossen.
3. Das Ticket wird als vollautomatisiert verarbeitet markiert (L5).
---
## Beispiel: Datenexport für Reporting
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/events/example-data-export-for-reporting
**Description:** Übermittlung von Daten an ein Reportingsystem am Beispiel
### Szenario
Angenommen, es existiert ein Reporting-System, in dem die Statusangaben zu den Tickets aus Enneo dargestellt werden sollen. Das Drittsystem verfügt über eine technische Schnittstelle (API), über die die Informationen zu den Tickets übermittelt werden können. Das Drittsystem benötigt als Eingabeparameter beim Aufruf der Schnittstelle den Absender des Tickets sowie den Status des Tickets.
### Lösungsmöglichkeit
Jede Statusänderung eines Tickets triggert ein "TicketUpdated" Event. Um diesen Ablauf zu konfigurieren, gehe zu **Einstellungen -> Integration in Umsysteme -> Events** und erstelle einen neuen Event Hook, indem das "TicketUpdated" Event ausgewählt wird. Anschließend kann mit der Konfiguration begonnen werden.
### Einsehen der Daten im Event
Die Daten, die im Event zur Verfügung gestellt werden, können an einem der Tickets eingesehen werden. Hier ein Beispiel der Daten:
```json
{
"userId": 123,
"changes": {
"status": "closed"
},
"ticketId": 456
}
```
In diesem Fall wurde das Ticket mit der ID 456 vom User mit der ID 123 geschlossen.
### Beispiel für den kundenspezifischen Code
Falls die im Event zur Verfügung stehenden Daten nicht ausreichen, können im kundenspezifischen Code weitere Daten mit Hilfe der Enneo SDK nachgeladen werden.
Konfigurierte Eingabeparameter werden von Enneo geladen und stehen in der Input-Variable zur Verfügung. Als Output wird ein valides JSON\_objekt erwartet, welches nach der Ausführung in den technischen Details des Aktivitätsprotokolls am Ticket angezeigt wird.
---
## Beispiel: Abgleich mit weiterem Ticketsystem
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/events/example-reconciliation-with-another-ticket-system
**Description:** Abgleich von Konversationen an Tickets mit einem anderen Ticketsystem am Beispiel
### Szenario
In manchen Fällen ist es notwendig, dass bestimmte Tickets und die dazugehörigen Konversationen in einem weiteren
Ticketsystem verfügbar sind. So kann beispielsweise eine Antwort eines Kunden auf eine Anfrage aus dem Ticket auch
im parallel laufenden System angezeigt werden. Dies kann durch den Einsatz eines Webhooks ermöglicht werden.
### Lösungsmöglichkeit
Um sicherzustellen, dass neue Konversationen in beiden Systemen synchronisiert werden, kann ein Webhook implementiert werden.
Unter **Einstellungen** -> **Kommunikationskanäle** -> **E-Mail Konten** muss dazu das entsprechende E-Mail Konto
ausgewählt werden. Falls die Webhooks an diesem Konto noch nicht aktiv sind, muss der Switch **Webhooks** aktiviert werden,
damit die Felder zur Konfiguration des Webhooks "Neue E-Mail" erscheinen.
### Beispiel für den kundenspezifischen Code
Der folgende PHP-Code nutzt das Enneo SDK, um Informationen von einem Ticket-System abzurufen und diese an ein
drittes System zu übermitteln.
In diesem Beispiel wird mithilfe des Enneo SDK zunächst das Nutzerprofil geladen.
Anschließend werden erweiterte Daten zum Ticket sowie die Konversationen geladen.
Am Ende des Codeausschnitts werden die Daten der aktuellen Konversation an das externe Ticketsystem übertragen.
Hierbei wird eine Funktion `send-to-third-party` verwendet, die zuvor als
["User defined Function"](/docs/de/system-integration/user-defined-functions-tools/user-defined-functions-in-enneo) hinterlegt werden muss.
---
## Claude Code Plugin
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/integration-of-third-party-systems/claude-code-plugin
**Description:** KI-gestützte Entwicklung von Enneo-Integrationen — Agenten, UDFs, Einstellungen und Debugging — direkt aus dem Terminal.
Das **Enneo Claude Code Plugin** verbindet [Claude Code](https://claude.ai/code) mit Ihrer Enneo-Instanz. Sie können damit Integrationen — regelbasierte Agenten, UDFs, Event-Hooks, Einstellungen — per natürlicher Sprache entwickeln und debuggen, während Claude die API-Aufrufe übernimmt.
## Installation
```bash
claude plugin marketplace add https://github.com/enneo-AI/claude-plugin
claude plugin install enneo@claude-plugin
```
Nach der Installation Claude Code neu starten. Einrichtung und Authentifizierung sind im [Plugin-README](https://github.com/enneo-AI/claude-plugin) beschrieben.
---
## Beispiele
### Regelbasierte Agenten entwickeln
```
Zeig mir alle vorhandenen regelbasierten Agenten und ihre Executor-Sprachen
```
```
Hol mir den vollständigen Quellcode des Agenten "Vertragskündigung"
```
```
Erstelle einen neuen Agenten "Adressänderung", der aus der Kundennachricht
eine neue Postanschrift extrahiert, validiert und eine Bestätigungsantwort sendet.
Sprache: Python. Kanal: E-Mail.
```
```
Vorschau von Agent #42 auf Ticket #1234 — welche Daten würde er extrahieren
und welche Optionen anbieten, ohne etwas zu verändern?
```
### KI-Verarbeitung debuggen
```
Warum hat kein KI-Agent Ticket #5678 bearbeitet?
```
```
Zeig mir die vollständige Event-Spur für Ticket #5678
```
```
Starte die KI-Verarbeitung für Ticket #5678 neu und zeig mir die neuen Intents
```
### Einstellungen und Konfiguration
```
Welche Einstellungen steuern das Auto-Processing? Zeig mir deren aktuelle Werte.
```
```
Welche Agenten stehen in der immediateAiAgents-Liste?
```
```
Liste alle E-Mail-Subkanäle auf
```
### UDFs und Event-Hooks
```
Liste alle UDFs auf und zeig, welche auch als KI-Tools verfügbar sind
```
```
Erstelle eine UDF "lookup_customer_by_vat" in Python, die unsere ERP-API
unter https://erp.example.com/api/customer aufruft und den Kundendatensatz zurückgibt
```
```
Gib mir den lokalen Ausführungsbefehl, um "lookup_customer_by_vat"
gegen Ticket #9999 zu testen
```
```
Füge einen Event-Hook hinzu, der "notify_slack" aufruft, wenn ein Ticket
im Subkanal support@firma.de erstellt wird
```
### Tickets untersuchen
```
Zeig mir alle offenen Tickets der letzten 24 Stunden mit Kanal E-Mail
```
```
Finde alle Tickets, bei denen KI-Agent #7 in der letzten Woche einen Intent erstellt hat
```
---
## Codex Plugin
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/integration-of-third-party-systems/codex-plugin
**Description:** KI-gestützte Arbeit mit Enneo-Instanzen — Tickets, KI-Agenten, Einstellungen und Debugging — direkt aus Codex.
Das **Enneo Codex Plugin** verbindet [Codex](https://openai.com/codex) mit Ihrer Enneo-Instanz. Sie können damit Tickets untersuchen, KI-Agenten entwickeln, Einstellungen prüfen und Integrationen über natürliche Sprache debuggen, während Codex die API-Aufrufe übernimmt.
## Installation
```bash
codex plugin marketplace add https://github.com/enneo-AI/codex-plugin
codex plugin add enneo-codex@enneo
```
Nach der Installation Codex neu starten. Einrichtung und Authentifizierung sind im [Plugin-README](https://github.com/enneo-AI/codex-plugin) beschrieben.
---
## Beispiele
### Verbindung einrichten
```
Use the Enneo Codex plugin. Connect to .enneo.ai and show my profile.
```
```
Connect to demo.enneo.ai and verify the Enneo profile.
```
### Tickets untersuchen
```
Search recent open tickets in Enneo.
```
```
Get ticket #1234 and summarize the customer request, detected intents, tags, and next best action.
```
```
Investigate why an Enneo AI agent skipped ticket #5678.
```
### KI-Agenten entwickeln
```
Show me the configured AI agents and explain which one should handle ticket #1234.
```
```
Review the executor logic for the address-change agent and suggest a safer validation path.
```
```
Create a draft plan for turning this support process into a rule-based Enneo agent.
```
### Einstellungen und Integrationen prüfen
```
List the configured email subchannels and identify which mailbox receives support requests.
```
```
Show the customer-recognition settings and explain which API calls are required.
```
```
Check which UDFs are available as AI tools.
```
---
## Chat (Bot)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/integration-of-contact-channels/chat-bot
**Description:** Chat (Bot)
---
## Chat (Mensch)
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/integration-of-contact-channels/chat-human
**Description:** Chat (Mensch)
---
## Chat
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/integration-of-contact-channels/chat
**Description:** Optionen und Konfiguration
## Chatbot-Konfiguration
Unter **Einstellungen → Chat** können beliebig viele Chatbots angelegt und konfiguriert werden. Jeder Chatbot verfügt über eigene Einstellungen wie Name, Begrüßungsnachricht und Erscheinungsbild.
### Zuordnung zum KI-Agenten
Jeder Chatbot ist einem **KI-Agenten** zugeordnet. Dieser Agent liefert den initialen Prompt, auf dessen Grundlage die Chatkonversation stattfindet. Standardmäßig wird der **Basis-Agent** verwendet.
## Einbindung auf der Webseite
Das Chat-Widget wird über einen JavaScript-Code auf der gewünschten Webseite eingebunden:
```html
```
Ersetzen Sie `[your-domain]` durch Ihre Enneo-Domain und `[your-subchannelid]` durch die ID Ihres Chatbots.
##########################################################################
## Chatbot-Konfiguration
Unter **Einstellungen → Chat** können beliebig viele Chatbots angelegt und konfiguriert werden. Jeder Chatbot verfügt über eigene Einstellungen für Name, Status, Erscheinungsbild, KI-Agent, Startseite und Widget-Einbindung.
### Allgemeine Einstellungen
In den allgemeinen Einstellungen legen Sie fest, wie der Chatbot im Chatfenster angezeigt wird:
- **Interne Bezeichnung** — Name des Chatbots innerhalb von Enneo.
- **Status** — steuert, ob der Chatbot aktiv, inaktiv oder fehlerbehaftet ist.
- **Name und Avatar des Chatbots** — werden Kundinnen und Kunden im Chat angezeigt.
- **Name und Avatar des Agenten** — werden verwendet, wenn ein menschlicher Agent antwortet.
- **Unternehmensname und Logo** — erscheinen auf der Chat-Startseite und im Chatfenster.
### Zuordnung zum KI-Agenten
Jeder Chatbot ist einem **KI-Agenten** zugeordnet. Dieser Agent übernimmt die initiale Kommunikation mit dem Kunden. Standardmäßig wird der **Basis-Agent** verwendet.
### Übergabe an menschliche Agenten
Für Chatbots kann konfiguriert werden, ob eine **Übergabe an menschliche Agenten** möglich ist.
Wenn die Übergabe aktiviert ist, kann der Chatbot bei Bedarf an einen menschlichen Agenten übergeben. Zusätzlich kann der **Echtzeit-Chat mit menschlichen Agenten** aktiviert werden:
- Ist der Echtzeit-Chat aktiviert, wird bei einer Übergabe ein offenes Chat-Ticket erstellt, das manuell durch einen Agenten übernommen werden kann.
- Ist der Echtzeit-Chat deaktiviert oder ist der Kunde nicht mehr online, wird das Anliegen asynchron weiterbearbeitet. Falls eine E-Mail-Adresse bekannt ist, kann die Antwort zusätzlich per E-Mail zugestellt werden.
### Kundenlegitimation im Chat
Chatbots können eigene Regeln für die **Kundenlegitimation** verwenden. Dadurch lässt sich je Chatbot festlegen, welche Informationen ein Kunde nennen muss, bevor der Chatbot oder aufgerufene KI-Agenten Zugriff auf Kundendaten erhalten.
Wenn keine spezifischen Regeln hinterlegt sind, gelten die allgemeinen Einstellungen unter **Kunden- und Vertragssuche** für Chatbot und Voicebot.
## Startseite des Chat-Widgets
Das Chat-Widget verfügt über eine konfigurierbare Startseite. Dort können Kunden entweder einen freien Chat starten, ein häufiges Anliegen auswählen oder eine bestehende Konversation fortsetzen.
### Freier Chat
Für den freien Chat können Titel, Beschreibung und Einführungsnachrichten konfiguriert werden. Die Einführungsnachrichten werden automatisch angezeigt, sobald der Kunde den Chat startet.
### Schnellaktionen / Häufige Anliegen
Zusätzlich können **Schnellaktionen** hinterlegt werden. Diese erscheinen auf der Startseite als auswählbare Anliegen, z. B. „Bankdaten anpassen“.
Für jede Schnellaktion können unter anderem festgelegt werden:
- Titel der Aktion,
- optional ein zugehöriger KI-Agent bzw. Intent,
- eigene Einführungsnachrichten für diesen Einstieg.
Dadurch kann ein Chat direkt mit einem passenden Kontext oder spezifischen Anliegen gestartet werden.
### Bestehende Chats fortsetzen
Das Widget kann die letzte bestehende Konversation anzeigen. Kunden können dadurch einen bereits begonnenen Chat wieder öffnen und fortsetzen.
## Erscheinungsbild
Das Design des Chat-Widgets kann je Chatbot angepasst werden:
- Primärfarbe des Chatfensters,
- Sekundärfarbe für Buttons,
- Textfarbe auf der Startseite,
- Rundungen des Chatfensters,
- Logo, Bot-Avatar und Agenten-Avatar.
## Einbindung auf der Webseite
Das Chat-Widget wird über einen JavaScript-Code auf der gewünschten Webseite eingebunden. Den fertigen Code finden Sie in den Einstellungen des jeweiligen Chatbots unter **„Widget Code"**.
```html
```
Ersetzen Sie [your-domain] durch Ihre Enneo-Domain und [your-subchannelid] durch die ID Ihres Chatbots.
### Widget aktivieren oder deaktivieren
Über die Einstellung Widget aktiv kann das Chat-Widget ein- oder ausgeschaltet werden. Wenn das Widget deaktiviert ist, wird es auf der Webseite nicht angezeigt – auch dann nicht, wenn der JavaScript-Code weiterhin eingebunden ist.
---
## Kontaktkanäle
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/integration-of-contact-channels/contact-channels-overview
**Description:** Funktionsübersicht und Einstiegspunkte
## Unterstützte Kanäle in Enneo
Enneo unterstützt drei primäre Kommunikationskanäle:
| Kanal | Interaktionsmodell | Typische Nutzung | Besonderheiten |
|---|---|---|---|
| **E-Mail / Brief** | asynchron | schriftliche Kommunikation, Dokumente, Rückmeldungen | klassische Eingangskanäle für Servicecentern |
| **Chat** | Echtzeit / asynchron | Live-Chat, Self Service, Assistenz über Chatbot | spricht Endkunden direkt im Web oder in Apps an |
| **Voice** | Echtzeit | Telefonie, Beratung, Sprachdialoge | unterstützt Telefonie und Voice-Bots |
Alle Kanäle nutzen dieselben Bearbeitungslogiken (Ticketing, Routing, Automatisierung), unterscheiden sich jedoch hinsichtlich Interaktion, Reaktionszeit und Konfiguration.
## Funktionsprinzip
Unabhängig vom Kanal folgt der Ablauf demselben Prinzip:
1. Nachricht oder Anruf geht ein
2. Enneo legt ein Ticket an oder aktualisiert es
3. Routing entscheidet über Zielteam oder Bearbeiter
4. Bearbeitung erfolgt manuell oder durch KI-Agenten
Damit ist die technische Basis aller Kanäle identisch, und Konfigurationen können kanalübergreifend einheitlich erfolgen.
## Abhängigkeiten und Voraussetzungen
Für den Betrieb eines Kanals sind in der Regel folgende Aspekte zu berücksichtigen:
- existierende Kommunikationsinfrastruktur (E-Mail, Telefonie, Chat)
- Berechtigungen und Routingregeln
- Sichtbarkeit für Agenten und Teams
- Anbindung von Kundendaten (für kontextbezogene Bearbeitung)
- optionale KI-Agenten für Automatisierung
Die Aktivierung erfolgt pro Kanal, die technische Logik bleibt systemweit konsistent.
## Welcher Kanal zuerst?
In Projekten beginnt die Einführung typischerweise mit E-Mail, da schriftliche Eingangskanäle häufig bereits vorhanden sind und keine zusätzliche Infrastruktur benötigen. Chat und Voice können jederzeit ergänzt werden und folgen demselben Integrationsmodell.
Die Wahl des ersten Kanals ist projektbezogen und richtet sich nach:
- bestehender Eingangskommunikation
- erwarteten Volumina
- gewünschten Interaktionsarten (Echtzeit oder asynchron)
- technischer Infrastruktur
## Weiterführende Konfiguration
Die konkreten Konfigurationsschritte sind je Kanal unterschiedlich. Die folgenden Abschnitte beschreiben die technischen Integrationswege:
- [E-Mail](/docs/de/system-integration/integration-of-contact-channels/email)
- [Brief](/docs/de/system-integration/integration-of-contact-channels/mail)
- [Chat](/docs/de/system-integration/integration-of-contact-channels/chat)
- [Voice](/docs/de/system-integration/integration-of-contact-channels/voice)
---
## E-Mail
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/integration-of-contact-channels/email
**Description:** Optionen und Konfiguration
### **IMAP**
Die IMAP-Integration ruft E-Mails von einem IMAP-Mailserver ab und sendet sie darüber. Enneo unterstützt eine unbegrenzte Anzahl von Postfächern, sodass mehrere E-Mail-Konten verbunden und alle E-Mails zentral verwaltet werden können. Ob private und berufliche Postfächer oder mehrere Konten für unterschiedliche Projekte – mit der IMAP-Integration können alle E-Mails komfortabel an einem Ort organisiert werden.
Die IMAP-Integration sorgt für ein reibungsloses Erlebnis bei der Verwaltung von E-Mails. E-Mails können gelesen, beantwortet und organisiert werden, ähnlich wie in einem E-Mail-Client. Durch die Verbindung mehrerer Postfächer wird die gesamte Kommunikation gebündelt, und der Wechsel zwischen verschiedenen E-Mail-Konten entfällt.
### **API**
Die Enneo-API und die `/ticket`-Endpoints ermöglichen das Erstellen und Bearbeiten von E-Mails. Diese Option bietet eine nahtlose Zwei-Wege-Synchronisation zwischen Enneo und bestehenden Ticketsystemen. Die API ermöglicht nicht nur das Abrufen und Senden von E-Mails, sondern auch das Auslösen und Empfangen von Webhooks, um die Synchronisation der E-Mail-Kommunikation mit anderen Systemen sicherzustellen.
Die API-Integration bietet ein höheres Maß an Anpassung und Automatisierung. E-Mails können programmatisch erstellt und verwaltet und nahtlos in bestehende Workflows integriert werden. Diese Option eignet sich besonders für Unternehmen, die zwei Ticketsysteme parallel nutzen, etwa während einer Testphase. Änderungen, die in Enneo oder einem anderen Ticketsystem vorgenommen werden, werden dank der Zwei-Wege-Synchronisation auf beiden Plattformen synchronisiert, wodurch eine konsistente und aktuelle Kommunikation gewährleistet wird.
Hier ein Beispiel für eine Anfrage:
```bash
curl --location 'https://demo.enneo.ai/api/mind/ticket' \
--header 'Authorization: bearer ' \
--data-raw '{
"fromName": "Customer Service",
"process": "batch",
"from": "support@enneo.ai",
"to": [
"eugene@enneo.ai"
],
"priority": "medium",
"channel": "email",
"status": "open",
"subject": "Subject",
"body": "Body New",
"direction": "in",
"firstResponseDueBy": "2024-01-01 00:00:00",
"dueBy": "2024-01-01 00:00:00",
"tags": [
54
],
"contractId": 781506,
"attachments": [
{
"name": "myattachment.png",
"url": "https://www.enneo.ai/wp-content/uploads/2022/11/Frame.png"
}
]
}'
```
Weitere Details zu den relevanten `/ticket`-Endpoints, einschließlich der Parameter, sind hier zu finden:
[**API Dokumentation**](/docs/de/api-reference/introduction)
### OAuth-basierte Anbindung (Microsoft 365)
Neben der klassischen IMAP- oder API-Anbindung können Postfächer auch direkt über OAuth verbunden werden.
Die Einrichtung erfolgt über eine einmalige Autorisierung und ermöglicht anschließend den automatischen Empfang und Versand von E-Mails über Enneo.
Einrichtungsschritte:
* Microsoft 365 als Methode auswählen.
* E-Mail-Adresse des Postfachs hinterlegen
* Auf "Konto verknüpfen" klicken und den Anmeldevorgang beim jeweiligen Anbieter abschließen.
* Nach erfolgreicher Autorisierung werden Access Token und Refresh Token automatisch befüllt.
* Mit "E-Mail Empfang testen" kann die Konfiguration überprüft werden.
#### Häufig gestellte Fragen (FAQ)
---
## Adressformat-Validierung
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/integration-of-contact-channels/mail-address-validation
**Description:** Adressen in Enneo müssen folgendes Format haben, damit ausgehende Briefe durch die Post korrekt zugestellt werden können
## Übersicht
Dieser Leitfaden erklärt die vom System unterstützten Adressformate. Adressen müssen eine gültige Postleitzahl gefolgt von einem Ortsnamen in derselben Zeile enthalten, um eine ordnungsgemäße Validierung zu gewährleisten.
## Allgemeine Adressstruktur
- Regel 1: Muss zwischen 3 und 5 Zeilen haben
- Regel 2: In der letzten oder vorletzten Zeile muss eine gültige PLZ gefolgt von einer Stadt sein
### Typischer Aufbau einer vollständigen Adresse
#### 3-Zeilen-Format (Minimum)
```
[Name]
[Straße Hausnummer]
[Postleitzahl] [Ort]
```
Beispiel:
```
Max Mustermann
Hauptstraße 123
10115 Berlin
```
#### 4-Zeilen-Format
```
[Empfängername/Firma]
[Straße Hausnummer]
[Postleitzahl] [Ort]
[Land]
```
Beispiel:
```
Max Mustermann
Hauptstraße 123
10115 Berlin
Deutschland
```
```
ABC GmbH
z. Hd. Max Mustermann
Hauptstraße 123
10115 Berlin
```
#### 5-Zeilen-Format (Maximum)
```
[Empfängername]
[Firma/Abteilung]
[Straße Hausnummer]
[Postleitzahl] [Ort]
[Land]
```
Beispiel:
```
Max Mustermann
Muster GmbH
Hauptstraße 123
10115 Berlin
Deutschland
```
### Anforderungen an die Postleitzahlenzeile
Die Zeile mit der Postleitzahl muss folgendem Format entsprechen:
```
[Postleitzahl] [Ortsname]
```
Die Postleitzahl muss von mindestens einem Leerzeichen gefolgt sein und dann der Ortsname folgen.
## Unterstützte Postleitzahlenformate nach Land/Region
### Europa
#### Niederlande
- **Format**: 4 Ziffern + 2 Buchstaben (mit oder ohne Leerzeichen)
- **Beispiele**:
- `1234 AB Amsterdam`
- `1234AB Amsterdam`
#### Vereinigtes Königreich
- **Format**: UK-Postleitzahl (verschiedene Formate)
- **Beispiele**:
- `SW1A 1AA London`
- `SW1A1AA London`
- `M1 1AA Manchester`
- `B33 8TH Birmingham`
- `CR2 6XH Croydon`
- `DN55 1PT Doncaster`
#### Deutschland, Frankreich, Spanien, Italien, Finnland, Luxemburg
- **Format**: 5 Ziffern
- **Beispiele**:
- `10115 Berlin`
- `75001 Paris`
- `28001 Madrid`
- `00100 Roma`
- `00100 Helsinki`
#### Belgien, Schweiz, Österreich, Dänemark, Norwegen
- **Format**: 4 Ziffern
- **Beispiele**:
- `1000 Brüssel`
- `8000 Zürich`
- `1010 Wien`
- `1050 Kopenhagen`
- `0150 Oslo`
#### Portugal
- **Format**: 4 Ziffern - 3 Ziffern
- **Beispiele**:
- `1000-001 Lissabon`
- `4000-001 Porto`
#### Polen
- **Format**: 2 Ziffern - 3 Ziffern
- **Beispiele**:
- `00-001 Warschau`
- `30-001 Krakau`
#### Schweden, Tschechien
- **Format**: 3 Ziffern [Leerzeichen] 2 Ziffern
- **Beispiele**:
- `123 45 Stockholm`
- `110 00 Prag`
#### Irland
- **Format**: Buchstabe + 2 Ziffern [Leerzeichen] 4 alphanumerische Zeichen (Eircode)
- **Beispiele**:
- `D02 AF30 Dublin`
- `A65 F4E2 Galway`
### Amerika
#### Vereinigte Staaten
- **Format**: 5 Ziffern oder 5 Ziffern - 4 Ziffern (ZIP+4)
- **Beispiele**:
- `10001 New York`
- `90210 Beverly Hills`
- `10001-0001 New York`
#### Kanada
- **Format**: 5 Ziffern (wie USA)
- **Beispiele**:
- `10001 Toronto`
- `90001 Vancouver`
#### Brasilien
- **Format**: 5 Ziffern - 3 Ziffern (CEP)
- **Beispiele**:
- `01310-100 São Paulo`
- `20040-020 Rio de Janeiro`
### Asien
#### Japan
- **Format**: 3 Ziffern - 4 Ziffern
- **Beispiele**:
- `100-0001 Tokio`
- `530-0001 Osaka`
#### Indien
- **Format**: 6 Ziffern (PIN-Code)
- **Beispiele**:
- `110001 Delhi`
- `400001 Mumbai`
#### China
- **Format**: 6 Ziffern
- **Beispiele**:
- `100000 Peking`
- `200000 Shanghai`
### Ozeanien
#### Australien, Neuseeland
- **Format**: 4 Ziffern
- **Beispiele**:
- `2000 Sydney`
- `3000 Melbourne`
- `1010 Auckland`
### Afrika
#### Südafrika
- **Format**: 4 Ziffern
- **Beispiele**:
- `0001 Pretoria`
- `8001 Kapstadt`
### Russland
- **Format**: 6 Ziffern
- **Beispiele**:
- `101000 Moskau`
- `190000 Sankt Petersburg`
## Wichtige Hinweise
### Allgemeine Anforderungen
1. Sollte ein Komma in der Adresszeile existieren, z.B. "Max Mustermann, Marina Mustermann" oder "Max Mustermann, ABC-Straße 1", so ersetzt ein Komma mit einer neuen Zeile - bitte nutzen sie daher ein Komma entsprechend
2. Leere Zeilen werden gelöscht
### Postleitzahlen-Spezifische Anforderungen
1. **Leerzeichen**: Der Postleitzahl muss mindestens ein Leerzeichen vor dem Ortsnamen folgen
2. **Ortsname erforderlich**: Nach der Postleitzahl muss ein Ortsname (oder ein beliebiger Text ohne Leerzeichen) folgen
3. **Groß-/Kleinschreibung**: Bei Formaten mit Buchstaben (UK, Niederlande, Irland) werden Großbuchstaben erwartet
4. **Vollständige Zeilen**: Die gesamte Postleitzahl und der Ort müssen in derselben Zeile stehen
## Ungültige Beispiele
### Ungültige Postleitzahlenzeilen
❌ `12345` - Ortsname fehlt
❌ `12345 ` - Nur Leerzeichen nach Postleitzahl
❌ `Berlin 10115` - Ort vor Postleitzahl
❌ `1234ab Amsterdam` - Kleinbuchstaben (Niederlande)
❌ `sw1a 1aa London` - Kleinbuchstaben (UK)
### Ungültige vollständige Adressen
❌ Zu wenige Zeilen (nur 2 Zeilen):
```
Hauptstraße 123
10115 Berlin
```
❌ Zu viele Zeilen (6 Zeilen):
```
Herr
Max Mustermann
Muster GmbH
Abteilung IT
Hauptstraße 123
10115 Berlin
```
❌ Leere Zeilen innerhalb der Adresse:
```
Max Mustermann
Hauptstraße 123
10115 Berlin
Deutschland
```
❌ Keine Postleitzahlenzeile:
```
Max Mustermann
Hauptstraße 123
Deutschland
```
## Gültige Beispiele
### Gültige Postleitzahlenzeilen
✅ `10115 Berlin`
✅ `SW1A 1AA London`
✅ `1234 AB Amsterdam`
✅ `75001 Paris`
✅ `10001-0001 New York`
✅ `100-0001 Tokio`
✅ `D02 AF30 Dublin`
---
## Brief
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/integration-of-contact-channels/mail
**Description:** Optionen und Konfiguration
Genau wie E-Mails können auch Briefe in Enneo auf zwei Arten verbunden werden, abhängig von den Anforderungen: IMAP und API.
## Empfang von Briefen
### Variante 1: Import von Briefen als E-Mail mit Anhang
Diese Lösung wird empfohlen, wenn ein Scandienst verwendet wird, der eingehende Briefe in E-Mails mit den Briefen als Anhang (z. B. PDF) umwandelt.
Zum Verbinden von Briefen sind folgende Schritte notwendig:
1. Verbinden des Postfachs wie hier beschrieben: [E-Mails verbinden](/docs/de/system-integration/integration-of-contact-channels/email)
2. Sicherstellen, dass die E-Mails als Briefe erkannt werden. Enneo erkennt eine E-Mail als Brief, wenn folgende Kriterien erfüllt sind:
- Der Absender der E-Mail ist der Scandienst. Die E-Mail-Adresse des Absenders kann in den Brief-Einstellungen angegeben werden.
- Der Betreff der E-Mail enthält ausschließlich das Wort „LETTER“. Falls ein anderes Schlüsselwort bevorzugt wird, kann dies in den Brief-Einstellungen angepasst werden.
### Variante 2: Import von Briefen über die REST API
1. Beim Import von Briefen über die API muss das `channel`-Attribut auf „letter“ gesetzt werden. Enneo übernimmt den Rest.
2. Ein Beispiel für eine Anfrage mit minimalen Parametern:
```bash
curl --location 'https://demo.enneo.ai/api/mind/ticket' \
--header 'Authorization: bearer ' \
--data '{
"channel": "letter",
"process": "batch",
"attachments": [
{
"base64": "base-64-encoded-string-of-pdf-or-image-file",
}
]
}
```
**Hinweise:**
- Der Parameter `process` kann auf `batch` (Standard), `realtime` oder `false` gesetzt werden. In allen Fällen kehrt die API-Antwort sofort nach dem Speichern des Tickets zurück – die KI-Verarbeitung läuft im Hintergrund. Der Unterschied liegt darin, *wann* sie startet: Bei `batch` wird das Ticket in die normale Verarbeitungswarteschlange eingereiht und vom nächsten freien Worker abgearbeitet. Bei `realtime` wird die KI-Verarbeitung sofort in einem eigenen Hintergrundprozess angestoßen, ohne in der Warteschlange zu warten – sinnvoll, wenn ein Ticket bevorzugt sofort verarbeitet werden soll. Bei `false` wird das Ticket ohne KI-Verarbeitung angelegt.
- Anhänge können entweder als Base64-kodierte Dateien über den Parameter `base64` hochgeladen oder über eine URL mit dem Parameter `url` bereitgestellt werden.
- Alle Ticket-Attribute, die in der API-Spezifikation definiert sind, können ebenfalls angegeben werden. Dies ist nützlich, um Metadaten wie eine Vertrags-ID, Tags oder ein Erstellungsdatum zu übermitteln.
### Unterstützte Dateiformate
Enneo unterstützt die automatische Konvertierung von Anhängen in folgenden Formaten:
- PDF
- PNG
- JPG
- TIFF
## Versand von Briefen
Enneo übergibt wenn ein Brief versendet werden soll ein JSON-Objekt mit den relevanten Daten wie Empfänger, Betreff und Textinhalt an ihren Usercode. Von dort können sie per API einen Druckdienstleister ihrer Wahl aufrufen.
Dies konfiguriert man unter Einstellungen -\> Briefe -\> (Postfach auswählen) -\> Webhooks -\> Brief versenden
Hier ist Beispielcode für den Briefversand:
## Validierung von Postanschriften
Enneo validiert Postanschriften, damit keine Briefe an ungültige Anschriften versandt werden und als Postrückläufer zurück geschickt werden. Diese sind hier beschrieben: [Adressvalidierung](/docs/de/system-integration/integration-of-contact-channels/mail-address-validation)
## Nutzung von in ERP hinterlegten Adressen
Enneo kann anstelle auf den per KI erkannten Absender auch an eine von Ihnen hinterlegte Postanschrift antworten. Dazu muss im [Antwortformat der Vertragsdaten](/docs/de/system-integration/customer-recognition/search-by-contract-number) die Variable `letterAddress` gesetzt sein, also z.B. `"letterAddress": "Laura Ludwig, Hauptstraße 29, 20249 Hamburg"`
---
## Telefon
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/integration-of-contact-channels/telephone
**Description:** Telefon
---
## Voice
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/integration-of-contact-channels/voice
**Description:** Optionen und Konfiguration
## Call-Flow
Jede geschaltete Leitung verfügt über einen **Call-Flow**, der individuell konfiguriert werden kann. Im Call-Flow lassen sich frei kombinieren, z.B.:
- **Voicebots** für automatisierte Sprachdialoge
- **Mitarbeitertelefonie** für die Weiterleitung an Agenten
- **Externe Weiterleitungen** an externe Telefonnummern
- **Weichen**, z.B. nach Datum wie Arbeitszeiten
- **Ansagen**, z.B. Bandansagen oder andere Texte
## Telefonnummern
Für die Telefonie stehen zwei Optionen zur Verfügung:
| Option | Beschreibung |
|---|---|
| **Enneo SIP-Trunk** | Von Enneo bereitgestellte Nummern, sofort einsatzbereit |
| **Eigener SIP-Trunk** | Nutzung eigener Telefonnummern, z. B. über Sipgate |
### Eigene Telefonnummern einrichten
Bei Verwendung eigener Telefonnummern sind folgende Schritte in dieser Reihenfolge erforderlich:
1. **SIP-Trunk anlegen** – Den eigenen SIP-Trunk in den Telefonieeinstellungen hinterlegen
2. **Telefonnummern hinzufügen** – Die gewünschten Nummern dem SIP-Trunk zuordnen
3. **Nummern den Leitungen zuordnen** – Die Telefonnummern den entsprechenden Leitungen zuweisen
## Voraussetzungen für die Agenten-Telefonie
Damit Mitarbeiter über Enneo telefonieren können, müssen folgende Bedingungen erfüllt sein:
## Firewall-Einstellungen
Für Benutzer, die über Enneo telefonieren, müssen folgende Netzwerkverbindungen freigegeben werden:
| Host | IP-Adresse | Port | Protokoll | Zweck |
|---|---|---|---|---|
| `turn1.enneo.ai` | `91.99.219.69` | 3478 | UDP | TURN |
| `turn1.enneo.ai` | `91.99.219.69` | 5349 | TCP | TURNS |
| `turn1.enneo.ai` | `91.99.219.69` | 32769–65535 | UDP | Media |
---
## Zugriffskontrolle
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/security/access-control
**Description:** IP-Whitelist und Anmeldemethoden (OAuth/SSO) — Konfiguration und Wirkungsweise
Enneo bietet zwei unabhängige Mechanismen zur Kontrolle des Systemzugangs: eine
netzwerkbasierte IP-Whitelist und eine identitätsbasierte Konfiguration der
erlaubten Anmeldemethoden. Beide Mechanismen greifen auf unterschiedlichen
Ebenen und lassen sich kombinieren.
## IP-Whitelist
Die IP-Whitelist beschränkt den Zugriff auf Enneo auf Basis der Netzwerkadresse
des anfragenden Clients. Ist die Einstellung aktiv, werden alle Anfragen von
Benutzern abgewiesen, deren IP-Adresse nicht in der Liste enthalten ist.
Die Konfiguration findest du unter
`Erweiterte Einstellungen → Datenschutz → Zugriffssteuerung - IP Whitelist`.
Die Einstellung nimmt eine Liste von IP-Adressen oder CIDR-Bereichen entgegen.
Sowohl IPv4 als auch IPv6 werden unterstützt.
```json
["192.168.1.0/24", "10.0.0.5", "2001:db8::/32"]
```
Ist die Liste leer, ist der Zugriff ohne IP-Beschränkung möglich. Sobald
mindestens ein Eintrag gesetzt ist, wird jede Anfrage geprüft — bei einem
Treffer wird der Zugriff gewährt, andernfalls verweigert.
## Anmeldemethoden (OAuth / SSO)
Enneo unterstützt mehrere Anmeldemethoden, die pro Mandant konfiguriert werden.
Die SSO-Konfiguration findest du unter `Erweiterte Einstellungen → Single-Sign-On`.
### Erlaubte Anmeldemethoden
Die Einstellung legt fest, welche Login-Typen aktiv sind:
| Wert | Beschreibung |
|---------------|----------------------------------------------|
| `microsoft` | Microsoft Azure AD / Entra ID (OAuth2/OIDC) |
| `google` | Google OAuth2 |
| `oauth` | Generischer OAuth2-Anbieter (konfigurierbar) |
| `local` | Lokale Anmeldung mit E-Mail und Passwort |
### Erlaubte E-Mail-Domains
Ist diese Einstellung gesetzt, werden neue Benutzer nur dann angelegt, wenn
ihre E-Mail-Adresse zu einer der konfigurierten Domains gehört.
```json
["example.com", "partner.org"]
```
---
## Dateianhänge
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/security/attachment-security
**Description:** Klassifizierung und Behandlung von Dateianhängen nach Sicherheitsstufe
Enneo bewertet jeden Dateianhang automatisch anhand seines MIME-Typs und — soweit technisch verfügbar — seines tatsächlichen Dateityps. Das Ergebnis ist eine Risikoklasse, die steuert, wie das System mit dem Anhang umgeht: bei der Ablage, bei der Anzeige und beim Versand.
### Risikoklassen
Jeder Anhang wird einer von drei Klassen zugeordnet:
- **safe** — Dateitypen, die als unbedenklich gelten (z. B. PDF, DOCX, XLSX, JPEG, PNG, MP3, MP4). Diese werden normal gespeichert und angezeigt.
- **risky** — Dateitypen mit erhöhtem Risikopotenzial (z. B. ZIP, RAR, 7z, TAR, EML, `application/octet-stream`). Die Dateien werden gespeichert, aber dem Nutzer vor dem Öffnen mit einer Warnmeldung angezeigt.
- **dangerous** — Ausführbare oder potenziell schadhafte Dateitypen (z. B. EXE, MSI, Binary). Diese werden nicht gespeichert; der Anhang wird durch eine Textdatei mit einem Hinweis ersetzt.
Kann der MIME-Typ keiner der Listen zugeordnet werden, stuft das System den Anhang automatisch als **risky** ein.
Zusätzlich zur MIME-Typ-Prüfung wird geprüft, ob die Datei auf dem Dateisystem als ausführbar markiert ist. Trifft das zu, wird sie unabhängig vom MIME-Typ als **dangerous** behandelt.
### Verhalten im System
**Beim E-Mail-Import:**
Gefährliche Anhänge (`dangerous`) werden nicht im System gespeichert. An ihrer Stelle legt enneo eine Textdatei ab, die den Nutzer über die Entfernung informiert. Der ursprüngliche Inhalt geht verloren.
**Bei ausgehenden Nachrichten und Notizen:**
Beim Hinzufügen von Anhängen zu einer Antwort oder internen Notiz prüft das System die Risikoklasse vor dem Speichern. Für nicht authentifizierte Kontexte (z. B. über die externe API ohne Profil) sind sowohl `risky` als auch `dangerous` blockiert. Für authentifizierte Nutzer ist nur `dangerous` blockiert.
**In der Benutzeroberfläche:**
Anhänge der Klasse `risky` lassen sich öffnen, zeigen aber vor dem Öffnen einen Bestätigungsdialog. Anhänge der Klasse `dangerous` sind deaktiviert und können nicht geöffnet werden.
### Konfiguration
Die drei Listen — Safe, Risky, Dangerous — sind in den Settings unter **Erweiterte Einstellungen → Allgemeines → Attachment Security List** konfigurierbar. Jede Liste enthält MIME-Type-Strings. Änderungen wirken sich unmittelbar auf das Verhalten bei neu eingehenden E-Mails und beim Anhang-Upload aus; bestehende Anhänge werden nicht rückwirkend neu klassifiziert.
### Einordnung
Die Attachment Security ersetzt keine Antivirus-Infrastruktur. Sie bietet eine strukturierte erste Filterebene auf Basis bekannter MIME-Typen und schützt vor dem versehentlichen Speichern oder Öffnen offensichtlich gefährlicher Dateiformate. Für höhere Sicherheitsanforderungen sollte eine nachgelagerte Prüfung auf Netzwerkebene oder durch einen Virenscanner erfolgen.
---
## Eigener Code in Enneo
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/user-defined-functions-tools/code-execution-overview
**Description:** Grundprinzipien: wo eigener Code in Enneo ausgeführt wird und welche Ausführungsarten zur Verfügung stehen
Enneo lässt sich an vielen Stellen mit kundeneigenem Code erweitern. Damit können Umsysteme angebunden, Geschäftslogik abgebildet und Automatisierungen umgesetzt werden, ohne die Plattform selbst zu verändern.
### Wo eigener Code in Enneo eingesetzt wird
Eigener Code wird in Enneo immer als sogenannter **Executor** hinterlegt und an verschiedenen Stellen referenziert. Typische Einsatzgebiete:
- **[Kundenerkennung](/docs/de/system-integration/customer-recognition/flow)** — Suche nach [Vertragsnummer](/docs/de/system-integration/customer-recognition/search-by-contract-number), [Kundennummer](/docs/de/system-integration/customer-recognition/search-by-customer-number), [Attributen](/docs/de/system-integration/customer-recognition/search-by-attributes) oder [Freitext](/docs/de/system-integration/customer-recognition/search-by-free-text) greift auf eigene Funktionen zurück, die Daten aus dem ERP oder anderen Quellsystemen laden.
- **[Regelbasierte KI-Agenten](/docs/de/ai-functions-agents/rule-based-agents)** — Die Business-Logik eines Agenten (z. B. Zählerstand erfassen, Adressänderung schreiben, Vertrag kündigen) ruft eigenen Code auf, um die eigentliche Aktion im Umsystem auszuführen.
- **KI-Tools für [smarte KI-Agenten](/docs/de/ai-functions-agents/smart-agents)** — Smarte (LLM-basierte) Agenten entscheiden während eines Gesprächs eigenständig, welches Tool sie aufrufen. Jedes benutzerdefinierte Tool (verwaltet unter **KI-Anpassung → KI-Tools**) ist ein Executor, der eine konkrete Aktion im Umsystem ausführt — z. B. `get_tariff_offer`, `send_offer_by_email` oder `do_tariff_change`.
- **[Webhooks](/docs/de/system-integration/events/concept-of-webhooks-in-enneo)** — Synchrone Aufrufe an Umsysteme, z. B. der Versand einer E-Mail per API. Fehler werden direkt an den Nutzer zurückgemeldet, der Ablauf wartet auf die Antwort.
- **[Event-Hooks](/docs/de/system-integration/events/concept-of-events-in-enneo)** — Asynchrone Reaktionen auf Enneo-interne Events (Ticket erstellt, beantwortet, geschlossen, …), etwa um Daten zu exportieren oder andere Systeme zu informieren. Fehler werden im Event-Trace protokolliert, aber nicht direkt an den Nutzer surfaced.
- **[User Defined Functions (UDFs)](/docs/de/system-integration/user-defined-functions-tools/user-defined-functions-in-enneo)** — Wiederverwendbare Code-Bausteine, die zentral verwaltet und von beliebigen anderen Stellen aufgerufen werden können.
### Die zwei Ausführungsarten
Enneo unterstützt zwei Wege, eigenen Code auszuführen. Der Unterschied liegt nicht in der Komplexität des Codes, sondern darin, **wer den Code hostet und betreibt** — Enneo oder das Umsystem auf eigener Infrastruktur. In beiden Fällen werden **Eingabe- und Ausgabedaten als JSON** übergeben.
#### Hosting durch Enneo: Sandbox-Ausführung (Typ `code`)
Der Code wird direkt in Enneo hinterlegt und in der Enneo-Sandbox ausgeführt. Unterstützte Sprachen sind PHP, Python und Node.js. Innerhalb der Sandbox stehen das volle Enneo-SDK, beliebige Pakete (per Composer, pip, npm) und Zugriff auf Eingabeparameter, Speicherobjekte und alle Enneo-APIs zur Verfügung. Eingabe und Ausgabe sind JSON.
Vorteile:
- Keine eigene Server-Infrastruktur, kein Deployment, keine Erreichbarkeit von außen nötig.
- Änderungen sind sofort wirksam, ohne Release-Prozess.
- Direkter Zugriff auf das Enneo-SDK und auf Enneo-APIs.
Einschränkungen:
- Keine Versionskontrolle (Git) und nur eingeschränktes Debugging.
- Tests laufen nicht im üblichen CI-Setup der eigenen Codebasis.
Daher in der Praxis am besten für **einfache, überschaubare Logik** geeignet.
#### Hosting durch das Umsystem: Direkter API-Aufruf (Typ `apiCall`)
Der Code wird auf eigener Infrastruktur als HTTP-Endpunkt betrieben. Enneo schickt einen Request an die konfigurierte URL und arbeitet mit der Antwort weiter. Angegeben werden:
- HTTP-Methode (`GET`, `POST`, `PUT`, `PATCH`, `DELETE`)
- URL
- HTTP-Header (Authentifizierungs-Header können auf [Secrets](/docs/de/system-integration/user-defined-functions-tools/secrets) verweisen)
Auch hier sind **Eingabe und Ausgabe JSON**: Bei `GET` und `DELETE` werden die Eingabeparameter automatisch als Query-String an die URL angehängt, bei `POST`, `PUT` und `PATCH` als JSON-Body übergeben. Die Antwort wird als JSON geparst und zurückgegeben.
Vorteile:
- Voller Kontrollumfang über Quellcode, Versionierung, Tests, Deployment und Monitoring.
- Integration in bestehende interne Systeme und Tooling.
Einschränkungen:
- Erfordert eine eigene, von Enneo aus erreichbare Server-Komponente.
- Jede Änderung läuft durch den eigenen Release-Prozess.
---
## Icons
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/user-defined-functions-tools/icons
**Description:** Übersicht der verfügbaren Icons
# Icon-Bibliothek
Icons werden an vielen Stellen in Enneo verwendet. Einige Beispiele sind:
- Eigene Stati
- Eigene Aktions-Buttons
- Links zu ERP-Systemen von Verträgen
## Verfügbare Icons
export const IconGrid = () => {
const baseUrl = 'https://main.enneo.dev/icons/';
const icons = [
'account',
'activity',
'agentAssign',
'ai',
'aiAgent_1',
'aiBroken',
'aiColorful',
'announcements',
'archive',
'arrow',
'arrowLeft',
'arrowLetter',
'arrowRight',
'article',
'attachment',
'barChart',
'baseContract',
'bcc',
'bell',
'bolt',
'book',
'britishFlag',
'brokenAccount',
'busts',
'calendar',
'callActive',
'category',
'cc',
'chat',
'chatAgentAvatar',
'chatColorful',
'check',
'checkboxChecked',
'checkboxIndeterminate',
'checkboxUnchecked',
'checkmark',
'chevronDown',
'chevronLeft',
'chevronRight',
'chevronUp',
'clock',
'coffee',
'collapseContent',
'collapseLow',
'connectinglines',
'copy',
'crayon',
'cross',
'danger',
'diagram',
'document',
'download',
'drag',
'dynamicArrow',
'earthquake',
'edit',
'emb',
'emojiAngry',
'emojiConcerned',
'emojiDisappointed',
'emojiHappy',
'emojiNeutral',
'emojiSad',
'emojiThankful',
'enneo-logo',
'enneo',
'enneo_icon_dark',
'enneo_icon_white',
'enter',
'euro',
'ewe',
'exclamation',
'expandContent',
'expandLow',
'externalLink',
'eye',
'facebook',
'holiday',
'figures',
'filter',
'filterActive',
'filterClear',
'filterGreen',
'filterRed',
'flag',
'folder',
'folderOpen',
'forward',
'frenchFlag',
'freshdesk',
'gas',
'gasag',
'gear',
'gearColorful',
'germanFlag',
'globe',
'good',
'google',
'googlessoicon',
'gridView',
'heatPump',
'helpCenter',
'home',
'imCall',
'inbox',
'info',
'internalLink',
'internet',
'layoutCard',
'layoutTable',
'left2',
'letter',
'letterColorful',
'letterGearColorful',
'letterbox',
'lightning',
'link',
'linkedAccount',
'listView',
'locked',
'loginlogo',
'lynq',
'magic',
'magic2',
'magicBroken',
'magicColorful',
'magnify',
'microsoft',
'mobile',
'neo',
'newFolder',
'news',
'noAccount',
'noCall',
'notVerified',
'note',
'office',
'okay',
'otherDoc',
'overview',
'paragraph',
'partners',
'pdf',
'pen',
'pending',
'peopleColorful',
'person',
'phone',
'play',
'plus',
'plusCircle',
'powercloud',
'priority',
'profile',
'question',
'redirect',
'refresh',
'refreshNew',
'reload2',
'reply',
'replyConfig',
'rerun',
'restore',
'right2',
'robot',
'sap',
'save',
'searchList',
'send',
'serverGearColorful',
'smile',
'star',
'statusClosed',
'statusOpen',
'statusProgress',
'statusWaiting',
'stroke',
'sun',
'tFriendly',
'tMagic',
'tNew',
'tProfessional',
'tSimplify',
'target',
'team',
'technologist',
'template',
'text',
'textFormating',
'textRecog',
'threeDots',
'thumbUp',
'tick',
'tickCircle',
'tickets',
'ticketsNew',
'time',
'timeOff',
'translate',
'translateDe',
'translateEn',
'translateFr',
'trash',
'truck',
'tune',
'typingIndicator',
'undo',
'unlink',
'update',
'upload',
'users',
'verification',
'warning',
'waterDrop',
'wikiBook',
'workflowColorful'
];
return (
{icons.map(icon => (
{icon}.svg
))}
);
};
---
## Secrets
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/user-defined-functions-tools/secrets
**Description:** Sichere Ablage von API-Tokens und anderen Geheimnissen für eigenen Code
Enneo bietet einen zentralen Speicher für Secrets — beispielsweise API-Tokens, Client-Secrets oder Basic-Auth-Credentials —, die in den Headern von API-Call-Executoren über Platzhalter referenziert werden können. Werte werden in der Oberfläche maskiert und nie in API-Antworten ausgegeben.
Secrets werden insbesondere für die [direkte API-Aufruf-Ausführung](/docs/de/system-integration/user-defined-functions-tools/code-execution-overview) (Typ `apiCall`) verwendet, damit Authentifizierungs-Header gesetzt werden können, ohne den eigentlichen Token-Wert in der Executor-Definition zu speichern.
### Secrets verwalten
Secrets werden in den Einstellungen unter **Integration der Umsysteme → Secrets** verwaltet. Jeder Eintrag besteht aus:
- **Key** — der Name des Secrets, z. B. `MY_API_TOKEN`. Dieser Name wird im Platzhalter referenziert.
- **Value** — der eigentliche Wert. In der Oberfläche maskiert dargestellt und nicht in API-Antworten enthalten.
Es können beliebig viele Secrets hinterlegt werden.
### Secrets in API-Call-Executoren verwenden
In den Header-Werten eines API-Call-Executors können Secrets über den Platzhalter `{{secret.KEY}}` referenziert werden. Beim Ausführen des Executors ersetzt Enneo den Platzhalter durch den hinterlegten Wert.
Beispiel-Header eines API-Call-Executors:
```json
{
"Authorization": "Bearer {{secret.MY_API_TOKEN}}",
"X-Api-Key": "{{secret.PARTNER_API_KEY}}",
"Accept": "application/json"
}
```
Wenn ein Secret mit dem angegebenen Key nicht existiert, bleibt der Platzhalter im Header-Wert stehen — der Aufruf wird also typischerweise mit einem Authentifizierungsfehler abbrechen, anstatt mit einem leeren Token weitergeleitet zu werden.
### Secrets im SDK (Sandbox-Executoren Typ `code`)
In Sandbox-Executoren stellt das SDK die Methode `ApiEnneo.getSecret(key)` bereit. Sie liefert den hinterlegten Wert des Secrets oder `null`/`None`, falls der Key nicht konfiguriert ist. So lassen sich Secrets verwenden, ohne sie im Code zu hinterlegen.
### Berechtigungen
Lesen und Schreiben der `executorSecrets`-Einstellung erfordern die Berechtigung `updateAiAgent`. Werte werden in der Oberfläche maskiert und nicht in Lese-Endpunkten ausgegeben.
---
## User Defined Functions
**URL:** https://richard-dev-playground.enneo.ai/docs/de/system-integration/user-defined-functions-tools/user-defined-functions-in-enneo
**Description:** Wiederverwendbare Bausteine für Integrationen
Enneo ermöglicht es, eigenen Code in Form von "User Defined Functions" zu hinterlegen und in verschiedenen Bereichen
anzuwenden. Diese Funktionen können insbesondere in der Business-Logik von regelbasierten KI-Agenten, in Webhooks
oder Event-Implementierungen genutzt werden. Also überall dort, wo eigener Code oder SDKs verwendet werden.
### Verwaltung von User Defined Functions
Die Verwaltung der user defined Funktionen erfolgt im Bereich **Integration der Umsysteme** in den Einstellungen.
Hier können beliebig viele benutzerdefinierte Funktionen hinterlegt werden.
### Einsatzmöglichkeiten
User Defined Functions bieten vielfältige Einsatzmöglichkeiten. Zum Beispiel:
- **Schnittstellenaufrufe der Umsysteme**: Zum Beispiel für ERP, Task-Management, oder Archiv-Systeme.
- **Anbindung von Output-Management-Systemen**: Beispielsweise für den Versand von Benachrichtigungen.
- **Auslagerung komplexer Abläufe**: In Form von wiederverwendbaren Bausteinen.
Mit diesen Funktionalitäten erweitert Enneo die Anpassungsfähigkeit und ermöglicht die Integration spezifischer
Unternehmenslogik in die AI-basierte Kundenbetreuung.
### Aufruf von Benutzerdefinierten Funktionen
Enneo kann benutzerdefinierte Funktionen speichern und verwenden. Folgende Aufrufe sind möglich,
am Beispiel einer User-Defined-Function namens 'my-udf':
Innerhalb von Enneo mittels Python SDK:
```python
sdk.ApiEnneo.executeUdf('my-udf', {"parameter1": "value1", "parameter2": "value2"}, 'serviceWorker')
```
Innerhalb von Enneo mittels PHP SDK:
```php
\EnneoSDK\ApiEnneo::executeUdf('my-udf', ['parameter1' => 'value1', 'parameter2' => 'value2'],'serviceWorker');
```
Per externem Web-Request:
```plaintext
POST https://your-subdomain.enneo.ai/api/mind/executor/execute/my-udf
Payload: '{"parameter1": "value1", "parameter2": "value2"}'
```
### Speicherobjekt für Benutzerdefinierte Funktionen
Es kann ein beliebiges JSON-Objekt als Enneo-internes Speicherobjekt für benutzerdefinierte Funktionen verwendet werden.
Dies ermöglicht das Speichern und Abrufen von Daten mittels des Enneo-SDK.
```php
\EnneoSDK\Setting::set('udfStorage', ['my' => 'data']);
$storedData = \EnneoSDK\Setting::get('udfStorage');
```
### Beispiel: Aufruf der API eines Drittsystems
Zuerst werden notwendige Daten im Speicherobjekt für benutzerdefinierte Funktionen festgelegt:
```json
{
"thirdParty": {
"oauth": {
"clientId": "123456789",
"grantType": "client_credentials",
"clientSecret": "abcdefg.....hijklmnop",
"tokenEndpoint": "https://token-url/oauth2/token",
"baseUrl": "https://third-party-url/api"
}
}
}
```
Im zweiten Schritt, kann eine benutzerdefinierte Funktion **fetch-thirdparty-token** für das Laden der Credentials
implementiert werden. Diese Vorgehensweise ist besonders dann sinnvoll, wenn das Laden der Credentials in mehreren
anderen Prozessen wiederverwendet werden kann.
```php
thirdParty->oauth->clientId;
$clientSecret = $udfStorage->thirdParty->oauth->clientSecret;
$result = \EnneoSDK\Api::call(
method: 'POST',
url: $udfStorage->thirdParty->oauth->tokenEndpoint,
headers: [
'Authorization: Basic ' . base64_encode($clientId . ':' . $clientSecret),
'Content-Type: application/x-www-form-urlencoded',
'Accept: application/json'
],
params: http_build_query(['grant_type' => $udfStorage->thirdParty->oauth->grantType ?? 'client_credentials',
'scope' => $udfStorage->thirdParty->oauth->scope ?? null])
);
// Die Ausgabe erfolgt im JSON Format und kann nach dem Aufruf im entsprechenden Code verwendet werden
echo json_encode(['accessToken' => $result->access_token,
'accessTokenExpiresAt' => date("Y-m-d H:i:s T", time() + $result->expires_in),
"baseUrl" => $udfStorage->thirdParty->baseUrl,
"headers" => $udfStorage->thirdParty->headers ?? [],
"apiName" => $udfStorage->thirdParty->apiName ?? "Kunden-API",
]);
```
Anschließend kann die Implementierung der Funktion **third-party-api-call** für den eigentlichen API-Aufruf erfolgen:
```php
accessToken,
'Accept: application/json'
];
foreach (($cred->headers ?? []) as $key => $val) {
$headers[] = "$key: $val";
}
// API Aufruf und Ausgabe
$res = \EnneoSDK\Api::call(
method: $in->method,
url: $credentials->baseUrl.'/'.$in->api,
headers: $headers,
params: $in->params
);
// Output result
echo json_encode($res);
```
Diese Struktur ermöglicht die flexible Nutzung und Integration von benutzerdefiniertem Code innerhalb von Enneo,
um spezifische Geschäftslogik abzubilden oder externe Systeme nahtlos anzubinden.
../../../../snippets/de/user-defined-functions/user-defined-function-call.mdx
---
## First Overview
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/ai-control-centre/aicc-summary
**Description:** Introduction, Usage and Best Practices
### Requirements for Viewing and Using
- **General access**: Authorization in the area `Data and Reports → AI Control Center`
- **Automation settings**: Access for configuration, ticket detection, and triggering is controlled via permissions in the `Dark processing` area
- **Quality check**: Authorization in the `AI Quality Check` area, controls access to views, execution of test runs, and their processing
- **Live overview**: Authorization in the area `Tickets → Ticket Overview Page`
- **AI Agent Team**: Authorization in the `AI Agent Management` area controls access to views, creation, and editing possibilities
### Tools in Overview
The AI Control Center brings together the most important tools for automation in one place:
- **Live Overview & Metrics**: Overview of live key figures, degree of automation, and AI agent performance → [learn more](/docs/en/ai-functions-agents/ai-control-centre/dashboard_metrics)
- **Quality check**: Management of test cases and evaluation of test runs → [learn more](/docs/en/ai-functions-agents/ai-control-centre/quality-check/test-cases-and-runs)
- **Automation settings**: Control of automation levels with and without release → [learn more](/docs/en/ai-functions-agents/ai-control-centre/dark-processing/types-of-release)
### Stages of Automation
The goal is the **fully autonomous processing** of business transactions by AI agents.
The journey there involves several stages:
1. **Manual processing**
The AI agent fully recognizes the request, correctly reads out the relevant data, derives suitable processing options and makes them available. A human decides on the further action(s).
2. **Dark processing with release**
The AI agent takes over all steps of processing: It recognizes the concern, reads out the data, derives the correct action, and selects the appropriate processing option.
The examiner only needs to approve the selection made by the AI agent with one click, or reset the process to manual processing if deviations are noticeable.
3. **Dark processing without release**
The AI agent takes over processing completely autonomously: It recognizes the concern, reads the data, derives the appropriate action, selects the correct processing option, and executes it independently.
### Example: Bank Data Agent
A **rule-based AI agent** was created for the purpose of processing customer concerns about bank account changes.
It's supposed to check whether the IBAN provided by the customer is already stored in the system, whether it's invalid or whether it can be adopted as a new, valid bank connection.
Initially, a processor manually decides on the performance of the AI agent:
- Is the **customer's request correctly recognized** (change of bank details)?
- Are all **relevant parameters correctly read out** (IBAN, validity date, account holder)?
- Are the **typical use cases** correctly covered? (IBAN valid, IBAN invalid, IBAN already present, validity date in the past)
- Are the **correct processing options** offered? (Adopt IBAN, inform customer about errors in the IBAN, adjust validity date)
If the processor finds that individual points on the checklist are not reliably met, this is an indication that the bank data agent needs to be adjusted.
This includes, for example, adjustments to the **detection of input parameters**, the optimization of the **business logic**, or additions to the **output handling**. Only when this feedback is implemented and the results are stable can the next automation step take place.
If the bank data agent consistently shows correct results, it can be switched to [**Dark processing with release**](/docs/en/ai-functions-agents/ai-control-centre/dark-processing/types-of-release).
If reliable results are confirmed here too, the switch to [**Dark processing without release**](/docs/en/ai-functions-agents/ai-control-centre/dark-processing/types-of-release), or fully autonomous processing, follows.
### Preconditions and Risks
Before an AI agent is transferred to higher levels of automation, certain conditions must be met:
- **Reliable customer recognition**
- **Accurate request recognition**
- **Low error rates** when recognizing and reading out parameters
- **Successful test runs** in the quality check
Risks arise primarily when incorrect decisions go unnoticed in dark processing. The dashboard and the quality check help minimize these risks and detect errors in a timely manner.
### Role of the Users in the Control Center
Users of the AI Control Center have different tasks:
- **Create test cases** and maintain them to check the reliability of the AI agents
- **Monitor results** and document and/or communicate any irregularities
- **Make assessments** on whether an AI agent can be transferred to the next stage of automation
---
## Dashboard and Metrics
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/ai-control-centre/dashboard_metrics
**Description:** Explanation and further steps
### Basic AI Metrics
These key figures provide information on **how reliably the AI operates in daily use**.
- **Customer correctly identified**
The proportion of work sessions in which the customer could be assigned unequivocally and without manual intervention.
- **Correctly categorized with tags**
The proportion of work sessions in which the AI **set the correct tags**. No manual intervention was required.
- **Text Assistant Accuracy**
Average **accuracy of the text assistant**, calculated across all work sessions in the selected period.
### AI Performance Metrics
This is where the **operational effectiveness** of the automation becomes apparent:
- **Automatic Processing**
Indicates the number of tickets that were processed automatically, distinguished by **With Approval (L4)** and **fully autonomous (L5)**.
- **Degree of Automation**
Evaluates how strongly tickets were overall supported by the AI:
- **L0**: No AI, except identification/categorization
- **L1**: AI used for text editing
- **L2**: Adopted the text suggestion of the basic agent
- **L3**: Suggestion of a specialist agent confirmed
- **L4**: Dark processing with approval
- **L5**: Complete dark processing
### Agent Overview
The table view lists **the AI agents with active automation**, i.e., those that process tickets **with approval (L4)** or **fully autonomously (L5)**.
For each of these AI agents, the following are displayed:
- **Processed**: Number of tickets processed during the period
- **Awaiting approval**: Cases currently awaiting manual approval
- **Automatically processed cases (L4+L5)**: Total of all successfully **automatically** closed tickets
- **Dark processing rate (L5)**: Proportion of cases that were closed **without human intervention**
- **Human approval rate (L4)**: Proportion of cases where an employee **approved** the AI proposal
- **Error rate**: Proportion of cases that had to be **corrected** or **withdrawn**
---
## API-based Agents
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/default-agents/api-agent
**Description:** Outsource and extend business logic flexibly
API-based agents form the bridge between the Enneo platform and your custom IT landscape. They allow for the entire business logic to be outsourced to external services while retaining full control over data flows and processing steps. Standardized communication via HTTP enables any systems to be connected – from internal microservices to external SaaS solutions.
Unlike rule-based agents, whose logic is directly implemented in Enneo, API-based agents focus on a clear separation between the Enneo platform and the actual business logic. This not only allows for higher scalability and better maintainability, but also enables the reuse of existing services and infrastructures.
../../../../snippets/default-agents/default_api.mdx
---
## Bank Data Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/default-agents/bankdata-agent
**Description:** Automated processing of bank account changes
### Key Functions
The Bank Data Agent takes over the complete process of updating bank data, providing the following core functionalities:
* **IBAN Validation:** Automatic review of the formatting and checksum conformity of new bank accounts
* **Identity Verification:** Comparison of the account holder with contract information to ensure legitimacy
* **System Integration:** Seamless update of bank data in all relevant systems
* **Customer Communication:** Automated confirmations of successful changes or queries in case of ambiguities
### Process Flow
The agent operates according to a clearly defined process, ensuring maximum security while maintaining high user-friendliness:
1. **Extraction of relevant data** from the customer request (new IBAN, account holder, desired date)
2. **Validation of the new bank account** based on international standards
3. **Verification of authorization** to change the bank data
4. **Execution of the change** in all linked systems
5. **Confirmation to the customer** with the relevant information about the new bank account details
Through rule-based logic, all inputs are systematically checked and processed, which minimizes errors and significantly reduces manual processing effort.
../../../../snippets/default-agents/default_bankdata.mdx
---
## Advance-Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/default-agents/deposit-agent
**Description:** Efficient management and adjustment of advance payments
### Core functionalities
The Advance-Agent handles the entire process of adjusting advance payments and offers the following key services:
* **Needs analysis:** Evaluation of the desired change in the context of actual consumption
* **Plausibility check:** Automatic validation of whether the requested change is within sensible limits
* **Implementation:** Direct adjustment of the advance payment amount in all relevant systems
* **Communication:** Automated confirmation of the change with indication of the effective date
### Process flow
The agent follows a structured procedure that ensures both customer satisfaction and financial stability:
1. **Recognition of the issue** and extraction of relevant information (desired advance payment amount, time)
2. **Comparison with consumption data** to verify the appropriateness of the requested change
3. **Evaluation of the change request** based on predefined rules and limits
4. **Execution of the adjustment** in case of positive evaluation or suggestion of alternative amounts
5. **Transparent communication** with the customer about the result and next steps
By combining data analysis and clear decision rules, the Advance-Agent facilitates rapid, consistent, and customer-centric processing of change requests while simultaneously relieving the customer service team.
../../../../snippets/default-agents/default_deposit.mdx
---
## Meter Reading Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/default-agents/reading-agent
**Description:** Automated collection and processing of meter readings using OCR technology
### Core Functions
The Meter Reading Agent handles the entire process of meter reading collection, providing the following essential functions:
* **Intelligent Data Recognition:** Automatic identification of meter readings and associated meter numbers in customer requests.
* **OCR Image Analysis:** Recognition and extraction of meter reading data from email attachments such as photos or scanned documents.
* **Plausibility Check:** Validation of reported readings compared to historical values and typical consumption patterns.
* **System Integration:** Seamless transfer of validated meter readings into billing systems.
* **Customer Communication:** Automated confirmation of captured data or follow-up questions if there are any uncertainties.
### Process Flow
The agent operates according to a structured procedure that combines accuracy and efficiency:
1. **Extraction of meter information** from the customer request or by OCR analysis of attachments.
2. **Comparison with master data** for assignment to the correct contract and meter.
3. **Carrying out of plausibility checks** to ensure realistic consumption values.
4. **Transmission of validated data** to the billing systems.
5. **Feedback to the customer** confirming successful processing.
The combination of intelligent text analysis and modern OCR technology makes the Meter Reading Agent particularly powerful. It not only processes meter readings from structured inputs but also recognizes these in images of meters that customers submit as email attachments - without the need for manual entry.
../../../../snippets/default-agents/default_reading.mdx
---
## Delete an existing AI Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agent/delete-delete-ai-agent
**Description:** DELETE /aiAgent/{id}
## `DELETE /aiAgent/{id}`
### Path parameters
### Responses
**`200`** — Intent description deleted
**`403`** — Unauthorized
**`404`** — Intent description not found
**`500`** — Internal error
---
## Get an AI Agent by id
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agent/get-get-ai-agent
**Description:** GET /aiAgent/{id}
## `GET /aiAgent/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Intent description not found
**`500`** — Internal error
---
## List of all available AI agents as an tree based on associated tag
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agent/get-get-ai-agents-tree
**Description:** GET /aiAgents/tree
## `GET /aiAgents/tree`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## List of all available AI agents as an array
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agent/get-get-ai-agents
**Description:** GET /aiAgents
## `GET /aiAgents`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get list of available enneo default AI Agents
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agent/get-get-available-default-ai-agents
**Description:** GET /aiAgents/availableDefaults
## `GET /aiAgents/availableDefaults`
Retrieve all available enneo default AI agents that can be imported. Shows which agents are already imported and which are available for import.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get a sample AI agent by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agent/get-get-sample-ai-agent
**Description:** GET /aiAgents/samples/{id}
## `GET /aiAgents/samples/{id}`
Returns a single sample AI agent from the enneo admin portal by its ID. The response includes additional `includedInSeeds` and `category` metadata fields.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Sample AI agent not found
**`500`** — Internal error
---
## Get similar tickets for an AI Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agent/get-get-similar-tickets
**Description:** GET /aiAgent/{id}/similarTickets
## `GET /aiAgent/{id}/similarTickets`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Intent description not found
**`500`** — Internal error
---
## List all sample AI agents
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agent/get-list-sample-ai-agents
**Description:** GET /aiAgents/samples
## `GET /aiAgents/samples`
Returns all sample AI agents from the enneo admin portal, without any environment or category filtering. Each agent includes additional `includedInSeeds` and `category` metadata fields.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Update an existing AI Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agent/patch-update-ai-agent
**Description:** PATCH /aiAgent/{id}
## `PATCH /aiAgent/{id}`
### Path parameters
### Request body
The new updated AI agent
### Responses
**`200`** — Intent description updated
**`403`** — Unauthorized
**`404`** — Intent description not found
**`422`** — AI agent definition contains invalid parameter references
**`500`** — Internal error
---
## Create a new aiAgent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agent/post-create-ai-agent
**Description:** POST /aiAgent
## `POST /aiAgent`
This API creates a new AI Agent and returns the newly created id
### Request body
The new AI Agent that should be created. If not defined, then a blank "new ai agent" will be created
### Responses
**`200`** — New intent created
**`403`** — Unauthorized
**`422`** — AI agent definition contains invalid parameter references
**`500`** — Internal error
---
## Get the outcome of an AI Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agent/post-get-ai-agent-outcome
**Description:** POST /aiAgent/outcome
## `POST /aiAgent/outcome`
### Request body
The new updated AI agent
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Preview an AI Agent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agent/post-get-ai-agent-preview
**Description:** POST /aiAgent/{id}/preview
## `POST /aiAgent/{id}/preview`
### Path parameters
### Query parameters
### Request body
The new updated AI agent
### Responses
**`200`** — Successful operation
---
## Load enneo default AI Agents
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agent/post-load-default-ai-agents
**Description:** POST /aiAgents/loadDefaults
## `POST /aiAgents/loadDefaults`
Load all the enneo default AI agents, e.g. for meter reading, bank data, etc., and saves them in the client DB. If the client is configured to not use enneo's default AI agents, then nothing is written.
### Responses
**`200`** — Loaded successfully
**`403`** — Unauthorized
**`412`** — Client is configured to not use AI agents in his settings
**`500`** — Internal error
---
## Evaluate an AI agent prompt
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-agents/post-ai-agent-prompt-eval
**Description:** POST /aiAgent/{id}/prompt-eval
## `POST /aiAgent/{id}/prompt-eval`
Run the LLM prompt that belongs to the given AI agent against a sample input and return the
raw model output. Used by the prompt editor in ops-fe to iterate on prompt wording without
deploying the agent.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid input
**`403`** — Unauthorized
---
## Delete a persisted value
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/delete-delete-app-data
**Description:** DELETE /app/{appId}/data/{key}
## `DELETE /app/{appId}/data/{key}`
### Path parameters
### Responses
**`200`** — Deleted
---
## Delete an app
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/delete-delete-app
**Description:** DELETE /app/{appId}
## `DELETE /app/{appId}`
### Path parameters
### Responses
**`200`** — Deleted
**`403`** — Unauthorized.
---
## Get metadata for a persisted value
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/get-get-app-data-meta
**Description:** GET /app/{appId}/data/{key}/meta
## `GET /app/{appId}/data/{key}/meta`
Returns size, timestamps and ownership information for the given key.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Key not found.
---
## Get a persisted value
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/get-get-app-data
**Description:** GET /app/{appId}/data/{key}
## `GET /app/{appId}/data/{key}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Key not found.
---
## Get app store entry
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/get-get-app-store-entry
**Description:** GET /app/store/{storeId}
## `GET /app/store/{storeId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Store entry not found.
---
## Get an app by id or slug
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/get-get-app
**Description:** GET /app/{appId}
## `GET /app/{appId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — App not found.
---
## List persisted keys for an app
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/get-list-app-data
**Description:** GET /app/{appId}/data
## `GET /app/{appId}/data`
### Path parameters
### Responses
**`200`** — Successful operation
---
## List app revisions
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/get-list-app-revisions
**Description:** GET /app/{appId}/revisions
## `GET /app/{appId}/revisions`
### Path parameters
### Responses
**`200`** — Successful operation
---
## List app store entries
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/get-list-app-store-apps
**Description:** GET /app/store
## `GET /app/store`
Returns the curated list of installable apps available in the app store.
### Responses
**`200`** — Successful operation
**`500`** — Internal error.
---
## List apps
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/get-list-apps
**Description:** GET /app
## `GET /app`
Return all installed/created apps the caller can read.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized — missing `readApps` permission.
**`500`** — Internal error.
---
## Run an app
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/get-run-app
**Description:** GET /app/{appId}/run
## `GET /app/{appId}/run`
Executes the app in the code-executor sandbox and returns the rendered HTML. Same handler is mounted on POST.
### Path parameters
### Responses
**`200`** — Rendered HTML
**`404`** — App not found.
---
## Update an app
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/patch-update-app
**Description:** PATCH /app/{appId}
## `PATCH /app/{appId}`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized.
---
## Create app
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/post-create-app
**Description:** POST /app
## `POST /app`
Create a new app. Requires `appCreator` permission.
### Request body
### Responses
**`201`** — Created
**`400`** — Missing `name` or invalid payload.
**`403`** — Unauthorized — missing `appCreator` permission.
---
## Import app
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/post-import-app
**Description:** POST /app/import
## `POST /app/import`
Import an app from an exported bundle. Requires `appCreator` permission.
### Request body
### Responses
**`201`** — Imported
**`400`** — Invalid bundle.
**`403`** — Unauthorized.
---
## Install an app from the store
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/post-install-app-from-store
**Description:** POST /app/store/{storeId}/install
## `POST /app/store/{storeId}/install`
### Path parameters
### Responses
**`200`** — Installed
**`403`** — Unauthorized.
---
## Preview an app without persisting changes
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/post-preview-app
**Description:** POST /app/{appId}/preview
## `POST /app/{appId}/preview`
Render the supplied app code in the sandbox and return the resulting HTML. Used by the editor's preview pane.
### Path parameters
### Request body
### Responses
**`200`** — Rendered HTML
---
## Roll back an app to a previous revision
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/post-rollback-app
**Description:** POST /app/{appId}/rollback/{revision}
## `POST /app/{appId}/rollback/{revision}`
### Path parameters
### Responses
**`200`** — Rolled back
**`404`** — Revision not found.
---
## Run an app (with POST body)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/post-run-app-with-body
**Description:** POST /app/{appId}/run
## `POST /app/{appId}/run`
Same as `GET /app/{appId}/run`, but accepts a JSON body forwarded to the app as input.
### Path parameters
### Request body
### Responses
**`200`** — Rendered HTML
---
## Uninstall a previously store-installed app
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/post-uninstall-app-from-store
**Description:** POST /app/store/{storeId}/uninstall
## `POST /app/store/{storeId}/uninstall`
### Path parameters
### Responses
**`200`** — Uninstalled
**`403`** — Unauthorized.
---
## Save a persisted value
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/apps/put-save-app-data
**Description:** PUT /app/{appId}/data/{key}
## `PUT /app/{appId}/data/{key}`
### Path parameters
### Request body
### Responses
**`200`** — Saved
---
## Get contract by id
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/contract/get-get-contract-by-id
**Description:** GET /contract/{contractId}
## `GET /contract/{contractId}`
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Contract not found
**`500`** — Internal error
---
## Get ticket history for a contract
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/contract/get-get-contract-history
**Description:** GET /contract/{contractId}/history
## `GET /contract/{contractId}/history`
Returns the list of tickets ever opened against the given contract, oldest first.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Contract not found
---
## Search for contracts
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/contract/get-search-contracts
**Description:** GET /contract/search
## `GET /contract/search`
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Bad request
---
## Dry-run customer legitimation check
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/contract/post-contract-legitimation-preview
**Description:** POST /contract/legitimation/preview
## `POST /contract/legitimation/preview`
Evaluates the configured legitimation rules (`customerLegitimationRuleAsyncChannels` /
`customerLegitimationRuleSyncChannels`) against a synthetic ticket built from the supplied
fields. No data is written. Useful for testing legitimation settings without a real ticket.
### Request body
### Responses
**`200`** — Legitimation check result
**`400`** — Missing required field
**`403`** — Unauthorized
**`404`** — Contract not found
---
## Delete a test case by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/delete-delete-ai-quality-test-case
**Description:** DELETE /aiQualityCheck/testCase/{id}
## `DELETE /aiQualityCheck/testCase/{id}`
Delete a specific test case using its numeric test case ID. Here `{id}` is a test case id
(numeric only). The Dispatcher pins this method to the `\d+` regex constraint so AI-agent
`all` requests cannot reach this handler.
### Path parameters
### Responses
**`200`** — Successful operation
---
## Delete a specific test run by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/delete-delete-ai-quality-test-run
**Description:** DELETE /aiQualityCheck/testRun/{testRunId}
## `DELETE /aiQualityCheck/testRun/{testRunId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Test run not found
**`500`** — Internal error
---
## Get all AI agents for which test runs can be triggered
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/get-ai-quality-test-ai-agent
**Description:** GET /aiQualityCheck/testAiAgent
## `GET /aiQualityCheck/testAiAgent`
### Responses
**`200`** — Successful operation
---
## Get test cases for a specific AI agent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/get-get-ai-quality-test-cases-by-ai-agent-id
**Description:** GET /aiQualityCheck/testCase/{id}
## `GET /aiQualityCheck/testCase/{id}`
Get all test cases associated with the specified AI agent ID. Here `{id}` is treated as an
AI agent id (digits, or `all` to list across every agent). This is a different overload of
`{id}` than the `DELETE`/`PATCH` variants below, which take a numeric test case id.
### Path parameters
### Responses
**`200`** — Successful operation
---
## Get a specific test run by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/get-get-ai-quality-test-run
**Description:** GET /aiQualityCheck/testRun/{testRunId}
## `GET /aiQualityCheck/testRun/{testRunId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get all test runs with pagination
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/get-get-ai-quality-test-runs
**Description:** GET /aiQualityCheck/testRun
## `GET /aiQualityCheck/testRun`
### Query parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## List all test cases
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/get-list-ai-quality-test-cases
**Description:** GET /aiQualityCheck/testCase
## `GET /aiQualityCheck/testCase`
### Responses
**`200`** — Successful operation
---
## Accept the expected result of a test ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/patch-accept-expected-result-ai-quality-test-ticket
**Description:** PATCH /aiQualityCheck/testRun/{testRunId}/acceptExpectedResult/{ticketId}
## `PATCH /aiQualityCheck/testRun/{testRunId}/acceptExpectedResult/{ticketId}`
Set the expected value for specific ticket in a run to the observed value. This also updates the expected results for all future runs, and updates the statistics of the test run.
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Cancel a specific test run by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/patch-cancel-ai-quality-test-run
**Description:** PATCH /aiQualityCheck/testRun/{testRunId}/cancel
## `PATCH /aiQualityCheck/testRun/{testRunId}/cancel`
Cancels a test run that is currently in 'scheduled' or 'processing' state. All pending test tickets will be cancelled and the test run will be set to 'cancelled' state.
### Path parameters
### Responses
**`200`** — Successful operation
**`400`** — Test run cannot be cancelled in its current state
**`404`** — Test run not found
**`500`** — Internal error
---
## Update a test case by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/patch-update-ai-quality-test-case
**Description:** PATCH /aiQualityCheck/testCase/{id}
## `PATCH /aiQualityCheck/testCase/{id}`
Update a specific test case using its numeric test case ID. As with `DELETE`, `{id}` here is
a test case id and is pinned to `\d+` by the Dispatcher.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
---
## Update the expected result of a test ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/patch-update-expected-result-ai-quality-test-ticket
**Description:** PATCH /aiQualityCheck/testRun/{testRunId}/updateExpectedResult/{ticketId}
## `PATCH /aiQualityCheck/testRun/{testRunId}/updateExpectedResult/{ticketId}`
Update the expected value for specific ticket in a run to a value passed in the payload. This also updates the expected results for all future runs, and updates the statistics of the test run.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Accept ALL the expected results of for a test run
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/post-accept-all-expected-results-ai-quality-test-run
**Description:** POST /aiQualityCheck/testRun/{testRunId}/acceptAllExpectedResults
## `POST /aiQualityCheck/testRun/{testRunId}/acceptAllExpectedResults`
Set the expected values for all tickets in a run to their observed values. This also updates the expected results for all future runs, and updates the statistics of the test run.
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Add test cases for an AI agent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/post-add-ai-quality-test-cases
**Description:** POST /aiQualityCheck/testCase/{id}
## `POST /aiQualityCheck/testCase/{id}`
Add multiple test cases (tickets) to the specified AI agent. Here `{id}` is the AI agent id —
see the note on `GET` above for the dual meaning of `{id}` on this path.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
---
## Create an AI quality test case
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/post-create-ai-quality-test-case
**Description:** POST /aiQualityCheck/testCase
## `POST /aiQualityCheck/testCase`
Create a new test case (an AI-agent-bound ticket whose expected result is locked in) so it
can be replayed by future test runs. The body specifies the ticket id, target AI agent and
the expected result.
### Request body
### Responses
**`200`** — Created
---
## Re-run a previously executed test run
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/post-rerun-ai-quality-test-run
**Description:** POST /aiQualityCheck/testRun/{testRunId}/rerun
## `POST /aiQualityCheck/testRun/{testRunId}/rerun`
Re-executes the same set of test tickets that the original test run used. The new run is
created in `scheduled` state and processed asynchronously. Compare its result against the
original to measure regressions across AI agent versions.
### Path parameters
### Responses
**`200`** — Re-run scheduled
**`404`** — Original test run not found
---
## Schedule a new AI quality check
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-quality-check/post-schedule-ai-quality-check
**Description:** POST /aiQualityCheck/testRun
## `POST /aiQualityCheck/testRun`
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get a specific custom tool
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-tools/get-get-tool-2
**Description:** GET /tools/{identifier}
## `GET /tools/{identifier}`
Get details of a specific custom tool by its ID or slug. These are user-defined functions marked as tools.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Tool not found
**`500`** — Internal error
---
## Get available tools
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-tools/get-get-tools
**Description:** GET /tools
## `GET /tools`
Get a list of available tools that can be used by AI agents. This includes both built-in tools and user-defined functions marked as tools.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Execute a tool
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ai-tools/post-execute-tool
**Description:** POST /tools/{identifier}/run
## `POST /tools/{identifier}/run`
Execute a specific custom tool by its ID or slug. The request body should contain the parameters the tool expects. Required parameters are validated before execution.
### Path parameters
### Request body
### Responses
**`200`** — Tool executed successfully
**`400`** — Validation error (missing required parameters or type mismatch) or tool execution failed
**`403`** — Unauthorized - missing runExecutors permission or tool is private
**`404`** — Tool not found
**`500`** — Internal error
---
## Clear cache
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/cache/get-clear-cache
**Description:** GET /internal/cache/clear
## `GET /internal/cache/clear`
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get cache entries
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/cache/get-get-cache
**Description:** GET /internal/cache/get/{key}
## `GET /internal/cache/get/{key}`
Get cache entries.
- If no key is provided (or key='all'), all cache items are returned.
- If a key with wildcard characters (* or %) is provided, all keys matching the pattern are returned.
- If a specific key is provided, only that cache item is returned.
- Can filter results with q parameter to find entries where value contains the search string.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Invalidate user cache
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/cache/get-invalidate-user-cache
**Description:** GET /internal/cache/invalidateUser/{userId}
## `GET /internal/cache/invalidateUser/{userId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — User not found
**`500`** — Internal error
---
## Invalidate cache entries by key pattern
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/cache/post-invalidate-internal-cache
**Description:** POST /internal/invalidateCache
## `POST /internal/invalidateCache`
Drops cache entries matching the supplied keys/patterns. Use sparingly — `clearCache` is the
blunter alternative.
### Request body
### Responses
**`200`** — Successful operation
---
## Get a customer by contract id
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/customer/get-get-customer-by-contract-id
**Description:** GET /customer/byContractId/{contractId}
## `GET /customer/byContractId/{contractId}`
Get a customer and associated contracts
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Contract not found
**`500`** — Internal error
---
## Get a customer by customer id
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/customer/get-get-customer-by-customer-id
**Description:** GET /customer/byCustomerId/{customerId}
## `GET /customer/byCustomerId/{customerId}`
Get a customer and associated contracts
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## Get a customer by ticket id
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/customer/get-get-customer-by-ticket-id
**Description:** GET /customer/byTicketId/{ticketId}
## `GET /customer/byTicketId/{ticketId}`
Get a customer and associated contracts by ticket id. Tickets are mapped to customer using enneo.MIND's AI, or when manually assigned by a user
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — No customer id associated with ticket (yet)
**`500`** — Internal error
---
## Search a customer
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/customer/get-search-customer
**Description:** GET /customer/search
## `GET /customer/search`
Search a customer by firstname, lastname contractId
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## Get a customer by customer id
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/customer/patch-update-customer-by-customer-id
**Description:** PATCH /customer/{customerId}
## `PATCH /customer/{customerId}`
Get a customer and associated contracts
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — No customer id associated with ticket (yet)
**`500`** — Internal error
---
## Invalidate cache for a contract or customer
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/customer/post-invalidate-cache
**Description:** POST /customer/invalidateCache
## `POST /customer/invalidateCache`
This endpoint invalidates the cache for a given contract or customer by their IDs.
### Responses
**`200`** — Cache invalidated successfully.
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## Get deferrer for contract
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/deferrer/get-get-deferrer-for-contract
**Description:** GET /deferrer/contract/{contractId}
## `GET /deferrer/contract/{contractId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get deferrer for PC
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/deferrer/get-get-deferrer-for-pc
**Description:** GET /deferrer/pc
## `GET /deferrer/pc`
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Submit request to cortex for ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/debugging-for-ai-microservice-cortex/post-trigger-cortex-for-ticket
**Description:** POST /experimental/cortex/ticket/{ticketId}/trigger
## `POST /experimental/cortex/ticket/{ticketId}/trigger`
Manually trigger Cortex processing for a ticket.
**Deprecated** — this endpoint will be removed in the 2026-06-14 release.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Delete a conversation
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/conversation/delete-delete-conversation
**Description:** DELETE /ticket/{ticketId}/conversation/{conversationId}
## `DELETE /ticket/{ticketId}/conversation/{conversationId}`
Delete an existing conversation (only private conversations can be deleted)
### Path parameters
### Responses
**`200`** — Successful operation
**`400`** — Bad request - Cannot delete public conversation or user doesn't have permission
**`403`** — Unauthorized
**`404`** — Ticket or conversation not found
**`500`** — Internal error
---
## Get a specific conversation by ID
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/conversation/get-get-conversation-by-id
**Description:** GET /ticket/{ticketId}/conversation/{conversationId}
## `GET /ticket/{ticketId}/conversation/{conversationId}`
Retrieve a specific conversation by its ID within a ticket
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Bad request - Conversation does not belong to this ticket
**`403`** — Unauthorized
**`404`** — Ticket or conversation not found
**`500`** — Internal error
---
## Get conversations for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/conversation/get-get-conversations
**Description:** GET /ticket/{ticketId}/conversation
## `GET /ticket/{ticketId}/conversation`
Retrieve all conversations associated with a specific ticket
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Update a conversation
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/conversation/patch-update-conversation
**Description:** PATCH /ticket/{ticketId}/conversation/{conversationId}
## `PATCH /ticket/{ticketId}/conversation/{conversationId}`
Update an existing conversation (internal notes and drafts can be updated; drafts can also be published by changing isDraft to false)
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Bad request - Can only update internal notes or user doesn't own the note
**`403`** — Unauthorized
**`404`** — Ticket or conversation not found
**`500`** — Internal error
---
## Reply to a ticket thread
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/conversation/post-reply-to-ticket
**Description:** POST /ticket/{ticketId}/conversation/reply
## `POST /ticket/{ticketId}/conversation/reply`
Create a new conversation by replying to a ticket thread. This actually sends out an email (for email tickets), triggers sending of a letter (for letter tickets) or a message (for chat tickets). Can also create drafts that require supervisor approval before sending.
### Path parameters
### Query parameters
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Bad request - Invalid input
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Store a new conversation
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/conversation/post-store-conversation
**Description:** POST /ticket/{ticketId}/conversation/store
## `POST /ticket/{ticketId}/conversation/store`
Store a new conversation without sending any messages
### Path parameters
### Request body
### Responses
**`201`** — Conversation created successfully
**`400`** — Bad request - Invalid input
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Get an event trace by id
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/event/get-get-event-trace
**Description:** GET /eventTrace/{id}
## `GET /eventTrace/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Event trace not found
---
## Get available event types
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/event/get-get-event-types
**Description:** GET /event/getEventTypes
## `GET /event/getEventTypes`
Returns the catalogue of supported event types with their subtypes and human-readable labels.
### Responses
**`200`** — Successful operation
---
## Get an event by id
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/event/get-get-event
**Description:** GET /event/{id}
## `GET /event/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Event not found
---
## Update an event trace
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/event/patch-update-event-trace
**Description:** PATCH /eventTrace/{id}
## `PATCH /eventTrace/{id}`
### Path parameters
### Request body
### Responses
**`200`** — Updated
**`404`** — Event trace not found
---
## Update an event
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/event/patch-update-event
**Description:** PATCH /event/{id}
## `PATCH /event/{id}`
Patch metadata on an event — usually `status`, `outcome`, or `hookOutcome`. The body contains the partial object to merge.
### Path parameters
### Request body
### Responses
**`200`** — Updated
**`404`** — Event not found
---
## Create an event trace
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/event/post-create-event-trace
**Description:** POST /eventTrace
## `POST /eventTrace`
Persist a single event trace attached to a parent event.
### Request body
### Responses
**`200`** — Created
**`400`** — Invalid payload
**`403`** — Unauthorized
---
## Create event traces in batch
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/event/post-create-event-traces-batch
**Description:** POST /eventTrace/batch
## `POST /eventTrace/batch`
Same as `POST /eventTrace`, but accepts an array of trace payloads. Used by Cortex and other
services that buffer traces and flush them periodically to reduce request overhead.
### Request body
### Responses
**`200`** — Created
**`400`** — Invalid payload
**`403`** — Unauthorized
---
## Create an event
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/event/post-create-event
**Description:** POST /event
## `POST /event`
Manually emit a Mind event. The created event is enqueued for processing by the standard
event pipeline (event hooks, automation, traces).
### Request body
### Responses
**`200`** — Created
**`400`** — Invalid payload
**`403`** — Unauthorized
---
## Search events with filtering and pagination
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/event/post-search-events
**Description:** POST /event/search
## `POST /event/search`
For technical personnel to search and analyze events across the system. Allows searching, filtering, and paginating through events independent of ticket ID. Technical information is always included in the results.
### Query parameters
### Request body
Filters for searching events
### Responses
**`200`** — Successful operation
**`403`** — Forbidden - Insufficient permissions
---
## Execute executor
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/executor-sandbox/post-execute-executor
**Description:** POST /executor/execute/{name}
## `POST /executor/execute/{name}`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get local execution command
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/executor-sandbox/post-get-local-execution-command
**Description:** POST /executor/localExecutionCommand
## `POST /executor/localExecutionCommand`
### Request body
### Responses
**`200`** — Successful execution
**`403`** — Unauthorized
**`500`** — Internal error
---
## Preview executor
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/executor-sandbox/post-preview-executor
**Description:** POST /executor/preview
## `POST /executor/preview`
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get agent queue status
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/general/get-get-agents-queue
**Description:** GET /agents/queue
## `GET /agents/queue`
Get information about agent availability and expected waiting times for customer service
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get documentation
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/general/get-get-documentation
**Description:** GET /docs/{path}
## `GET /docs/{path}`
Serves the Mind documentation index or a specific document at the given path.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Documentation not found
**`500`** — Internal error
---
## Get merged OpenAPI spec
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/general/get-get-open-api-spec
**Description:** GET /docs/open-api
## `GET /docs/open-api`
Returns the fully merged OpenAPI YAML document with all `$ref` references resolved.
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get version
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/general/get-get-version
**Description:** GET /version
## `GET /version`
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Run cron job
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/general/get-run-cron-job
**Description:** GET /cron/{interval}
## `GET /cron/{interval}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Render a customer survey form
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/general/get-show-customer-survey
**Description:** GET /survey/{id}
## `GET /survey/{id}`
Renders the customer-facing survey form. The numeric `id` resolves to the survey row that was
generated when the originating ticket was closed; the public link in the closing email points
here.
### Path parameters
### Responses
**`200`** — Survey HTML
**`404`** — Survey not found or expired
---
## Create a reminder
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/general/post-create-reminder
**Description:** POST /reminder
## `POST /reminder`
### Request body
### Responses
**`201`** — Reminder created
**`403`** — Unauthorized
**`500`** — Internal error
---
## Submit a customer survey
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/general/post-submit-customer-survey
**Description:** POST /survey/{id}
## `POST /survey/{id}`
Submit the response payload generated by the rendered survey form.
### Path parameters
### Request body
### Responses
**`200`** — Submitted (or already submitted — idempotent)
**`404`** — Survey not found or expired
---
## Submit a survey response
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/general/post-submit-survey
**Description:** POST /survey/{reference}-{ticketId}
## `POST /survey/{reference}-{ticketId}`
### Path parameters
### Request body
The survey response
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Validate a value of the given type
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/general/post-validate
**Description:** POST /validation/{type}
## `POST /validation/{type}`
Validates a value against the rules of the specified validation type. Supported types are `email` and `letterAddress`.
### Path parameters
### Request body
The value to validate
### Responses
**`200`** — Validation result
**`400`** — Bad request — missing required field or unsupported type
**`500`** — Internal error
---
## Delete a folder
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/files-connector/delete-delete-files-connector-folder
**Description:** DELETE /knowledgeSource/filesConnector/folders/{id}
## `DELETE /knowledgeSource/filesConnector/folders/{id}`
Deletes a folder and all its contents recursively. For each contained file article, calls `KnowledgeSource::delete()` and emits a `knowledgeSourceChanged action=delete` event so Cortex removes the vectors. Sub-folders are also deleted.
### Path parameters
### Responses
**`200`** — Folder deleted successfully
**`404`** — Folder not found
---
## Download original file
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/files-connector/get-get-files-connector-file-original
**Description:** GET /knowledgeSource/filesConnector/{id}/original
## `GET /knowledgeSource/filesConnector/{id}/original`
Returns a 302 redirect to the internal storage URL of the original uploaded binary. The storage endpoint performs regular-vs-archive lookup.
### Path parameters
### Responses
**`302`** — Redirect to the original file URL
**`404`** — File not found or no original URL stored
---
## Get files connector
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/files-connector/get-get-files-connector
**Description:** GET /knowledgeSource/filesConnector
## `GET /knowledgeSource/filesConnector`
Returns the files connector row (auto-created if missing), including all folder structure rows and file knowledge_source rows underneath. The connector is a singleton per installation.
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Move a file to a different folder
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/files-connector/patch-move-files-connector-file
**Description:** PATCH /knowledgeSource/filesConnector/{id}/move
## `PATCH /knowledgeSource/filesConnector/{id}/move`
Moves a file article to a new folder and rebuilds its `source` path. Fires a `knowledgeSourceChanged action=update` event.
### Path parameters
### Request body
### Responses
**`200`** — File moved successfully
**`404`** — File or folder not found
---
## Rename or move a folder
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/files-connector/patch-update-files-connector-folder
**Description:** PATCH /knowledgeSource/filesConnector/folders/{id}
## `PATCH /knowledgeSource/filesConnector/folders/{id}`
Renames and/or moves a folder. After the change, rebuilds the `source` column for all descendant files and emits one `knowledgeSourceChanged action=update` event per descendant. Cortex handles these via `update_properties` (no re-embedding).
### Path parameters
### Request body
### Responses
**`200`** — Folder updated successfully
**`404`** — Folder or parent folder not found
---
## Create a folder
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/files-connector/post-create-files-connector-folder
**Description:** POST /knowledgeSource/filesConnector/folders
## `POST /knowledgeSource/filesConnector/folders`
Creates a new folder under the files connector hierarchy.
### Request body
### Responses
**`200`** — Folder ensured (created or already existed)
**`404`** — Parent folder not found
**`422`** — Folder name is required
---
## Refresh the index for a file
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/files-connector/post-refresh-files-connector-file-index
**Description:** POST /knowledgeSource/filesConnector/{id}/refreshIndex
## `POST /knowledgeSource/filesConnector/{id}/refreshIndex`
Forces Cortex to re-embed the file's current `text` without re-parsing the original binary. Preserves manual Markdown edits. Bumps `modifiedAt` unconditionally and fires `knowledgeSourceChanged action=update`. Use this when the AI search seems stale or after an embedding-model change; use `reindex` to discard manual edits and re-parse the original.
### Path parameters
### Responses
**`200`** — Index refresh queued successfully
**`404`** — File not found
---
## Replace the binary of a file
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/files-connector/post-replace-files-connector-file
**Description:** POST /knowledgeSource/filesConnector/{id}/replace
## `POST /knowledgeSource/filesConnector/{id}/replace`
Replaces the binary backing an existing file knowledge_source. The KS id is preserved
(so embeddings keep their identity in downstream stores); the row's `name`, `title`,
`source` and `data.original*` fields are refreshed to match the new file.
The new file may have a different filename and extension from the previous one — replace
is keyed by KS id, not by filename. A 422 is returned if the new filename collides with
another active file in the same folder.
Side-effects mirror an initial upload: the old S3 object is removed, the new binary is
stored under the same KS id, Markdown is re-parsed (Firecrawl / Cortex vision / plaintext
depending on extension), page thumbnails are regenerated, and `data.hasManualMarkdownEdits`
is reset to `false`. A `knowledgeSourceChanged action=update` event is emitted so Cortex
re-embeds the new content.
### Path parameters
### Responses
**`200`** — File replaced successfully
**`400`** — Incomplete upload (partial transfer)
**`404`** — File knowledge source not found
**`413`** — File size exceeds limit
**`422`** — No file provided, unsupported type, MIME spoofing, archived file, or the new filename
collides with another active file in the same folder.
**`500`** — Internal error
---
## Reset file to original (re-parse)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/files-connector/post-reset-files-connector-file-to-original
**Description:** POST /knowledgeSource/filesConnector/{id}/resetToOriginal
## `POST /knowledgeSource/filesConnector/{id}/resetToOriginal`
Re-downloads the original binary from storage, re-converts it to Markdown, and updates the knowledge_sources row. **Destructive** — discards any manual Markdown edits and clears `hasManualMarkdownEdits`. If the embedding hash is unchanged, skips firing the `knowledgeSourceChanged` event (saves a needless Weaviate upsert) but still bumps `modifiedAt`. Use `refreshIndex` to re-embed the current text non-destructively.
### Path parameters
### Responses
**`200`** — File re-indexed successfully
**`404`** — File not found
**`500`** — Could not download original file
---
## Upload a file (or batch of files)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/files-connector/post-upload-files-connector-file
**Description:** POST /knowledgeSource/filesConnector/upload
## `POST /knowledgeSource/filesConnector/upload`
Uploads one or more files to the files connector. Each file is:
1. Validated (extension allowlist + 50 MB per-file cap + MIME-type sniff)
2. Stored in MinIO under the `knowledgeSources/` prefix
3. Converted to Markdown (Firecrawl for office/PDF, Cortex vision LLM for images, direct read for .md/.txt)
4. Saved as a `knowledge_sources` row with `type='file'`
5. Triggers a `knowledgeSourceChanged` event for Cortex indexing
**Single-file mode** (backward-compatible): send `name="file"` — response is `{success, id}`.
**Batch mode**: send `name="files[]"` with multiple parts — response is `{successful: [{id, name}], failed: [{name, error}]}`. Max 20 files and 50 MB total per request. Files are processed in parallel via Amp futures. Per-file errors land in `failed` without aborting the batch.
### Responses
**`200`** — Single-file: `{success: true, id: N}`.
Batch: `{successful: [{id, name}], failed: [{name, error}]}` — HTTP 200 even when some files failed.
**`400`** — Incomplete upload (partial transfer)
**`413`** — File or total batch size exceeds limit
**`422`** — No file provided, unsupported type, MIME spoofing, or too many files in batch
**`500`** — Internal error
---
## Get health status of cron jobs
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/health/get-get-health-cron
**Description:** GET /health/cron
## `GET /health/cron`
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get health status
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/health/get-get-health
**Description:** GET /health
## `GET /health`
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Container-level health probe
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/health/get-health-containers
**Description:** GET /health/containers
## `GET /health/containers`
Detailed health check that reports the status of each container Mind depends on (Auth, Cortex,
io-proxy, ACD, code-executor). Used by uptime monitors that need a more granular signal than
`/health`.
### Responses
**`200`** — Successful operation
**`500`** — At least one dependency is unhealthy
---
## Export AI agent performance
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/export/get-export-ai-agent-performance
**Description:** GET /export/aiAgentPerformance
## `GET /export/aiAgentPerformance`
Export per-AI-agent performance metrics (executions, success rate, latency, …) for a time range.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized.
**`500`** — Internal error.
---
## Export AI insights (one row per ticket, one column per question)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/export/get-export-ai-insights
**Description:** GET /export/aiInsights
## `GET /export/aiInsights`
Wide-format export. For each active question the export carries two columns: alias
`insight_<id>` for the value and `confidence_<id>` for the LLM's 0–1 confidence. The
question's human-readable name is used as the XLSX/CSV header. The `reasoning` column
is intentionally excluded from bulk export — it contains free-form AI text that quotes
conversation content; it remains visible per ticket via the ticket-AI-insights endpoint.
Large ranges are handed off to the `exportBigList` async pipeline.
### Query parameters
### Responses
**`200`** — Export file (sync) or async scheduling message
**`403`** — Unauthorized (requires exportData)
---
## Export call log
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/export/get-export-call-log
**Description:** GET /export/callLog
## `GET /export/callLog`
Export the call log as a downloadable file (xlsx/csv/json).
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized.
**`500`** — Internal error.
---
## Export conversations
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/export/get-export-conversations-list
**Description:** GET /export/conversations
## `GET /export/conversations`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal server error
---
## Export custom client reports
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/export/get-export-custom-data
**Description:** GET /export/customData
## `GET /export/customData`
Export data using custom SQL queries with dynamic parameters. This endpoint allows you to execute
pre-configured SQL queries with customizable parameters that replace placeholders in the query.
This endpoint should only be used if standard export endpoints (for tickets, messages, worklog, survey, etc.) do not suffice. It is an adanced feature and every query requires prior approval by your Enneo account manager.
## How Parameters Work
1. **SQL Query Placeholders**: Custom exports contain SQL queries with placeholders like `{limit}`, `{offset}`, `{customerId}`
2. **Parameter Resolution**: Parameters are resolved in this order:
- GET query parameters (highest priority)
- Default values from export configuration
- Required parameters will throw an error if missing
3. **Security**: All parameters are safely bound using prepared statements
## Example Custom Export Configuration
```json
{
"label": "Customer Events Report",
"sqlQuery": "SELECT id, type, createdAt FROM event WHERE customerId = {customerId} ORDER BY id DESC LIMIT {limit} OFFSET {offset}",
"parameters": [
{
"key": "customerId",
"label": "Customer ID",
"description": "The customer to export events for",
"defaultValue": null
},
{
"key": "limit",
"label": "Limit",
"description": "Maximum number of records to return",
"defaultValue": "100"
},
{
"key": "offset",
"label": "Offset",
"description": "Number of records to skip",
"defaultValue": "0"
}
]
}
```
## Example Usage
```
GET /api/mind/export/customData?exportId=0&format=json&customerId=12345&limit=50&offset=0
```
This would execute:
```sql
SELECT id, type, createdAt FROM event WHERE customerId = ? ORDER BY id DESC LIMIT ? OFFSET ?
```
With parameters: `[12345, 50, 0]`
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Bad request - required parameter missing or invalid export configuration
**`403`** — Unauthorized
**`500`** — Internal server error
---
## Export GDPR private data for a customer
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/export/get-export-gdpr-private-data
**Description:** GET /export/gdprPrivateData
## `GET /export/gdprPrivateData`
Export all personally identifiable data tied to a given customer/contract for GDPR data-portability
and right-to-access requests. The call requires the requesting user to hold the relevant GDPR
permission.
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Missing `contractId`/`customerId` or invalid parameters.
**`403`** — Unauthorized — caller lacks GDPR export permission.
**`500`** — Internal error.
---
## Export knowledge sources
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/export/get-export-knowledge-sources
**Description:** GET /export/knowledgeSources/{type}
## `GET /export/knowledgeSources/{type}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal server error
---
## Export training data that is used by the AI's default text answer
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/export/get-export-message-samples
**Description:** GET /export/messageSamples
## `GET /export/messageSamples`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal server error
---
## Export quality assessments
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/export/get-export-quality-assessments
**Description:** GET /export/qualityAssessments
## `GET /export/qualityAssessments`
Export quality assessments with all criterion scores for a given scorecard.
Each row represents one assessment with the following columns:
- Date (createdAt - when the assessment was created)
- Assessment Date (when the supervisor completed the assessment, null for AI-only assessments)
- Reviewed Agent (name of the assessed user)
- Reviewer (name of the reviewer or "AI" for AI-generated assessments)
- State (translated to readable labels: "Ready for Review", "Reviewed", etc.)
- Ticket ID
- Total Score (absolute scored points as integer)
- Total Score (%) (percentage score)
- One column per criterion score (e.g., "Communication Quality - Clarity & Readability")
**Default Scorecard Behavior:**
If `scorecardId` is omitted, the scorecard from the most recent valid assessment is used as default.
**Multi-Sheet XLSX Export:**
When format is `xlsx` and `scorecardId` is omitted, the export generates one Excel sheet per scorecard
that has assessments. Each sheet is named after the scorecard.
**Excluded States:**
Assessments in states `unprocessed`, `aiInProgress`, `deleted`, and `error` are excluded from the export.
Example requests:
```
GET /api/mind/export/qualityAssessments?format=json
GET /api/mind/export/qualityAssessments?format=xlsx&scorecardId=1
GET /api/mind/export/qualityAssessments?format=xlsx&from=2024-01-01&to=2024-12-31
```
### Query parameters
### Responses
**`200`** — Export returned successfully.
**`403`** — Unauthorized – user lacks `qualityViewAssessmentAll` permission.
**`500`** — Internal server error
---
## Export user profiles and their permissions
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/export/get-export-users
**Description:** GET /export/users
## `GET /export/users`
Export all user profiles and their associated data including permissions.
Used primarily by workforce managers to quickly view all profiles.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized - User doesn't have permission to export user profiles
**`500`** — Internal server error
---
## Preview a generic export by key
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/export/get-generic-export-preview
**Description:** GET /export/{key}/preview
## `GET /export/{key}/preview`
Returns a preview of the data that `GET /export/{key}` would produce — the first rows and
column metadata, used to power the export-overview UI in ops-fe.
### Path parameters
### Responses
**`200`** — Successful operation
**`400`** — Unknown or invalid export key.
**`403`** — Unauthorized.
**`500`** — Internal error.
---
## Generic export by key
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/export/get-generic-export
**Description:** GET /export/{key}
## `GET /export/{key}`
Dispatches to the per-key export handler that matches `key`. Use this endpoint for keys that
don't have a dedicated path on this page (e.g. `reporting_tickets`, `reporting_messages`,
`reporting_worklog`, `survey`). The accepted query parameters and response shape depend on
the chosen key — see the dedicated schema blocks (`exportReportingTickets`,
`exportReportingMessages`, `exportReportingWorklog`, `exportSurveyResponses`) in
`endpoints/export.yaml` for the per-key contract.
Large result sets are queued asynchronously and delivered to the current user's email; small
sets stream the file in the response body.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation — file body or async-confirmation payload.
**`400`** — Unknown or invalid export key.
**`403`** — Unauthorized.
**`500`** — Internal error.
---
## Get knowledge source dashboard
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/knowledge-sources/get-get-knowledge-source-dashboard
**Description:** GET /knowledgeSource/dashboard
## `GET /knowledgeSource/dashboard`
Returns aggregated KPIs for the knowledge base: total entries per type/structure node,
processing status, and recent ingestion errors. Used to power the dashboard widget on the
Knowledge Sources landing page.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
---
## Delete an intent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/intent/delete-delete-intent
**Description:** DELETE /intent/{intentId}
## `DELETE /intent/{intentId}`
Delete an intent. This is only possible if the intent is not yet executed
### Path parameters
### Responses
**`200`** — Intent was deleted
**`403`** — Unauthorized
**`404`** — Intent not found
**`500`** — Internal error
---
## Get an intent by id
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/intent/get-get-intent-by-id
**Description:** GET /intent/{intentId}
## `GET /intent/{intentId}`
An intent defines in a structured and machine-processable way what the customer wanted, e.g. *save my meter reading of 265 kWh* or *send me a bill*
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## Get intent(s) detected/assigned for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/intent/get-get-intent-by-ticket-id
**Description:** GET /intent/byTicketId/{ticketId}
## `GET /intent/byTicketId/{ticketId}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## List of all available intents and categories
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/intent/get-get-intent-list
**Description:** GET /intent/list
## `GET /intent/list`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## Get a preview of an intent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/intent/get-get-intent-preview
**Description:** GET /intent/preview/{aiAgentId}
## `GET /intent/preview/{aiAgentId}`
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Customer not found
**`500`** — Internal error
---
## Execute an option for a specific intent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/intent/post-execute-intent
**Description:** POST /intent/{intentId}/execute
## `POST /intent/{intentId}/execute`
### Path parameters
### Request body
Optional additional parameters to override/validate the existing data in the intent or trigger a response to the customer
### Responses
**`200`** — Option was processed
**`403`** — Unauthorized
**`404`** — Intent not found
**`500`** — Internal error
---
## Update an intent with new, modified input data
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/intent/put-update-intent
**Description:** PUT /intent/{intentId}
## `PUT /intent/{intentId}`
### Path parameters
### Request body
Parameters to override/validate the existing data in the intent
### Responses
**`200`** — Intent was updated
**`403`** — Unauthorized
**`404`** — Intent not found
**`500`** — Internal error
---
## Delete a file
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/file-manager/delete-delete-managed-file
**Description:** DELETE /files/manager/file
## `DELETE /files/manager/file`
### Request body
### Responses
**`200`** — File deleted successfully
**`403`** — Permission denied
**`409`** — File is in use and cannot be deleted
**`500`** — Internal error
---
## Delete a folder and its contents
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/file-manager/delete-delete-managed-folder
**Description:** DELETE /files/manager/folder
## `DELETE /files/manager/folder`
### Request body
### Responses
**`200`** — Folder deleted successfully
**`403`** — Permission denied
**`404`** — Folder not found
**`409`** — Folder contains files that are in use
**`500`** — Internal error
---
## Get file usage information
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/file-manager/get-get-managed-file-usages
**Description:** GET /files/manager/usages
## `GET /files/manager/usages`
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Bad request
**`403`** — Permission denied
**`500`** — Internal error
---
## List files and folders in managed-files storage
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/file-manager/get-list-managed-files
**Description:** GET /files/manager/list
## `GET /files/manager/list`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Permission denied
**`500`** — Internal error
---
## Rename or move a file
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/file-manager/patch-update-managed-file
**Description:** PATCH /files/manager/file
## `PATCH /files/manager/file`
### Request body
### Responses
**`200`** — File renamed successfully
**`403`** — Permission denied
**`404`** — File not found
**`409`** — Target file already exists
**`500`** — Internal error
---
## Rename or move a folder
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/file-manager/patch-update-managed-folder
**Description:** PATCH /files/manager/folder
## `PATCH /files/manager/folder`
### Request body
### Responses
**`200`** — Folder renamed successfully
**`403`** — Permission denied
**`404`** — Folder not found
**`500`** — Internal error
---
## Upload a file to managed-files storage
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/file-manager/post-create-managed-file
**Description:** POST /files/manager/file
## `POST /files/manager/file`
### Request body
### Responses
**`200`** — File uploaded successfully
**`400`** — Bad request
**`403`** — Permission denied
**`409`** — File already exists
**`500`** — Internal error
---
## Create a folder
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/file-manager/post-create-managed-folder
**Description:** POST /files/manager/folder
## `POST /files/manager/folder`
### Request body
### Responses
**`200`** — Folder created successfully
**`403`** — Permission denied
**`409`** — Folder already exists
**`500`** — Internal error
---
## Explain time-tracking decisions
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/internal-enneo-only/get-explain-time-tracking
**Description:** GET /internal/explainTimeTracking
## `GET /internal/explainTimeTracking`
Diagnostic endpoint that returns the time-tracking computation breakdown for the current user
or a given user/window. Used to debug worklog disputes.
### Query parameters
### Responses
**`200`** — Successful operation
---
## List Superset users
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/internal-enneo-only/get-get-superset-users
**Description:** GET /internal/getSupersetUsers
## `GET /internal/getSupersetUsers`
Returns the user list provisioned in the Superset analytics tenant for this client. Used by
the Settings UI when wiring Superset SSO.
### Responses
**`200`** — Successful operation
---
## Get a telemetry trace
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/internal-enneo-only/get-get-telemetry-trace
**Description:** GET /internal/telemetry/trace/{traceId}
## `GET /internal/telemetry/trace/{traceId}`
Proxies the admin portal telemetry endpoint
(`admin.enneo.ai/api/telemetry/clients/{CLIENT_ID}/traces/{traceId}`) for the current
environment's client. Restricted to enneo and partner users (HTTP 403 for all other profile types).
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Forbidden — caller is not an enneo or partner user
**`502`** — Upstream failure — admin portal returned an error
---
## Get worker status
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/internal-enneo-only/get-get-worker-status
**Description:** GET /internal/workerStatus
## `GET /internal/workerStatus`
Returns liveness + progress information for all Mind workers (`worker_*.log`).
### Responses
**`200`** — Successful operation
---
## Initialise message samples (dev)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/internal-enneo-only/get-init-message-samples
**Description:** GET /internal/initMessageSamples
## `GET /internal/initMessageSamples`
Loads canned message-sample fixtures into the local DB. Dev-only.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized / disabled in this environment
---
## Load seed tickets (dev)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/internal-enneo-only/get-load-seed-tickets
**Description:** GET /internal/loadSeedTickets
## `GET /internal/loadSeedTickets`
Loads a curated set of seed tickets into the local DB for development and demos.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized / disabled in this environment
---
## Reset the local environment
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/internal-enneo-only/get-reset
**Description:** GET /internal/reset
## `GET /internal/reset`
Wipes data tables and reseeds dev fixtures. Available only in non-production environments.
### Responses
**`200`** — Reset complete
**`403`** — Unauthorized / disabled in this environment
---
## Run an ad-hoc read-only query
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/internal-enneo-only/get-run-internal-query
**Description:** GET /internal/query
## `GET /internal/query`
Diagnostic SQL endpoint — accepts a SQL string in `q` and returns the rows. Locked down to
Enneo staff and never enabled on customer-facing deployments.
### Query parameters
### Responses
**`200`** — Successful operation
---
## Sync phone numbers from the telephony provider (read)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/internal-enneo-only/get-sync-phone-numbers-get
**Description:** GET /internal/syncPhoneNumbers
## `GET /internal/syncPhoneNumbers`
Pulls the current list of phone numbers configured at the telephony provider and reconciles
them with `subchannel` rows in Mind. Mounted on both GET (preview) and POST (apply).
### Responses
**`200`** — Successful operation
---
## Receive processed ticket response from Cortex
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/internal-enneo-only/post-callback-from-cortex-for-ticket
**Description:** POST /internal/cortex/ticket/{ticketId}/callback
## `POST /internal/cortex/ticket/{ticketId}/callback`
Internal endpoint called by the Cortex microservice to deliver AI processing results for a ticket.
Requires the `x-internal-communication-token` header — regular user tokens are rejected.
### Path parameters
### Request body
The response from Cortex
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Convert a PDF to an image
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/internal-enneo-only/post-convert-pdf-to-image
**Description:** POST /internal/helpers/convertPdfToImage
## `POST /internal/helpers/convertPdfToImage`
Internal helper used by various Mind flows (e.g. document previews, intent input). Accepts a PDF file
reference (storage path or base64 payload) and returns the rendered page(s) as image(s).
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid PDF input
**`403`** — Unauthorized
---
## Sync phone numbers from the telephony provider (apply)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/internal-enneo-only/post-sync-phone-numbers-post
**Description:** POST /internal/syncPhoneNumbers
## `POST /internal/syncPhoneNumbers`
Same as `GET /internal/syncPhoneNumbers`, but persists the diff.
### Responses
**`200`** — Successful operation
---
## Soft-delete a NEO tool
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-tools/delete-delete-tool
**Description:** DELETE /tool/{id}
## `DELETE /tool/{id}`
Soft-deletes the tool and appends a delete snapshot to its history.
### Path parameters
### Responses
**`200`** — Deleted
**`404`** — Tool not found
---
## NEO tool change history
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-tools/get-get-tool-history
**Description:** GET /tool/{id}/history
## `GET /tool/{id}/history`
Append-only version history (newest first), never pruned.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Tool not found
---
## Get a NEO tool
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-tools/get-get-tool
**Description:** GET /tool/{id}
## `GET /tool/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Tool not found
---
## List NEO tools
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-tools/get-list-tools
**Description:** GET /tool
## `GET /tool`
Returns live (non-deleted) tools. With `?aiAgentId=N`, returns shared tools (`aiAgentId` null) plus that agent's private tools.
### Query parameters
### Responses
**`200`** — Successful operation
**`401`** — Unauthorized
---
## Update a NEO tool
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-tools/patch-update-tool
**Description:** PATCH /tool/{id}
## `PATCH /tool/{id}`
Updates `name`, `description`, `definition` and/or `aiAgentId`. `slug` is immutable and ignored. Re-validated via an ephemeral agent; an update snapshot is appended to history.
### Path parameters
### Request body
### Responses
**`200`** — Updated
**`404`** — Tool not found
**`422`** — Invalid definition (validation violations returned)
---
## Create a NEO tool
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-tools/post-create-tool
**Description:** POST /tool
## `POST /tool`
Creates a tool. `slug` is the cortex reference name; it defaults to a slug of `name` and is immutable after creation. The definition is validated via an ephemeral agent before saving; a create snapshot is appended to the tool history.
### Request body
### Responses
**`201`** — Created
**`400`** — Missing name or invalid slug
**`409`** — A tool with this slug already exists
**`422`** — Invalid definition (validation violations returned)
---
## Get one NEO session
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-sessions/get-get-neo-session
**Description:** GET /sessions/{id}
## `GET /sessions/{id}`
Returns a single session with its `ticketId` — the session→ticket lookup used on a cold-start when only the session id is known. Caller must be a participant of the session, or have `accessTechnicalEvents` permission.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Not a participant of this session
**`404`** — Session not found
---
## Get session transcript
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-sessions/get-list-neo-session-messages
**Description:** GET /sessions/{id}/messages
## `GET /sessions/{id}/messages`
Returns all messages for a session, ordered by createdAt ascending. Caller must be a participant of the session, or have `accessTechnicalEvents` permission. `costUsd`, `usageJson`, and `model` are only included when the caller has `reportAiPerformance`.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Not a participant of this session
**`404`** — Session not found
---
## List NEO sessions
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-sessions/get-list-neo-sessions
**Description:** GET /sessions
## `GET /sessions`
Returns sessions the caller participates in. With `?ticketId=` and `accessTechnicalEvents` permission: returns all sessions on that ticket. With `?ticketId=` as a plain human agent (ticket must be accessible): returns the caller's own sessions on that ticket **plus** the ticket's unclaimed (owner-less) cortex warm-start sessions — the discover-and-continue path, so the human agent picks up cortex's pre-work and continues the same session. `costUsd`/`model` are only included when the caller has `reportAiPerformance`.
### Query parameters
### Responses
**`200`** — Successful operation
**`401`** — Unauthorized
---
## Update session participants
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-sessions/patch-patch-neo-session
**Description:** PATCH /sessions/{id}
## `PATCH /sessions/{id}`
Add or remove participants from a session. The caller must already be a participant of the session. A future `title` field is accepted but ignored.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Not a participant of this session
**`404`** — Session not found
---
## Append a message to a session
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-sessions/post-create-neo-session-message
**Description:** POST /sessions/{id}/messages
## `POST /sessions/{id}/messages`
Append a message to a session. On the first message the session is lazily created and the initiator is recorded as a participant.
A human agent who is not yet a participant may append to an **unclaimed** (owner-less) cortex warm-start session on a ticket they can access — this **claims** it (they become its first participant), the discover-and-continue path. Posting to a session already claimed by another human returns `403`.
**Auth rules:** - Cookie/JWT (human agent): sender = {id, name, email}, direction = 'in' - Internal token (cortex/NEO): sender = null, direction = 'out';
`costUsd`, `usageJson`, `model` accepted only from the internal caller.
The `to` field is stamped by Mind from the current participant set — never read from the request body.
### Path parameters
### Request body
### Responses
**`201`** — Message created
**`400`** — Missing or invalid fields
**`401`** — Unauthorized
---
## Create a NEO session
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-sessions/post-create-neo-session
**Description:** POST /sessions
## `POST /sessions`
Create a session with a **server-minted** UUID — the BE-owned id-generation path. Always creates a new session (a ticket may have many; the UI decides how many). This is an additional path, not a replacement: a client may still lazily create a session by POSTing its first message with a self-minted UUID (see `POST /sessions/{id}/messages`).
The human agent caller is recorded as a participant; an internal (cortex) caller creates an unowned session. `costUsd`/`model` in the response are only included when the caller has `reportAiPerformance`.
### Request body
### Responses
**`201`** — Session created
**`401`** — Unauthorized
---
## Check whether worklogs exist for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality/get-ticket-worklog-exists
**Description:** GET /ticket/{ticketId}/worklog/exists
## `GET /ticket/{ticketId}/worklog/exists`
Lightweight existence probe used by the UI to decide whether to show the worklog tab. Cheaper
than `GET /ticket/{ticketId}/worklog` because it skips loading the worklog entries.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Ticket not found
---
## Delete partner
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/partner/delete-delete-partner
**Description:** DELETE /partner/{id}
## `DELETE /partner/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get partner
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/partner/get-get-partner-by-id
**Description:** GET /partner/{id}
## `GET /partner/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get all partner
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/partner/get-get-partners
**Description:** GET /partner/list
## `GET /partner/list`
### Query parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Update partner
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/partner/patch-update-partner
**Description:** PATCH /partner/{id}
## `PATCH /partner/{id}`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Create partner
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/partner/post-create-partner
**Description:** POST /partner
## `POST /partner`
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get AI performance metrics for a specific AI agent
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/report/get-get-ai-agent-performance
**Description:** GET /report/aiAgentPerformance/{aiAgentId}
## `GET /report/aiAgentPerformance/{aiAgentId}`
Returns performance metrics scoped to a specific AI agent for a selected time window.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Invalid filter parameters
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get overall AI performance metrics
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/report/get-get-ai-performance
**Description:** GET /report/aiPerformance
## `GET /report/aiPerformance`
Returns overall AI performance metrics across the workspace for a selected time window.
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Invalid filter parameters
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get dashboard structure
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/report/get-get-report-structure
**Description:** GET /report/structure
## `GET /report/structure`
Returns dashboard structure based on user's role and permissions.
Structure contains widget layout and configuration.
All available components and their configurations are described in the enneo documentation.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get report data
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/report/get-get-report
**Description:** GET /report/{reportCode}
## `GET /report/{reportCode}`
Returns the data for a specific report type
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Invalid filter parameters
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get telephony agent call insights
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/report/get-get-telephony-agent-call-insights
**Description:** GET /report/telephonyAgentCallInsights/{agentId}
## `GET /report/telephonyAgentCallInsights/{agentId}`
Returns detected intents data for a specific telephony agent.
Shows distribution of customer intents identified in the agent's calls.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony agent not found
**`500`** — Internal error
---
## Get telephony agent details
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/report/get-get-telephony-agent-details
**Description:** GET /report/telephonyAgent/{agentId}
## `GET /report/telephonyAgent/{agentId}`
Returns detailed information about a specific telephony agent including their status and team assignments.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony agent not found
**`500`** — Internal error
---
## Get telephony agent performance metrics
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/report/get-get-telephony-agent-performance
**Description:** GET /report/telephonyAgentPerformance/{agentId}
## `GET /report/telephonyAgentPerformance/{agentId}`
Returns performance metrics for a specific telephony agent over time.
Similar to telephonyPerformance, returns 5 metrics: answered calls, missed calls, answer rate, average wait time, and average handling time.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony agent not found
**`500`** — Internal error
---
## Get telephony AI agent call insights
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/report/get-get-telephony-ai-agent-call-insights
**Description:** GET /report/telephonyAiAgentCallInsights/{aiAgentId}
## `GET /report/telephonyAiAgentCallInsights/{aiAgentId}`
Returns hourly breakdown of call outcomes for a specific telephony AI agent.
Shows how calls were handled throughout the day (0-23 hours).
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony AI agent not found
**`500`** — Internal error
---
## Get telephony AI agent details
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/report/get-get-telephony-ai-agent-details
**Description:** GET /report/telephonyAiAgent/{aiAgentId}
## `GET /report/telephonyAiAgent/{aiAgentId}`
Returns detailed information about a specific telephony AI agent.
Includes AI agent ID and live overview statistics.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony AI agent not found
**`500`** — Internal error
---
## Get telephony AI agent performance metrics
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/report/get-get-telephony-ai-agent-performance
**Description:** GET /report/telephonyAiAgentPerformance/{aiAgentId}
## `GET /report/telephonyAiAgentPerformance/{aiAgentId}`
Returns performance metrics for a specific telephony AI agent over time.
Returns 5 metrics: answered calls, missed calls, service level, average wait time, and average handling time.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony AI agent not found
**`500`** — Internal error
---
## Get telephony line details
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/report/get-get-telephony-line-details
**Description:** GET /report/telephonyLine/{lineId}
## `GET /report/telephonyLine/{lineId}`
Returns detailed information about a specific telephony line (subchannel) including voicebot configuration and connected phone numbers.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Telephony line not found
**`500`** — Internal error
---
## Soft-delete a NEO skill
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-skills/delete-delete-skill
**Description:** DELETE /skill/{id}
## `DELETE /skill/{id}`
Soft-deletes the skill and appends a delete snapshot to its history.
### Path parameters
### Responses
**`200`** — Deleted
**`404`** — Skill not found
---
## NEO skill change history
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-skills/get-get-skill-history
**Description:** GET /skill/{id}/history
## `GET /skill/{id}/history`
Append-only version history (newest first), never pruned.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Skill not found
---
## Get a NEO skill
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-skills/get-get-skill
**Description:** GET /skill/{id}
## `GET /skill/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Skill not found
---
## List NEO skills
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-skills/get-list-skills
**Description:** GET /skill
## `GET /skill`
Returns live (non-deleted) skills. With `?aiAgentId=N`, returns shared skills (`aiAgentId` null) plus that agent's private skills.
### Query parameters
### Responses
**`200`** — Successful operation
**`401`** — Unauthorized
---
## Update a NEO skill
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-skills/patch-update-skill
**Description:** PATCH /skill/{id}
## `PATCH /skill/{id}`
Updates `name`, `description`, `content` and/or `aiAgentId`. `slug` is immutable and ignored. Re-validated via an ephemeral agent; an update snapshot is appended to history.
### Path parameters
### Request body
### Responses
**`200`** — Updated
**`404`** — Skill not found
**`422`** — Invalid skill (validation violations returned)
---
## Create a NEO skill
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/neo-skills/post-create-skill
**Description:** POST /skill
## `POST /skill`
Creates a skill. `slug` is the cortex reference name; it defaults to a slug of `name` and is immutable after creation. `content` is the `skill.md` markdown body. Validated via an ephemeral agent before saving; a create snapshot is appended to the skill history.
### Request body
### Responses
**`201`** — Created
**`400`** — Missing name or invalid slug
**`409`** — A skill with this slug already exists
**`422`** — Invalid skill (validation violations returned)
---
## Delete a role
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/role/delete-delete-role
**Description:** DELETE /roles/{id}
## `DELETE /roles/{id}`
### Path parameters
### Responses
**`200`** — Role deleted successfully
**`403`** — Unauthorized
**`404`** — Role not found
**`500`** — Internal error
---
## Get role by id
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/role/get-get-role
**Description:** GET /roles/{id}
## `GET /roles/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Role not found
**`500`** — Internal error
---
## Get roles
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/role/get-get-roles
**Description:** GET /roles
## `GET /roles`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Update a role
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/role/patch-update-role
**Description:** PATCH /roles/{id}
## `PATCH /roles/{id}`
### Path parameters
### Request body
### Responses
**`200`** — Role updated successfully
**`403`** — Unauthorized
**`404`** — Role not found
**`500`** — Internal error
---
## Add a new role
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/role/post-create-role
**Description:** POST /roles
## `POST /roles`
### Request body
### Responses
**`200`** — Role added successfully
---
## Delete specific profile
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/delete-delete-specific-profile
**Description:** DELETE /profile/{id}
## `DELETE /profile/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get a JWT for a user (browser-friendly)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/get-get-jwt-for-profile
**Description:** GET /jwt/{id}
## `GET /jwt/{id}`
Returns a JWT scoped to the given user. The GET form is intended for browser navigation
during dev / impersonation flows — `POST` is the canonical form used by tooling.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Profile not found
---
## Get profile image
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/get-get-profile-image
**Description:** GET /profile/{id}/image
## `GET /profile/{id}/image`
Returns the profile image for a user. If the user has the permission 'readUserNamesOfNonTeamMates' or the requested user is in the same team, returns the actual image from Auth service. Otherwise returns a stub image.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Image not found
**`500`** — Internal error
---
## Get currently logged in user's profile
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/get-get-profile
**Description:** GET /profile
## `GET /profile`
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Concurrent users + telephony/chat counters (admin polling)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/get-get-profiles-online-summary
**Description:** GET /profiles/onlineSummary
## `GET /profiles/onlineSummary`
Compact summary of users who were active in the last 10 minutes, broken
down by user type, plus current live-call and in-queue counters from ACD
and the number of ongoing chats (open chat tickets with a message in the
last 5 minutes).
Used by the admin portal for concurrent-user monitoring; replaces the
deprecated `?lastSeen=online` summary fast-path on `GET /profiles`.
Requires `readUserLastSeenDate` or `readAnyUserProfile`.
### Responses
**`200`** — Successful operation
**`403`** — Permission denied
**`500`** — Internal error
---
## Search profiles
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/get-get-profiles
**Description:** GET /profiles
## `GET /profiles`
### Query parameters
### Responses
**`200`** — Successful operation
---
## Get specific profile
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/get-get-specific-profile
**Description:** GET /profile/{id}
## `GET /profile/{id}`
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get available options for analytics roles
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/get-get-superset-roles
**Description:** GET /profile/{id}/supersetRoles
## `GET /profile/{id}/supersetRoles`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get special time tracking status options
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/get-get-time-tracking-status-options
**Description:** GET /profile/timeTrackingStatusOptions
## `GET /profile/timeTrackingStatusOptions`
Returns the key time tracking status options configured in the system:
- `active`: First status with autoActiveMode set to true
- `away`: First status with autoAwayMode set to true
- `absent`: First status with both allowTicketDelegation and interactionsBlocked set to true,
or if none exist, the first status with only allowTicketDelegation set to true
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Explain routing priorities for a user
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/get-get-user-routing
**Description:** GET /profile/{id}/routing
## `GET /profile/{id}/routing`
Explain the ticket routing considering the routing priorities. Useful when a user wants to know why they are being pushed a certain ticket.
The response format is controlled by `limit`:
- **`limit=1` (short format)**: returns `{"details":[{"routingPriority":<int|string>,"id":<int>}]}`.
`routingPriority` is an integer when the ticket will be routed to this user, or a localized human-readable string reason when it will not.
An empty `details` array means the ticket is not in the routing queue (closed, AI-only, or non-existent).
- **`limit>1` or default (full format)**: returns full routing metadata including `routingPriority` (ordered ticket IDs), `details` (all fields), `total`, and `query`.
Permission: `updateUserProfileSkills` is required, EXCEPT for a single-ticket self-check —
`limit=1` + numeric `q` (ticket id) + own profile — where the permission check is bypassed.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Ping endpoint to track user activity
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/get-ping-profile
**Description:** GET /profile/ping
## `GET /profile/ping`
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Show the current access token
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/get-show-access-token
**Description:** GET /profile/showAccessToken
## `GET /profile/showAccessToken`
Returns the access token the user is currently using to authenticate. No specific permissions required, the user just needs to be logged in.
### Responses
**`200`** — Successful operation
**`401`** — Not authenticated
**`500`** — Internal error
---
## Bulk-update routing status
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/patch-bulk-update-routing-status
**Description:** PATCH /profiles/routingStatus
## `PATCH /profiles/routingStatus`
Update routing status (calls / chats) for multiple profiles in a single call. The body lists
profile ids and the routing-status object to apply to each.
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Permission denied
---
## Update multiple profiles at once
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/patch-bulk-update-specific-profiles
**Description:** PATCH /profiles
## `PATCH /profiles`
Bulk update multiple user profiles. Each profile update can include settings and auth service fields.
Requires 'updateSpecificProfile' permission. For enneo users, also requires 'enneoAdmin' permission.
### Request body
### Responses
**`200`** — Results of bulk update operation
**`400`** — Invalid request format
**`403`** — Insufficient permissions
---
## Update profile routing status
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/patch-update-routing-status
**Description:** PATCH /profile/{id}/routingStatus
## `PATCH /profile/{id}/routingStatus`
Update the routing status for calls and chats for a specific profile. Necessary to manually control which agents should be able to take calls or chats when integrating a custom telephony solution. Requires having 'updateSpecificProfile' permission.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized - user does not have permission to update this profile's routing status
---
## Update specific profile
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/patch-update-specific-profile
**Description:** PATCH /profile/{id}
## `PATCH /profile/{id}`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Create a new user
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/post-create-specific-profile
**Description:** POST /profile
## `POST /profile`
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Build a polished portrait prompt from four selections
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/post-generate-portrait-prompt
**Description:** POST /profile/generatePortraitPrompt
## `POST /profile/generatePortraitPrompt`
Takes four playful dropdown selections (person, style, mood, setting) and
uses an LLM to turn them into a polished image-generation prompt. The
resulting string is intended to be shown in an editable textarea in the
UI and then submitted to `/profile/generatePortrait`.
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Generate a portrait image from a prompt
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/post-generate-portrait
**Description:** POST /profile/generatePortrait
## `POST /profile/generatePortrait`
Calls the image-generation backend (Grok via the LiteLLM proxy)
using the provided prompt to produce a single 512x512 portrait. The
generated image is fetched into Mind's storage so the response never
leaks the provider URL. Use `/profile/generatePortraitPrompt` first to
build a polished prompt from descriptive selections.
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Missing or empty prompt
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get a JWT for a user
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/profile/post-post-jwt-for-profile
**Description:** POST /jwt/{id}
## `POST /jwt/{id}`
Returns a JWT scoped to the given user. Use this form from tooling; GET exists for browser
access in dev.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Profile not found
---
## Top-performing AI agents across the time window
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/reports/get-get-top-ai-agents-performance
**Description:** GET /report/topAiAgentsPerformance
## `GET /report/topAiAgentsPerformance`
Ranked list of AI agents by execution volume and quality metrics for the requested period.
Powers the "Top AI agents" widget on the reporting dashboard.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
---
## Delete a quality assessment
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality-management/delete-delete-quality-assessment
**Description:** DELETE /quality/assessment/{id}
## `DELETE /quality/assessment/{id}`
Soft-delete a quality assessment. Requires qualityDeleteAssessment permission.
### Path parameters
### Responses
**`200`** — Assessment deleted successfully
**`403`** — Unauthorized (missing qualityDeleteAssessment permission)
**`404`** — Assessment not found
**`500`** — Internal error
---
## Delete a quality scorecard
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality-management/delete-delete-quality-scorecard
**Description:** DELETE /quality/scorecard/{id}
## `DELETE /quality/scorecard/{id}`
Soft-delete a quality scorecard. Requires qualityDeleteScorecard permission.
### Path parameters
### Responses
**`200`** — Scorecard deleted successfully
**`403`** — Unauthorized (missing qualityDeleteScorecard permission)
**`404`** — Scorecard not found
**`500`** — Internal error
---
## Get a specific quality assessment
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality-management/get-get-quality-assessment
**Description:** GET /quality/assessment/{id}
## `GET /quality/assessment/{id}`
Retrieve a quality assessment in full format. User must have permission to view this assessment.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized (no permission to view this assessment)
**`404`** — Assessment not found
**`500`** — Internal error
---
## Get a specific quality scorecard
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality-management/get-get-quality-scorecard
**Description:** GET /quality/scorecard/{id}
## `GET /quality/scorecard/{id}`
Retrieve full details of a quality scorecard by ID
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Scorecard not found
**`500`** — Internal error
---
## Get all worklogs for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality-management/get-get-ticket-worklogs
**Description:** GET /ticket/{ticketId}/worklog
## `GET /ticket/{ticketId}/worklog`
Retrieve all worklog entries associated with a specific ticket, including their linked assessments and detailed worklog information.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## List quality assessments
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality-management/get-list-quality-assessments
**Description:** GET /quality/assessment
## `GET /quality/assessment`
Get a list of quality assessments with optional filters. Respects view permissions.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## List quality scorecards
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality-management/get-list-quality-scorecards
**Description:** GET /quality/scorecard
## `GET /quality/scorecard`
Get a list of all quality scorecards with optional state filter
### Query parameters
### Responses
**`200`** — List of quality scorecards
**`403`** — Unauthorized
**`500`** — Internal error
---
## Check if Live Quality Coach is configured for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality-management/get-ticket-quality-exists
**Description:** GET /ticket/{ticketId}/quality/exists
## `GET /ticket/{ticketId}/quality/exists`
Fast pre-flight check used by the FE to decide whether to expose the Live Quality
Coach Check action in the answer panel. Returns `exists: true` when at least one
applicable scorecard has `liveCoach.enabled=true` AND has at least one AI-evaluable
criterion (i.e. running `quality/check` would actually return a result).
Does not call cortex.
### Path parameters
### Responses
**`200`** — Live coach availability for this ticket
**`404`** — Ticket not found
---
## Update a quality assessment
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality-management/patch-update-quality-assessment
**Description:** PATCH /quality/assessment/{id}
## `PATCH /quality/assessment/{id}`
Update an assessment including scores, reasons, supervisor notes, and dates.
User must have permission to edit this assessment (qualityDoAssessmentsTeam or qualityDoAssessmentsAll).
Automatically transitions state from aiReady to reviewOngoing when edits are made.
### Path parameters
### Request body
### Responses
**`200`** — Assessment updated successfully
**`403`** — Unauthorized (no permission to edit this assessment)
**`404`** — Assessment not found
**`500`** — Internal error
---
## Update a quality scorecard
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality-management/patch-update-quality-scorecard
**Description:** PATCH /quality/scorecard/{id}
## `PATCH /quality/scorecard/{id}`
Update an existing quality scorecard. Requires qualityManageScorecards permission.
### Path parameters
### Request body
### Responses
**`200`** — Scorecard updated successfully
**`403`** — Unauthorized
**`404`** — Scorecard not found
**`500`** — Internal error
---
## Create a new quality scorecard
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality-management/post-create-quality-scorecard
**Description:** POST /quality/scorecard
## `POST /quality/scorecard`
Creates a new quality scorecard. Requires qualityManageScorecards permission.
### Request body
Provide the complete scorecard payload as JSON.
### Responses
**`200`** — Scorecard created successfully
**`400`** — Bad request (e.g., missing required fields)
**`403`** — Unauthorized (missing qualityManageScorecards permission)
**`500`** — Internal error
---
## Re-run AI processing for a quality assessment
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality-management/post-refresh-quality-assessment
**Description:** POST /quality/assessment/{id}/refresh
## `POST /quality/assessment/{id}/refresh`
Re-runs the AI processing of an existing assessment, regenerating AI-scored criteria
and the AI summary.
By default, the assessment is upgraded to the latest active scorecard revision
(resolved by `baseId`). To pin processing to a specific revision, pass `scorecardId`
in the request body — it must belong to the same scorecard family (same `baseId`)
as the assessment's current revision.
The user must have permission to edit this assessment. Cannot be called when the
assessment is in `discussedWithAssessee` or `reviewedBySupervisor` state.
### Path parameters
### Request body
### Responses
**`200`** — Assessment re-processed successfully
**`400`** — Assessment is in a state that does not allow re-running AI processing, or the requested scorecard revision belongs to a different scorecard
**`403`** — Unauthorized (no permission to edit this assessment)
**`404`** — Assessment not found
**`500`** — Internal error
---
## Live Quality Coach check on a draft reply
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/quality-management/post-ticket-quality-check
**Description:** POST /ticket/{ticketId}/quality/check
## `POST /ticket/{ticketId}/quality/check`
Score an unsent draft reply against every applicable scorecard whose
`liveCoach.enabled` is true. Nothing is persisted. Used by the Quality Coach
panel to render live scores per scorecard.
One ticket may match multiple live-enabled scorecards (e.g. Compliance, Empathy,
Tone) — every match is scored and returned in `scorecards`, ordered by
`scorecardId` ascending so the FE can rely on positional rendering.
Scorecards without any AI-evaluable criteria are silently skipped. When no
applicable scorecard has Live Coach enabled for this ticket, `scorecards` is empty.
Either every applicable scorecard is scored successfully, or — if cortex fails on
any of them — the whole request fails with 502; no partial results are returned.
### Path parameters
### Request body
### Responses
**`200`** — Live coach evaluation results
**`400`** — Missing or invalid `draftText`, or requested `scorecardId` is not active
**`404`** — Requested explicit `scorecardId` does not exist
**`502`** — Cortex evaluation endpoint unreachable or returned a validation error for one of
the scorecards. The error message includes the scorecard name that failed.
---
## Delete an event hook
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/delete-delete-event-hook
**Description:** DELETE /settings/event-hook/{id}
## `DELETE /settings/event-hook/{id}`
### Path parameters
### Responses
**`200`** — Deleted
**`404`** — Event hook not found
---
## Delete a Subchannel
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/delete-delete-subchannel
**Description:** DELETE /settings/subchannel/{id}
## `DELETE /settings/subchannel/{id}`
### Path parameters
### Responses
**`200`** — Subchannel deleted successfully
**`403`** — Unauthorized
**`500`** — Internal error
---
## Delete a User Defined Function
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/delete-delete-user-defined-function
**Description:** DELETE /settings/user-defined-function/{id}
## `DELETE /settings/user-defined-function/{id}`
### Path parameters
### Responses
**`200`** — User Defined Function deleted successfully
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get a single setting by name
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-get-setting
**Description:** GET /settings/{name}
## `GET /settings/{name}`
### Path parameters
### Query parameters
### Responses
**`200`** — The requested setting object.
**`403`** — Unauthorized
**`404`** — Setting not found
**`500`** — Internal error
---
## Get settings of a client in a grouped way for a category
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-get-settings-category
**Description:** GET /settings/category/{category}
## `GET /settings/category/{category}`
### Path parameters
### Responses
**`200`** — List of client-specific configruation settings.
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get settings of a client and return the results in a compact form
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-get-settings-compact
**Description:** GET /settings/compact
## `GET /settings/compact`
### Query parameters
### Responses
**`200`** — List of client-specific configruation settings in a compact key-value format.
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get UI overview of settings sections
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-get-settings-ui-overview
**Description:** GET /settings/uiOverview
## `GET /settings/uiOverview`
Returns the sections-and-categories tree that powers the Settings landing page in ops-fe.
The response is filtered by the caller's permissions: categories whose `requiredPermissions`
/ `requiredPermissionsAny` don't match are omitted. Labels are translated to the caller's
locale.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized — missing `settingsUiOverview` permission
---
## Get settings of a client
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-get-settings
**Description:** GET /settings
## `GET /settings`
### Query parameters
### Responses
**`200`** — List of client-specific configruation settings.
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get Subchannels
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-get-subchannels
**Description:** GET /settings/subchannel
## `GET /settings/subchannel`
A subchannel is a further differentiation of the channel, and is - For emails, they are the mailboxes, e.g. support@enneo.ai and sales@enneo.ai - For chat, they are the chatbots, e.g. the chatbot on the website and the chatbot on the customer portal - For voice, they are the phone numbers, e.g. the phone number for support and the phone number for sales.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get User Defined Functions
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-get-user-defined-functions
**Description:** GET /settings/user-defined-function
## `GET /settings/user-defined-function`
A user-defined function (UDF) is a function that you can define yourself and use in your queries. It is a way to extend the functionality of the database.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Callback for Google authorization
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-google-authorization-callback
**Description:** GET /settings/mailbox/google/authorization/callback
## `GET /settings/mailbox/google/authorization/callback`
Google OAuth callback. Persists the issued tokens against the mailbox subchannel.
### Query parameters
### Responses
**`302`** — Redirect to the post-callback success page
**`400`** — Bad request
**`403`** — Unauthorized
---
## Redirect to Google authorization page
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-google-authorization
**Description:** GET /settings/mailbox/google/authorization
## `GET /settings/mailbox/google/authorization`
Starts the OAuth flow for the Google (Gmail) mailbox integration.
### Responses
**`302`** — Redirect to Google authorization page
**`400`** — Bad request
**`403`** — Unauthorized
---
## List event hooks
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-list-event-hooks
**Description:** GET /settings/event-hook
## `GET /settings/event-hook`
Returns all event hooks (outbound webhooks fired on Mind events) configured for this client.
### Responses
**`200`** — Successful operation
---
## Callback for Microsoft authorization
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-microsoft-authorization-callback
**Description:** GET /settings/mailbox/microsoft/authorization/callback
## `GET /settings/mailbox/microsoft/authorization/callback`
### Responses
**`200`** — Operation successful
**`302`** — Redirect to /success page
**`400`** — Bad request
**`403`** — Unauthorized
---
## Redirect to Microsoft authorization page
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-microsoft-authorization
**Description:** GET /settings/mailbox/microsoft/authorization
## `GET /settings/mailbox/microsoft/authorization`
### Responses
**`200`** — Operation successful
**`302`** — Redirect to Microsoft authorization page
**`400`** — Bad request
**`403`** — Unauthorized
---
## Redirect to Microsoft Graph authorization page
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-microsoft-graph-authorization
**Description:** GET /settings/mailbox/microsoft/graph/authorization
## `GET /settings/mailbox/microsoft/graph/authorization`
Starts the OAuth flow for the modern Microsoft Graph mailbox integration (`/api/mind/settings/mailbox/microsoft/graph/...`).
The user is redirected to Microsoft to grant Graph mailbox scopes; on success Microsoft calls
back to `microsoftGraphCallback`.
### Responses
**`302`** — Redirect to Microsoft authorization page
**`400`** — Bad request
**`403`** — Unauthorized
---
## Callback for Microsoft Graph authorization
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-microsoft-graph-callback
**Description:** GET /settings/mailbox/microsoft/graph/callback
## `GET /settings/mailbox/microsoft/graph/callback`
Microsoft Graph OAuth callback. Persists the issued tokens against the mailbox subchannel.
### Query parameters
### Responses
**`302`** — Redirect to the post-callback success page
**`400`** — Bad request — missing or invalid code
**`403`** — Unauthorized
---
## Search settings
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-search-settings
**Description:** GET /settings/search
## `GET /settings/search`
Search through settings by name, description, or category
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Bad request - No search term provided
**`403`** — Unauthorized
**`500`** — Internal error
---
## Test receive on a mailbox subchannel
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/get-test-receive-mailbox
**Description:** GET /settings/mailbox/{subchannelId}/test/receive
## `GET /settings/mailbox/{subchannelId}/test/receive`
Triggers a one-off mailbox fetch for the given subchannel to verify that authentication and
mailbox connectivity are working. Returns the count and metadata of messages that would be
pulled, but does not persist them as tickets.
### Path parameters
### Responses
**`200`** — Operation successful
**`400`** — Bad request
**`403`** — Unauthorized
**`500`** — Internal error
---
## Create an event hook
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/post-create-event-hook
**Description:** POST /settings/event-hook
## `POST /settings/event-hook`
Create a new outbound event hook bound to one or more Mind events.
### Request body
### Responses
**`200`** — Created
**`403`** — Unauthorized
---
## Add a new Subchannel
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/post-create-subchannel
**Description:** POST /settings/subchannel
## `POST /settings/subchannel`
### Request body
The new Subchannel that should be created. The ID does not need to be included in the payload, as it will be generated automatically.
### Responses
**`200`** — Subchannel added successfully
**`403`** — Unauthorized
**`500`** — Internal error
---
## Add a new User Defined Function
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/post-create-user-defined-function
**Description:** POST /settings/user-defined-function
## `POST /settings/user-defined-function`
### Request body
The new User Defined Function that should be created. The ID does not need to be included in the payload, as it will be generated automatically.
### Responses
**`200`** — User Defined Function added successfully
**`403`** — Unauthorized
**`500`** — Internal error
---
## Update multiple settings at once
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/post-update-settings
**Description:** POST /settings
## `POST /settings`
Update multiple settings in a single request.
**Special setting formats:**
- Tag properties: Use `_tag[{id}].{property}` format (e.g., `_tag[123].name`, `_tag[456].visibility`)
- See Tag schema for available properties
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Update setting
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/settings/put-update-setting
**Description:** PUT /settings/{name}
## `PUT /settings/{name}`
Update a single setting value.
**Special setting formats:**
- Tag properties: Use `_tag[{id}].{property}` format (e.g., `_tag[123].name`, `_tag[123].visibility`)
- See Tag schema for available properties
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get file from storage
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/storage/get-get-file-from-storage
**Description:** GET /storage/{path}
## `GET /storage/{path}`
### Path parameters
### Responses
**`200`** — Binary file
**`403`** — Unauthorized
**`404`** — File not found
**`500`** — Internal error
---
## Get a file from the tmp namespace
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/storage/get-get-tmp-file-from-storage
**Description:** GET /storage/tmp/{path}
## `GET /storage/tmp/{path}`
Returns a file from the short-lived `tmp/` namespace in storage. The tmp namespace is used
for files that are produced server-side and immediately offered for download (e.g. generated
exports). Files there expire after a short TTL.
### Path parameters
### Responses
**`200`** — Binary file
**`404`** — File not found or expired
---
## Test storage
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/storage/get-test-storage
**Description:** GET /storage/test
## `GET /storage/test`
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Upload a file
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/storage/post-upload-storage-file
**Description:** POST /storage
## `POST /storage`
Upload a file to storage. The body is sent as `multipart/form-data`.
### Responses
**`200`** — Successful operation
**`400`** — Missing file
**`403`** — Unauthorized
---
## Delete a team
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/team/delete-delete-team
**Description:** DELETE /team/{id}
## `DELETE /team/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get team by id
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/team/get-get-team-by-id
**Description:** GET /team/{id}
## `GET /team/{id}`
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get all teams
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/team/get-get-team-list
**Description:** GET /team/list
## `GET /team/list`
### Query parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get all teams
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/team/get-get-teams
**Description:** GET /team/tree
## `GET /team/tree`
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Update a team
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/team/patch-update-team
**Description:** PATCH /team/{id}
## `PATCH /team/{id}`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Create a new team
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/team/post-create-team
**Description:** POST /team
## `POST /team`
### Request body
### Responses
**`200`** — Created
**`500`** — Internal error
---
## Delete a Tag
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/tag/delete-delete-tag
**Description:** DELETE /tag/{id}
## `DELETE /tag/{id}`
### Path parameters
### Responses
**`200`** — Tag deleted successfully
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get tag tree structure
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/tag/get-get-tag-tree
**Description:** GET /tag/tree
## `GET /tag/tree`
Retrieve a hierarchical tree structure of all tags
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get a Tag
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/tag/get-get-tag
**Description:** GET /tag/{id}
## `GET /tag/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Tag not found
**`500`** — Internal error
---
## List all tags
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/tag/get-list-all-tags
**Description:** GET /tag
## `GET /tag`
Get all tags (skills, products, brands) available
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Add a new tag
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/tag/post-create-tag
**Description:** POST /tag
## `POST /tag`
### Request body
The new tag that should be created. The only mandatory parameters are name, refernce and type. If the other parameters are not provided, they will revert to defaults.
### Responses
**`200`** — Tag added successfully
**`403`** — Unauthorized
**`500`** — Internal error
---
## Detect a Tag
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/tag/post-detect-tag
**Description:** POST /tag/{id}/detect
## `POST /tag/{id}/detect`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Tag not found
**`500`** — Internal error
---
## Delete a template
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/template/delete-delete-template
**Description:** DELETE /template/{id}
## `DELETE /template/{id}`
Soft-deletes the template. Requires the `manageTemplates` permission.
### Responses
**`200`** — Template deleted successfully
**`400`** — Template cannot be deleted (e.g., used as generic template)
**`403`** — Unauthorized / missing permission
**`404`** — Template not found
**`500`** — Internal error
---
## Get template details
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/template/get-get-template
**Description:** GET /template/{id}
## `GET /template/{id}`
Returns the template including the underlying generic wrapper and merged HTML. Example ticket IDs are filtered to existing tickets.
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Template not found
**`500`** — Internal error
---
## List response templates
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/template/get-list-templates
**Description:** GET /template
## `GET /template`
Returns the paginated list of response templates that agents can insert into tickets. When no template matches the provided filters the API responds with HTTP 404.
### Query parameters
### Responses
**`200`** — Templates found
**`403`** — Unauthorized
**`404`** — No templates match the provided filters
**`500`** — Internal error
---
## Update a template
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/template/patch-update-template
**Description:** PATCH /template/{id}
## `PATCH /template/{id}`
Requires the `manageTemplates` permission.
### Request body
### Responses
**`200`** — Template updated successfully
**`400`** — Validation error
**`403`** — Unauthorized / missing permission
**`404`** — Template not found
**`500`** — Internal error
---
## Create a response template
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/template/post-create-template
**Description:** POST /template
## `POST /template`
Requires the `manageTemplates` permission.
### Request body
### Responses
**`200`** — Template created successfully
**`400`** — Validation error (e.g., invalid handlebars syntax)
**`403`** — Unauthorized / missing permission
**`500`** — Internal error
---
## Preview a template with ticket data
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/template/post-preview-template
**Description:** POST /template/preview
## `POST /template/preview`
Renders a template fragment using the optional ticket or contract data. When `ticketId` is provided, AI extracted intent data is injected before rendering. The response returns HTML with `<br>` tags to preserve formatting in downstream clients.
### Request body
### Responses
**`200`** — Template preview rendered successfully
**`400`** — Invalid template or missing required data
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get ACD configuration
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/telephony/get-get-acd-config
**Description:** GET /telephony/acd/config
## `GET /telephony/acd/config`
Returns configuration for the ACD microservice including:
- ACD-enabled phone channels with their workflows
- SIP trunk configurations
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Get routing status
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/telephony/get-get-routing
**Description:** GET /telephony/getRouting
## `GET /telephony/getRouting`
Returns the routing status of a specific ticket in the routing queue.
### Query parameters
### Responses
**`200`** — Successful operation
**`400`** — Invalid input - missing required parameters
**`403`** — Unauthorized
**`404`** — Queue entry not found
**`500`** — Internal error
---
## Get routing availability for all users
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/telephony/get-routing-availability
**Description:** GET /telephony/routingAvailability
## `GET /telephony/routingAvailability`
Returns the routing availability for all users. Used by a dispatcher to check which agents are currently available to pick up a ticket.
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized - user does not have permission to read user status
**`500`** — Internal error
---
## Test outbound call
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/telephony/get-test-outbound-call
**Description:** GET /telephony/testOutboundCall
## `GET /telephony/testOutboundCall`
Makes a test outbound call using configured settings. Used for testing the telephony integration.
### Responses
**`200`** — Successful operation
**`400`** — Invalid input or missing settings
**`401`** — Unauthorized
**`500`** — Internal error
---
## Call received
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/telephony/post-call-received
**Description:** POST /telephony/callReceived
## `POST /telephony/callReceived`
Called when a call is received (inbound) or initiated (outbound).
For inbound calls (direction=in, default): creates a ticket, attempts customer identification from phone number, and returns the ticket ID. Routing happens later via getRouting.
For outbound calls (direction=out): creates a ticket, creates a queue entry (no routing needed), and links customer/contract data if available. Requires 'to'. No human initiator is required — the call can be fully autonomous/callflow-driven. If a human initiator is provided ('agentId'/'userId'), they are set to 'interacting' and the ticket is assigned to them. For bot/callflow-driven calls with no human on the line, omit 'agentId'/'userId' — presence is not touched and the queue is created as Unknown (out of routing).
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid input
**`500`** — Internal error
---
## Complete call and store transcript
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/telephony/post-complete-call
**Description:** POST /telephony/callCompleted
## `POST /telephony/callCompleted`
Called when a call is completed to store the final transcript and call details
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid input
**`404`** — Ticket not found
**`500`** — Internal error
---
## Connect agent to call
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/telephony/post-connect-agent-to-call
**Description:** POST /telephony/agentConnected
## `POST /telephony/agentConnected`
Called whenever the telephony system has connected a agent (user) with a call that was previously sent to enneo via the /telephony/callReceived endpoint. Upon receiept, the specified agent's browser window is then redirected to the previously created ticket id (specified via ticket id or channel id)
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid input
**`404`** — Ticket not found
**`500`** — Internal error
---
## Test outbound call (POST)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/telephony/post-test-outbound-call-post
**Description:** POST /telephony/testOutboundCall
## `POST /telephony/testOutboundCall`
Same as `GET /telephony/testOutboundCall`, but accepts a JSON body to override the configured target phone number or subchannel.
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid input or missing settings
**`401`** — Unauthorized
**`500`** — Internal error
---
## AuthSync webhook
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/webhook/post-auth-sync-webhook
**Description:** POST /webhook/authSync
## `POST /webhook/authSync`
Sync auth data from auth.users to mind.users
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Contract not found
**`500`** — Internal error
---
## Trigger mailbox fetch
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/webhook/post-fetch-emails-webhook
**Description:** POST /webhook/fetchEmails/{subchannelId}
## `POST /webhook/fetchEmails/{subchannelId}`
External trigger that asks Mind to poll the given mailbox subchannel for new messages and
convert them into tickets. Without `subchannelId` all configured mailboxes are polled.
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Lynqtech webhook
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/webhook/post-lynqtech-webhook
**Description:** POST /webhook/lynqtech
## `POST /webhook/lynqtech`
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Contract not found
**`500`** — Internal error
---
## PowerCloud webhook
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/webhook/post-power-cloud-webhook
**Description:** POST /webhook/powercloud
## `POST /webhook/powercloud`
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Firecrawl webhook receiver
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/webhook/post-website-connector-webhook
**Description:** POST /webhook/websiteConnector/{id}
## `POST /webhook/websiteConnector/{id}`
Receives crawl events from Firecrawl. Authenticated via x-webhook-token header (per-connector secret).
Handles crawl.page (upsert/delete pages), crawl.completed, and crawl.failed events.
### Path parameters
### Request body
### Responses
**`200`** — Event processed
**`401`** — Invalid webhook token
**`404`** — Connector not found
---
## Delete a website connector
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/website-connector/delete-delete-website-connector
**Description:** DELETE /knowledgeSource/websiteConnector/{id}
## `DELETE /knowledgeSource/websiteConnector/{id}`
Cancels any active crawl, soft-deletes all child pages (with knowledgeSourceChanged events), and marks the connector as deleted.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Connector not found
**`500`** — Internal error
---
## Get a website connector
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/website-connector/get-get-website-connector
**Description:** GET /knowledgeSource/websiteConnector/{id}
## `GET /knowledgeSource/websiteConnector/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Connector not found
**`500`** — Internal error
---
## List website connectors
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/website-connector/get-get-website-connectors
**Description:** GET /knowledgeSource/websiteConnector
## `GET /knowledgeSource/websiteConnector`
Returns all website connectors (excluding deleted ones). Each connector includes its page count and data (with webhookSecret removed).
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Update a website connector
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/website-connector/patch-update-website-connector
**Description:** PATCH /knowledgeSource/websiteConnector/{id}
## `PATCH /knowledgeSource/websiteConnector/{id}`
Updates a website connector. The `excludePaths` field has three mutually compatible inputs:
- `excludePaths` — full replace (operator-edit form).
- `addExcludePaths` — append to the current excludePaths (set-union, deduped server-side).
- `removeExcludePaths` — remove from the current excludePaths (set-difference).
`excludePaths` is **mutually exclusive** with `addExcludePaths`/`removeExcludePaths` —
sending both in the same request returns 422. `addExcludePaths` and `removeExcludePaths`
can be combined in one request (add applied first, then remove).
Whenever excludePaths actually changes, Mind diffs old-vs-new and emits
`knowledgeSourceChanged` events: `delete` for newly-matching pages (now excluded),
`create` for newly-unmatching pages (now included). This keeps Cortex's Weaviate index
in sync immediately rather than waiting for the next periodic resync.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`404`** — Connector not found
**`422`** — Invalid frequency value, or excludePaths combined with addExcludePaths/removeExcludePaths
**`500`** — Internal error
---
## Create a website connector
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/website-connector/post-create-website-connector
**Description:** POST /knowledgeSource/websiteConnector
## `POST /knowledgeSource/websiteConnector`
Creates a new website connector with the given URL and configuration. Generates a webhook secret automatically.
### Request body
### Responses
**`200`** — Created
**`422`** — Validation error (missing URL or unconfigured webhook URL)
**`500`** — Internal error
---
## Trigger a crawl
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/website-connector/post-start-website-connector-crawl
**Description:** POST /knowledgeSource/websiteConnector/{id}/crawl
## `POST /knowledgeSource/websiteConnector/{id}/crawl`
Triggers a Firecrawl crawl for the specified connector. Resets crawl stats and sets status to running.
### Path parameters
### Responses
**`200`** — Crawl started
**`404`** — Connector not found
**`422`** — Firecrawl settings not configured
**`500`** — Internal error
---
## Stop a running crawl
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/website-connector/post-stop-website-connector-crawl
**Description:** POST /knowledgeSource/websiteConnector/{id}/stop
## `POST /knowledgeSource/websiteConnector/{id}/stop`
Cancels the active Firecrawl job and sets the connector status to idle.
### Path parameters
### Responses
**`200`** — Crawl stopped
**`404`** — Connector not found
**`500`** — Internal error
---
## GDPR-clean attachment deletion
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/delete-delete-ticket-attachment
**Description:** DELETE /ticket/{ticketId}/attachment/{attachmentId}
## `DELETE /ticket/{ticketId}/attachment/{attachmentId}`
Permanently removes a single attachment from a ticket or its conversations:
deletes the S3 object, the `files` row, and strips the entry from the
ticket/conversation `attachments` JSON.
The attachment is identified by its numeric `id` field inside the JSON array.
Search covers both ticket-level and conversation-level attachments.
Requires the `updateTechnicalTicketFields` permission (admin / role 1 only).
This action is irreversible.
### Path parameters
### Responses
**`200`** — Attachment deleted successfully
**`403`** — Unauthorized — requires updateTechnicalTicketFields permission
**`404`** — Ticket or attachment not found
**`500`** — Internal error
---
## GDPR-clean ticket deletion
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/delete-delete-ticket
**Description:** DELETE /ticket/{ticketId}
## `DELETE /ticket/{ticketId}`
Permanently deletes a ticket and **all** associated data: conversations,
intents, tag links, queue entries, quality assessments, surveys, reminders,
reporting rows, worklog, time-tracking, S3 attachments, and `files` rows.
Requires the `deleteTicket` permission (admin / role 1 only).
This action is irreversible.
### Path parameters
### Responses
**`200`** — Ticket deleted successfully
**`403`** — Unauthorized — requires deleteTicket permission
**`404`** — Ticket not found
**`500`** — Internal error
---
## Get ticket activity
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/get-get-ticket-activity
**Description:** GET /ticket/{ticketId}/activity
## `GET /ticket/{ticketId}/activity`
Get ticket activity by ticketId
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Get a tickets history
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/get-get-ticket-history
**Description:** GET /ticket/{ticketId}/history
## `GET /ticket/{ticketId}/history`
Get a history of created tickets and other relevant actions from a customer/contract
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Get ticket stats
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/get-get-ticket-stats
**Description:** GET /ticket/stats
## `GET /ticket/stats`
### Responses
**`200`** — Successful operation
---
## Get ticket variables
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/get-get-ticket-variables
**Description:** GET /ticket/{ticketId}/variables
## `GET /ticket/{ticketId}/variables`
Get ticket variables by ticketId
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Get a ticket (full data)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/get-get-ticket
**Description:** GET /ticket/{ticketId}
## `GET /ticket/{ticketId}`
Get a single ticket by ticketId with FULL data.
Unlike POST /ticket/search (which returns compact data), this endpoint includes:
- body, bodyPlain, bodyClean (full content)
- attachments (complete list)
- intents (full details)
- template (email template)
- workitem (for system tickets only)
- customer (full object with all properties)
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Ping a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/get-ping-ticket
**Description:** GET /ticket/{ticketId}/ping
## `GET /ticket/{ticketId}/ping`
Ping a ticket to keep time tracking for agent and to refresh the list of
currently-active agents on this ticket. The FE polls this every 30s and
uses `workedOnBy` to overwrite its cached list, so the "another agent
is working on this ticket" warning becomes two-sided (both the first and
the second agent see it).
### Path parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Update a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/patch-update-ticket
**Description:** PATCH /ticket/{ticketId}
## `PATCH /ticket/{ticketId}`
Update a ticket by ticketId
### Path parameters
### Query parameters
### Request body
A JSON object containing changes
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Update a few tickets at once
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/patch-update-tickets
**Description:** PATCH /ticket
## `PATCH /ticket`
Update a few tickets at once.
**Tags handling:**
- Use `tagIds` to replace all tags
- Use `addTagIds`/`removeTagIds` to modify existing tags
- Cannot combine `tagIds` with `addTagIds`/`removeTagIds`
**Special flags:**
- `refreshMode`: Schedule a selective AI re-run (`full`, `summaryAndText`, `customer`, `tags`, `agents`). Skips saving and webhooks.
- `refresh` (deprecated — use `refreshMode=full`): Skips saving and webhooks, used for refreshing data without changes.
- `refreshTags` (deprecated — use `refreshMode=tags`): Performs only AI tag detection (faster), skips saving and webhooks.
### Query parameters
### Request body
A JSON object containing changes
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Auto-execute a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/post-auto-execute-ticket
**Description:** POST /ticket/{ticketId}/autoexecute
## `POST /ticket/{ticketId}/autoexecute`
Automatically process a ticket that was previously marked as auto-executable. Optionally, specify an AI agent to force-execute even if the agent is not configured for auto-execution.
### Path parameters
### Query parameters
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Create a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/post-create-ticket
**Description:** POST /ticket
## `POST /ticket`
Create a new ticket.
Required fields:
- channel (only required field!)
Auto-generated if not provided:
- direction (default: 'in')
- status (default: 'open')
- priority (default: 'low')
- interface (default: 'internal')
- to, ccEmails, bccEmails (default: [])
- createdAt (default: current timestamp)
- aiSupportLevel (default: 'unprocessed')
- id (auto-generated by database)
Agent assignment:
- If `agentId` is set in the request, it is used as-is.
- Otherwise the ticket is auto-assigned to the calling profile only when the `lastAgentRouting` setting is enabled AND the caller is a human profile (`user`, `enneo`, or `enneoPartner`). Service workers, code executors, and system users never trigger auto-assignment.
- When `lastAgentRouting` is disabled, the ticket stays unassigned regardless of direction.
### Query parameters
### Request body
Ticket object to create
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`500`** — Internal error
---
## Forward a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/post-forward-ticket
**Description:** POST /ticket/{ticketId}/forward
## `POST /ticket/{ticketId}/forward`
Forward a ticket to free typed email address
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Get next ticket id to work on
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/post-get-latest-ticket
**Description:** POST /ticket/getLatest
## `POST /ticket/getLatest`
### Request body
Parameters for getting the next ticket
### Responses
**`200`** — Successful operation
---
## Get a list of tickets
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/post-get-tickets
**Description:** POST /ticket/search
## `POST /ticket/search`
Get a list of tickets in compact format for performance.
⚠️ IMPORTANT: This endpoint returns a COMPACT version of tickets. The following fields are EXCLUDED from the response:
- body, bodyPlain, bodyClean
- attachments
- template
- workitem
Also note:
- customer: Only includes {tagIds: [], tags: []} structure, NOT the full customer object
- `ticketScope=skills` activates routing context: spam tickets (`spamStatus` in `auto_spam`, `auto_programmatic`, `manual_spam`) are excluded automatically. Backlog spam filter (both whitelist `in`): spam → those statuses; not spam → `null`, `auto_clean`, `manual_clean`.
To get the full ticket data including these fields, use GET /ticket/{id}.
### Request body
Search parameters for tickets
### Responses
**`200`** — Successful operation
**`403`** — Unauthorized
**`404`** — Ticket not found
**`500`** — Internal error
---
## Apply an AI-driven text transformation
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket/post-ticket-text-update
**Description:** POST /ticket/textUpdate
## `POST /ticket/textUpdate`
Runs an AI text-modification operation on the supplied text and returns the transformed result.
Used by ops-fe's compose box (rephrase, shorten, translate, …).
### Request body
### Responses
**`200`** — Successful operation
**`400`** — Invalid input
**`403`** — Unauthorized
**`500`** — Internal error
---
## Delete a knowledge source structure
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/wiki-knowledge-source-structure/delete-delete-knowledge-source-structure
**Description:** DELETE /knowledgeSourceStructure/{id}
## `DELETE /knowledgeSourceStructure/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get the knowledge source structure
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/wiki-knowledge-source-structure/get-get-knowledge-source-structure
**Description:** GET /knowledgeSourceStructure
## `GET /knowledgeSourceStructure`
Returns the knowledge source structure tree. By default, website tree nodes whose `source` URL
matches the parent connector's `sourceConfig.excludePaths` (`fnmatch` patterns) are omitted —
this is the sidebar view. Pass `withExcluded=true` to include those nodes (each website
node then carries `excluded: true|false`); used by the connector configuration view.
### Query parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Create a new knowledge source structure
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/wiki-knowledge-source-structure/post-create-knowledge-source-structure
**Description:** POST /knowledgeSourceStructure
## `POST /knowledgeSourceStructure`
### Request body
### Responses
**`200`** — Created
**`500`** — Internal error
---
## Set team ACL for a structure node
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/wiki-knowledge-source-structure/put-set-knowledge-source-structure-teams
**Description:** PUT /knowledgeSourceStructure/{id}/teams
## `PUT /knowledgeSourceStructure/{id}/teams`
Replace-set the team access list for a structure node (folder, file-connector root,
or website connector — any type). Passing an empty array removes all restrictions
and makes the node visible to everyone. When non-empty, only users whose
`actualTeamIds` intersect with this list (or users with no teams at all) can see
the node and all its descendants.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`404`** — Structure node not found
**`500`** — Internal error
---
## Update a knowledge source structure
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/wiki-knowledge-source-structure/put-update-knowledge-source-structure
**Description:** PUT /knowledgeSourceStructure/{id}
## `PUT /knowledgeSourceStructure/{id}`
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get AI insights for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket-ai-insights/get-get-ticket-ai-insights
**Description:** GET /ticket/{ticketId}/aiInsight
## `GET /ticket/{ticketId}/aiInsight`
Active questions of the ticket's subchannel, each paired with its stored insight (or `null`).
### Path parameters
### Responses
**`200`** — Question + insight pairs
**`404`** — Ticket not found
---
## Manually re-run AI insights for a ticket
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/ticket-ai-insights/post-refresh-ticket-ai-insights
**Description:** POST /ticket/{ticketId}/aiInsight/refresh
## `POST /ticket/{ticketId}/aiInsight/refresh`
### Path parameters
### Responses
**`200`** — Refresh scheduled
**`400`** — No active questions or system channel
**`403`** — Unauthorized
**`404`** — Ticket not found
---
## Delete knowledgeSource
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/wiki-knowledge-source/delete-delete-knowledge-source
**Description:** DELETE /knowledgeSource/{id}
## `DELETE /knowledgeSource/{id}`
### Path parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Get archived knowledge sources
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/wiki-knowledge-source/get-get-archived-knowledge-sources
**Description:** GET /knowledgeSource/archived
## `GET /knowledgeSource/archived`
Retrieves a paginated list of archived knowledge sources
### Query parameters
### Responses
**`200`** — Successful operation
**`401`** — Unauthorized
**`403`** — Forbidden - User doesn't have the 'viewArchivedKnowledge' permission
---
## Get knowledgeSource by id
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/wiki-knowledge-source/get-get-knowledge-source-by-id
**Description:** GET /knowledgeSource/{id}
## `GET /knowledgeSource/{id}`
Returns a single knowledge source. **Excluded website pages** (whose source URL matches the
parent connector's `sourceConfig.excludePaths`) return `404 Not Found` — this matches the
bulk list filter so Cortex sync stays consistent.
### Path parameters
### Responses
**`200`** — Successful operation
**`404`** — Not found, or the page is an excluded website page
**`500`** — Internal error
---
## Get knowledgeSource
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/wiki-knowledge-source/get-get-knowledge-source
**Description:** GET /knowledgeSource
## `GET /knowledgeSource`
Returns a list of knowledge sources. **Excluded website pages** (whose source URL matches
the parent connector's `sourceConfig.excludePaths`) are filtered out of the response —
this is required so Cortex's `sync_knowledge_base` does not re-index excluded pages.
**Folder listing** (`parent` present): paginated. `limit` defaults to 50, maximum 500.
Response includes `total`, `offset`, and `limit` for cursor-free pagination.
**Global / search** (`parent` absent, or `q` present): not paginated. `limit` defaults
to 1000 and is not capped. `total`/`offset`/`limit` are not returned.
### Query parameters
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Update knowledgeSource
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/wiki-knowledge-source/patch-update-knowledge-source
**Description:** PATCH /knowledgeSource/{id}
## `PATCH /knowledgeSource/{id}`
For file-type rows (uploaded via the files connector) only `name`, `status`, and `text`
are accepted — other fields return 422. Editing `text` sets `data.hasManualMarkdownEdits = true`
so the FE can warn before a re-upload would overwrite manual edits. The `embeddingHash`
is intentionally NOT recomputed on text-only edits — it represents the parse hash of the
original binary and stays stable until a real reindex / replace.
Website-type pages cannot be edited through this endpoint.
**Teams (per-article ACL):** sending `teams: [1,2]` replaces the full team-restriction set;
omitting `teams` entirely leaves the existing set unchanged. An empty array (`teams: []`)
removes all restrictions and makes the article visible to everyone.
### Path parameters
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Create knowledgeSource
**URL:** https://richard-dev-playground.enneo.ai/docs/en/api-reference/wiki-knowledge-source/post-create-knowledge-source
**Description:** POST /knowledgeSource
## `POST /knowledgeSource`
### Request body
### Responses
**`200`** — Successful operation
**`500`** — Internal error
---
## Apps
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/apps/apps-overview
**Description:** Creating and integrating your own HTML applications in Enneo
## Overview
Apps are custom applications that return **HTML** and are displayed directly in Enneo as their own page.
Each app runs in a sandbox and has access to the Enneo API.
**Typical use cases:**
- **Individual Dashboards** — visualize real-time data from the ERP or CRM
- **Reports and evaluations** — tailor-made reports with own logic
- **Internal tools** — forms, calculators or workflow helpers
- **Data queries** — display contract data, customer status or statistics
## App Structure
Each App consists of:
| Component | Description |
|---|---|
| **Name** | Display name in the sidebar and in the settings |
| **Slug** | Unique technical identifier (e.g., `my-dashboard`). Used in the URL |
| **Description** | Optional description of the purpose of the App |
| **Provider** | Optional: Who has created the App |
| **Executor** | The code that is executed when called (Python, Node.js or PHP) |
### Executor
The executor uses Enneo's standard executor format (same structure as for settings and AI agents).
It currently supports the **Source code** type with the languages Python 3.11, Node.js 20 and PHP 8.2.
The output to `stdout` is returned as HTML to the browser.
### Input Parameters
With each call, the code automatically receives metadata as a parameter via STDIN:
```json
{
"_metadata": {
"userId": 1,
"clientId": "1",
"appId": "a1b2c3d4-...",
"appRevision": 3,
"userAuthToken": "Bearer ..."
}
}
```
Additional GET or POST parameters are automatically passed on and are available in the code.
### Environment Variables
The following environment variables are available in the app code:
| Variable | Description |
|---|---|
| `ENNEO_API_URL` | Base URL of the Enneo API |
| `ENNEO_SESSION_TOKEN` | Session token for API calls |
| `ENNEO_USER_AUTH_HEADER` | Auth Header of the calling user |
| `ENNEO_APP_ID` | UUID of the App |
| `ENNEO_APP_SLUG` | Slug of the App |
| `ENNEO_APP_VERSION` | Version of the App (e.g., `1.0.0`) |
| `SDK` | Path to the SDK file |
## Using Apps
### Sidebar
As soon as at least one app exists and the user has the `readApps` permission, the menu item **Apps** appears
in the sidebar. All available apps are displayed as tabs here.
The app-url in the browser uses the **Slug** of the app:
```
/apps/my-dashboard
```
### Call App
Each app runs in an iFrame inside of Enneo. The API URL accepts both UUID and Slug:
```
/api/mind/app/{slug}/run
/api/mind/app/{appId}/run
```
GET parameters can be directly appended:
```
/api/mind/app/my-dashboard/run?param1=value1¶m2=value2
```
## App Storage
Apps can store and read persistent data. The **App Storage** is a key-value store,
which is isolated per app. The values are stored as JSON.
### SDK Access
### App Info
The `AppInfo` class can be used to retrieve app metadata:
### Supported Value Types
| Type | Example |
|---|---|
| String | `"hello world"` |
| Number | `42`, `3.14` |
| Boolean | `true`, `false` |
| Null | `null` |
| Object | `{"key": "value"}` |
| Array | `[1, "two", 3.0]` |
## Manage Apps
Management is under **Settings → Advanced Settings → Apps**.
### Create New App
1. Navigate to **Settings → Apps**
2. Click on **Create App**
3. Enter name, slug and optional description
4. Write the executor code
5. Use the **Preview** to check the output
6. Click on **Save**
### Edit App
Each change automatically creates a new **Revision**. This way, you can always revert to a
previous version.
Unsaved changes are indicated by a **Draft** tag in the sidebar.
A warning will appear when navigating with unsaved changes.
### Export and Import
Apps can be exported and imported as JSON. The export button is located
in the **Specifications** tab. This allows for transfer between environments.
### Revisions and Rollback
Apps support versioning:
- Each save creates a new revision
- Through the revisions overview, you can revert to any previous version
- The active revision is displayed to the users
## Permissions
| Permission | Description | Standard Roles |
|---|---|---|
| `readApps` | View and run Apps | Admin, Agent |
| `appCreator` | Create, edit and preview Apps | Admin |
| `manageApps` | Import and delete Apps | Admin |
## Examples
### Dashboard with Contract data
```python
# Load SDK
file_path = os.getenv('SDK', 'sdk.py')
spec = importlib.util.spec_from_file_location('sdk', file_path)
sdk = importlib.util.module_from_spec(spec)
spec.loader.exec_module(sdk)
# Load input data
input_data = sdk.load_input_data()
metadata = input_data.get('_metadata', {})
# Load contract data (example)
contract_id = input_data.get('contractId', '715559')
try:
contract = sdk.ApiEnneo.get_contract(contract_id)
name = f"{contract.get('firstname', '')} {contract.get('lastname', '')}"
status = contract.get('status', 'Unknown')
except Exception:
name = "Not found"
status = "-"
# Output HTML
print(f"""
""")
```
### App with Persistent Counter
```python
file_path = os.getenv('SDK', 'sdk.py')
spec = importlib.util.spec_from_file_location('sdk', file_path)
sdk = importlib.util.module_from_spec(spec)
spec.loader.exec_module(sdk)
input_data = sdk.load_input_data()
# Load the counter from the App Storage
try:
counter = sdk.AppStorage.get("page_views")
except Exception:
counter = 0
# Increase and save the counter
counter += 1
sdk.AppStorage.save("page_views", counter)
print(f"""
Visitor Counter
This page has been visited {counter} times.
The value is stored in the App Storage and remains persistent across page loads.
""")
```
### Static Info Page
```python
print("""
Important Information
Service times: Mon-Fri, 8:00 AM - 6:00 PM
Note: Maintenance work planned for the weekend.
""")
```
## API Reference
### App Management
| Method | Endpoint | Description |
|---|---|---|
| `GET` | `/api/mind/app` | List all apps |
| `POST` | `/api/mind/app` | Create new app |
| `GET` | `/api/mind/app/{appId}` | Retrieve app details (UUID or Slug) |
| `PATCH` | `/api/mind/app/{appId}` | Update app (new revision) |
| `DELETE` | `/api/mind/app/{appId}` | Delete app |
| `GET` | `/api/mind/app/{appId}/revisions` | Show all revisions |
| `POST` | `/api/mind/app/{appId}/rollback/{revision}` | Rollback to revision |
| `POST` | `/api/mind/app/{appId}/preview` | Execute preview |
| `POST` | `/api/mind/app/import` | Import app |
| `GET/POST` | `/api/mind/app/{appId}/run` | Execute app (HTML-Response) |
### App Storage
| Method | Endpoint | Description |
|---|---|---|
| `GET` | `/api/mind/app/{appId}/data` | List all keys |
| `GET` | `/api/mind/app/{appId}/data/{key}` | Read value |
| `GET` | `/api/mind/app/{appId}/data/{key}/meta` | Read value with metadata |
| `PUT` | `/api/mind/app/{appId}/data/{key}` | Save/update value |
| `DELETE` | `/api/mind/app/{appId}/data/{key}` | Delete key |
All endpoints accept both the app UUID and the slug as `{appId}`.
### Data Format (executorUser)
The executor object in `data.executorUser` follows the standard executor format:
```json
{
"id": 1,
"code": "print('
Hello
')",
"type": "sourceCode",
"language": "python311",
"packages": null,
"parameters": [],
"parameterDefinitions": []
}
```
---
## Chat (Bot)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/integration-of-contact-channels/chat-bot
**Description:** Chat (Bot)
---
## Chat (Human)
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/integration-of-contact-channels/chat-human
**Description:** Chat (Human)
---
## Chat
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/integration-of-contact-channels/chat
**Description:** Options and Configuration
## Chatbot Configuration
Multiple Chatbots can be created and configured under **Settings → Chat**. Each Chatbot has its own settings like Name, Welcome Message, and Appearance.
### Assignment to AI Agent
Each Chatbot is associated with an **AI Agent**. This agent provides the initial prompt based on which the chat conversation takes place. The **Basic-Agent** is used by default.
## Integration on the Website
The chat widget is integrated on the desired website through a JavaScript code:
```html
```
Replace `[your-domain]` with your Enneo domain and `[your-subchannelid]` with the ID of your Chatbot.
##########################################################################
## Chatbot Configuration
Multiple Chatbots can be created and configured under **Settings → Chat**. Each Chatbot has unique settings for Name, Status, Appearance, AI agent, Homepage, and Widget Integration.
### General Settings
The general settings determine how the chatbot will appear in the chat window:
- **Internal Label** — Name of the bot within Enneo.
- **Status** — controls whether the chatbot is active, inactive or erroneous.
- **Name and Avatar of the Chatbot** — displayed to customers in the chat.
- **Name and Avatar of the Agent** — used when a human agent replies.
- **Company Name and Logo** — appear on the chat home page and in the chat window.
### Assignment to AI Agent
Each chatbot is associated with an **AI Agent**. This agent handles the initial communication with the customer. The **Basic-Agent** is used as the default setting.
### Transfer to Human Agents
For Chatbots, it can be set whether a **transfer to human agents** is possible.
If the transfer is enabled, the chatbot can hand over to a human agent if needed. In addition, the **real-time chat with human agents** can be activated:
- If the real-time chat is enabled, an open chat ticket is created during a handover, which can be taken over manually by an agent.
- If the real-time chat is disabled or the customer is no longer online, the concern will be processed asynchronously. If an e-mail address is known, the answer can also be delivered by e-mail.
### Customer Legitimation in Chat
Chatbots can use their own rules for **customer legitimization**. This allows each chatbot to specify which information a customer must provide before the chatbot or called AI agents receive access to customer data.
If no specific rules are defined, the general settings under **Customer and Contract Search** apply for Chatbot and Voicebot.
## Home Page of the Chat Widget
The chat widget has a configurable home page. There, customers can either start a free chat, choose a frequent concern, or continue an existing conversation.
### Free Chat
Title, description, and introduction messages can be configured for the free chat. The introduction messages are automatically displayed as soon as the customer starts the chat.
### Quick Actions / Frequent Concerns
In addition, **Quick Actions** can be stored. These appear on the home page as selectable concerns, such as "modify bank details".
For each quick action, the following can, among others, be specified:
- Title of the action,
- optionally an associated AI Agent or intent,
- own introduction messages for this start.
This allows a chat to be started directly with a suitable context or specific concern.
### Continue Existing Chats
The widget can display the last existing conversation. This allows customers to reopen and continue an already started chat.
## Appearance
The design of the chat widget can be adjusted for each chatbot:
- Primary color of the chat window,
- Secondary color for buttons,
- Text color on the home page,
- Roundings of the chat window,
- Logo, Bot Avatar, and Agent Avatar.
## Integration on the Website
The chat widget is integrated onto the desired website through a JavaScript code. You can find the finished code in the settings of the respective chatbot under **"Widget Code"**.
```html
```
Replace [your-domain] with your Enneo domain and [your-subchannelid] with the ID of your Chatbot.
### Widget Enable or Disable
The chat widget can be turned on or off via the Widget active setting. If the widget is disabled, it will not be displayed on the website - even if the JavaScript code is still integrated.
---
## Contact Channels
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/integration-of-contact-channels/contact-channels-overview
**Description:** Functional overview and starting points
## Supported Channels in Enneo
Enneo supports three primary communication channels:
| Channel | Interaction Model | Typical Use | Special Features |
|---|---|---|---|
| **Email / Letter** | asynchronous | written communication, documents, feedback | classic entry channels for service centres |
| **Chat** | Real-time / asynchronous | Live chat, Self-service, Assistance through chatbot | directly addresses end customers on the web or in apps |
| **Voice** | Real-time | Telephony, Advice, Voice dialogues | supports telephony and voice bots |
All channels use the same processing logic (ticketing, routing, automation) but differ in terms of interaction, response time, and configuration.
## Functional Principle
Regardless of the channel, the process follows the same principle:
1. Message or call comes in
2. Enneo creates or updates a ticket
3. Routing decides on target team or processor
4. Processing takes place manually or by AI agents
Thus, the technical basis of all channels is identical, and configurations can be done uniformly across channels.
## Dependencies and Requirements
The operation of a channel usually requires consideration of the following aspects:
- Existing communication infrastructure (Email, Telephony, Chat)
- Permissions and routing rules
- Visibility for agents and teams
- Linking of customer data (for context-related processing)
- Optional AI agents for automation
Activation occurs per channel, while the technical logic remains system-wide consistent.
## Which Channel First?
In projects, the introduction typically starts with Email, as written entry channels are often already present and do not require additional infrastructure. Chat and Voice can be added at any time and follow the same integration model.
The choice of the first channel is project-related and depends on:
- Existing input communication
- Expected volumes
- Desired types of interaction (real-time or asynchronous)
- Technical infrastructure
## Further Configuration
The detailed configuration steps are different for each channel. The following sections describe the technical integration paths:
- [Email](/docs/en/system-integration/integration-of-contact-channels/email)
- [Letter](/docs/en/system-integration/integration-of-contact-channels/mail)
- [Chat](/docs/en/system-integration/integration-of-contact-channels/chat)
- [Voice](/docs/en/system-integration/integration-of-contact-channels/voice)
---
## Email
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/integration-of-contact-channels/email
**Description:** Options and Configuration
### **IMAP**
The IMAP integration retrieves emails from an IMAP mail server and sends them via it. Enneo supports an unlimited number of mailboxes, allowing multiple email accounts to be connected and all emails to be centrally managed. Whether private and professional mailboxes or multiple accounts for different projects - with the IMAP integration, all emails can be comfortably organized in one place.
The IMAP integration ensures a smooth experience when managing emails. Emails can be read, replied to, and organized, similar to an email client. By linking multiple mailboxes, all communication is bundled, and switching between different email accounts is eliminated.
### **API**
The Enneo API and the `/ticket` endpoints enable the creation and editing of emails. This option offers a seamless two-way synchronization between Enneo and existing ticket systems. The API not only allows retrieving and sending emails but also triggering and receiving webhooks to ensure the synchronization of email communication with other systems.
The API integration offers a higher level of customization and automation. Emails can be programmatically created and managed and seamlessly integrated into existing workflows. This option is particularly suitable for companies that use two ticket systems in parallel, for example, during a testing phase. Changes made in Enneo or another ticket system are synchronized on both platforms thanks to the two-way synchronization, ensuring consistent and up-to-date communication.
Here is an example of a request:
```bash
curl --location 'https://demo.enneo.ai/api/mind/ticket' \
--header 'Authorization: bearer ' \
--data-raw '{
"fromName": "Customer Service",
"process": "batch",
"from": "support@enneo.ai",
"to": [
"eugene@enneo.ai"
],
"priority": "medium",
"channel": "email",
"status": "open",
"subject": "Subject",
"body": "Body New",
"direction": "in",
"firstResponseDueBy": "2024-01-01 00:00:00",
"dueBy": "2024-01-01 00:00:00",
"tags": [
54
],
"contractId": 781506,
"attachments": [
{
"name": "myattachment.png",
"url": "https://www.enneo.ai/wp-content/uploads/2022/11/Frame.png"
}
]
}'
```
Further details on the relevant `/ticket` endpoints, including the parameters, can be found here:
[**API Documentation**](/docs/en/api-reference/introduction)
### OAuth-based Connection (Microsoft 365)
In addition to the classic IMAP or API connection, mailboxes can also be directly connected via OAuth.
The setup is carried out via a one-time authorization and subsequently enables automatic sending and receipt of emails via Enneo.
Setup steps:
* Select Microsoft 365 as the method.
* Deposit the email address of the mailbox.
* Click on "Connect Account" and complete the registration process with the relevant provider.
* After successful authorization, the access token and refresh token are automatically filled in.
* The configuration can be checked with "Test Email Receipt".
#### Frequently Asked Questions (FAQ)
---
## Address Format Validation
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/integration-of-contact-channels/mail-address-validation
**Description:** Addresses in Enneo must have a specific format to ensure that outgoing mail can be correctly delivered
## Overview
This guide explains the address formats supported by the system. Addresses must include a valid postal code followed by a city name on the same line to ensure proper validation.
## General Address Structure
- Rule 1: Must have between 3 and 5 lines
- Rule 2: The last or penultimate line must contain a valid postal code followed by a city name
### Typical Structure of a Complete Address
#### 3-line Format (Minimum)
```
[Name]
[Street Number]
[Postal Code] [City]
```
Example:
```
Max Mustermann
Main Street 123
10115 Berlin
```
#### 4-line Format
```
[Recipient Name/Company]
[Street Number]
[Postal Code] [City]
[Country]
```
Example:
```
Max Mustermann
Main Street 123
10115 Berlin
Germany
```
```
ABC LLC
Attention: Max Mustermann
Main Street 123
10115 Berlin
```
#### 5-line Format (Maximum)
```
[Recipient Name]
[Company/Department]
[Street Number]
[Postal Code] [City]
[Country]
```
Example:
```
Max Mustermann
Example LLC
Main Street 123
10115 Berlin
Germany
```
### Requirements for the Postal Code Line
The line that contains the postal code must adhere to this format:
```
[Postal Code] [City Name]
```
The postal code must be followed by at least one space and then the city name.
## Supported Postal Code Formats by Country/Region
### Europe
#### The Netherlands
- **Format**: 4 digits + 2 letters (with or without space)
- **Examples**:
- `1234 AB Amsterdam`
- `1234AB Amsterdam`
#### United Kingdom
- **Format**: UK postal code (various formats)
- **Examples**:
- `SW1A 1AA London`
- `SW1A1AA London`
- `M1 1AA Manchester`
- `B33 8TH Birmingham`
- `CR2 6XH Croydon`
- `DN55 1PT Doncaster`
#### Germany, France, Spain, Italy, Finland, Luxembourg
- **Format**: 5 digits
- **Examples**:
- `10115 Berlin`
- `75001 Paris`
- `28001 Madrid`
- `00100 Roma`
- `00100 Helsinki`
#### Belgium, Switzerland, Austria, Denmark, Norway
- **Format**: 4 digits
- **Examples**:
- `1000 Brussels`
- `8000 Zurich`
- `1010 Vienna`
- `1050 Copenhagen`
- `0150 Oslo`
#### Portugal
- **Format**: 4 digits - 3 digits
- **Examples**:
- `1000-001 Lisbon`
- `4000-001 Porto`
#### Poland
- **Format**: 2 digits - 3 digits
- **Examples**:
- `00-001 Warsaw`
- `30-001 Krakow`
#### Sweden, Czech Republic
- **Format**: 3 digits [space] 2 digits
- **Examples**:
- `123 45 Stockholm`
- `110 00 Prague`
#### Ireland
- **Format**: Letter + 2 digits [space] 4 alphanumeric characters (Eircode)
- **Examples**:
- `D02 AF30 Dublin`
- `A65 F4E2 Galway`
### America
#### United States
- **Format**: 5 digits or 5 digits - 4 digits (ZIP+4)
- **Examples**:
- `10001 New York`
- `90210 Beverly Hills`
- `10001-0001 New York`
#### Canada
- **Format**: 5 digits (like the USA)
- **Examples**:
- `10001 Toronto`
- `90001 Vancouver`
#### Brazil
- **Format**: 5 digits - 3 digits (CEP)
- **Examples**:
- `01310-100 São Paulo`
- `20040-020 Rio de Janeiro`
### Asia
#### Japan
- **Format**: 3 digits - 4 digits
- **Examples**:
- `100-0001 Tokyo`
- `530-0001 Osaka`
#### India
- **Format**: 6 digits (PIN Code)
- **Examples**:
- `110001 Delhi`
- `400001 Mumbai`
#### China
- **Format**: 6 digits
- **Examples**:
- `100000 Beijing`
- `200000 Shanghai`
### Oceania
#### Australia, New Zealand
- **Format**: 4 digits
- **Examples**:
- `2000 Sydney`
- `3000 Melbourne`
- `1010 Auckland`
### Africa
#### South Africa
- **Format**: 4 digits
- **Examples**:
- `0001 Pretoria`
- `8001 Cape Town`
### Russia
- **Format**: 6 digits
- **Examples**:
- `101000 Moscow`
- `190000 Saint Petersburg`
## Important Notes
### General Requirements
1. Should a comma exist in the address line, e.g. "Max Mustermann, Marina Mustermann" or "Max Mustermann, ABC-St. 1," a comma is replaced with a new line - so please use a comma accordingly
2. Empty lines will be deleted
### Postal Code-Specific Requirements
1. **Spaces**: There must be at least one space before the city name after the postal code
2. **City Name Required**: After the postal code, a city name (or any text without spaces) must follow
3. **Capitalization**: For formats with letters (UK, Netherlands, Ireland), capital letters are expected
4. **Complete Lines**: The entire post code and the city must be on the same line
## Invalid Examples
### Invalid Postal Code Lines
❌ `12345` - City name missing
❌ `12345 ` - Only spaces after the postal code
❌ `Berlin 10115` - City before postal code
❌ `1234ab Amsterdam` - Lowercase letters (Netherlands)
❌ `sw1a 1aa London` - Lowercase letters (UK)
### Invalid Complete Addresses
❌ Too few lines (only 2 lines):
```
Main Street 123
10115 Berlin
```
❌ Too many lines (6 lines):
```
Mr.
Max Mustermann
Example LLC
IT Department
Main Street 123
10115 Berlin
```
❌ Empty lines within the address:
```
Max Mustermann
Main Street 123
10115 Berlin
Germany
```
❌ No postal code line:
```
Max Mustermann
Main Street 123
Germany
```
## Valid Examples
### Valid Postal Code Lines
✅ `10115 Berlin`
✅ `SW1A 1AA London`
✅ `1234 AB Amsterdam`
✅ `75001 Paris`
✅ `10001-0001 New York`
✅ `100-0001 Tokyo`
✅ `D02 AF30 Dublin`
---
## Letter
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/integration-of-contact-channels/mail
**Description:** Options and Configuration
Just like emails, letters in Enneo can also be connected in two ways, depending on the requirements: IMAP and API.
## Receiving Letters
### Option 1: Importing letters as emails with attachments
This solution is recommended if a scanning service is used that converts incoming letters into emails with the letters as an attachment (e.g., PDF).
The following steps are necessary to connect letters:
1. Connect the mailbox as described here: [Connect Emails](/docs/de/system-integration/integration-of-contact-channels/email)
2. Ensure that the emails are recognized as letters. Enneo recognizes an email as a letter if the following criteria are met:
- The sender of the email is the scanning service. The email address of the sender can be specified in the letter settings.
- The subject of the email contains only the word "LETTER". If you prefer a different keyword, this can be adapted in the letter settings.
### Option 2: Importing letters via the REST API
1. When importing letters via the API, the `channel` attribute must be set to "letter". Enneo does the rest.
2. An example of a request with minimal parameters:
```bash
curl --location ˋhttps://demo.enneo.ai/api/mind/ticket' \
--header 'Authorization: bearer ' \
--data '{
"channel": "letter",
"process": "batch",
"attachments": [
{
"base64": "base-64-encoded-string-of-pdf-or-image-file",
}
]
}
```
**Notes:**
- The `process` parameter can be set to `batch` (default), `realtime`, or `false`. In all cases the API response returns immediately after the ticket is saved — AI processing runs in the background. The difference is *when* it starts: with `batch` the ticket is queued and picked up by the next available worker; with `realtime` AI processing is triggered immediately in its own background process, without waiting in the queue — useful when a ticket should be processed as soon as possible; with `false` the ticket is created without any AI processing.
- Attachments can either be uploaded as base64-encoded files via the `base64` parameter or provided via a URL with the `url` parameter.
- All ticket attributes defined in the API specification can also be specified. This is useful for transmitting metadata such as a contract ID, tags, or a creation date.
### Supported file formats
Enneo supports the automatic conversion of attachments in the following formats:
- PDF
- PNG
- JPG
- TIFF
## Sending letters
Enneo delivers a JSON object with the relevant information such as receiver, subject and text content, when a letter is to be shipped, to your usercode. From there, you can call a printing service of your choice via API.
This is configured under Settings -> Letters -> (Select mailbox) -> Webhooks -> Send letter.
Here is example code for sending letters:
## Validation of Postal Addresses
Enneo validates postal addresses to prevent letters from being sent to invalid addresses and returned as return post. These are described here: [Address Validation](/docs/de/system-integration/integration-of-contact-channels/mail-address-validation)
## Using Addresses Stored in ERP
Instead of the sender identified by AI, Enneo can also reply to a postal address you have stored. For this, the variable `letterAddress` must be set in the [Response Format of the Contract Data](/docs/de/system-integration/customer-recognition/search-by-contract-number), e.g. `"letterAddress": "Laura Ludwig, Main Street 29, 20249 Hamburg"`.
---
## Telephone
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/integration-of-contact-channels/telephone
**Description:** Telephone
---
## Voice
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/integration-of-contact-channels/voice
**Description:** Options and Configuration
## Call-Flow
Each switched line has its own **Call-Flow**, which can be individually configured. In the Call-Flow, any combination of features can be used, including:
- **Voicebots** for automated voice dialogues
- **Employee telephony** for forwarding to agents
- **External forwarding** to external phone numbers
- **Switchboards**, e.g. based on dates like working hours
- **Announcements**, e.g. tape announcements or other texts
## Phone Numbers
Two options are available for telephony:
| Option | Description |
|---|---|
| **Enneo SIP-Trunk** | Numbers provided by Enneo, ready to use immediately |
| **Own SIP-Trunk** | Use of own phone numbers, e.g. via Sipgate |
### Setting up your own phone numbers
If using your own phone numbers, the following steps are required in this order:
1. **Set up SIP-Trunk** – Store your own SIP-Trunk in the telephony settings
2. **Add phone numbers** – Assign the desired numbers to the SIP-Trunk
3. **Assign numbers to lines** – Assign the phone numbers to the appropriate lines
## Requirements for Agent Telephony
In order for employees to be able to use Enneo for telephony, the following conditions must be met:
## Firewall Settings
For users telephoning via Enneo, the following network connections must be released:
| Host | IP Address | Port | Protocol | Purpose |
|---|---|---|---|---|
| `turn1.enneo.ai` | `91.99.219.69` | 3478 | UDP | TURN |
| `turn1.enneo.ai` | `91.99.219.69` | 5349 | TCP | TURNS |
| `turn1.enneo.ai` | `91.99.219.69` | 32769–65535 | UDP | Media |
---
## Concept of Events in Enneo
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/events/concept-of-events-in-enneo
**Description:** Design efficient processes and create intelligent automations with Enneo's Event Architecture
### Process Integration
Events in Enneo enable an efficient and automated customer service that responds to different events. This allows existing systems and workflows to be seamlessly integrated.
### Asynchronous Reaction to Events
Through custom configuration, customer-specific code can react asynchronously to events. This enables a reaction to triggered events without interrupting the main process. Actions such as forwarding data to analysis or reporting tools or synchronization with other ticket systems can be automated.
### Configuration of Events
Event-based integrations can be configured in the settings area under **Settings -> Integration into surrounding systems -> Events**. The following events are available:
* **AutoProcessIntent**: The AI agent of the ticket is automatically processed.
* **ConversationCreated**: The agent responded with a message or an internal note.
* **CronDay**: Triggered every Monday to Friday at 2 am (0 2 * * 1-5).
* **CronHour**: Triggered every hour at the first minute (1 * * * *).
* **CronMinute**: Triggered every 5 minutes on weekdays (\*/5 * * * 1-5).
* **CronWeek**: Triggered every Saturday at 2 am (0 2 * * 6).
* **EmailAutoresponder**: An automatic response is sent to the customer, informing them of receipt of their email.
* **NotifySurroundingSystems**: Add notifications to surrounding systems.
* **ProfileCreated**: A new user profile was created in the system.
* **ProfileDeleted**: A user profile was deleted from the system.
* **ProfileUpdated**: A user profile was updated, e.g. the name, settings or other properties were changed.
* **SendEmail**: Sends an email to the customer with a specified template and data.
* **TestTicketAiQuality**: Conducts a quality check of the AI on the ticket.
* **TicketClosedDueToInactivity**: A ticket was closed due to inactivity.
* **TicketCreated**: A new ticket was received and AI processing completed.
* **TicketForwarded**: The agent forwarded the ticket to another email address or subchannel.
* **TicketResponse**: A response to a ticket thread from an external party (not the agent) was received.
* **TicketRouted**: A ticket was forwarded to an agent via the Enneo routing system.
* **TicketUpdated**: A ticket property was updated by an agent, e.g. it was assigned to a user or the status was changed.
After selecting an event, the handling can be defined via the corresponding configuration. Depending on the scenario, the choice can be made between executing customer-specific code and an API call. API calls from third-party systems are also possible with the customer-specific code.
* **Customer-specific code**: Allows the execution of user-defined scripts that respond to the specific event. Within this code, API calls can be integrated to interact with third-party systems. The Enneo SDK can be used in the code.
* **API call**: Offers the option to execute a direct API call to seamlessly communicate with other systems and improve integration.
The parameter definition can be used to determine which properties of the event are used in the code or in the API call.
To better understand the data structure of the events, it is helpful to examine them using the example of tickets:
1. Open a ticket.
2. Click on **Ticket details** in the top right.
3. Select **Activity Log**.
4. Click on **Show technical information**.
After clicking, the events and the data they contain are displayed, which allows a better understanding of the available properties of an event.
### Application Examples
* **Analysis & Reporting:** Configurations can be created that automatically send data to the preferred analysis tool at certain events. This ensures that the latest data is always available.
* **Ticket System Synchronization:** The synchronization with other ticket systems can be automated to ensure that all teams are on the same page and no request is lost.
---
## Concept of Webhooks in Enneo
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/events/concept-of-webhooks-in-enneo
**Description:** Influencing Enneo processes in real time with Webhooks
In addition to events that allow asynchronous processing, Enneo also offers Webhooks that support synchronous
processing of processes. Webhooks are particularly useful when it comes to influencing the process flow in
real time and directly integrating external systems.
### Webhooks for email receipt / dispatch
With webhooks, your own code or external APIs can be called as soon as certain events occur,
for example when an email is received or sent. The request is synchronous, meaning in case of a failure,
the user will be notified.
To enable webhooks for email events, go to the settings section under **Communication channels**
-> **Email accounts**, select an email account, and activate the **Webhooks** switch.
Then, two types of webhooks can be defined:
- **Webhook for Ticket Updates:** It is called when properties of a ticket change, for example,
status (open/closed), priority, deadline, assignment, etc.
- **Webhook for new Emails:** It is called for each incoming or outgoing email, as well as for internal
notes. If the email is a reply to an existing one or is outgoing, the `conversationId` field is set,
otherwise it is `null`.
### Webhooks in the Area of ERP Integration
By integrating webhooks, external APIs can be connected to query customer data live.
Whenever Enneo needs customer data, the request is forwarded via the configured custom code to the stored API.
Enneo also stores queries between requests.
Configuration is done under **Settings** -> **Integration of surrounding systems** -> **ERP Integration**.
The following types of webhooks are available:
- **Search contract by ID:** Enneo can search for contracts based on the contract ID. This webhook is used
to load the contract data.
- **Search customer by ID:** Enneo can search for customers based on the customer ID. This webhook is used
to load the customer data.
- **Characteristic-based search of contracts:** Enneo can search for contracts based on specific features.
This code is executed when the Enneo AI identifies certain characteristics, such as names or addresses in customer communication,
and searches for contracts based on these.
- **Free text search of customers:** Enneo allows the search for customers using a free text search. This code is
executed when agents use the free text search bar at the top right.
---
## Example: Processing Multiple AI Agents and/or Sequential Responses in the Background
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/events/example-auto-execute-on-customer-reply
**Description:** Approach for automatic execution of multiple AI Agents and/or in case of sequential customer responses
### Scenario
By default, Enneo carries out the automatic execution (background processing) of AI agents only for the first incoming email of a ticket and only when exactly one AI agent has been identified. The standard background processing therefore does not apply in two situations:
1. **Multiple AI Agents Recognized:** A customer raises multiple concerns in one email, e.g., a cancellation and a revocation. Enneo recognizes both AI agents, but for security reasons does not automatically execute either.
2. **Sequential Replies:** A customer replies again to an existing ticket. AI processing does occur (tags, AI agent recognition, parameter extraction), but automatic execution is not triggered again.
In both cases, the ticket is instead assigned to a human processor. This behavior can be adjusted using an Event Hook.
### Possible Solution
An Event Hook responds to incoming tickets or customer responses, checks the recognized AI agents, and triggers the automatic execution for each one.
### Step 1: Create an Event Hook
Under **Settings -> External System Integration -> Events**, create one or both of the following Event Hooks:
- **TicketCreated** — is triggered after receiving a new ticket and the completion of AI processing. Use when multiple AI agents on the initial email should be automatically executed.
- **TicketResponse** — is triggered when a response to an existing ticket has been received from the customer and AI processing has been completed. Use when AI agents should also be automatically executed in the case of sequential responses.
The following code can be used for both events. It loads all recognized AI Agents (Intents) in `ready` status and executes each one individually:
```
POST /api/mind/ticket/:ticketId/autoexecute?executeAgentId=:aiAgentId&allowMultipleIntents=true&allowWithReplies=true
```
### Step 2: Automatic Processing by Enneo
After each call to the Autoexecute endpoint, Enneo automatically performs the following steps:
1. The customer is sent the reply created by the AI agent.
2. The ticket is closed.
3. The ticket is marked as having been processed fully automatically (L5).
In the case of multiple AI agents, each is executed separately and the results are processed sequentially.
### Notes
- The **TicketCreated** event is suitable for the initial email with multiple issues. The **TicketResponse** event is suitable for sequential responses. Both events can be configured simultaneously with the same code.
- The `allowWithReplies=true` parameter is necessary because Enneo by default blocks automatic execution as soon as a customer response exists on the ticket. For the **TicketCreated** event, this parameter is ineffective as there are not yet any responses.
- The `allowMultipleIntents=true` parameter is necessary because without it, execution is rejected for security reasons when multiple agents are identified.
- The `executeAgentId` parameter ensures that only the desired AI agent is executed per call.
- It is recommended to maintain a whitelist (`allowedAgentIds`) of the AI agents that are allowed for automatic execution in the code.
---
## Example: Automate Smart AI Agents
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/events/example-auto-execute-smart-agents
**Description:** Approach to automatically execute smart AI agents based on your own security criteria
### Scenario
By default, Enneo processes rule-based AI agents per dark processing for emails and letters, but not purely prompt-based ones. The reason is that the reliability of text produced purely by AI is less predictable than that of a rule value.
However, there are certain customer inquiries – e.g. password reset instructions or login problems with the Android or Apple app – which can be fully automated with a certain level of reliability. Instead of using the standard dark processing, the smart AI agent itself should decide whether an answer is secure enough to be sent automatically.
### Possible Solution
The approach consists of four steps: A custom AI tool marks safe answers, an Event Hook checks the marking and triggers the automatic execution.
### Step 1: Create Custom AI Tool
Under **Settings -> AI Customization -> AI Tools**, create a new tool, e.g. with the name `mark_answer_as_safe`. This tool will be invoked by the smart AI agent when it is confident that the answer can be sent automatically.
In the smart AI Agent's prompt, there must be a reference to the tool, e.g.:
> The following types of inquiries should be marked as safe: (a) Password reset or (b) Login problems with the Android or Apple app. In these cases, invoke the `mark_answer_as_safe` tool.
### Step 2: Mark Ticket in Tool as Automatically Executable
In the `mark_answer_as_safe` tool's code, the ticket is marked as automatically executable via the API, for example with the following code:
### Step 3: Create Event Hook for TicketCreated
Under **Settings -> System Integration -> Events**, create a new Event Hook for the Event **TicketCreated**. This event is triggered after a new ticket has been received and the AI processing has been completed.
The customer-specific code checks whether the ticket has been marked as safe. If needed, additional checks can be performed, e.g. whether certain tags are set or the customer has been clearly identified.
If all criteria are met, the automatic execution is triggered:
```
POST /api/mind/ticket/:ticketId/autoexecute?executeAgentId=:aiAgentId
```
The `executeAgentId` parameter is the numeric ID of the AI agent that should be executed. All other potentially recognized AI agents are ignored.
### Step 4: Automatic Processing by Enneo
After calling the Autoexecute endpoint, Enneo automatically carries out the following steps:
1. The answer created by the AI agent is sent to the customer.
2. The ticket is closed.
3. The ticket is marked as fully automated processing (L5).
---
## Example: Data Export for Reporting
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/events/example-data-export-for-reporting
**Description:** Transmission of data to a reporting system using an example
### Scenario
Assume that there is a reporting system in which the status information for tickets from Enneo are to be displayed. The third-party system has a technical interface (API), through which the information about the tickets can be transmitted. The third-party system requires as input parameters when calling the interface, the sender of the ticket and the status of the ticket.
### Possible Solution
Each status change of a ticket triggers a "TicketUpdated" event. To configure this process, go to **Settings -> Integration into Other Systems -> Events** and create a new event hook by selecting the "TicketUpdated" event. The configuration process can then begin.
### Viewing the Data in the Event
The data provided in the event can be viewed on one of the tickets. Here is an example of the data:
```json
{
"userId": 123,
"changes": {
"status": "closed"
},
"ticketId": 456
}
```
In this case, the ticket with the ID 456 was closed by the user with the ID 123.
### Example of Customer-Specific Code
If the data available in the event is not sufficient, further data can be loaded in the customer-specific code with the help of the Enneo SDK.
Configured input parameters are loaded by Enneo and are available in the Input variable. A valid JSON\_object is expected as output, which is displayed after execution in the technical details of the activity log on the ticket.
---
## Example: Comparison with another ticket system
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/events/example-reconciliation-with-another-ticket-system
**Description:** Comparison of conversations with tickets from another ticket system using an example
### Scenario
In some cases, it is necessary for specific tickets and their related conversations to be available in an additional ticket system. For instance, a customer's response to a request from the ticket can also be displayed in the parallel running system. This can be facilitated by the use of webhooks.
### Possible Solution
To ensure that new conversations are synchronized in both systems, a webhook can be implemented. In **Settings** -> **Communication channels** -> **Email accounts**, the corresponding email account must be selected. If the webhooks on this account are not yet active, the **Webhooks** switch must be activated, so that the fields for configuring the "New email" webhook appear.
### Example of customer-specific code
The following PHP code uses the Enneo SDK to retrieve information from a ticket system and pass this on to a third system.
In this example, the user profile is loaded first using the Enneo SDK. Subsequently, extended data for the ticket and the conversations are loaded. At the end of the code snippet, the data of the current conversation is transmitted to the external ticket system. Here, a function `send-to-third-party` is used, which must be deposited as a ["User defined Function"](/docs/de/system-integration/user-defined-functions-tools/user-defined-functions-in-enneo) beforehand.
---
## Authentication of Clients
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/customer-recognition/contract-legitimation
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](mailto:tom@smith.com). However, the email is from [michael@jackson.com](mailto: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](mailto:tom@smith.com). The email comes from [tom@smith.com](mailto: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:
### Procedure
Configure rules in two steps:
1. 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)
2. 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
```php
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.
---
## Customer Identification Process
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/customer-recognition/flow
**Description:** 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
## Process for Chat and Voicebot
The process is largely identical to email processing — the difference is **when** and **how** features are collected.
## 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](/docs/de/system-integration/customer-recognition/search-by-free-text), which should support search queries by name, email or other relevant fields.
## Examples
### Email
### Voicebot
---
## Feature Search
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/customer-recognition/search-by-attributes
**Description:** Feature Search
### Data that Enneo passes to your code (Input)
```json
{
"customerId": "C-abcd-123",
"contractId": "123",
"my-custom-parameter": "abcd", // to be configured in enneo settings
"any-other-parameter-the-ai-found": "abcd",
"ticketId": 123, // always provided natively by enneo, regardless of AI search results
}
```
The variable names, e.g. `customerId` or `my-custom-parameter`, can be defined by the user under settings -> customer and contract search -> customer identification using AI -> Search parameters for customer identification, including the prompt used for recognition. The above values are examples.
### Data structure expected by Enneo as a return value (Output)
```json
{
"contractId": "100001", // contract id of the found contract. cannot be null
"customerId": "200001", // customer id associated to the found contract. cannot be null
}
```
Notes:
- Enneo always expects exactly one or no contract. If the search parameters deliver more than one result, the search must be narrowed down to exactly one result before calling Enneo.
- If the search does not deliver any results, Enneo expects an empty object (`{}`) or a null result (`null`).
- If user wants to override Enneo authentication, the `customerLegitimation` and `customerLegitimationMessage` properties can be included. More information can be found on the relevant documentation page ([/de/system-integration/customer-recognition/contract-legitimation]).
### Sample implementation
---
## Search by Contract Number
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/customer-recognition/search-by-contract-number
**Description:** Data Structure
### Data that Enneo passes to your code (Input)
```json
{
"contractId": "VN-00001"
}
```
### Data structure expected by Enneo as a return value (Output)
```json
{
// Mandatory properties. Must be defined for Enneo to function
"id": "VN-00001", // must be an integer or string up to 50 characters
"customerId": "C-abcd-123", // must be an integer or string up to 50 characters
"business": false, // boolean, indicating whether the customer is a company or individual
"lastname": "Smith", // last name of the customer, can be null ONLY if business is true
"company": null, // company name, e.g. "ACME Corp.", can be null ONLY if business is false
// Recommended properties. Should be defined if possible and is used by Enneo's AI and customer identification logic. Defaults to null if not set
"firstname": "John", // first name of customer, can be null
"email": "john@smith.com",
"deliveryAddress": "Horst-Kohl-Str. 15a, 12157 Berlin", // address of customer
"billingAddress": null, // Optional separate billing address. If null, billing address is the same as delivery address
"phone": "+49190332332",
"zip": "12157", // Used by the default call/phone identification based on contract id and zip code
// Optional preview section for the agent that is shown in the top right corner on the ticket page
"agentPreview": [
{
"url": "https://my-erp/customers/1234#tab=billing",
"type": "string",
"label": "Installment",
"value": "39 €",
"tooltip": null
},
{
"url": null,
"type": "string",
"label": "Consumption",
"value": "1085 kWh",
"tooltip": "Relevant for installments: 1085 kWh NB-JVP: 1637 kWh Previous year: 1637 kWh According to customer: 3500 kWh"
}
],
// Links to any systems holding client data you want your agents to have quick access to
"erpUrls": [
{
"url": "https://my-erp.com/contract-details/1234",
"icon": "/icons/powercloud.svg"
},
{
"url": "https://my-marketing-crm.com/customer-details/c123",
"icon": "/icons/link.svg"
}
],
// Other properties that you want Enneo to be aware of can be defined here.
// Below are some examples for inspiration from the energy sector
"iban": "DE0000000000000000",
"energy": "electricity",
"status": "expired",
"endDate": "2021-10-28",
"orderId": 752050,
"vatRate": 0.19,
"basePrice": 49.41
}
```
### Example Implementation
---
## Searching for Customer Number
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/customer-recognition/search-by-customer-number
**Description:** Data Structure
### Data that Enneo passes to your code (Input)
```json
{
"customerId": "C-abcd-123"
}
```
### Data structure that Enneo expects as a return value (Output)
```json
{
// Mandatory properties. Must be defined for Enneo to work
"id": "C-abcd-123", // must be integer or string up to 50 chars
"business": false, // boolean, if the customer is a company or private person
"lastname": "Smith", // last name of customer, can be null ONLY if business is true
"company": null, // company name, e.g. "ACME Corp.", can be null ONLY if business is false
"contractIds": ["VN-00001", "VN-00002"], // array of contracts this customer has. Must be at least one contract (otherwise it's not a "customer")
// Recommended properties. Should be defined if possible and are used by Enneo's AI and customer identification logic. Default to null if not set
"firstname": "John", // first name of customer, it can be null
"email": "john@smith.com",
"deliveryAddress": "Horst-Kohl-Str. 15a, 12157 Berlin", // address of customer
"billingAddress": null, // Optional separate billing address. If null, then billing address is the same as delivery address
"phone": "+49190332332",
// Any other properties that Enneo should be aware of can be defined here.
// See below some examples as inspiration from the energy sector
"salutation": "Mrs."
}
```
### Sample Implementation
---
## Free Text Search
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/customer-recognition/search-by-free-text
**Description:** Free Text Search
### The data Enneo passes to your code (Input)
```json
{
"q": "John Smith", // this is the value the user typed into the search field
"limit": 10, // in case of pagination, not currently used
"offset": 0 // in case of pagination, not currently used
}
```
### The data structure which Enneo expects as a return value (Output)
```json
[
{
"id": "100020" // customer id (not contract id) of the first contract that was found
},
{
"id": "200001" // second id
},
{
"id": "200002" // third id
},
{
"id": "200003" // n-th id. Enneo accepts up to 10 search results, any additional results will be ignored.
}
]
```
### Example implementation
---
## Claude Code Plugin
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/integration-of-third-party-systems/claude-code-plugin
**Description:** AI-assisted development of Enneo integrations — agents, UDFs, settings, and debugging — directly from the terminal.
The **Enneo Claude Code Plugin** connects [Claude Code](https://claude.ai/code) with your Enneo instance. It can be used to develop integrations — rule-based agents, UDFs, Event-Hooks, Settings — with natural language, while Claude takes care of the API calls.
## Installation
```bash
claude plugin marketplace add https://github.com/enneo-AI/claude-plugin
claude plugin install enneo@claude-plugin
```
After installation, restart Claude Code. Set up and authentication are described in the [plugin README](https://github.com/enneo-AI/claude-plugin).
---
## Examples
### Develop Rule-Based Agents
```
Show me all existing rule-based agents and their executor languages
```
```
Fetch the full source code of the agent "Contract Termination"
```
```
Create a new agent "Change of Address" that extracts a new postal address from the customer message,
validates it and sends a confirmation response.
Language: Python. Channel: E-Mail.
```
```
Preview agent #42 on ticket #1234 — what data would be extracted and
what options would be offered without changing anything?
```
### Debug AI Processing
```
Why didn't any AI agent process ticket #5678?
```
```
Show me the complete event trace for ticket #5678
```
```
Restart AI processing for ticket #5678 and show me the new intents
```
### Settings and Configuration
```
What settings control auto-processing? Show me their current values.
```
```
Which agents are in the immediateAiAgents list?
```
```
List all e-mail subchannels
```
### UDFs and Event-Hooks
```
List all UDFs and indicate which are also available as AI tools
```
```
Create a UDF "lookup_customer_by_vat" in Python, that calls our ERP API
at https://erp.example.com/api/customer and returns the customer record
```
```
Give me the local execution command to test "lookup_customer_by_vat"
against ticket #9999
```
```
Add an event hook that calls "notify_slack" when a ticket
in the subchannel support@company.com is created
```
### Investigate Tickets
```
Show me all open tickets from the last 24 hours with E-Mail channel
```
```
Find all tickets where AI Agent #7 created an intent in the last week
```
---
## Codex Plugin
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/integration-of-third-party-systems/codex-plugin
**Description:** AI-assisted work with Enneo instances — tickets, AI agents, settings, and debugging — directly from Codex.
The **Enneo Codex Plugin** connects [Codex](https://openai.com/codex) with your Enneo instance. It can be used to investigate tickets, develop AI agents, inspect settings, and debug integrations with natural language, while Codex takes care of the API calls.
## Installation
```bash
codex plugin marketplace add https://github.com/enneo-AI/codex-plugin
codex plugin add enneo-codex@enneo
```
After installation, restart Codex. Set up and authentication are described in the [plugin README](https://github.com/enneo-AI/codex-plugin).
---
## Examples
### Configure the Connection
```
Use the Enneo Codex plugin. Connect to .enneo.ai and show my profile.
```
```
Connect to demo.enneo.ai and verify the Enneo profile.
```
### Investigate Tickets
```
Search recent open tickets in Enneo.
```
```
Get ticket #1234 and summarize the customer request, detected intents, tags, and next best action.
```
```
Investigate why an Enneo AI agent skipped ticket #5678.
```
### Develop AI Agents
```
Show me the configured AI agents and explain which one should handle ticket #1234.
```
```
Review the executor logic for the address-change agent and suggest a safer validation path.
```
```
Create a draft plan for turning this support process into a rule-based Enneo agent.
```
### Check Settings and Integrations
```
List the configured email subchannels and identify which mailbox receives support requests.
```
```
Show the customer-recognition settings and explain which API calls are required.
```
```
Check which UDFs are available as AI tools.
```
---
## Access Control
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/security/access-control
**Description:** IP Whitelist and login methods (OAuth/SSO) — Configuration and Operation
Enneo offers two independent mechanisms for controlling system access: a
network-based IP whitelist and an identity-based configuration of
permitted login methods. Both mechanisms act on different
levels and can be combined.
## IP Whitelist
The IP whitelist restricts access to Enneo based on the network address
of the requesting client. If the setting is active, all requests from
users are rejected whose IP address is not included in the list.
The configuration can be found under
`Advanced settings → Privacy → Access control - IP Whitelist`.
The setting accepts a list of IP addresses or CIDR ranges.
Both IPv4 and IPv6 are supported.
```json
["192.168.1.0/24", "10.0.0.5", "2001:db8::/32"]
```
If the list is empty, access is possible without IP restriction. As soon as
at least one entry is set, each request is checked — if there is
a match, access is granted, otherwise it is denied.
## Login methods (OAuth / SSO)
Enneo supports several login methods that can be configured per tenant.
The SSO configuration can be found under `Advanced Settings → Single-Sign-On`.
### Permitted Login Methods
The setting determines which login types are active:
| Value | Description |
|---------------|----------------------------------------------|
| `microsoft` | Microsoft Azure AD / Entra ID (OAuth2/OIDC) |
| `google` | Google OAuth2 |
| `oauth` | Generic OAuth2 provider (configurable) |
| `local` | Local login with email and password |
### Allowed Email Domains
If this setting is set, new users will only be created if
their email address belongs to one of the configured domains.
```json
["example.com", "partner.org"]
```
---
## File Attachments
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/security/attachment-security
**Description:** Classification and treatment of file attachments according to security level
Enneo automatically evaluates each file attachment based on its MIME type and — if technically available — its actual file type. The result is a risk class that controls how the system deals with the attachment: in storage, display, and transmission.
### Risk Classes
Each attachment is assigned to one of three classes:
- **safe** — File types that are considered harmless (e.g., PDF, DOCX, XLSX, JPEG, PNG, MP3, MP4). These files are stored and displayed normally.
- **risky** — File types with increased risk potential (e.g., ZIP, RAR, 7z, TAR, EML, `application/octet-stream`). These files are stored, but a warning message is displayed to the user before opening.
- **dangerous** — Executable or potentially malicious file types (e.g., EXE, MSI, Binary). These files are not stored; the attachment is replaced with a text file that includes a notification.
If the MIME type cannot be assigned to any of the lists, the system automatically classifies the attachment as **risky**.
In addition to checking the MIME type, it is checked whether the file is marked as executable on the file system. If so, regardless of the MIME type, it is treated as **dangerous**.
### System Behavior
**During Email Import:**
Dangerous attachments (`dangerous`) are not stored in the system. Instead, Enneo creates a text file that informs the user about the removal. The original content is lost.
**For outgoing messages and notes:**
When adding attachments to a reply or internal note, the system checks the risk class before storing. For unauthenticated contexts (e.g., through the external API without a profile), both `risky` and `dangerous` are blocked. For authenticated users, only `dangerous` is blocked.
**In the User Interface:**
Attachments of the `risky` class can be opened, but a confirmation dialog is displayed before opening. Attachments of the `dangerous` class are disabled and cannot be opened.
### Configuration
The three lists — Safe, Risky, Dangerous — can be configured in the settings under **Advanced Settings → General → Attachment Security List**. Each list contains MIME type strings. Changes immediately affect the behavior for newly incoming emails and file uploads; existing attachments are not reclassified retroactively.
### Classification
Attachment Security does not replace antivirus infrastructure. It provides a structured first filter layer based on known MIME types and protects from accidentally storing or opening obviously dangerous file formats. For higher security requirements, subsequent verification at the network level or by a virus scanner should take place.
---
## Custom Code in Enneo
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/user-defined-functions-tools/code-execution-overview
**Description:** Basic principles: where custom code in Enneo is executed and what types of execution are available
Enneo can be extended at many points with custom code. This allows peripheral systems to be connected, business logic to be mapped, and automations to be implemented without changing the platform itself.
### Where custom code in Enneo is used
Custom code in Enneo is always stored as a so-called **Executor** and referenced in various places. Typical areas of application include:
- **[Customer Recognition](/docs/en/system-integration/customer-recognition/flow)** — Search by [contract number](/docs/en/system-integration/customer-recognition/search-by-contract-number), [customer number](/docs/en/system-integration/customer-recognition/search-by-customer-number), [attributes](/docs/en/system-integration/customer-recognition/search-by-attributes) or [free text](/docs/en/system-integration/customer-recognition/search-by-free-text) relies on own functions that load data from the ERP or other source systems.
- **[Rule-Based AI Agents](/docs/en/ai-functions-agents/rule-based-agents)** — The business logic of an agent (e.g., capturing meter reading, writing address change, canceling contract) calls own code to perform the actual action in the peripheral system.
- **AI Tools for [Smart AI Agents](/docs/en/ai-functions-agents/smart-agents)** — Smart (LLM-based) agents decide on their own during a conversation which tool they call. Each user-defined tool (managed under **AI Customization → AI Tools**) is an Executor that performs a specific action in the peripheral system - e.g., `get_tariff_offer`, `send_offer_by_email` or `do_tariff_change`.
- **[Webhooks](/docs/en/system-integration/events/concept-of-webhooks-in-enneo)** — Synchronous calls to peripheral systems, e.g., sending an email via API. Errors are reported directly to the user, the process waits for the response.
- **[Event Hooks](/docs/en/system-integration/events/concept-of-events-in-enneo)** — Asynchronous reactions to Enneo-internal events (ticket created, answered, closed, …), for example, to export data or inform other systems. Errors are logged in the event trace, but not surfaced directly to the user.
- **[User Defined Functions (UDFs)](/docs/en/system-integration/user-defined-functions-tools/user-defined-functions-in-enneo)** — Reusable code blocks, which can be centrally managed and called from any other points.
### The two types of execution
Enneo supports two ways to execute custom code. The difference is not in the complexity of the code, but in **who hosts and operates the code** — Enneo or the peripheral system on its own infrastructure. In both cases, **input and output data are passed as JSON**.
#### Hosting by Enneo: Sandbox execution (type `code`)
The code is stored directly in Enneo and executed in the Enneo sandbox. Supported languages are PHP, Python and Node.js. Within the sandbox, the full Enneo SDK, any packages (via Composer, pip, npm) and access to input parameters, storage objects and all Enneo APIs are available. Input and output are JSON.
Advantages:
- No own server infrastructure, no deployment, no external accessibility needed.
- Changes are effective immediately, without release process.
- Direct access to the Enneo SDK and to Enneo APIs.
Restrictions:
- No version control (Git) and only limited debugging.
- Tests do not run in the usual CI setup of the own codebase.
Therefore, in practice, it's best suited for **simple, manageable logic**.
#### Hosting by the peripheral system: Direct API call (type `apiCall`)
The code is operated on its own infrastructure as an HTTP endpoint. Enneo sends a request to the configured URL and continues with the response. The following are specified:
- HTTP method (`GET`, `POST`, `PUT`, `PATCH`, `DELETE`)
- URL
- HTTP headers (authentication headers can refer to [secrets](/docs/en/system-integration/user-defined-functions-tools/secrets))
Here too, **input and output are JSON**: With `GET` and `DELETE`, the input parameters are automatically appended as a query string to the URL, with `POST`, `PUT` and `PATCH` they are passed as a JSON body. The response is parsed as JSON and returned.
Advantages:
- Full control over source code, versioning, tests, deployment, and monitoring.
- Integration into existing internal systems and tooling.
Restrictions:
- Requires a separate server component that can be accessed from Enneo.
- Each change goes through the own release process.
---
## Icons
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/user-defined-functions-tools/icons
**Description:** Overview of available icons
# Icon Library
Icons are used in many places in Enneo. Some examples include:
- Custom statuses
- Custom action buttons
- Links to ERP systems from contracts
## Available Icons
export const IconGrid = () => {
const baseUrl = 'https://main.enneo.dev/icons/';
const icons = [
'account',
'activity',
'agentAssign',
'ai',
'aiAgent_1',
'aiBroken',
'aiColorful',
'announcements',
'archive',
'arrow',
'arrowLeft',
'arrowLetter',
'arrowRight',
'article',
'attachment',
'barChart',
'baseContract',
'bcc',
'bell',
'bolt',
'book',
'britishFlag',
'brokenAccount',
'busts',
'calendar',
'callActive',
'category',
'cc',
'chat',
'chatAgentAvatar',
'chatColorful',
'check',
'checkboxChecked',
'checkboxIndeterminate',
'checkboxUnchecked',
'checkmark',
'chevronDown',
'chevronLeft',
'chevronRight',
'chevronUp',
'clock',
'coffee',
'collapseContent',
'collapseLow',
'connectinglines',
'copy',
'crayon',
'cross',
'danger',
'diagram',
'document',
'download',
'drag',
'dynamicArrow',
'earthquake',
'edit',
'emb',
'emojiAngry',
'emojiConcerned',
'emojiDisappointed',
'emojiHappy',
'emojiNeutral',
'emojiSad',
'emojiThankful',
'enneo-logo',
'enneo',
'enneo_icon_dark',
'enneo_icon_white',
'enter',
'euro',
'ewe',
'exclamation',
'expandContent',
'expandLow',
'externalLink',
'eye',
'facebook',
'holiday',
'figures',
'filter',
'filterActive',
'filterClear',
'filterGreen',
'filterRed',
'flag',
'folder',
'folderOpen',
'forward',
'frenchFlag',
'freshdesk',
'gas',
'gasag',
'gear',
'gearColorful',
'germanFlag',
'globe',
'good',
'google',
'googlessoicon',
'gridView',
'heatPump',
'helpCenter',
'home',
'imCall',
'inbox',
'info',
'internalLink',
'internet',
'layoutCard',
'layoutTable',
'left2',
'letter',
'letterColorful',
'letterGearColorful',
'letterbox',
'lightning',
'link',
'linkedAccount',
'listView',
'locked',
'loginlogo',
'lynq',
'magic',
'magic2',
'magicBroken',
'magicColorful',
'magnify',
'microsoft',
'mobile',
'neo',
'newFolder',
'news',
'noAccount',
'noCall',
'notVerified',
'note',
'office',
'okay',
'otherDoc',
'overview',
'paragraph',
'partners',
'pdf',
'pen',
'pending',
'peopleColorful',
'person',
'phone',
'play',
'plus',
'plusCircle',
'powercloud',
'priority',
'profile',
'question',
'redirect',
'refresh',
'refreshNew',
'reload2',
'reply',
'replyConfig',
'rerun',
'restore',
'right2',
'robot',
'sap',
'save',
'searchList',
'send',
'serverGearColorful',
'smile',
'star',
'statusClosed',
'statusOpen',
'statusProgress',
'statusWaiting',
'stroke',
'sun',
'tFriendly',
'tMagic',
'tNew',
'tProfessional',
'tSimplify',
'target',
'team',
'technologist',
'template',
'text',
'textFormating',
'textRecog',
'threeDots',
'thumbUp',
'tick',
'tickCircle',
'tickets',
'ticketsNew',
'time',
'timeOff',
'translate',
'translateDe',
'translateEn',
'translateFr',
'trash',
'truck',
'tune',
'typingIndicator',
'undo',
'unlink',
'update',
'upload',
'users',
'verification',
'warning',
'waterDrop',
'wikiBook',
'workflowColorful'
];
return (
{icons.map(icon => (
{icon}.svg
))}
);
};
---
## Secrets
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/user-defined-functions-tools/secrets
**Description:** Secure storage of API tokens and other secrets for own code
Enneo offers a centralized storage for secrets — for example, API tokens, client secrets or basic-auth credentials — which can be referenced in the headers of API call executors via placeholders. Values are masked in the interface and never output in API responses.
Secrets are particularly used for [direct API call execution](/docs/en/system-integration/user-defined-functions-tools/code-execution-overview) (type `apiCall`), so authentication headers can be set without storing the actual token value in the executor definition.
### Managing Secrets
Secrets are managed in the settings under **System integration → Secrets**. Each entry consists of:
- **Key** — the name of the secret, such as `MY_API_TOKEN`. This name is referenced in the placeholder.
- **Value** — the actual value. It is presented masked in the interface and is not included in API responses.
An arbitrary number of secrets can be stored.
### Using Secrets in API call executors
In the header values of an API call executor, secrets can be referenced via the placeholder `{{secret.KEY}}`. When executing the executor, Enneo replaces the placeholder with the stored value.
Example header of an API call executor:
```json
{
"Authorization": "Bearer {{secret.MY_API_TOKEN}}",
"X-Api-Key": "{{secret.PARTNER_API_KEY}}",
"Accept": "application/json"
}
```
If a secret with the specified key does not exist, the placeholder remains in the header value — the call will therefore typically abort with an authentication error rather than being forwarded with an empty token.
### Secrets in the SDK (Sandbox executors type `code`)
In sandbox executors, the SDK provides the `ApiEnneo.getSecret(key)` method. It returns the stored value of the secret or `null`/`None` if the key is not configured. This way, secrets can be used without storing them in the code.
### Permissions
Reading and writing the `executorSecrets` setting requires the `updateAiAgent` permission. Values are masked on the interface and are not output in read endpoints.
---
## User Defined Functions
**URL:** https://richard-dev-playground.enneo.ai/docs/en/system-integration/user-defined-functions-tools/user-defined-functions-in-enneo
**Description:** Reusable building blocks for integrations
Enneo allows the depositing of custom code in the form of "User Defined Functions" for various applications. These functions can be particularly used in the business logic of rule-based AI agents, in webhooks or event implementations. Therefore, whenever own code or SDKs are used.
### Management of User Defined Functions
User defined functions are managed in the **Integration of peripheral systems** section in the settings. Any number of custom functions can be stored here.
### Application possibilities
User Defined Functions offer various application possibilities. For example:
- **Interfaces calls of the peripheral systems**: For instance, ERP, Task-Management, or Archive-Systems.
- **Connection to Output-Management-Systems**: For example, for the dispatch of notifications.
- **Outsourcing of complex processes**: In the form of reusable building blocks.
With these functionalities, Enneo extends the adaptability and enables the integration of specific
company logic into AI-based customer support.
### Calling User Defined Functions
Enneo can save and use user-defined functions. The following calls are possible,
using the example of a User-Defined-Function named 'my-udf':
Within Enneo using Python SDK:
```python
sdk.ApiEnneo.executeUdf('my-udf', {"parameter1": "value1", "parameter2": "value2"}, 'serviceWorker')
```
Within Enneo using PHP SDK:
```php
\EnneoSDK\ApiEnneo::executeUdf('my-udf', ['parameter1' => 'value1', 'parameter2' => 'value2'],'serviceWorker');
```
External Web-Request:
```plaintext
POST https://your-subdomain.enneo.ai/api/mind/executor/execute/my-udf
Payload: '{"parameter1": "value1", "parameter2": "value2"}'
```
### Storage object for User Defined Functions
Any JSON object can be used as an internal Enneo storage object for custom functions.
This allows data to be stored and retrieved using the Enneo-SDK.
```php
\EnneoSDK\Setting::set('udfStorage', ['my' => 'data']);
$storedData = \EnneoSDK\Setting::get('udfStorage');
```
### Example: Calling a Third-Party API
First, required data is set in the storage object for user-defined functions:
```json
{
"thirdParty": {
"oauth": {
"clientId": "123456789",
"grantType": "client_credentials",
"clientSecret": "abcdefg.....hijklmnop",
"tokenEndpoint": "https://token-url/oauth2/token",
"baseUrl": "https://third-party-url/api"
}
}
}
```
In the second step, a user-defined function **fetch-thirdparty-token** can be implemented for loading the credentials.
This approach is particularly useful when the loading of credentials can be reused in several
other processes.
```php
thirdParty->oauth->clientId;
$clientSecret = $udfStorage->thirdParty->oauth->clientSecret;
$result = \EnneoSDK\Api::call(
method: 'POST',
url: $udfStorage->thirdParty->oauth->tokenEndpoint,
headers: [
'Authorization: Basic ' . base64_encode($clientId . ':' . $clientSecret),
'Content-Type: application/x-www-form-urlencoded',
'Accept: application/json'
],
params: http_build_query(['grant_type' => $udfStorage->thirdParty->oauth->grantType ?? 'client_credentials',
'scope' => $udfStorage->thirdParty->oauth->scope ?? null])
);
// The output is in JSON format and can be used after the call in the corresponding code
echo json_encode(['accessToken' => $result->access_token,
'accessTokenExpiresAt' => date("Y-m-d H:i:s T", time() + $result->expires_in),
"baseUrl" => $udfStorage->thirdParty->baseUrl,
"headers" => $udfStorage->thirdParty->headers ?? [],
"apiName" => $udfStorage->thirdParty->apiName ?? "Customer-API",
]);
```
Subsequently, the implementation of the function **third-party-api-call** can take place for the actual API call:
```php
accessToken,
'Accept: application/json'
];
foreach (($cred->headers ?? []) as $key => $val) {
$headers[] = "$key: $val";
}
// API call and output
$res = \EnneoSDK\Api::call(
method: $in->method,
url: $credentials->baseUrl.'/'.$in->api,
headers: $headers,
params: $in->params
);
// Output result
echo json_encode($res);
```
This structure enables flexible use and integration of custom code within Enneo,
to map specific business logic or seamlessly connect external systems.
../../../../snippets/en/user-defined-functions/user-defined-function-call.mdx
---
## Aktionen
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/ai-control-centre/dark-processing/actions
**Description:** Arten und Erklärung
### Anwendungsbeispiel:
Der Abschlags-Agent wurde so konfiguriert, dass er in diesen Fällen bei der Ticketbearbeitung unterstützend passende Aktionen anbieten kann:
1. vom Kunde gewünschter Abschlag ist plausibel und wird ins System übernommen
2. vom Kunde gewünschter Abschlag ist bereits im System
3. vom Kunde gewünschter Abschlag ist unplausibel
4. der Vertrag ist bereits abgelaufen
***1. Anpassung:** Für Fall 3 wurde der KI-Agent angepasst, so dass diese Kundenanliegen ab sofort vollautomatisiert verarbeitet werden können. Die Anpassung wird auf neu eingehende Kundenanliegen sofort angewendet. Damit auch bestehende Tickets mit der Anpassung verlinkt werden können, nutzt man diese Aktion:*
### Alle offenen Tickets auf Dunkelverarbeitungsfähigkeit prüfen
Diese Aktion überprüft alle offenen Tickets darauf, ob sie für die Dunkelverarbeitung geeignet sind. Falls ein Ticket als geeignet erkannt wird, wird es markiert und gemäß den Konfigurationseinstellungen weiterverarbeitet (sofort, nach Freigabe, mit Zeitversatz, etc.).
In der anschließenden Übersicht wird das Prüfergebnis detailliert abgebildet, und weitere Aktionen zur Verfügung gestellt.
***2. Anpassung:** Der Abschlags-Agent wurde in seiner generellen Konfiguration maßgeblich optimiert. Die Anpassung wird auf neu eingehende Kundenanliegen sofort angewendet. Damit auch bestehende Tickets mit den Optimierungen verarbeitet werden können, braucht es einen Refresh aller Tickets, die mit dem Abschlags-Agenten verlinkt sind:*
### Re-run AI Processing for human tickets
Hier wird ein Refresh für alle offenen Tickets durchgeführt, die einem KI-Agenten zugeordnet sind und noch nicht zur Dunkelverarbeitung markiert wurden. Voraussetzung ist, dass der KI-Agent mindestens einen vollautomatisierten Fall bearbeiten kann.
In der anschließenden Übersicht wird wieder das Prüfergebnis detailliert abgebildet und weitere Aktionen zur Verfügung gestellt.
***3. Anpassung:** Die Dunkelverarbeitung für Fall 3 wird deaktiviert. Die Agenten sollen Fälle dieser Art wieder selbst nach neuer Arbeitsanweisung lösen. Neue Tickets zu diesen Fällen werden nicht mehr für die Dunkelverarbeitung vorgemerkt. Die Markierung bleibt jedoch in bereits vorhandenen Tickets bestehen:*
### Re-run AI Processing for all tickets
Mit dieser Aktion werden auch die bereits zur Dunkelverarbeitung markierten Tickets erneut via Refresh geprüft.
### Alle erkannten dunkelverarbeitungsfähigen Tickets jetzt verarbeiten
Nach erfolgreicher Prüfung können damit alle Tickets, die für die Dunkelverarbeitung markiert wurden, verarbeitet werden.
### Fazit
Mit unseren **KI-Agenten** bieten wir eine leistungsstarke Möglichkeit zur **automatischen Bearbeitung von Kundenanliegen**. Durch gezielte Aktionen kann die Dunkelverarbeitung effizient gesteuert und flexibel an veränderte Regeln angepasst werden. Besonders durch die **zentralen Prüf- und Refresh-Mechanismen** lassen sich Änderungen der KI-Agenten **schnell und effizient** in den bestehenden Ticketfluss integrieren.
---
## Arten der Freigabe
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/ai-control-centre/dark-processing/types-of-release
**Description:** Arten, Konfidenzlevel und Zeitversatz
### Aktivierung der Dunkelverarbeitung
Die Dunkelverarbeitung wird im Bereich **KI-Anpassung** aktiviert. Es gelten folgende Grundprinzipien:
* Der Kunde muss eindeutig erkannt werden (Absenderadresse stimmt mit ERP-Daten überein).
* KI-Agenten bearbeiten Kundenanliegen automatisiert und fallabschließend nach definierten Regeln.
* Die Prüfung erfolgt durch einen KI-Agenten mit ERP-Datenabgleich.
* Unklare Fälle werden an einen Mitarbeiter weitergeleitet.
### Konfidenzlevel für die Dunkelverarbeitung
Das Konfidenzlevel stellt sicher, dass Anfragen mit der notwendigen Zuverlässigkeit bearbeitet werden. Je höher die festgelegte Stufe, desto sicherer muss die Identifikation des Kunden und die Übereinstimmung der Anfrage mit den definierten Regeln sein, bevor eine automatische Verarbeitung erfolgt.
**Verfügbare Optionen:**
* **Maximal:** Absender-E-Mail/Postanschrift des Kunden stimmt mit ERP-Daten überein.
* **Sehr hoch:** Kunde nennt korrekte Kombination aus Kunden- und Vertragsnummer.
* **Hoch:** Kunde nennt richtige Kunden-/Vertragsnummer und den im ERP-System hinterlegten Nachnamen (empfohlene Einstellung).
* **Mittel:** Falls im ERP-System keine E-Mailadresse hinterlegt ist, werden alle Absenderadressen akzeptiert.
* **Keine:** E-Mail/Postanschrift des Absenders nicht prüfen.
### Freigabearten in der Dunkelverarbeitung
Es gibt zwei Möglichkeiten, Geschäftsprozesse in der Dunkelverarbeitung freizugeben:
**1. Dunkelverarbeitung mit Freigabe**
Hierbei werden Kundenanliegen und Geschäftsvorfälle erst nach einer vorherigen, manuellen Freigabe automatisiert verarbeitet. Erst nach einer positiven Prüfung erfolgt die Dunkelverarbeitung.
*In diesem Ticket wurde der Kunde eindeutig erkannt, sein Anliegen als automatisiert verarbeitbar gekennzeichnet und wird nach manueller Prüfung via Klick auf "Jetzt verarbeiten" ohne weitere Interaktion fallabschließend gelöst.*
**2. Dunkelverarbeitung ohne Freigabe**
In dieser Variante werden Kundenanliegen und Geschäftsvorfälle sofort und ohne weitere Freigabe automatisch verarbeitet. Dies bietet den höchsten Automatisierungsgrad, erfordert jedoch eine präzise Konfiguration, um Fehldeklarationen zu vermeiden.
### Zeitversatz für die Dunkelverarbeitung
Ein optionaler **Zeitversatz** kann genutzt werden, falls Tickets erst nach einer definierten Wartezeit bearbeitet werden sollen. Ist diese Funktion aktiviert, wird das Ticket erst nach Ablauf der festgelegten Stunden automatisch verarbeitet.
Bei einem Zeitversatz von bspw. 8 Stunden werden Arbeitszeiten, Wochenenden und Feiertage gemäß der SLA-Einstellung berücksichtigt.
### Namensgebung des KI-Bots
Für eine transparente Kommunikation kann der Name des KI-Bots, der in der Dunkelverarbeitung aktiv ist, individuell definiert werden. Dieser Name wird beispielsweise in E-Mails oder Signaturen genutzt, um automatisierte Antworten zu kennzeichnen.
### Fazit
Die Dunkelverarbeitung bietet eine leistungsstarke Möglichkeit, Kundenanliegen effizient und automatisiert zu bearbeiten. Durch die flexible Konfiguration der Freigabearten und Sicherheitsstufen lässt sich die Automatisierung optimal an die spezifischen Anforderungen des Unternehmens anpassen. Dies führt zu einer spürbaren Entlastung des Kundenservice und einer verbesserten Bearbeitungsgeschwindigkeit.
---
## Testergebnisse auswerten
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/ai-control-centre/quality-check/evaluate-test-results
**Description:** Analyse und mögliche Aktionen
### Testergebnisse einsehen
* In der **Testläufe-Übersicht** den gewünschten Testlauf auswählen und auf den **Pfeil rechts** klicken.
* Die detaillierte Ansicht des Testlaufs wird angezeigt, inklusive Status, getesteter KI-Agent, Laufzeit und Testergebnis.
* Die Übersicht zeigt auch, ob die Parameter-Übergabe erfolgreich war und ob es Abweichungen oder Fehler gab.
### Testergebnisse analysieren
* Durch einen Klick auf den **Pfeil rechts** der einzelnen Testergebnisse öffnet sich die **Sidebar mit den Testdetails**.
* Dort sind die Ergebnisse in zwei Kategorien unterteilt:
* **Empfangen**: Die tatsächliche Reaktion des KI-Agenten.
* **Erwartet**: Die definierte, korrekte Antwort, mit der das empfangene Ergebnis verglichen wird.
* Falls eine Abweichung vorliegt, kann analysiert werden, warum der KI-Agent anders reagiert hat als erwartet.
### Testergebnisse akzeptieren oder weiter analysieren
* Falls die empfangene Antwort korrekt ist, kann sie als neues Testergebnis **akzeptiert** werden.
* Wenn es Abweichungen gibt, sollte überprüft werden, ob eine Anpassung des KI-Agenten notwendig ist.
* Bei kritischen Fehlern kann eine genauere Analyse der Trainingsdaten oder Logiken erforderlich sein.
### Fazit
Die Auswertung der Testergebnisse ist essenziell, um die Qualität und Zuverlässigkeit der KI-Agenten sicherzustellen. Durch das Vergleichen von **empfangenen** und **erwarteten** Ergebnissen können Schwächen erkannt und gezielt optimiert werden.
---
## Testfälle und Testläufe
**URL:** https://richard-dev-playground.enneo.ai/docs/de/ai-functions-agents/ai-control-centre/quality-check/test-cases-and-runs
**Description:** Überblick, Erstellung und Aktionen
### Testfälle
Ein **Testfall** beschreibt ein einzelnes Szenario zur Überprüfung der Leistung eines KI-Agenten. Durch das Hinzufügen spezifischer Tickets können unterschiedliche Anwendungsfälle getestet werden, um sicherzustellen, dass der KI-Agent erwartungsgemäß reagiert.
**Erstellung:**
* Im Bereich *Qualitätsprüfung - Testfälle* beim gewünschten KI-Agenten die Sidebar öffnen.
* Via Ticket-ID die für den Test vorgesehenen Tickets hinzufügen.
* Falls noch keine konkrete Ticket-ID vorliegt:
* Im Filter der Ticket-Übersicht den Punkt\*\*\*\* "**Anliegen**" selektieren.
* Passende Tickets anzeigen lassen und per ID dem Testlauf hinzufügen.
* Testfälle können bei Bedarf über die Sidebar wieder entfernt werden.
### Testläufe
Ein **Testlauf** führt eine definierte Anzahl von Testfällen aus, um die KI-Funktionalität zu bewerten.
**Testläufe-Übersicht**
Die Übersicht zeigt alle durchgeführten Testläufe mit folgenden Details:
* **ID des Testlaufs**: Eindeutige Kennung für den Testlauf
* **KI-Agent**: Name des getesteten KI-Agenten
* **Startdatum**: Zeitpunkt des Testlaufs
* **Status**: Zeigt den Fortschritt (z. B. "Processing", "Completed", "Failed")
* **Tickets**: Anzahl der im Testlauf verwendeten Tickets
* **Ergebnis**: Prozentuale Bewertung der Testergebnisse
Testläufe werden im Tab "Testfälle" via Play-Button rechts beim KI-Agenten gestartet. Es können beliebig viele Testläufe parallel initiiert werden.
---
## Actions
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/ai-control-centre/dark-processing/actions
**Description:** Types and Explanation
### Application Example:
The discount agent has been configured to help offer suitable actions in these cases during ticket processing:
1. Discount requested by the customer is plausible and is recorded into the system
2. Discount requested by the customer is already in the system
3. Discount requested by the customer is implausible
4. The contract has already expired
***1. Adjustment:** The AI agent has been modified for case 3, so these customer requests can be processed fully automatedly from now on. The adjustment is immediately applied to newly submitted customer requests. To link existing tickets with the adjustment, this action is used:*
### Inspect all open tickets for dark processing ability
This action checks all open tickets for their suitability for dark processing. If a ticket is recognised as suitable, it is marked and processed further in accordance with the configuration settings (immediately, upon approval, with time delay, etc.).
The ensuing overview provides a detailed representation of the test result, and further actions are made available.
***2. Adjustment:** The discount agent has been significantly optimized in its general configuration. The adjustment is immediately applied to newly submitted customer requests. To process existing tickets with the optimizations, a refresh of all tickets linked to the discount agent is needed:*
### Re-run AI Processing for human tickets
Here, a refresh is performed for all open tickets that are assigned to an AI agent and have not yet been marked for dark processing. The prerequisite is that the AI agent is able to handle at least one fully automated case.
In the following overview, again, the test result is detailed and more actions are available.
***3. Adjustment:** The dark processing for case 3 is deactivated. Agents should solve cases of this nature again themselves according to the new work instruction. New tickets to these cases will no longer be flagged for dark processing. However, the marking remains in already existing tickets:*
### Re-run AI Processing for all tickets
With this action, tickets already marked for dark processing are also checked again via refresh.
### Process all detected dark-processing-capable tickets now
After successful review, all tickets marked for dark processing can be processed.
### Conclusion
With our **AI agents**, we offer a powerful way to **automatically process customer requests**. Through targeted actions, dark processing can be efficiently steered and flexibly adapted to changed rules. Especially through the **central check and refresh mechanisms**, changes to AI agents can be **quickly and efficiently** integrated into the existing ticket flow.
---
## Types of Release
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/ai-control-centre/dark-processing/types-of-release
**Description:** Types, Confidence Level and Time Offset
### Activation of Dark Processing
Dark Processing is activated under **AI customization**. The following basic principles apply:
* The customer must be clearly identified (sender address matches with ERP data).
* AI agents process customer concerns automatically and case conclusively according to defined rules.
* The check is carried out by an AI agent with ERP data comparison.
* Unclear cases are forwarded to an employee.
### Confidence Level for Dark Processing
The confidence level ensures that enquiries are processed with the necessary reliability. The higher the set level, the more certain the identification of the customer and the match of the enquiry with the defined rules must be before automatic processing occurs.
**Available Options:**
* **Maximum:** Sender email/postal address of the customer matches with ERP data.
* **Very high:** Customer provides correct combination of customer and contract number.
* **High:** Customer provides correct customer/contract number and the surname stored in the ERP system (recommended setting).
* **Medium:** If no email address is stored in the ERP system, all sender addresses are accepted.
* **None:** Do not check sender's email/postal address.
### Types of Release in Dark Processing
There are two ways to release business processes in the dark processing:
**1. Dark Processing with Release**
Here, customer concerns and business incidents are only processed automatically after a prior manual release. Dark Processing only takes place after a positive check.
*In this ticket, the customer has been clearly identified, their concern has been marked as automatically processable and will be solved case conclusively without further interaction after a manual check by clicking on "Process Now".*
**2. Dark Processing without Release**
In this variant, customer concerns and business incidents are processed automatically and without further release immediately. This offers the highest degree of automation but requires precise configuration to avoid misdeclarations.
### Time delay for Dark Processing
An optional **time delay** can be used in case tickets should only be processed after a defined waiting period. If this function is activated, the ticket will only be processed automatically after the set hours have elapsed.
For example, a time delay of 8 hours takes working hours, weekends and holidays into account according to the SLA setting.
### Naming of the AI Bot
For transparent communication, the name of the AI bot active in the dark processing can be defined individually. This name is used, for example, in emails or signatures to mark automated responses.
### Conclusion
Dark Processing offers a powerful way to efficiently and automatically process customer concerns. The flexible configuration of release types and security levels allows the automation to be optimally tailored to the specific requirements of the company. This leads to a noticeable relief of customer service and an improved processing speed.
---
## Evaluating Test Results
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/ai-control-centre/quality-check/evaluate-test-results
**Description:** Analysis and Possible Actions
### View Test Results
* In the **Test Runs Overview**, select the desired test run and click on the **arrow on the right**.
* The detailed view of the test run is displayed, including status, tested AI agent, runtime, and test result.
* The overview also shows whether the parameter transfer was successful and whether there were deviations or errors.
### Analyze Test Results
* By clicking on the **arrow on the right** of the individual test results, the **sidebar with the test details** opens.
* The results are divided into two categories:
* **Received**: The actual reaction of the AI agent.
* **Expected**: The defined correct response to which the received result is compared.
* If there is a deviation, it can be analyzed why the AI agent reacted differently than expected.
### Accept Test Results or Continue Analysis
* If the received response is correct, it can **accepted** as a new test result.
* If there are deviations, it should be checked whether an adjustment of the AI agent is necessary.
* In the case of critical errors, a more detailed analysis of the training data or logics may be required.
### Conclusion
Evaluating the test results is essential to ensure the quality and reliability of the AI agents. By comparing **received** and **expected** results, weaknesses can be identified and specifically optimized.
---
## Test Cases and Test Runs
**URL:** https://richard-dev-playground.enneo.ai/docs/en/ai-functions-agents/ai-control-centre/quality-check/test-cases-and-runs
**Description:** Overview, creation, and actions
### Test Cases
A **test case** describes a single scenario to check the performance of an AI agent. By adding specific tickets, different use cases can be tested to ensure that the AI agent reacts as expected.
**Creation:**
* In the *Quality Assurance - Test Cases* section, open the sidebar for the desired AI agent.
* Add the tickets intended for the test via the ticket ID.
* If there is not yet a specific ticket ID:
* In the filter of the ticket overview, select the point\*\*\*\* "**Concern**".
* Display suitable tickets and add them to the test run via the ID.
* Test cases can be removed via the sidebar if necessary.
### Test Runs
A **test run** executes a defined number of test cases to evaluate the AI functionality.
**Test Runs Overview**
The overview shows all conducted test runs with the following details:
* **Test Run ID**: Unique identifier for the test run
* **AI Agent**: Name of the tested AI agent
* **Start Date**: Time of the test run
* **Status**: Displays the progress (e.g., "Processing", "Completed", "Failed")
* **Tickets**: Number of tickets used in the test run
* **Result**: Percentual evaluation of the test results
Test runs are started in the "Test Cases" tab via the Play button on the right of the AI agent. Any number of test runs can be initiated in parallel.
---
## Links
- [Support](https://www.enneo.ai)
{icon}.svg