Report Accelerators
- Notes
- Best Practice
- Modification to incidents/service requests lists, filters and views
- Adding new reports
- New Time Calculation Table
- Support Dashboard
- Methodology behind the reports and lists
- Adding Custom widgets in ev Service Workplace
- (A) INC vs SRQ (60 Days) (by Week)
- (B) New vs Closed INC (60 Days) (by Week)
- (BG) New vs Closed INC (60 Days) (My Groups) (by Week)
- (C) New Closed INC vs SRQ (by Week)
- (CG) New Closed INC vs SRQ (60 Days) (My Groups) (by Week)
- (D) INC Accepted vs Rejected (by Owner)
- (E) Nb Groups Handling INC (by Category)
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.
example The SD_REQUEST__RECIPIENT alias indicates that you are looking at the recipient information from the SD_REQUEST table.
- 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.
example SD_REQUEST__RECIPIENT: You will have all the recipient information that comes from the ticket.
Note: In the past, that link would have been named AM_EMPLOYEE_RECIPIENT or worse AM_EMPLOYEE and which does not tell you where the information comes from (SD_REQUEST or AM_ACTION or another source).
- 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:
- 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.
Filters |
---|
EV-GLOBAL - Handled by 2 or more groups and SLA breached (60 Days) |
EV-GLOBAL - Handled by 2 or more groups (60 Days) |
EV-GLOBAL - Solved by one group (60 Days) |
- 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.
Filters |
---|
EV-GLOBAL - With a Resolution Rejection (60 Days) |
EV-GLOBAL - Accepted Without Rejection (60 Days) |
EV-GLOBAL - Pending User Validation (60 Days) |
- 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 |
---|---|
![]() |
2018/01/24 |
![]() |
2018/01/24 |
![]() |
2018/01/24 |
![]() |
2018/01/24 |
![]() |
2018/01/24 |
![]() |
2018/01/24 |
![]() |
2018/01/24 |
![]() |
2018/01/24 |
![]() |
2018/01/24 |
![]() |
2018/01/24 |
Reports
Go to the Administration > Import / Export > Import menu and import the 5 following packages.
Package to import | Last updated |
---|---|
![]() |
2018/01/24 |
![]() |
2018/01/24 |
![]() |
2018/01/24 |
![]() |
2018/01/24 |
![]() |
2018/01/24 |
Then go to the Continual Improvement menu to add each report under the appropriate menu.
example You would add all the EV-INC reports under the Incidents 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.
example
- 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 |
![]() |
(B) New vs Closed INC (60 Days) (by Week)
See the Description |
![]() |
(BG) New vs Closed INC (60 Days) (My Groups) (by Week)
See the Description |
![]() |
(C) New Closed INC vs SRQ (by Week)
See the Description |
![]() |
(CG) New Closed INC vs SRQ (60 Days) (My Groups) (by Week)
See the Description |
![]() |
(D) INC Accepted vs Rejected (by Owner)
See the Description |
![]() |
(E) Nb Groups Handling INC (by Category)
See the Description |
![]() |
Naming convention
example (EV-INC5001) – (CURRENTLY OPENED INCIDENTS) ((MY GROUPS))
- 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.
example EV_Priority => Manager ==> View where the items are first grouped by priority then by managers.
- Custom widgets export files start with CW.
example (evApps_CW)Incidents Directly Accepted vs with Rejection Group_20170406.tar.gz
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:
- 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.
example What you can do and how to add it to the reports provided:
- Incident list with detailed time information
- Incident category with resolution and response time in days
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.
(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.
example
- A ticket comes through email or Front Office: Whoever requalifies the ticket is the owner.
- A ticket is created with the quick call: The creator of the ticket is the owner.
- A ticket is created with the quick call and assigned to different groups and individual than the creator: The creator of the ticket is the owner.
- A ticket is transferred to another group: The creator is the owner.
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.
example
- A ticket comes through email or Front Office: Service Desk is the owner when the ticket is created and then whoever is assigned after requalification becomes the owner.
- A ticket is created with the quick call: The owner is the creator of the ticket until the main action is assigned. Then the owner is the main action assignee.
- A ticket is created with the quick call and assigned to different groups and individual than the creator: The owner is the creator of the ticket until the main action is assigned. Then the owner is the main action assignee.
- A ticket is transferred to another group: If you transfer the main action, then the ownership is transferred, otherwise, the ownership remains the same.
- 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:
- 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
- You can import the package below:
- 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.
All our actions have a prefix like S00 for Validation steps, S01 for our main action, S02 and up for any other actions in the workflows. We suggest you put some sort of tag to all your main action to simplifying the business rule query. It could be (MAIN) or another tags in the name of the action.
- 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.
example The custom widget (A) New/Closed INC 60 Days (Week) is based on the following data sources:
- (A) New vs Closed Incidents 60 Days (Week) // Composite
- (A1) New Incidents 60 Days (Week)
- (A2) Closed Incidents 60 Days (Week)
- 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:
Type | Name |
---|---|
Report | EV-INC0002 – ALL INCIDENTS |
Report | EV-SRQ0002 – ALL SERVICE REQUESTS |
(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:
Type | Name |
---|---|
Report | EV-INC0002 – ALL INCIDENTS |
Report | EV-INC0003 – CLOSED INCIDENTS |
(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:
Type | Name |
---|---|
Report | EV-INC5002 – ALL INCIDENTS (MY GROUPS) |
Report | EV-INC5003 – CLOSED INCIDENTS (MY GROUPS) |
(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:
Type | Name |
---|---|
Report | EV-INC0002 – ALL INCIDENTS |
Report | EV-INC0003 – CLOSED INCIDENTS |
Report | EV-SRQ0002 – ALL SERVICE REQUESTS |
Report | EV-SRQ0003 – CLOSED SERVICE REQUESTS |
(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:
Type | Name |
---|---|
Report | EV-INC5002 – ALL INCIDENTS (MY GROUPS) |
Report | EV-INC5003 – CLOSED INCIDENTS (MY GROUPS) |
Report | EV-SRQ5002 – ALL SERVICE REQUESTS (MY GROUPS) |
Report | EV-SRQ5003 – CLOSED SERVICE REQUESTS (MY GROUPS) |
(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.
Filter | View |
---|---|
*EV-GLOBAL – Accepted Without Rejection (60 Days) | *EV- by Owner (Manager) |
*EV-GLOBAL – With a Resolution Rejection (60 Days) | |
*EV-GLOBAL – Pending User Validation (60 Days) |
(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.
Filter | View |
---|---|
*EV-GLOBAL – Handled by 2 or more Groups (60 Days) | *EV- by Category |
*EV-GLOBAL – Handled by 2 or more Groups and SLA breached (60 Days) | |
*EV-GLOBAL – Solved by One Group (60 Days) |