Introducing Desired Completion

Let’s say a user submits a request. In this request the user explains that his laptop’s battery is no longer charging. He also explains that he will not be in the office until Tuesday.

The specialist to whom this request is assigned sets its status to ‘Waiting for…’ and sets the Waiting until field to Tuesday 9am. This ensures that the specialist receives a reminder on Tuesday morning so that she does not forget to drop by the user’s office with a new battery.

But what if the SLA by which the user is covered dictates that this incident needs to have already been resolved on Monday? The new Desired completion field has been introduced for just such situations.

In this example, the specialist can set the desired completion of the request to Tuesday 5pm. Because the manually entered desired completion is later than the automatically calculated resolution target, the desired completion will be used for SLA reporting. This can be seen in the Affected SLA record that is linked to the request. Its resolution target has been crossed out to indicate that it will be ignored.

To ensure that this feature does not get abused, the requester receives an automated email notification.

If a desired completion is more stringent than the calculated resolution target, then it is still used to prioritize the request in, for example, the Inbox console, but it is ignored when the SLA reports are generated.

The Desired resolution field can also be used to specify a target for requests that do not have an automatically calculated SLA target. This allows providers to prioritize, for example, the requests for new features that users submit for the provider’s application services.

For such requests, which do not have an automatically calculated resolution target, the SLA reports will not show a target violation when the manually entered desired completion is violated.