In this export, Enneo captures all the customer request modifications. It is particularly suitable for measuring the volume realized in the service center. The following information is exported:

Processing time (`duration`)

Enneo determines the processing times (AHT, "Average Handling Time") in ticket processing by summing up the entire screen time of the browser on a ticket. Three points in time are relevant for this:

Start time: The moment when the user opens the ticket - either manually or by skill-based routing.
Processing time: The moment when the user made changes to the ticket. If there are multiple modifications, the time of the first change is used.
End time: Day of the last browser access to a ticket.

The processing time (duration in export) is the difference between the end and start times. The post-processing time (durationAfterWork in export) is the difference between the processing and end times.

Frequently Asked Questions about processing time:

Handling distributed modifications: If a ticket is processed several times on the same day, for example in different sessions, the times are aggregated. Example:
- User 1 looks at a ticket in the morning for 5 minutes and then closes it at noon after another 10 minutes of processing time.
- User 2 is reading it at noon only.
- User 3 reopened the ticket in the evening after 2 minutes of editing and set it on standby.
- -> Enneo captures two modifications here: 1 modification of 15 minutes by User 1, no modification / recording for User 2, and 1 modification of 2 minutes by User 3. This results in an average daily AHT of (15+2)/2=8.5min
Consideration of during-the-day responses: If a user works on Ticket 1 in the morning for 5 minutes and then again in the afternoon for another 7 minutes because the customer asked a question at noon, these two time blocks count as two separate modifications. The AHT is then (5 + 7) / 2 = 6 minutes. If the customer had not responded at noon and the user worked on the same case twice, e.g. 5 minutes in the morning and 7 minutes in the afternoon without querying, this would count as one modification with a total of 12 minutes.
Parallel modifications: If a user has multiple tickets open at the same time in different browser windows, the AHT is distributed over the tickets. Thus, there is never any double counting. Example: If a user processes 4 tickets in parallel over 20 minutes, the AHT is 20 / 4 = 5 minutes.
Status: Time is only counted towards AHT when the user is in the "Active" status. More information can be found in the User Status section further below.

Type of modification (`action`)

Enneo only records a "modification" (i.e., the work of a user) if a ticket was not just read but was actually modified. There are four types of processing (in parentheses, the designation in data export):

Status set to Waiting (statusAction): The processing party has set the status of a ticket to "Waiting". Example: Information is missing that has been requested from the customer. As soon as this is available, processing can continue.
Modification without answer (closeAction): A ticket was closed by the processor without an answer being sent to the customer. Example: The customer wants to cancel, and the cancellation confirmation is sent by the billing system. A separate answer is therefore not necessary.
Modification with answer (writeAction): A ticket was closed with a response. Example: A customer has asked a question that is answered.
Dark processing (autoProcessAction): A ticket was autonomously closed by an Enneo AI agent configured for dark processing. Example: A customer wants a credit payout, and the respective AI agent automatically initiates this.

If there were multiple modifications (e.g., if a ticket was first closed and then an answer was sent), the type of modification with the higher priority according to the above order is considered. In this case, "Modification with answer" (writeAction) would be recorded.

Case concluding modification (`reOpened`)

If this value is set (= 1), the ticket was reopened after closing - either through a subsequent answer from the customer or by a colleague. This allows for a capture of the First Contact Resolution rate.

User Status (`status`)

Enneo has different status modes for users. By default, there are four status modes available:

Active: After logging in, a user is by default "Active" (also known as "Ticket processing"). In this status, tickets can be processed, and time is recorded.
Support: If support services need to be provided (e.g., assistance for colleagues), this status can be selected. In this mode, read accesses are possible, but any modifications are blocked. Also, no time is recorded in this status.
Break: Break mode. Neither read nor write access is possible, and no time is recorded.
Auto-Away: After a configurable period of inactivity, a user can automatically be put into break mode. On returning, a popup appears in which it is determined how the time should be booked. If "Active" is selected, the corresponding time will be counted towards AHT.

