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:
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
