Metrics Glossary

Quick links in this article:

In this article, we’ll cover the calculation and definition for metrics found in Gnatta Reporting and/or Dashboards.

Interactions

In this section:

Interactions Closed

Calculates the number of interactions closed between two dates, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

Why is Gnatta Reporting and Make HTTP Request Interaction data different?

Let’s run through a scenario to explain why you may see different values externally compared to Gnatta Analytics. Consider the following scenario:

If you’re collecting reporting data from a Make HTTP Request action via Workflow, you’ll receive the Interaction Closed occurrence for both occasions the interaction is closed i.e. two separate data points. This is because data is pushed to your endpoint every time an interaction is Closed.

In Gnatta Analytics, we’re able to view the current status of the interaction to determine whether it is Closed or not. This provides a more dynamic, accurate view on interaction statuses.

Interactions Closed by Channel

Calculates the number of interactions closed between two dates for the channels provided, and if applicable groups them into hours, days, weeks or months and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The channels property is required, and must contain at least one valid value (Facebook, Instagram, Email, Twitter, SMS, Voice, TrustPilot, WebChat).

Interactions Closed by Data

Calculates the number of interactions closed between two dates for the data provided, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The data property is required and must be a single or status select type, or a string editor type that’s been marked as reportable. You must also explicitly specify the string editor values you want to group by.

Interactions Closed by Queue

Calculates the number of interactions closed between two dates for the queues provided, and if applicable groups them into hours, days, weeks or months and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The queues property is required, and must contain at least one valid queue.

Interactions Closed by User

Calculates the number of interactions closed between two dates for the users provided, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The User property is required and most contain at least one valid user.

Interactions Received

Calculates the number of interactions received between two dates, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

Interactions that move directly into a Closed state from Draft have been excluded here to prevent interactions that were created, never used, and then subsequently closed (manual creation) from skewing reports.

Interactions Received by Channel

Calculates the number of interactions received between two dates for the channels provided, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The channels property is required, and must contain at least one channel (Facebook, Instagram, Email, Twitter, SMS, Voice, TrustPilot, WebChat).

Interactions Received by Queue

Calculates the number of interactions received between two dates for the queues provided, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The queues property is required, and must contain at least one valid queue.

Interactions Reopened

Calculates the number of interactions reopened between two dates, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

All interactions are considered reopened when they transition out of a Closed state into any of Queued/Assigned/Automation.

Interactions Reopened by Channel

Calculates the number of interactions reopened between two dates for the channels provided, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The channels property is required, and must contain at least one valid channel (Facebook, Instagram, Email, Twitter, SMS, Voice, TrustPilot, WebChat).

Interactions Reopened by Queue

Calculates the number of interactions reopened between two dates for the queues provided, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The queues property is required, and must contain at least one valid queue.

Time interactions spent queueing by Queue (per channel)

Calculates the average time taken for an interaction’s state to transition from Queued to Assigned, but only where the interaction matches the given channels filter. In order to obtain channel specific data, e.g. for an “Email Time in Queue” Tile, only one channel should be provided (in this case Email).

If applicable, results are grouped into hours, days, weeks or months and then if provided, filters (data in this case) to audits found within that timeframe.

The queues property is a required field and must contain at least one valid queue.

Messages

[Go to top of article]

In this section:

Message Volume

Calculates the number of out/inbound messages sent/received between two dates, and if applicable groups them into hours, days, weeks or months and then if provided, filters (channels/queues/data in this case) to audits found within that timeframe.

Message Volume by Channel

Calculates the number of messages sent/received between two dates for the channels provided, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The channels property is required, and must contain at least one valid channel (Facebook, Instagram, Email, Twitter, SMS, Voice, TrustPilot, WebChat).

Message Volume by Queue

Calculates the number of messages sent/received between two dates for the queues provided, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The queues property is required, and must contain at least one valid queue.

Message Volume by Account

Calculates the number of interactions sent/received between two dates for the accounts provided, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The accounts property is required, and must contain at least one valid media account.

Message Volume by User (Outbound only)

Calculates the number of messages sent between two dates for the users provided, and if applicable groups them into hours, days, weeks or months (by-date endpoint), and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The Users property is required, and must contain at least one valid user.

Wait Times

[Go to top of article]

In this section:

Advisor Response & Customer Wait Times

These metrics are message based, which means they can be filtered by the channel, queue and dynamic data set against the interaction at the time the message was sent.

Customer Wait Time - Time is measured between the first inbound message without a response and the next advisor response. This is to prevent multiple inbound messages from skewing wait times. For example:

In this example, the customer wait time is measured between 12:01 and 12:05.

Advisor Response Time - Time is measured between the first inbound message without a response (after assignation) and the next advisor response.

