In this export, Enneo records all edits of customer requests. 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”) during ticket processing by summing up the total screen time of the browser on a ticket. Three points in time are relevant for this:
  • Start time: The point in time at which the user opens the ticket - either manually or by skill-based routing.
  • Processing time: The point in time at which the user has made an edit to the ticket. If there are several edits, the time of the first edit will be used.
  • End time: Date of the last browser access to a ticket.
The processing time (duration in export) is the difference between the end and start time. The post-processing time (durationAfterWork in export) is the difference between the processing time and the end time.

​
Frequently asked questions about processing time:

  • Handling distributed editing: If a ticket is edited 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 editing time.
    • User 2 only reads it at noon
    • User 3 reopened the ticket in the evening after 2 minutes of editing and set it to waiting.
    • -> Enneo records two edits here: 1 edit of 15 minutes from User 1, no edit/record for User 2 and 1 edit of 2 minutes from User 3. This would result in an average daily AHT of (15+2)/2=8.5min
  • Intraday responses consideration: If a user works on Ticket 1 for 5 minutes in the morning and another 7 minutes in the afternoon because the customer had a query at noon, these two time slots count as two separate edits. 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 a query, this would be counted as one edit with a total of 12 minutes.
  • Parallel editing: If a user has multiple tickets open simultaneously in different browser windows, the AHT is distributed across the tickets. There is therefore never double counting. Example: If a user edits 4 tickets parallel for 20 minutes, the AHT is 20 / 4 = 5 minutes.
  • Status: Only when the user is in the “Active” status, the time is counted towards the AHT. For more information, see the User Status section below.

​
Type of editing (action)

Enneo only records an “edit” (i.e., a user’s work) if a ticket has not just been viewed, but actually edited. Four types of editing are distinguished (bracketed is the name in the data export):
  • Status set to waiting (statusAction): The editor has set a ticket’s status to “Waiting”. For example: there is a lack of information that has been requested from the customer. Once this is available, processing can continue.
  • Editing without response (closeAction): A ticket was closed by the editor without a response being sent to the customer. For example: The customer wants to cancel, and the cancellation confirmation is sent by the billing system. Therefore, a separate response is not necessary.
  • Editing with response (writeAction): A ticket was closed with a response. For example: A customer has asked a question that is being answered.
  • Dark processing (autoProcessAction): A ticket was closed autonomously by an Enneo AI agent configured for dark processing. For example: A customer wants a credit payment, and the corresponding AI agent arranges this automatically.
If there were several edits (e.g., if a ticket was first closed and then a response was sent), the type of edit with the higher priority according to the above order applies. In this case, “Editing with response” (writeAction) would be recorded.

​
Case-closing editing (reOpened)

If this value is set (= 1), the ticket was reopened after being closed – either by a subsequent response from the customer or by a colleague. This makes it possible to record the First-Contact-Resolution rate.

​
User status (status)

In Enneo, there are various status modes for users. By default, four status modes are available:
  • Active: After logging in, a user is “Active” by default (also called “Ticket processing”). In this status, ticket processing is possible and time is recorded.
  • Support: If supporting services need to be provided (e.g., helping colleagues), this status can be chosen. In this mode, read access is possible, but all edits are blocked. No time is recorded in this status either.
  • 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 be automatically set to break mode. Upon returning, a pop-up appears in which it is determined how the time should be booked. If “Active” is selected, the corresponding time is counted towards the AHT.
The User Status Modes and Auto-Away settings can freely be configured under Settings -> Advanced Settings -> General -> Time Recording -> Time Recording Options.

​
Editor’s Name (name) / Data protection

The editing export provides performance-related data such as processing volumes and times. If desired, Enneo can make these inaccessible. There are three data protection levels available:
  • Anonymization: No conclusions as to who made which edit when. Each edit is listed under the user “Anonymous”.
  • Pseudonymization: Instead of clear names (e.g., “Jane Doe”), Enneo assigns random pseudonyms (e.g., “Hungry Raspberry”).
  • Clear names: The clear names of the editors (e.g., “Jane Doe”) are displayed.

​
Degree of automation of the edit (aiAutomationLevel)

Records the highest level of automation observed in the edit (values range from 0–5). This field supports the measurement of progress towards dark processing. The stages at a glance:
  • L0: No AI support, except for 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: Completely autonomous auto processing

​
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 the detection prompts.

​
Quality of Text Assistance (textAssistanceAccuracy)

Numeric 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. Similarity is calculated as 1 minus normalized text difference (e.g., so-called normalized Levenshtein distance). NULL, if no base agent was used or no comparison basis exists. This field measures the utility of AI text suggestions. The value can be improved through 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 AI agents used in processing. Enables adoption tracking and impact analyses per agent. 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 detecting possible cherry picking or for uncovering routing problems.

​
SLA Deviation at Closure (netSecondsClosedAfterSLA)

Seconds between the time of closure and the SLA due date – net, i.e., taking into account the configured working hours and excluding weekends/non-working hours. A negative value means closed on time, a positive value means delayed. NULL, if no SLA due date could be determined. Also, see Routing and Tags → SLAs and working hours.

​
User’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 analyses on a tag level and flexible filters.

​
Topic Classification (topic, subTopic)

If configured, a topic classification is displayed. topic represents the main category (e.g., “General”), subTopic the subcategory (e.g., “Invoice: Advance Payment/Standard Rate”). Both fields can be NULL if no classification exists.

​
Channel (channel)

Customer request contact channel (e.g., email, mail). Can be NULL if not determinable.

​
Technical fields

These are only filled if Enneo does not anonymize the users (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 captured but will be removed in a future release:
  • aiAgentId - Name of an AI agent used in processing. Replaced by aiAgentsUsed, as multiple agents can be used per processing.
  • department - Comma-separated list of the processor’s departments. Replaced by teams, which displays 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 displays this as a JSON-array and is thus easier to process.
  • email - Email address of the processor. As alternatives, the name of the processor (name) or the user-ID (userId) can be used.
  • rawData - JSON-string of the rawData value of the ticket/message. No longer necessary, as messages can be uniquely identified via ticketId and conversationId.