In diesem Export erfasst Enneo alle Bearbeitungen von Kundenanliegen. Er eignet sich insbesondere dazu, das im Service-Center realisierte Volumen zu messen. Dabei werden insbesondere 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: Dann erfasst Enneo für dieses Ticket 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, die erfasst wird) 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. Im Standard werden diese vier verwendet:
  • 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. sogensannte normalisierte Lhevenstein-Distanz) berechnet. NULL, wenn kein Basis‑Agent verwendet wurde oder keine Vergleichsbasis vorliegt. Das Feld misst den Nutzwert der KI‑Textvorschläge und lässt sich u. a. durch Prompt‑Optimierung des Basis‑Agenten, bessere Wiki‑Einträge oder zusätzliche Kundendaten aus der ERP‑Integration 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 Schließzeitpunkt 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.

​
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.
  • deparment - 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.