The interaction the message belongs to must be in a state of Assigned. If there is an inbound message, it can not already have an outbound response. If the last unresponded to inbound message was sent after the interaction was assigned, the time is the difference between that inbound message and the current outbound one. Else it is the difference between when the interaction entered the Assigned state, and when the current outbound message was created.

This prevents the advisors response time from being skewed based on how long the interaction was waiting in a queue, as they are only able to control their response time once it has been assigned. For example:

In this example, the customer wait time is measured between 12:03 and 12:05.

Calculation

Calculates the average time between two dates, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (channels/queues/data in this case) to audits found within that timeframe.

Advisor Response & Originator Wait Times by Channel

Calculates the average time between two dates for the channels provided, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The channels property is required, and must contain at least one valid channel (Facebook, Instagram, Email, Twitter, SMS, Voice, TrustPilot, WebChat).

Advisor Response & Originator Wait Times by Queue

Calculates the average time between two dates for the queues provided, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The queues property is required, and must contain at least one valid queue.

Advisor Response & Originator Wait Times by Account

Calculates the average time between two dates for the accounts provided, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (State/channels/queues/data in this case) to audits found within that timeframe.

The accounts property is required, and must contain at least one valid media account.

Live Conversations

[Go to top of article]

In this section:

There are currently two live channels (WebChat and Voice) with specific reporting available to them based around abandonment and handling data.

WebChat

• Abandoned by Customer - The chat ended before it was in progress with an operator.

• Abandoned by Operator - The chat was in progress with an operator but the last outbound message was before the chat made it’s way to that operator. i.e. The chat was ended and no outbound messages were sent after it was assigned.

• Handled - Anything not captured by the above.

Voice

• Abandoned by IVR - When the call was ended the caller was currently going through an IVR process i.e. Caller is listening to a file or text from a Play Audio action or has been asked for input via an IVR Input action (both configurable via Workflow).

• Abandoned - Call was ended after exiting the IVR, but before both the operator and the caller were connected to one another.

• Handled - Call was ended after both the operator and the caller had connected to one another.

In order to be counted, the conversations must be set to a Closed state (the abandonment metrics can’t be calculated if they haven’t ended).

Abandonment/Handled Percentages by Account

Retrieves the total number of live conversations for the specified channel and returns the abandonment/handled counts as a percentage of their total. If applicable they are also grouped into hours, days, weeks or months, and then if provided, filters (State/queues/data in this case) to audits found within that timeframe.

The accounts property is required, and must contain at least one valid media account.

Abandonment/Handled Totals by Account

Retrieves the total number of live conversations for the specified channel and returns the abandonment/handled raw totals. If applicable they are also grouped into hours, days, weeks or months, and then if provided, filters (State/queues/data in this case) to audits found within that timeframe.

The accounts property is required, and must contain at least one valid media account.

Average Duration by Account

Retrieves the total number of live conversations for the specified channel and returns the average duration of those conversations. If applicable they are also grouped into hours, days, weeks or months, and then if provided, filters (State/queues/data in this case) to audits found within that timeframe.

The way the durations are calculated differs based on the channel.

WebChat Duration

Calculated from when the originator is first connected to an agent, to when the conversation reaches a Closed state. Chats can potentially connect multiple times depending on their Workflows and automation, so the first connection is used to prevent automation journeys from skewing chat duration.

Voice Duration

• Inbound - Calculated from the first operator joining to the time the call was ended.

• Outbound - Calculated from the operator joining to the time the call was ended.

Telephony Time in IVR by Queue

Retrieves interactions for the specified channel and returns the average duration that those interactions spent transitioning from an Automation state (IVR) to any of Closed/Assigned/Queued. If applicable they are also grouped into hours, days, weeks or months, and then if provided, filters (channels/queues/data in this case) to audits found within that timeframe.

The queues property is required, and must contain at least one valid queue.

Contacts-per-hour

[Go to top of article]

In this section:

Contacts per hour (CPH) - Available vs Logged In

There are two ways in which we view CPH data, based on the user states Available and Logged In. These indicate the time restrictions we should use when calculating when and how long an operator was actually working.

User States

Logged In - The total time the operator spent logged into Gnatta, in any user state.

Available - The time the operator spent only in an Online user state - time spent in any other state (i.e. Away or Busy ) will be excluded even if interactions are handled in that time.

What is a ‘contact’?

A valid contact is any interaction where a user has completed at least one action (provided they are in an Available or Logged In state). Any of the below actions can be counted against an interaction:

Closed - The advisor has closed an interaction (the interaction may have been reopened and closed by someone else in the interim, an interaction can have multiple closures).

Message - The advisor has sent a message on the interaction.

Data - The advisor has modified the a data field on an interaction.

Note - The advisor has added a note to the interaction.

Only one action is necessary for the interaction to be counted i.e. if an advisor sends a message, changes a data field and sets the interaction to Closed, one contact will be recorded.

Contacts-per-hour

This calculates the total amount of time the user spent in either an Available or Logged In state, and then sums up the total number of contacts they did within those times to determine contacts-per-hour.

