Based on the service hierarchy, the 4me service provides a sophisticated mechanism for generating accurate real-time SLA reporting. The input for the SLA reports is the affected SLA records (ASLAs), which are automatically generated when requests are created or updated. When a request is passed down the service hierarchy by linking a child service instance to a request, SLAs may be affected for which the requester is not even directly covered. Still, 4me continues to track the SLAs for the parent service instances. This way, all the information is captured to ensure accurate SLA reporting.
Sometimes, though, a service provider wants to know specifically which requests did not meet the targets for their customers. Whether any underpinning SLAs were breached or not wouldn’t be relevant for such a report. Six new reports have now been created, which report on SLAs looking only at the customer ASLAs. These are the ASLAs that are visible in the current account and that either cover the Requested for user or have a customer account that is different from the current account. The new reports are called:
- Request Customer Response Targets Met and Breached
- Request Customer Resolution Targets Met and Breached
- Number of Request Customer Response Target Breaches By Creation Date
- Number of Request Customer Resolution Target Breaches By Creation Date
- Percentage of Request Customer Response Target Breaches By Creation Date
- Percentage of Request Customer Resolution Target Breaches By Creation Date
The first two reports are based on the existing ‘Request Response Targets Met and Breached’ and ‘Request Resolution Targets Met and Breached’ reports. Let’s illustrate the differences with an example. Imagine that someone registered an incident on the Personal Computing service. A specialist realizes the issue is with Directory Services, and updates the service instance to the correct child service instance, supported by another internal account. Two ASLAs are thus generated.
When the internal ASLA (for Directory Services) has breached the resolution target, but the customer ASLA (for Bronze Personal Computing) hasn’t, the ‘Request Resolution Targets Met and Breached’ report would show the request as ‘target breached’, while the ‘Request Customer Resolution Targets Met and Breached’ report would not show the request. From the point of view of the customer, the SLA is still not breached.
Note that requests in these reports that have not been completed but have not (yet) breached an SLA are not presented. This can easily be visualized by adding a new filter to the report, called ‘Completion status’. This filter can also be used in the ‘Group by’ option, resulting in the following overview:
The other four reports are completely new (so not based on existing reports), and show the number (or percentage) of requests that were created in a selected time interval and whether they had breached their response or resolution target, or not. These reports also only consider customer ASLAs. As an example, let’s look at the ‘Number of Request Customer Resolution Target Breaches By Creation Date’ report. These reports, too, can be grouped by Completion status, as was done with the report below.
Another difference with the other two reports is that they do show requests that have not been completed but have not yet breached an SLA. These are presented in bright green, along with requests that have a ‘Best Effort’ resolution target.