Report accelerators is a project aimed at simplifying the report building process through a rich library of ready-to-use reports. The delivery process is iterative. Batches of reports will be available for download on the wiki.

The report accelerators consist of several export files that are built around 2 main groups. There is a first series that modifies the content of the lists from the Operation and Transition menus and another that creates reports you can add in the Continual Improvement menu.

In this package, all lists and reports are aimed at the first 2 layers of reporting and were built with a particular methodology in mind. They are not just a series of reports for the sake of having lots of reports. They present the information with a simple purpose: make sure you know who does what, what ticket is being processed and where you are at.

All reports and packages in this report accelerators series are based on one of the 3 layers of reporting:

• Layer 1 is aimed at operational reports which provide a forward view of your ticket queue. In effect, they allow you to manage all your ticket queues and understand who is working on what, how many tickets you have and what are the priorities you have.
• Layer 2 is aimed at analytical reports which provide more of a rear view. By that, we mean that these reports start providing you some answers on your productivity and allow to look back on the work that has been accomplished. With these reports, you will be able to determine how many tickets you received and you did, what is your resolution times, etc.
• Layer 3 is centered around data visualization and provides a consolidated view, using the dashboard and reports, of the first 2 layers.

Notes

• The content of each report is explained in the sections below. Each package can be downloaded and any updates will be posted there as well.
• Reports are based on a new, lighter, parent queries with a new naming convention for aliases.

• The double _ is used to separate the table (SD_REQUEST) where the origin of the information and the data which indicates what field was used to do the link. 

• Some reports may come with a methodology to ensure the information produced is accurate. This means that some modification to your environment such as adding fields to your form and database, adding business rules or modifying the configuration of your environment may be required. The recipe to use this report is included in every report detailed documentation.

• A custom widget is provided with some reports. Its integration procedure is very simple and is included with every element.

Best Practice

• Reports, filters, and views you’re interested in should be imported in the sandbox environment first, where they may be tested and tuned before integration in production.

Modification to incidents/service requests lists, filters and views

What they do

You may have noticed that the submenu under Operation > Incidents contains 3 options for listing tickets (All Incidents, Incidents for my Groups, My Incidents) while the same submenu under Operation > Service Requests only contains one option (Requests). This means that there is currently no easy way to see the service requests for your group or your own service requests. These new lists correct these inconsistencies and provide you a new series of filters and views for both sections.

How to set them up

The following packages modify the content of Operation > Incidents > All Incidents and Operation > Service Requests > Requests respectively.

• Go to the Administration > Import / Export > Import menu and import the 2 following packages:
         Export Package - EV Report Accelerators - OPERATION-INCIDENT
         Export Package - EV Report Accelerators - OPERATION-SERVICE REQUEST

• Once imported each menu will now provide the filters and views you may need to list all the tickets, your group(s) tickets or your personal tickets from just one submenu.
• With this addition, the Incidents for my Groups and My Incidents submenus are no longer needed. We advise you to remove them after this update. You can remove these options using the profile or by editing the menu directly.
• The same way, the new filters and views added by this import will sometimes be duplicates of ones you already have. We recommend you remove any duplicates and unnecessary items.
  

Naming convention

• In both Incidents and Service Requests, the standard filters are split into 3 groups:
  • GLOBAL: Shows all tickets
  • MYGRPS: Shows tickets owned by the group(s) you belong to
  • MYINC or MYSRQ: Shows the ticket you own

• Each new filter and views start with a *EV- to distinguish them from the others. You can rename them, but they will be recreated if you update with a newer package.

Special filters

There are a few filters that are designed for a very specific purpose.

Multiple transfers of incidents between groups

• Problem: A high ratio of unplanned, repeated transfer between groups causes an increase in the cost per ticket average.

• Solution: Find the tickets that are handled by 2 or more groups.

• Configuration: If your incident handling process involves 2 handling groups in standard, you can easily adapt the filters to replace the value with the relevant one:

Rejected resolutions

• Problem: List which tickets have been rejected, accepted or pending a validation.

• Solution: Each of filters will let you see the tickets who have approved, rejected or pending validation in the last 60 days. The 60-day limit can be configured.

• Configuration: By default, the filters consider incidents issued the last 60 days only. You may replace the default with the value that fits better in your environment simply by editing the filter:

Adding new reports

What they do

This package contains a series of reports that can be added to your Continual Improvement menu or that can be accessed in the Reports menu in both Operation and Transition. They cover incidents, service requests, changes and problems. They also introduce a new set of consolidated reports for the first time.

