What is the Analytics and Data module?

These configurations pertain to custom attributes and configurations associated with Exchange of Information (EXI) application filters. The primary functionality of such settings is to structure the data handling processes by defining the data model relevant to the custom attributes. This allows you to create a system that's tailored according to your specific data management needs.

By customizing how the attributes associate with these data models, you improve the system's ability to process, manage, and interpret data, making it more efficient. In essence, these configurations play a crucial role in streamlining your data management tasks, thus enhancing overall productivity.

Configuring Analytics and Data

Custom attributes

Documentation for Registry Registrations Fields

Model

In the Registry Registrations, you're required to select a data model. This could either be the User Data Model or the Knowledge Article Data Model.

Example: If you want to store data related to users, you'd select the User Data Model.

The Model field determines how your data will be structured and categorized in the system.
Attributes

Custom attributes are additional parameters associated with the chosen data model.
- Name: Enter the name of the Custom Attribute that you expect for the chosen data model. Ensure this field matches, case-sensitively, with the name in the external system.
  
  Example: If a user is associated with a VIP status in your system, you'd enter "is_vip" as a custom attribute.
- Data Sensitivity Policy Policy Type: Select the type of sensitivity policy that the custom attribute should follow. The policy type option includes Customer Data.
  
  Example: If the custom attribute is dealing with sensitive user data, you'd select CUSTOMER_DATA_USER_DATA.

The Registry Registrations tab allows you to register and manage data models within your system. It provides key details about chosen data models and their custom attributes, helping organize and structure your data efficiently. Importantly, it ensures data matches exactly with the information from the external system, streamlining any data-related processes you execute.

Application Config

https://help.moveworks.com/docs/moveworks-setup-application-config

Bot Insights Config

Documentation for Issue Resolution Efficiency Fields

Measuring Issue Resolution Efficiency within 24 Hours

This denotes whether an issue is considered resolved if a user resets their password within 24 hours of receiving a password expiry notification.

Example: If set to "true", the system will include those instances where a user resets their password within 24 hours after receiving a notification about password expiry in calculating resolution efficiency.
Benchmark MTTR (Mean Time to Resolution)

This represents the average time expected to resolve issues prior to the bot's operation. This number is usually provided by the pre-sales team. The default value is 2820.

Example: If the Benchmark MTTR is set to 2820, this means that, on average, it took 2820 minutes to resolve an issue before the bot was implemented.
Agent Minutes Saved per Resolution

This shows the amount of agent time, in minutes, saved for each issue resolved by the bot. The default value is 48.

Example: If the default value of 48 is used, with each bot resolution, you're saving 48 minutes of an agent's time.
Agent Minutes Saved per Ticket Accelerated

This is the amount of agent time, in minutes, saved for each bot-accelerated ticket. The default value is 5.

Example: If this field is set to 5, then for each ticket sped up by the bot, you're saving 5 minutes of an agent's time.
Agent Minutes Saved per Accurate Triage

This represents the amount of agent time, in minutes, saved each time the bot accurately triages a ticket. The default value is 5.

Example: If the default value of 5 is used, an accurate triage by the bot saves an agent 5 minutes.
Employee Productivity Factor

This is the ratio of productive work time to total wait time for each issue resolution for each employee. The default value is 0.02.

Example: If the default value of 0.02 is used, that means the productive work time makes up 2% of the total wait time in the resolution process per employee.
Interaction Resolution Acceleration Factor

This stands for the portion of the original Time to Resolution (TTR) that becomes the new TTR because it benefits from issue acceleration and user interaction with the bot. The default value is 0.15.

Example: If its value is set to 0.15, then 15% of the original TTR becomes the new TTR due to bot acceleration.
Employee Minutes Saved per Lookup

This applies to the number of employee minutes saved per lookup operation. The default value is 1.

Example: With the default value of 1, an employee saves one minute per lookup operation.

