Measuring First Contact Fix Rates | Incident Management

[Glynn_Parker1]

My question relates to first contact fix rates.

I have been tasked with implementing a solution to track the volume of first contact fixes as they relate to incidents raised. A fundamental requirement is that the solution is automated, and no human interaction is required. This means my initial thought of having ITIL staff checking a box is out of the window .

Therefore, I'm thinking along the lines of an OnCellEdit client script that checks a field during incident creation. So, when an ITIL incident form is launched, and the status is set to resolved (before the incident is submitted/saved), my Resolved at first contact field is checked. If the status is anything other than Resolved, the field remains unchecked.

I'm wondering if anyone here has any experience of implementing such a solution/script and can offer some pointers. Or, does anyone have some advise if I'm going down the wrong route to resolve this task.

Thanks

[David OBrien · Accepted solution]

I've seen a few different thresholds that are used to determine first call resolution.   One is as you described that basically the incident is first saved in a resolved state.   Another I've seen is a time threshold where resolution within 30 minutes of creation gets set to first call resolution.   It sounds like resolving when the incident is created is really what you're targeting though.

For that, I would set it with a business rule that runs after insert and sets a flag to true (in this example, field names FCR [u_fcr]).

[Glynn_Parker1]

Hi David;

Many thanks for the input. I have played around with a business rule, as suggested. No need to script the rule, I was able to configure it through conditions, based around contact type and category selection.

Appreciate the assist.

Glynn

[David OBrien]

I'm glad that worked for you.   The only reason I did it scripted it because running it as an 'after' business rule, just using the 'set values' doesn't actually apply the change.   That works on a 'before' business rule but not an 'after'.  

I set it up as an after rule just in case there is another business rule that is set to run after this one that aborts the submission, you wouldn't necessarily want to set the flag if the record didn't get saved because of some other condition not being met.

Thanks.

[Uncle Rob]

My experience with "must be saved as closed" resulted in a ton of complaints from front end users.   The reason is it highly discourages saving the ticket at all, until you're sure you're done.   Ideally I want to save ASAP and then start logging worknotes, etc.  

The most frictionless way I've done it is a time threshold.   If it was resolved in an hour and did not change its assignment or assignment group within that time, then it was closed "on first contact".