• These reports allow you to view all tickets together.
• Each set of reports presents the information for all tickets in the organization or for just your groups. The latter is similar to the lists you can find under Operation or Transition.
• Each report set creates a new parent query that starts with the prefix EV_.
  Caution: While you can modify this parent query, be advised that a future update to these reports may overwrite your modification.
• In addition, these reports include widgets that can be included in any Service Apps dashboard.

How to add the reports

Each group of reports is built on a new set of Parent Queries. We have separated the parent queries from the reports to make it easier to update one without affecting the other. Check the last update on both the queries and reports. If both have the same date, then you must update the parent queries before importing the reports otherwise, the reports will not work. 

Each package below contains 8 reports: 4 reports to list all tickets and 4 to list your group tickets. You will need to import them into Service Manager.

Parent queries

Note: Only import if you do not have a prior version of the reports or if the last update is the same as the reports.

Go to the Administration > Import / Export > Import menu and import the 5 following packages.

Package to import	Last updated
Export Package - Parent Queries - ALL	2018/01/24
Export Package - Parent Queries - ALL (MY GROUPS)	2018/01/24
Export Package - Parent Queries - INCIDENT	2018/01/24
Export Package - Parent Queries - INCIDENT (MY GROUPS)	2018/01/24
Export Package - Parent Queries - PROBLEM	2018/01/24
Export Package - Parent Queries - PROBLEM (MY GROUPS)	2018/01/24
Export Package - Parent Queries - SERVICE REQUEST	2018/01/24
Export Package - Parent Queries - SERVICE REQUEST (MY GROUPS)	2018/01/24
Export Package - Parent Queries - CHANGE	2018/01/24
Export Package - Parent Queries - CHANGE (MY GROUPS)	2018/01/24

Reports

Go to the Administration > Import / Export > Import menu and import the 5 following packages.

Package to import	Last updated
Export Package - EV Report Accelerators – ALL Series	2018/01/24
Export Package - EV Report Accelerators – INCIDENT Series	2018/01/24
Export Package - EV Report Accelerators – PROBLEM Series	2018/01/24
Export Package - EV Report Accelerators – SERVICE REQUEST Series	2018/01/24
Export Package - EV Report Accelerators – CHANGE Series	2018/01/24

Then go to the Continual Improvement menu to add each report under the appropriate menu.

How to add widgets

There is also a series of widget you can add in ev Service Workplace.

• Connect to Service Apps and import the custom widget. It will be stored in a section named Reports.
• Add it to your app by simple drag & drop.

• The list below contains the custom widgets to import in ev Service Workplace.

Report	File to download
(A) INC vs SRQ (60 Days) (by Week) See the Description	EV_Widgets - (A) INC vs SRQ (60 Days) (by Week)_20170711
(B) New vs Closed INC (60 Days) (by Week) See the Description	EV_Widgets - (B) New vs Closed INC (60 Days) (by Week)_20170711
(BG) New vs Closed INC (60 Days) (My Groups) (by Week) See the Description	EV_Widgets - (BG) New vs Closed INC (60 Days) (My Groups) (by Week)_20170711
(C) New Closed INC vs SRQ (by Week) See the Description	EV_Widgets - (C) New Closed INC vs SRQ (by Week)_20170711
(CG) New Closed INC vs SRQ (60 Days) (My Groups) (by Week) See the Description	EV_Widgets - (CG) New Closed INC vs SRQ (60 Days) (My Groups) (by Week)_20170711
(D) INC Accepted vs Rejected (by Owner) See the Description	EV_Widgets - (D) INC Accepted vs rejected (by Owner)_201707111
(E) Nb Groups Handling INC (by Category) See the Description	EV_Widgets - (E) Nb Groups Handling INC (by Category)_20170711

Naming convention

• The prefix in a report’s name indicates the type of the process:
  • EV-ALL: All processes (Incidents + Problems + Service requests + Change requests)
  • EV-INC: Incidents
  • EV-SRQ: Service requests
  • EV-CHG: Change requests
  • EV-PRB: Problems
• It is followed by an incremental number.
  • Each series of reports has 2 series of number with almost identical reports.
  • The series 000X is for all tickets and the series 500X is for tickets related to your group only (support group you belong to).
• Some exports consist of a set of filters and views related to a standard menu.
  • The export file’s name is formed as follows: (Prefix + 000) + (name) + (content label)
  • All the filters and views related to a standard menu have the EV- prefix so they can be distinguished.
• In a view, grouping levels are separated by => for clarity.

• Custom widgets export files start with CW.

New Time Calculation Table

As part of this first series of reports, we have included the first version of an advanced Time Calculation table called SD_REQUEST_COMPUTED_TIMES.

This is not a series of reports but a new table that calculates new time-based calculation with new presentation format. With these new time calculations, you are no longer limited to present the information in minutes. You now have access to a large variety of formats such as minutes, hours, days, weeks, months and a new combined view.

The calculation made in this table are:

• Resolution Time: Time between the ticket creation and the completion of the ticket
• Resolution Delay: How much time has passed over the agreed SLA time
• Response Time: Time between the creation of the ticket and the creation of the first human action on the ticket. This first action is determined by a simple algorithm that looks at what actions type is created and determines when the first one was made

All these calculations are done in a very innovative way that allows you to personalize the calculation and also come up with your own calculation.

To achieve that we have created a series of alerts that can be imported into your environment. Theses alert run on your own schedule and can be adapted.

How to set up

• Go to the Administration > Import / Export > Import menu and import the following package:
         EXPORT PACK - EV RA TIME CALC - ALERTS.EXP
• The three scheduled alerts below are created which, when executed, do behind the scene calculation on your tickets and actions.
  • TABLE SD_REQUEST_COMPUTED_TIMES-FULL VERSION (STEP 1 - COMPUTATION)
  • TABLE SD_REQUEST_COMPUTED_TIMES-FULL VERSION (STEP 2 -  COMPUTER RESPONSE TIME WITH SLA)
  • TABLE SD_REQUEST_COMPUTED_TIMES-FULL VERSION (STEP 3 - SET RESPONSE TIMES-FULL VERSION (SETP 3 - SET RESPONSE_TIME_SLA_* FIELDS) 
• You must activate them and then the next night, the alerts will run. After a few days, all your tickets will have the new calculation attached to them.
• These alerts must run at night to prevent impact on your production. They calculate various time found in the new table for the last 10000 update tickets. In time all your tickets will have the new calculations but it may take some time. 
• To see the results in existing reports, you will need to modify your parent query and link the SD_REQUEST table to the SD_REQUEST_COMPUTED_TIMES table through the REQUEST_ID field.
• You can also see the results in one of the reports from the report pack mentioned before.

Support Dashboard

The following dashboard is available to use in Service Apps. It contains several views into an operational type dashboard.

Simply import the apps into your instance and it should be ready to go. All widgets are connected to a report from the accelerators.

  EV Reports - RA - Support Dashboard     (Last updated: 2018/01/24)

Methodology behind the reports and lists

These reports and lists are not just reports for reports sakes. They were built with a certain queue management methodology.

Ticket oriented reports

While we all know that Service Manager is action oriented, the reports and lists in this view are all tickets oriented. The reason is simple, while individuals may work on actions, the reporting is still mainly done on tickets by most customers. Very few people told us they were reporting the number of actions. All KPI are usually calculated around tickets and the customers don’t care how many actions you closed in their ticket, they just want you to complete the tickets.

Global vs My Groups

All list and views reports on 2 levels: 

• The GLOBAL level shows all the tickets in the organization.
• The MY GROUPS level only shows tickets for the groups you belong too. 

This is important because 2 different people may have a totally different list of tickets when they run the same MY GROUPS reports because they do not belong in the same group.

Service Manager knows which tickets belong to what group using the Ticket ownership.

Ticket ownership

The owner of a ticket is the person or the group responsible for the effective and efficient handling of a specific ticket throughout the entire ticket life cycle. In other words, if you own it, it is your job to see it through and do all the necessary follow-up with the customer and action assignee to ensure a quick completion of this ticket.

This is a very important topic while using these reports. MY GROUPS reports and lists will only work properly if the ticket ownership in your Service Manager is set according to how you want this work.

There can be any number of methods to determine the ownership of a ticket. Usually, there are 2 that are more prevalent.

Methods to determine the ownership of a ticket

Method 1: Ticket is owned by the creator

This is the default method in Service Manager. Whoever creates the tickets (from the Support group side) is set as the owner of the ticket (OWNER_ID). If the ticket comes from Front Office, then the owner if whoever requalified the ticket. The group who owns the ticket is based on the default group of the owner. If the ticket is transferred or reassigned, the ownership does not change. In other words, the owner is the first person who touched the ticket.

This methodology works well in an environment when one group (like the Service Desk or HR) is the main point of contact and when all tickets transit through that same group. In that system, any ticket created by customers are owned by the Service Desk and any other ticket created manually are owned by whoever created the ticket.

This methodology has a great advantage from a customer service standpoint. Whoever talked to the customer is the owner and is probably the best person to follow up on the ticket. In this methodology, actions are really important for any group or people working on a ticket. Remember that the owner is the one who will get the credit for closing the ticket and that is why actions are so important. Each intervention must be recorded in an action to ensure that everyone participation to the tickets is recognized and accounted for.

Method 2: Ticket is owned by the one working on solving the ticket

An alternative method is to say that the owner is, in fact, the person or group responsible for solving or completing the ticket. This implies that a group like the Service Desk is always responsible for the customer relationship but the real owner is the one working the ticket.

To achieve that you must decide which action in your workflow is what is called the main action. Then, whoever is assigned the main action is the owner. If the main action is reassigned or transferred, then the ownership is transferred as well. The main action is usually called Analysis and Resolution for incidents but can have very different names for other workflows.

• A more concrete example: An incident comes in through email. The service is set as the catalog group for Front Office and there is set as the owner of a ticket. The Service Desk then requalifies and assigns the ticket to the Desktop Support group. The Desktop Support becomes the owner because the first action after requalification is the main action.

The main advantage of this methodology is that it allows people and groups to work with tickets and not only action. Tickets are owned by the group working the issue. The one working the issue also gets credit for closing the tickets. The workflow for your ticket can more easily assign other actions based on the owner since that owner is likely the one working on the ticket.

How to set the method 2

• You will need a special set of business rules and related processes.
  • You can import the package below:
     Export Package - EV Config Accelerators - Ticket Ownership
  • It will create 2 business rules:
    (BR) Update owner when S01 is created
    (BR) Update owner when S01 is reassigned
  • And one related process:
    (BR) RELATED - Update Owner of ticket

• To make this work, you will need to tweak the business rule to match your environment.

  example  The condition for this business rule reads as follows:

  IF EXISTS
  (
  SELECT ACTION_ID FROM INSERTED
  WHERE
  (
  (ACTION_TYPE_ID in (20) and action_label_en like '%S01%')
  )
  )
  BEGIN
  @@FIRETRIGGER@@
  END

  • You must replace the %SO1% with the name of your main action.

  • Most people will have Analysis and Resolution as their main action for incidents, for example. But another workflow may have a very different name. Therefore, we have SO1 has our name in this example.

• Don’t forget to edit both business rules. The business rule checks if the main action is created or reassigned and when that happens, set the ownership of the ticket to whoever was assigned to this ticket (group or individual).

Adding Custom widgets in ev Service Workplace

The custom widgets presented below are ev Service Workplace widgets based on the new reports delivered by , that can be combined to make a dashboard.

• The name has a prefix that is repeated in the data source(s) used in the widget, which helps to distinguish them when many custom widgets are used in an app.

• After importing these custom widgets, you will find them under the REPORTS category under the Custom Widgets section.
   See the List of custom widgets to import.

(A) INC vs SRQ (60 Days) (by Week)

Line chart presenting the number of incidents and service requests, submitted the last 60 days, per week.

The data sources of this custom widget are based on:

(B) New vs Closed INC (60 Days) (by Week)

Line chart presenting the number of incidents submitted and closed the last 60 days, per week.

The data sources of this custom widget are based on:

(BG) New vs Closed INC (60 Days) (My Groups) (by Week)

Line chart presenting the number of incidents for my groups, submitted and closed the last 60 days, per week.

The data sources of this custom widget are based on:

(C) New Closed INC vs SRQ (by Week)

Bar chart presenting the number of new/closed incidents/service requests, submitted the last 60 days, per week.

The data sources of this custom widget are based on:

(CG) New Closed INC vs SRQ (60 Days) (My Groups) (by Week)

Bar chart presenting the number of new/closed incidents/service requests for my groups, submitted the last 60 days, per week.

The data sources of this custom widget are based on:

(D) INC Accepted vs Rejected (by Owner)

Table listing the owners of incidents that were handled the past 60 days and for each owner, the number of incidents that:

• Were accepted after resolution
• Were rejected
• Are pending user validation

Note: Incidents handled by a process without an end-user validation step are not considered.

The data sources of this custom widget are based on the Operation > Incidents > All Incidents menu.

(E) Nb Groups Handling INC (by Category)

Table listing the categories of incidents handled for the past 60 days and for each, the number of incidents that were:

• Handled by one group
• Handled by 2 or more groups
• Handled by 2 or more groups with an SLA breach

The data sources of this custom widget are based on the Operation > Incidents > All Incidents menu.