Each of these fields helps ensure that the bot accelerates issue resolution and contributes towards increased agent and employee productivity by reducing resolution time and enhancing work efficiency. These factors are crucial in driving performance analytics and business outcomes.

Analytics Value Config

1. Hourly Agent Salary

This denotes the hourly wage of an agent. It is derived from the agent's annual salary or from the total service contract divided by the number of service desk agents.
Example: If an agent's yearly salary is $62,400, their hourly wage would be $30 (assuming a 40-hour week over 52 weeks).

2. Hourly Employee Salary

The rate at which an employee's productive time is valued. This can be ascertained from the company's revenue per employee or individual employee's salary.
Example: An employee earning an annual salary of $124,800 will have an hourly wage of $60.

3. Non-Bot TTR (Time to Resolution)

This refers to the duration it takes for an issue to be solved by an agent, excluding time serviced by bots. This replaces the pre-bot TTR provided prior to a customer being with us for more than 2 years or a significant change in service desk offerings.
Example: If, on average, an agent takes 48 hours to resolve a ticket, the Non-Bot TTR would be listed as 48 hours.

4. Non-Bot TTR (Time to Resolution) for Answers Related Tickets

A similar metric to the overall TTR, but aimed specifically at issues pertaining to questions and answers.
Example: If the time taken to resolve answers related tickets is, on average, 36 hours, this is the Non-Bot TTR for Answers related tickets.

5. Non-Bot TTR for Access Software Related Tickets

This pertains to the resolution time taken by service agents for access software-specific issues.
Example: If access software related tickets take around 48 hours to be resolved by service agents, this value will be used.

6. Non-Bot TTR for Access Account Related Tickets

This metric measures the mean resolution time for matters related to access accounts.
Example: If tickets related to access accounts take 24 hours to resolve, this is the Non-Bot TTR for Access Account related tickets.

7. Non-Bot TTR for Access Group Related Tickets

This helps calculate the resolution time of issues concerning access groups.
Example: If an issue on access group is resolved in 10 hours on average, the TTR for Access Group related tickets is 10 hours.

8. Non-Bot TTR for Form Filling Related Tickets

Resolution time taken for form filling issues is recorded with this metric.
Example: If it takes, on average, 6 hours to resolve a form filling issue, then the Non-Bot TTR for form filling related tickets is 6 hours.

9. Non-Bot TTR for Permission Control Related Tickets

This stands for the average time agents take to resolve permission control issues.
Example: If the mean resolution time for permission control issues is about 2 hours, that's the Non-Bot TTR for permission control related tickets.

10. Non-Bot TTR for Ticket Approvals

The resolution time for approval actions on tickets by agents is covered under this attribute.
Example: If agents on average take 12 hours to approve a ticket, that would be the Non-Bot TTR for approval actions.

11. Agent Time to Accelerate

This metric refers to the active hours spent by an agent in expediting a ticket, with a typical benchmark of 0.08 hours (5 minutes).
Example: If an agent spends just under 5 minutes (0.07999999821186066 hours), they're meeting the standard.

12. Agent Time to Triage a Ticket

This represents the time spent by an agent to classify and prioritize a ticket, usually expected to be around 0.08 hours (5 minutes).
Example: Assume an agent on average spends 0.07999999821186066 hours to categorize a ticket, they're adhering to the benchmark.

13. Agent Time to Approve a Ticket

Measured as the active hours an agent takes to approve a ticket. Benchmark being at 0.08 hours (5 minutes), doubled for this specific task.
Example: An agent typically takes twice the usual time (0.1599999964237213 hours) to approve a ticket.

14. Agent Time to Resolve a Ticket

This signifies the active time associated with an agent's resolution of a ticket, estimated to be 0.75 hours (45 minutes).
Example: If it took an agent up to 40 hours to resolve a ticket, they're significantly exceeding the expected resolution time.

15. Agent Time to Resolve a Troubleshooting Ticket

This measures the time it takes for an agent to address and resolve a troubleshooting issue