Response Time Not Met Issue

[Chris Bardell]

Hi All.

I have created a Quick Log Call capture for things like Password Resets etc for our Service Desk to use.  I have created a separate business process for this also. However when using this progressive capture and business process it fails to mark the response time even know the node is there. 

I have tried to troubleshoot this by adding a Write Response success/failure to timeline message. On the call the timeline shows:

Also tried on the Mark Response Time when it gets past this marking the checkpoint. The checkpoint is marked also.

This issue is really intermittent sometimes it will mark the response time sometimes not.  Then sometimes it will mark the response time but fail the resolution.

Just raised a further call using the same BMP and Process Capture but this time its mark the response and resolution.

We have had this issue for a while now and when setting this up before Go-Live of Hornbill we could find a way to fix this.

[Hornbill Staff DR]

Morning Chris,

 thanks for your post.

The crux of the issue seems to be around the the response being met/breached. More specifically in the case of where it's breached, I gather that's the situation you feel isn't correct.

To advise further we'd need to understand:

• What the response target is for your Priority 4 Service Level in your Service Request SLA
• A screen shot of your Working Time Calendar showing your hours of operation

Can you provide this information?

Thanks,
Dan

[Chris Bardell]

Hi @DanielRi

The response target i have placed below for you.

Working Time Calendar:

Hope these help.

If you need a copy of the BMP and the progressive capture i am more than happy to provide these.

Chris

[Hornbill Staff DR]

HI @Chris Bardell,

 thanks for the additional info. So far, nothing is jumping out at me. 

I think the root of this behaviour may lie in when your response timer is started, and whether or not a different service level is set initially, then subsequently re-evaluated. Please could you tell/show me the following:

• A screen shot showing the location of your start response node, and also the mark response node in the same image
• A screen shot of the the Service levels you've created in your Service Request SLA

The aim here is to get a bit more of a broader perspective on what is happening in the process. If you can provide the above screen shots, I don't think your process definition will be necessary.

Thanks,
Dan

[Chris Bardell]

Hi @DanielRi,

No worries. Thank you for your help also.

Screen shot as below for you

Hopefully this is what you mean by Service Levels?

Chris  

[Hornbill Staff DR]

Thanks Chris,

That's great, thanks.

I'm going to guess your Service Level rules will be based on Priority (i.e. you'll have P1 to P4 which result in the corresponding service level Priority 1 to Priority 4, and some "Long Term" priority which evaluates to the "Long Term" service level).

Let me begin with some background:
When the "Start Response" node is reached, the system will evaluate your service level rules to determine what service level should be applied, and therefore what the target response time will be. If my assumption about your rule set-up is correct, the service level will evaluate to the "Default Rule" Service Level when the ticket doesn't have a priority.

Further on in your process, I can see a node that is labelled "set priority to P4", which I assume will do just that. The priority is a field that, when changed (either manually by an agent or via the bpm), will trigger an automatic re-evaluation of the service level i.e. the system will review each of the service level rules in turn and set the appropriate Service Level, which will probably be your "Priority 4" Service Level. 

I'll digress momentarily from the issue we're exploring and just highlight that blindly setting a priority (in this case a P4) isn't necessarily best practice, unless the process is specifically designed for a particular type(s) of request that always attract that particular priority. Firstly it can lull you into a false sense of security, in that its been prioritised and the assumption is that "it's fine, I've got 1 day to respond", whereas in reality nobody has triaged the ticket and you could have a P1 or P2 masquerading as a P4.
 
In an ideal world, when it comes to incidents, or if this is a process intended to be for any request, all tickets should be reviewed within the time allowed by your strictest service level (most likely that response target related to a P1 e.g. 1 hour). This ensures that should you identify a P1, you will be well positioned to respond within your stated commitment.

This is where your "Default Rule" service level comes in, which is considered Hornbill best practice. In the past, I've called this the "Triage Service Level" as it's set on the occasions where a priority is yet to be determined. The benefit here is two-fold, firstly it applies a service level to the ticket giving the agent the required targets to work towards. Secondly, this particular service level is not bound by any priority, and having a request sat in the request without a priority makes it clear that the severity/urgency of the ticket hasn't been determined and thus it must be reviewed. Should it be found to be a P4, this can be set by the agent, the service level is re-evaluated, and the targets increased. 

Anyway, coming back to the issue at hand:
In one of your screen shots above, it clearly shows that the target is marked as missed, but the target is actually 09/10/2020, which is in the future. So what gives?

The only situation I can think of is that the service level was re-evaluated and set to a "Priority 4" at some point after the response target of your "Default rule" Service Level had been exceeded. 
Currently, if the existing target has already been met or breached, this flag will remain unchanged upon a re-evaluation. In short, the re-evaluation updates the new Service Level target time, but doesn't change the state of the fix/breach flag.

What's the response target of your "Default Rule" Service Level?

Dan

[Chris Bardell]

Hi Dan, 

Thank you for this information.

In most of our other BMP the Analyst will select the priority however, in this case as its a quick log call i don't want an analysist to select a priority, category and assign to a team as this will waste time.

The purpose of this BMP is just to quick log and close calls that take our helpdesk 1-2 minutes to resolve, for example password resets.  In all other instances they would use another service and/or progressive capture to log calls. In these cases it requests them to assign to a team, select priority and category etc.

Just to clarify, when this call is getting logged it switches from the Default Rule to our P4 rule?  If so, it does show this in the Timeline from switching between the Default Service to P4.

This is the Default Rule Service Level.

[Hornbill Staff DR]

Hi @Chris Bardell,

 "Just to clarify, when this call is getting logged it switches from the Default Rule to our P4 rule?  If so, it does show this in the Timeline from switching between the Default Service to P4."

As long as the priority isn't being set elsewhere (i.e. in the progressive capture) and based on what I can see in the business process design, yes, I believe this is how it's currently behaving. When the BPM reaches the "Start Response" node, because there isn't a priority set at that time, it will set the "Default Rule" Service Level. Then a few seconds later, once the bpm has updated the priority to a P4, a re-evaluation will take place which should result in the "Priority 4" Service Level (obviously, I haven't seen your rule conditions, but based on everything else I can see, this would be the chain of events).

When the re-evaluation takes place, you should see an entry in the timeline which looks like this:

As it sounds like there isn't a need to do any triage in this situation, If you always want this request to be a P4, I'd suggest moving the "update priority" node to a position before the "Start Response" and "Start Resolve" nodes. That will mean the Service Level should evaluate to your "Priority 4" Service Level straight off the bat. This will more than likely eliminate the sitaution you're experiencing, however it would be good to understand why this is happening.

I'd still be interested to know the response target of your "Default Rule" Service Level to see whether it supports the following:

My current speculation is still that this is what we're seeing: where if the existing target has already been met or breached, the met/breached flag will remain unchanged upon a re-evaluation. In short, the re-evaluation updates the new Service Level target time, but doesn't change the state of the fix/breach flag.

What I suggest is, as you have a Hornbill Premier Support Plan, you raise an incident with our Application Support Team. They will then be able to determine if it is the situation I describe, or whether there is something else at play here. Include a link to this forum post so that they have the history to begin.

Thanks,
Dan