Timers

[Steve Giller]

I'm starting the Response Timer almost at the beginning of the Business Process, but it (for obvious reasons) is irrelevant until a Priority (or Service Level) has been assigned.

Once the Priority is assigned and the rules attach a Service Level I am not seeing a Response Target - is it safe to assume that this is because it expects the timer to start after this happens?
If this is the case then we need some way of monitoring the delay between a call being logged by a customer and the call being assigned a priority by the Service Desk otherwise there could be an indeterminate delay before the response timer is activated that will impact on customer satisfaction.
Also, is there anything in Service Manager like the Supportworks concept of setting the "Log Time" to the time an incoming email was received - as far as we are concerned that should be the time the call is logged, as if there is a delay it is not the fault of the customer.

What I am basically after is for the priority/Service Level to pick up the running timer where applicable and allow us to monitor the "real" time taken to respond to a job request. Is this already present and I'm just not setting things up correctly, and if not can it be implemented.

 

[Dan Munns]

We would also be interested in an option to add the difference between time logged and time responded as we face the same dilemma.

Our respond SLA will be 100% (good for us) but potentially untrue (not good for us) as the time between logging and selecting a priority is lost.

Would like to see the option "Set log time as timer start time" or similar.

[Victor]

20 hours ago, DeadMeatGF said:

Once the Priority is assigned and the rules attach a Service Level I am not seeing a Response Target

The response and fix timers are started (and stopped) by the "timers" nodes in the BP. If the SLM rules meet all the configured criteria when the timer starts, then you should see that timer on the request. What  do on our service desk, where we also have Service Levels depending on priority, is to assign a default priority on the request to allow timer to start - if there was no priority assigned during progressive capture. The Service level can then be changed upon assessing the request which will adjust the timers accordingly... So, for example, you put a default "minor" priority and when the analyst starts working on the request and decides is a higher priority, the Service level can be adjusted as such along with the timers... Possibly not the best workaround/solution though...

 

20 hours ago, DeadMeatGF said:

setting the "Log Time" to the time an incoming email was received

As far as I am aware our dev team was/is working to have this functionality available (or something similar at least)

[Steve Giller]

Thanks for the clarification, Victor.

From that it seems that if I

• Assign a "Processing" SLA
• Start the timers
• Pass to Service Desk for prioritising
• Assign the "real" SLA

The process will work as intented, without any real change to the human element of the workflow. My gut feeling is that the same code that can change the times from SLA1 to SLA2 should be able to cope with a change from NoSLA to SLA2 in a similar way (assuming the timers are running) but obviously that would be a change your end and this workaround is sufficient for where I am now.

If the "Log Time as email receipt" does become live that would be an excellent option, glad that's in the queue somewhere.

[Victor]

@DeadMeatGF the issue is that what you change from SLA1 to SLA2, the bit of code which recalculates the timers needs the initial timer to know what to calculate...like X + 5 = Y ... if X is unknown then there is no Y. When you have NoSLA to SLA2 there is no X... However if we change the behavior design to somehow cater for date logged or an email date in SLA calculation then we could use that as X...but that's not there yet

[Steve Giller]

@Victor I've found an issue with the workaround above: because the call now has a priority (albeit a "dummy" one) it is passed directly to the First Line team for initial review because the conditions for the Suspend/Wait for Priority node are met.

The only solution I can see for this would be to have a Suspend/Wait for New Priority (like the Wait for New Owner) node although you may have other ideas?

 

[edit]
I tested moving the "Assigned to Front Line" node onto the next stage, but it still flows straight through and assigns the call.

Edited March 2, 2017 by DeadMeatGF
Additional Info

[Steve Giller]

@Victor Unfortunately, it doesn't seem to be updating the Service Level when the priority is changed, although that may be because my setup (screenshot attached) is missing something?

[Victor]

@DeadMeatGF sorry, you are too fast for me today

1 hour ago, DeadMeatGF said:

the call now has a priority (albeit a "dummy" one) it is passed directly to the First Line team for initial review because the conditions for the Suspend/Wait for Priority node are met

Can you download the process in a TXT file and I'll have a look and see if I can find some useful advice? I also still owe you an answer in "*Really* suspend the process" thread so I can combine these...

 

11 minutes ago, DeadMeatGF said:

it doesn't seem to be updating the Service Level when the priority is changed

It won't ... :(  this is something we recently suggested to devs to implement a relation between Service Level rule criteria and actions on requests... In this example, if the SLA rules assign a Service Level, when the timer is started, based on priority (i.e. the priority is among the criteria for different service levels) then when the priority changes on a request the service levels should update accordingly... this should be valid for any criteria upon which the rules are built...

So the only (current) way to change the Service Level is by a manual action by an analyst on teh request...  

[Steve Giller]

@Victor I'm looking through the available options and I can't see one that allows me to change the Service Level, only Priority.
Am I missing something or am I stuck with a Service Level based on the first priority I assign?
If the latter, this does require a bit of an overhaul, either to start the timers and have the SL say "Oooh, it's already at ##:##" when it's activated, and/or to automatically re-assign the SL if the priority changes.

