In this export, Enneo captures all edits to customer concerns. It is particularly well suited for measuring the volume achieved in the Service Centre. The following information is exported:

​
Edit Time (duration)

Enneo determines the editing times (AHT, “Average Handling Time”) in ticket processing by adding 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 when the user opens the ticket – either manually or via skill-based routing.
  • Editing time: The point at which the user made an edit to the ticket. If there are several edits, the time of the first edit is used.
  • End time: Date of the last browser access to a ticket.
The editing time (duration in the export) is the difference between the end time and the start time. The post-processing time (durationAfterWork in the export) is the difference between the editing time and the end time.

​
Frequently asked questions about editing time:

  • Handling distributed edits: 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 just reads it at noon
    • User 3 re-opened the ticket in the evening after 2 minutes of editing and set it to pending.
    • -> Enneo records here two edits: 1 15-minute edit by User 1, no edit/capture for User 2 and 1 2-minute edit by User 3. This would result in an average daily AHT of (15+2)/2=8.5min
  • Consideration for intra-day replies: If a user works on Ticket 1 for 5 minutes in the morning and 7 more minutes in the afternoon because the customer had a question at noon, these two time blocks will be counted as two separate edits. The AHT is then (5 + 7) / 2 = 6 minutes. If the customer had not replied at noon and the user was working on the same ticket twice, e.g. 5 minutes in the morning and 7 minutes in the afternoon without a return question, this would count as one edit totaling 12 minutes.
  • Parallel editing: If a user has multiple tickets open simultaneously in different browser windows, the AHT is distributed across the tickets. This way, there is never a double count. Example: If a user processes 4 tickets in parallel over 20 minutes, an AHT of 20 / 4 = 5 minutes results.
  • Status: Only when the user is in “Active” status, the time is counted towards the AHT. You can find more information about this in the User Status section down below.

​
Type of Edit (action)

Enneo only records an “edit” (i.e., a user’s work) if a ticket has been not only viewed but actually edited. Four types of editing are distinguished (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 which has been requested from the customer. As soon as this information is available, editing can continue.
  • Editing without reply (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 from the billing system. A separate reply is therefore not necessary.
  • Editing with response (writeAction): A ticket was closed with a response. Example: A customer has asked a question which is answered.
  • Dark-processing (autoProcessAction): A ticket was autonomously closed by an Enneo AI agent configured for dark processing. Example: A customer wants a payout of credit, and the corresponding AI agent arranges this automatically.
If there were multiple edits (e.g., if a ticket was first closed and then a reply was sent), the type of editing with the higher priority according to the above order applies. In this case, “Editing with response” (writeAction) would be recorded.

​
Case-closing Edit (reOpened)

If this value is set (= 1), the ticket was reopened after closing – either by a follow-up answer from the customer or by a colleague. This allows for the capturing of the First-Contact-Resolution quote.

​
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 by default “Active” (also called “Ticket processing”). This status allows tickets to be edited, and time is recorded.
  • Support: If supportive services need to be provided (e.g., assistance for colleagues), this status can be selected. In this mode, read access is possible, but any editing is blocked. No time is recorded in this status either.
  • Pause: Pause 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 pause mode. Upon returning, a popup appears in which it is determined how the time should be booked. If “Active” is selected, the respective time will be counted towards the AHT.
The user status modes and settings for auto-absence are freely configurable under Settings -> Advanced Settings -> General -> Time Recording -> Time Recording Selection Options.

​
Author’s Name (name) / Data Protection

In the editing export, performance-related data such as editing quantities and times are provided. If desired, Enneo can make this inaccessible. There are three levels of data protection available:
  • Anonymisation: No conclusions about who made which editing when. Each edit is listed under the user “Anonym”.
  • Pseudonymisation: Instead of clear names (e.g., “Meike Mustermann”), Enneo assigns random pseudonyms (e.g., “Hungry Raspberry”).
  • Clear Names: The clear names of the editors (e.g., “Meike Mustermann”) are displayed.

​
Degree of Automation of the Editing (aiAutomationLevel)

Records the highest automation level observed in the editing (value range 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 has used AI for text editing
  • L2: User has manually confirmed the suggestion of the basis agent (with or without adjustments)
  • L3: User has manually confirmed the suggestion of another (not basis) agent
  • L4: Auto processing with approval (approval required)
  • L5: Fully autonomous auto processing

​
Correct customer recognition (customerIdentifiedCorrectly)

1/0 flag indicating if the customer was correctly identified, i.e. no correction was necessary during a manual adjustment. This field measures the data quality and friction in the intake process and shows potential for improvement in recognition prompts or in the customer code for customer search.

​
Correct Tag Recognition (tagsIdentifiedCorrectly)

1/0 flag indicating if the assigned tags (e.g., Skill tags, Product tags) were correctly identified, i.e. without subsequent manual correction. Tag recognition can be optimized using recognition 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 - provided 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 base is available. This field measures the utility value of the AI text suggestions. This value can be improved through base agent prompt optimization, 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 adoption tracking and impact analysis per agent. 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 possible cherry-picking or for revealing routing problems.

​
SLA Deviation at Closure (netSecondsClosedAfterSLA)

Seconds between the “processing time from the customer’s perspective” and SLA due date - net, i.e. taking into account the configured working hours and without weekends/non-working times. A negative value means closed on time, a positive value delayed. NULL if no SLA due date could be determined. See also Routing and Tags → SLAs and Working Hours. The “processing time from the customer’s perspective” is defined as the time of response sending, closing or in the case of dark processing using AI, the processing time. If there are multiple times, the earliest one is taken.

​
Processor’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 displayed. topic represents the main category (e.g. “General”), subTopic the subcategory (e.g. “IN: Installment/JVB”). Both fields can be NULL if there is no classification.

​
Channel (channel)

Contact channel for the customer inquiry (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 capture of 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 currently still captured, but will be removed in a future release:
  • aiAgentId - Name of an AI agent used in the processing. Replaced by aiAgentsUsed, since several 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 - E-mail address of the processor. As alternatives, the processor’s name (name) or the user ID (userId) can be used.
  • 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.