Jump to content

Timers


Steve Giller
 Share

Recommended Posts

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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 :(

Link to comment
Share on other sites

@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 by DeadMeatGF
Additional Info
Link to comment
Share on other sites

@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... :( 

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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" ;)

Link to comment
Share on other sites

@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"

 

Update_Service_Level.PNG

Link to comment
Share on other sites

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 :D ... (need to look in the flowcode)

 

Link to comment
Share on other sites

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.
 

Screenshot 2017-03-02 14.17.50.png

Link to comment
Share on other sites

  • 2 weeks later...
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

Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

  • 6 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...