(I will point out at this stage that Service Levels are in development at the moment, so this isn't affecting my production environment)

I've attached the txt-file as requested.

dev-dc-it-incident-v3-slm.bpm.txt

[Victor]

@DeadMeatGF is not an action button on the request... if you click on the Service Level you should be able to amend it...

 

[Steve Giller]

With you, there, thanks.
I assume there's no Flowcode to do that or request that it is done, based on the previous posts?

Paused my posting to go and do this - but nothing happens when I click on the SLA. Is that because it has passed the Response and progressed into the Resolution timer? If so I'm back to the same issue of having a priority and the flow "Not really suspending"

[Victor]

@DeadMeatGF if nothing happens when you click on the SLA it could mean your user does not have sufficient rights... Try adding "Service Desk Admin" role to your user and see if then works... You won't have to do this for an analyst (we can do this with a custom role), this is only to see if the button works for you...

EDIT:

I assume there's no Flowcode to do that

You could do this - change the Service Level -  via flowcode (I assume you mean BP). I need to have a look how this node works and what this "update" does since the only option on teh node is "Request ID"

 

[Steve Giller]

I'm a superUser, so I should have permission! I've added Service Desk Admin anyway.

I wonder what happens if I add an Update Service Level node straight after a Wait for Priority node ...

[Victor]

11 minutes ago, DeadMeatGF said:

I'm a superUser, so I should have permission!

Not really, this role does not give rights to applications (like Service Manager, Timesheet Manager, etc.) but I can see the name might imply this  . "Super User Role" gives you God like powers from an admin perspective...

 

13 minutes ago, DeadMeatGF said:

I wonder what happens if I add an Update Service Level node

This is the bit I honestly don't know how it works  ... (need to look in the flowcode)

 

[Steve Giller]

OK - adding Service Desk Admin allowed me to click!

Anyway - the old call, now I can click and alter the Service Level, still shows Project, but the new call, after I add an Update Service Level node shows Emergency, although it doesn't update the webclient display (see attached)

What I've done is add a decision after the Suspend/Wait for Priority and looped back if the Priority is Project, but Update Service Level if it's not. A bit of a fudge, but the only change to the Human Process now is that changing a priority requires a comment whereas assigning for the first time doesn't.
 

[Steve Giller]

Update: A full refresh of the browser window does show the new Service Level.

[Victor]

@DeadMeatGF at this point you definitely know more than I do

[Guest gregmarcroftorc]

On 02/03/2017 at 6:37 AM, Victor said:

As far as I am aware our dev team was/is working to have this functionality available (or something similar at least)

Hi @Victor,

Are you able to find out from your dev team if there is an estimated date for when this will be available as this was how timers were set up in Supportworks and in my opinion is the only true accurate way of calculating a response/fix time?

If we receive an email on 14th March at 1pm and log it the next day (15th) at 1pm. We have taken 24 hours to respond (or in our case where our timers only run 9-5, 8 working hours) and therefore for us to claim that we have a 100% response time in instances like this is not correct. The same goes for us with the fix/resolve times where the % of those tickets is also a lot higher due to the calculation being done from when we log the ticket rather than when the email came in.

It would be better for us if the ticket could record the times based on when the email has come to us so if this feature could be included by your dev team then that would be a big advantage for us.

Thanks

Greg

[Guest gregmarcroftorc]

@Victor @Bob Dickinson Hi both, do you know if anything is due to change with the timers?

[Guest]

Hi @gregmarcroftorc

Unfortunately I do not have an update on this piece of functionality as yet, to backdate SLA times from the moment an email is received. I have added you as an interested party and will ensure to provide you with an update as soon as I hear anything.

Kind Regards

Bob

[Guest gregmarcroftorc]

@Bob Dickinson OK thanks Bob. Do you know if there is a field that we can pull through to the reporting that has the date and time of the incoming email instead?

[Steve Giller]

Having worked on this some more, I have ascertained that a "Suspend: Wait for new priority" would work as a stop-gap - it doesn't allow the email arrival time to be the initial logging point, but of we could assign an "Incoming" priority within the BPM followed by an "Update Service Level" node, then the Response Timers will have a target.

A "Suspend: Wait for priority" node doesn't work as there is already a priority (I could test for the "Incoming" priority and loop back, but that is really clunky) but if we could wait for a new priority, then update the Service Level the timer should be recalculated and the call can be assigned with the new targets.

Is there any chance this could be implemented, assuming it's a quicker option than the code to work backwards to calculate the targets?

 

[Guest gregmarcroftorc]

@Bob Dickinson Hi Bob, has this been looked at at all since?

Thanks

Greg

[Guest]

Hi @gregmarcroftorc

Unfortunately I don't have any further update as yet - I have asked for this to be reviewed at our next CAB and prioritised accordingly.

Kind Regards

Bob

[JanS2000]

Morning @Steve Giller and @Victor, I'm just jumping on this old post as we're in the same position with requests and faults logged via email - our stats look like we respond 100% of the time within SLA, which isn't accurate, and we'll soon start sharing our reports with the rest of the org, so I need to find a way around this to ensure accuracy. Did "email arrival time" ever get added and if so, what's the best way to use it? If it's not available I'll run the suggestions for setting an initial default SLA followed by a node to review this once the response has been marked, but I'm not sure if my managers will go for that.