The User Status modes and Auto Away settings can be configured freely under Settings -> Advanced Settings -> General -> Time Recording -> Time Recording Options.

Name of the processor (`name`) / Data Protection

The processing export provides performance-related data such as processing volumes and times. If desired, Enneo can make this inaccessible. There are three levels of data protection available:

Anonymity: No conclusions can be drawn as to who made what modifications, when. Each modification is listed under the user "Anonym".
Pseudonymization: Instead of clear names (e.g., "Meike Mustermann"), Enneo assigns random pseudonyms (e.g., "Hungry Raspberry").
Clear names: The processors' clear names (e.g., "Meike Mustermann") are displayed.

Degree of automation of the modification (`aiAutomationLevel`)

Captures the highest level of automation observed in the modification (value range 0–5). This field supports the measurement of progress towards dark processing.

The levels at a glance:

L0: No AI support, except customer/tag recognition
L1: User used AI for text processing
L2: User manually confirmed the suggestion of the base agent (with or without adjustments)
L3: User manually confirmed the suggestion of another (not base) agent
L4: Auto processing with release (approval required)
L5: Fully autonomous auto processing

Correct customer identification (`customerIdentifiedCorrectly`)1/0 flag indicating if the customer was correctly identified i.e., no corrections were needed during a manual adjustment. This field measures data quality and friction in the intake process and shows potential for optimization in detection prompts or in the customer code for customer search.

Correct tag recognition (`tagsIdentifiedCorrectly`)

1/0 flag, whether the assigned tags (e.g., skill tags, product tags) were correctly identified i.e., without subsequent manual correction. Tag recognition can be optimized through detection prompts.

Quality of text assistance (`textAssistanceAccuracy`)

Numerical similarity as a value between 0 and 1 (e.g., 0.9843 for 98.43%) between the text recommended by the base agent and the text actually sent - assuming the base agent was used. The similarity is calculated as 1 minus normalized text difference (e.g., so-called normalized Levenshtein distance). NULL if no base agent was used or there was no comparison basis. This field measures the value of the AI text suggestions. The value can be improved by prompt optimization of the base agent, better wiki entries, or additional customer data from the ERP integration.

AI agents used (`aiAgentsUsed`)

JSON array of the names of the AI agents used in processing. Supports adoption tracking and impact analyses per agent. It may 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 identifying potential cherry picking or exposing routing problems.

SLA deviation when closing (`netSecondsClosedAfterSLA`)

Seconds between the "processing time from the customer's perspective" and SLA due date – net, i.e., considering the configured working hours and excluding weekends/non-working hours. A negative value means the case was closed on time, a positive value indicates a delay. NULL if no SLA due date could be determined. Also see Routing and Tags → SLAs and Working Hours.

The "processing time from the customer's perspective" is defined as the time of sending the response, closing, or in case of dark processing using AI, the processing time. If there are multiple times, the earliest is taken.

Technical Fields

These are only filled if enneo does not anonymize the users (see field name / Privacy).

date - The time the editing was recorded.
ticketId - Ticket ID of the ticket that was edited.
conversationId - Conversation ID of the customer's last message at the time of editing. NULL if it was an initial inquiry.
userId - User ID of the editor.
userWorklogId - Unique ID of the processing (primary key).

Obsolete Fields

The following fields are currently still recorded, but will be removed in a future release:

aiAgentId - Name of an AI agent that was used in the editing. Replaced by aiAgentsUsed, as multiple agents can be used per editing.
department - Comma-separated list of the editor's departments. Replaced by teams, which represents this as a JSON array and is therefore easier to process.
allTags - Comma-separated list of all tags assigned to the ticket. Replaced by tags, which represents this as a JSON array and is therefore easier to process.
email - E-mail address of the editor. Alternatives can be the editor'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 clearly identified via ticketId and conversationId.

Modifications