If the agent is online for a part of an hour (for example, an extra 15 minutes at the end of their shift) we will portray their productivity for that partial hour as an estimation based on the contacts they’ve done in that time. This is to avoid agents being penalised for partial hours.

For example:

In this example, the CPH calculation for 1pm - 2pm will be 8, even though they’ve only completed 2 contacts. This is because the number of contacts completed in that first 15 minutes will be used to project an estimation for the rest of the hour. i.e. The advisor has completed 2 contacts in the first 15 minutes, so as a total hour we can expect them to have a CPH of 8.

Contacts per hour (CPH) by Channel

Calculates the CPH for each user, grouped by the channels specified in the request.

The channels property is required, and must contain at least one valid channel. Only advisor actions completed in a user state of Available or LoggedIn are counted.

The Users property is also required, and will be used to group and filter the results retrieved.

Contacts per hour (CPH) by Queue

Calculates the CPH for each user, grouped by the queues specified in the request.

The queues property is required, and must contain at least one valid queue. Only advisor actions completed in a user state of Available or Logged In are counted.

The Users property is also required, and will be used to group and filter the results retrieved.

Contacts per hour (CPH) by User

Calculates the CPH between two dates for the users provided, and if applicable groups them into hours, days, weeks or months, and then if provided, filters (channels/queues/data in this case) to audits found within that timeframe.

Only advisor actions completed in a user state of Available or Logged In are counted. The Users property is required, and will be used to group and filter the results retrieved.

Users

[Go to top of article]

In this section:

Availability/Unavailability Duration by User

This returns the durations that your users were in either an Available or Unavailable state between the time ranges provided in the request. If applicable they are also grouped into hours, days, weeks or months, and then if provided, filters (channels/queues/data in this case) to audits found within that timeframe.

Available - The total time spent by the user in an Online state.

Unavailable - The total time spent by the user logged in, but in an Away or Busy state.

The Users property is required, and will be used to group and filter the results retrieved.

Availability/Unavailability Percentage by User

Very similar to the above, but returns the percentage that each user spent in an Available state vs the total time they spent logged in between the time ranges provided in the request. If applicable they are also grouped into hours, days, weeks or months, and then if provided, filters (channels/queues/data in this case) to audits found within that timeframe.

The Users property is required, and will be used to group and filter the results retrieved.

Advisor Metrics by User

This calculates the total number of contacts whilst Logged In vs Available, their CPH whilst Logged In vs Available, the amount of time they spent in aLogged In vs Available state, their unproductive time expressed as a percentage, and their average response time. (Please see previous section for more information on the individual metrics listed).

The Users property is required, and will be used to group and filter the results retrieved. All other filters (channels/queues/data) are optional, but the from/to dates will dictate the time range used to calculate the above stats.

Advisor Actions - Closed/Message/Data/Note/None/Any

The data in these tiles is stored as an audit record when an advisor is unassigned from an interaction, or when an advisor is replaced by another advisor on an interaction. When this happens, any messages sent, notes created, dynamic data changed or interaction closures will be recorded. Multiple of the same action in the same assignation period will not be counted - only one is required to meet the criteria.

Actions are:

• Closed - The advisor has closed an interaction (the interaction may have been reopened and closed by someone else in the interim, an interaction can have multiple closures).

• Message - The advisor has sent a message on the interaction.

• Data - The advisor has modified the dynamic data on an interaction.

• Note - The advisor has added a note to the interaction.

• None - The advisor has no Closed, Data, Message or Note actions logged against the interaction.

• Any - The advisor has at least one action of any type logged against the interaction.

The Users property is required, and will be used to group and filter the results retrieved.

Calculation

The count being returned refers to the number of audits that have been generated for that user. For example:

The count returned would be 2, one each for the two distinct periods the agent was assigned and audited against the interaction.

The results are returned grouped by the provided Users, then grouping them further if applicable by hours, days, weeks or months.

Automation

[Go to top of article]

There are three primary definitions to keep in mind with these metrics.

1. Automated- refers all messages or interactions that have, at any point, entered an automated state. This will include both fully and partially automated counts, and any interactions that haven’t yet been closed.

2. Fully Automated - refers to interactions that were passed straight from an automated to a closed state, without an agent’s intervention.

3. Semi-Automated - interactions that were automated and assigned/queued before reaching a closed state.

In order to be counted, the interaction must pass through an ‘Automation’ state. This state can be controlled via Workflow: Actions | Set Automation State

Automated messages are counted when the Send Autoresponse or Send WhatsApp Template actions are used.

There are 12 tiles available in this reporting category. They are:

• Automated messages

  • + by channel

  • + by queue

• Automated interactions

  • + by channel

  • + by queue

• Fully automated interactions

  • + by channel

  • + by queue

• Semi-automated interactions

  • + by channel

  • + by queue