Implementation Guide › Case Study Examples › Data Modeling Examples › Case Study 8: Helpdesk Performance

Case Study 8: Helpdesk Performance

This is a typical case study for Helpdesk performance

Given the data source shown below:

The data source shown above lists details for helpdesk tickets that are managed for each customer in the various locations that the customer services. A single location may also be shared between customers.

The following three requirements are required for reporting when using this data source:

• % priority 1 tickets resolved within four hours for customer CM3.
• % priority 1 tickets resolved within four hours for customer CM3 at each location.
• % priority 1 tickets closed within one day for customer CM3 at each location.

The above requirements indicate that the Events should be filtered by:

• priority
• customer
• location

You need to specify which of these filtering criteria is translated as an Event Type and which is to be the relevant Resource.

How do I select an Event Type?

Of the three filtering criteria needed, the ticket priority is the most appropriate to be translated into the Event type for the following reasons:

• It describes the kind of event that is being handled (Priority 1 tickets).
• The number of different priorities that exist is relatively small (priority 1,2,3).
• The event type itself is relatively constant (the helpdesk seldom changes the priorities by which it handles tickets).

How is a Resource selected?

The two other filtering criteria required, are the Customer and Location and these are the smallest entities that require reporting. Therefore, the combination of customer and location is the Resource.

Customer and location are relatively fixed entities and have a definite life-cycle, whereby new customers or new sites may be added. Additionally, the relationship between a site and a customer may change.

For the purposes of translations, it is possible to use more then one field from the data source. Whereas in the previous case study the server field was translated into an CA Business Service Insight Resource, in this case the Resource is built using the combination of two fields. Each permutation therefore produces a new Resource.

The Resources list is shown below:

The output Resource is a combination of the customer and site fields using the symbol '+' to combine them. It is important to be aware of the name of the Resource since it is extracted from the data source and it appears later in the reports. The reporting abilities need to meet expectations.

Note: One of the most common mistakes when modeling a helpdesk or any ticket or incident system is to define a single incident as a Resource.

The following incorrect assumptions often lead to mistakes:

1. The single incident is that which is reported.Do not set the entity to be reported as the entity that calculations are generated for so that the single incident is not the basis of the calculations for the customer site. In general, the SLA is based upon overall performance, not the individual ticket handling performance.
2. The guarantee is by ticket level. This is a mistake because the guarantees are periodic ones, what is calculated is an aggregation over time.

Setting Allocations for the Resources

For the first calculation requirement:

1. % Priority 1 tickets resolved within four hours for customer CM3.
   • Events of tickets attributable to a specific customer need to be received. The customer is part of this Resource, which also indicates the customer site. Therefore, to capture all Events related to Resources and attributable to that customer, there are two options:
   • In cases where the customer in the data source represents a Contract party, the Resources can be attached to the relevant Contract party. This allows registration by Contract party. Wherever possible, this is always preferable.
   • Create a Resource group for each of the customers in the data source and group all relevant Resources within it. Using this method, the registration is by Resource group.

   For the next two calculation requirements:

2. % Priority 1 tickets resolved within four hours for customer CM3 at each location.
3. % Priority 1 tickets closed within one day for customer CM3 at each location.

For these requirements, gather the Resources into Resource groups because the Metrics have to be clustered given that the calculation is required for each site individually.

Note: Even if the allocations of Resources for the current model and requirements are not necessary, it is important to create them keeping in mind future requirements. Doing so prevents overhead in future system development.

Choosing the Timestamp field

As mentioned previously, the Timestamp is very important to the way in which the correlation Engine handles the Events. Metrics always calculate service level per time period, and the Events that are processed within this time period are the ones whose Timestamp falls within the period.

In the first case study, the data source only has one time field. However in this case there are three possible fields that that can be set as the timestamp. Examining the first two records:

To calculate the resolution time, both the Raised at time and the Resolved at time are required. For the purposes of the Event, it is possible to attach only one Timestamp to it. Then the other can be used as a value within the value fields.

If the Raised at value is used as the Timestamp, then the ticket is included in the December results. If the Resolved at value is used as the Timestamp, then the ticket is included in the January results. Both options are viable. The selection just needs to meet expectations as to where the tickets should appear in reports.

It is very important point to consider during implementation, since it determines when events are used for calculations. For example, if a ticket is raised in November, but is not closed until December, when should it contribute towards the SLA result? Does it go into the November data, or December?

In this case, since the ticket is reported to the data source only after it is closed, the data can be captured only after the ticket is closed. Usually the Closed date is after both the Raised and Resolved dates. In a case where the Raised date was chosen to be the Timestamp, then it should be processed as part of the December results. The Closed date was in January, which means that December had already passed when this ticket was reported. Hence, the results for December had already been published. The correlation engine then notices the Event as being in the past because the Timestamp belongs to December and triggers recalculation. Therefore, the results of December change retroactively.

These consequences need to be understood completely in order to be able to define which time field must be chosen as a Timestamp. Typically, the Closed date is chosen in order to have final reports that do not change retroactively.

On the other hand, using the Closed date as the Timestamp delays tickets from entering calculations. A ticket that has been resolved may only be closed at a substantial time later.

Be aware however, that this use of the Closed date might also trigger a process in the organization that accelerates the closing time of tickets.

The final suggestion is then: