Back Date - Resolution

[Martyn Houghton]

Apologies if this has already been posted, but it would be really useful in Service Manager to have the ability to back date resolution updates, similar to the Support Works back dating capability, where the date/time updated is recorded but the date/time used in the SLA calculation is set to an earlier point in time up to or after the last timeline update.

Cheers

Martyn

[AbdiH]

Hi Martyn

Can you give us an idea of a use case here please.

Abdi

[Gerry]

@Martyn Houghton

Interesting requirement.  I guess this is an obvious question, but what happens if you enter a date/time that was before some SLA based event was fired?  We have seen all sorts of problems with this when you have the idea of "running timers".  If we were happy to forego the ability to see where we "currently" are in terms of SLA response then providing the resolution date/time would be a no-brainer, but as soon as you want those fancy running countdown timers and pre-breach evens, setting a past date no longer makes any sense - you cannot unwind time on an already run process.

I think what would be better here is some kind of SLA override where you would have a specific action to change the resolution time - despite the fact that the process and/or timers are expressing something different. This comes down to how you would expect to report on this really - it sounds easy to just provide the ability to provide a past date/time but there are a whole bunch of complicated problems, mostly business process related that have nothing to do with product features or capabilities.  I expect you will not get a simple response to this feature request

Gerry 

[Martyn Houghton]

@Gerry, @AbdiH

In terms of a scenario, this would be where a request has been updated by the customer to say the issues has been resolved with the request sitting at a Open status. Then there being a delay before the owner of the request actions this update  setting the request to resolved. The resolution date and time would be the time the analyst updates the request to resolved not the date and time of when the customer confirmed resolution.

By being able to back date the resolution up to the time of the last update, like it was possible in Support Works and the resolution date/time and within SLA indicators being updated based on the back dated operation.

In terms of achieving the same outcome, having the ability to override the SLA outcomes and resolution date/time in an audited manner would be fine.

Cheers

Martyn

[Gerry]

@Martyn Houghton

I am showing my lack of knowledge here around our own service portal, but if a customer marks their own ticket resolved would it not be better for the system to take that as red and set the request status to resolved taking the SLA measurement there and then? If the service portal does not allow for this I would say that would be a far better feature to add,

Gerry

[Martyn Houghton]

@Gerry

As far as my understanding as well, once you have the request at a resolved status there are two buttons to confirm whether it is fixes or is still broken, the latter which then re-opens the incident and the former closes it.

Cheers

Martyn

 

[Gerry]

I am sure @James Ainsworth can contribute here, he is far more expert than I on the detail workings of the Service Manager application. 

Gerry

[James Ainsworth]

There are two ways of managing the stopping of the Resolution Target.  The default is that the Resolution Target is stopped as soon as a resolution is provided by a support person.  This is managed through the Service Manager Application Setting app.request.stopResolutionTimerOnResolve

Alternatively, there is also a BPM Operation that can be used to stop the Resolution Target at any point within a BPM.  This allows you to utilize the features of the BPM workflow to determine different conditions under which the Resolve Target is met.  This works well with the Customer Portal option for accepting a resolution as a solution to their issue.  Once accepted, this can stop the resolution target.

Even with these options, this may leave scenarios where a customer's issue has been resolved, either by the customer resolving their own issue, or an engineer or analyst fixing an issue when they are not in a position to update the request.

I can see that if key performance indicators such as mean time to resolve are important then one would want to make sure that the actual time to resolve on each request is as actuate as possible.  I also see that in the case of when a resolution target is not met on a request where a solution was actually provided, that there is a need to provide a way to correct or specify that the resolution target was actually met.

I will investigate to see what types of options we could provide. As mentioned in previous comments, when dealing with timers, automated escalations, reports, rights and responsibilities around who can perform these actions, and auditing there is a lot to consider.  I'll keep this post updated as we look into options.

Regards,

James