Service Manager Dev Diary #1

[Victor]

Hi all

Foremost I wish to say many thanks to all community members for your valuable contribution to the forums  This thread is an initiative to introduce you in the world of our Service Manager development and you an insight of the wonderful projects and features they are working on. This is thought to be a regular post which will present various new planned things, what and how we want to do and give you a chance to get acquainted with future "stuff" and obviously to discuss them. We already have a Service Manager roadmap, accessible on customer portal which shows you everything in plan for the next 90 days, which I say is great. These diary posts will give give you a chance to find more in depth information about things on roadmap or even outside of it and, most importantly, you have the opportunity to feedback on it which I am sure not only development will appreciate but all Hornbill team and ultimately would allow us deliver an even better solution for you. But enough with introductions, let's get to the juicy stuff

 

Today we will cover a much coveted topic raise and discussed on many occasions: the disconnection between BP and manual interaction on requests - more specifically allow the BP to handle two stage closures and reopen! I know, right? We all want it!!! In any case I know I do  So, good news, we are building it!  And this is how we thought of it in a nutshell: provide a new BPM automated task that will wait for a status change and then use the new status as an output for a decision and improve the existing close after time period BPM automated task to support requests that have been reopened  Now that would be really nice I say!

How this would work then? This is what we think of: A new BPM operation called "Suspend and wait for Status Change" which allows the BPM designer to do the following: 

• Waits for any change in the status;
• The status that is changed to becomes the output so that a decision node can use this to branch based on the status that it changed to;
• Amend the "Close after time period" which will only close resolved requests and will delete timers once they're no longer required;
• If the request has been re-opened the closure timer is also deleted.

This was thought primarily to handle requests being actioned (e.g. reopened) by a customer on the portal but certainly can be put to good use in other scenarios as well. Happy to hear (well, actually read) your thoughts on this! Before anyone gets too hyped on this, there is no ETA when this functionality would be available yet.

I hope this is one (of many to come) insights into what we have planned for you and I promise I will try and make it as often as possible and more detailed!

[Martyn Houghton]

@Victor

Sound good and positive approach to focus on distilling the requirements.

Can you clarify the references to 'delete timers'? Will the resolution timer be restarted taking into account actions and previously on hold time etc , akin to the request being on hold in essence since the request was set a resolved/closed?

Also as we have a number of stages in our BPM, will it be possible to link back to an earlier stage in the BPM when a request is reopened, else we would have to put the whole process in a single stage to cope with potential re-opening of the request?

Is there any plans to allow the ability of requests to be reopened at the service level, which has been raised as well?

Cheers

Martyn

[Victor]

@Martyn Houghton good to hear your thoughts on this
 

On 13/04/2017 at 1:32 PM, Victor said:

Amend the "Close after time period" which will only close resolved requests and will delete timers once they're no longer required;

The "Close after time period" node creates a BPM event with associated timers. This means that when the timer is reached, the request will be closed. Currently there is no option to "cancel" this type of timers... meaning once the close BP event is created the request will close regardless of any actions on it... So, with the new functionality to cater for reopenings, such BP events will be adjusted accordingly (either removed or changed).

23 hours ago, Martyn Houghton said:

Will the resolution timer be restarted taking into account actions and previously on hold time etc , akin to the request being on hold in essence since the request was set a resolved/closed?

Request timers are independent of request actions... until recently, the resolve request also stopped the resolve/fix timer but this is no longer the case. To stop the timer you will need to have a "stop timer" node. Therefore you can trigger this when you think is needed and meanwhile have any request status... including close if you so need  ... but not "Canceled". However once the timer is stopped, it can't be restarted.

23 hours ago, Martyn Houghton said:

Also as we have a number of stages in our BPM, will it be possible to link back to an earlier stage in the BPM when a request is reopened, else we would have to put the whole process in a single stage to cope with potential re-opening of the request?

Not with this functionality. As far as I know there are some challenges around this design (return to previous stage) so can't say if and how this will be done... but not at the moment. This thread is discussing the same idea:

 

23 hours ago, Martyn Houghton said:

Is there any plans to allow the ability of requests to be reopened at the service level

I must have missed this thread, sorry about this. Would you mind detailing on what you mean by this?

[Keith]

@Victor It's good to hear that something is being done to address this problem. I think I understand your proposal but let me explain my current issue and you can tell me if this will be resolved by the proposed solution. 

Process: When we mark a request as resolved we automatically create an "Await Closure" activity with an expiry of 7 days. If the request is not closed by the customer during this period the activity will expire and close the request on expiry.

Problem: If a customer reopens a request we have to ensure we reopen the "await Closure" activity otherwise the request will autoclose, causing the customer and the analyst frustration. Unfortunately this happens all too often due to the additional step of having to reopen the activity once the customer has reopened the call. 

Do you think your development would negate the need for the "Await closure" activity and avoid the possibility of inadvertent request closure? 

 

Thanks

 

Keith

 

[Victor]

@Keith yes (to answer your last question), the new functionality will (better said should) cater for existence of BP events for request closure and amend them if the respective request status changes to "open" for example...

On 13/04/2017 at 1:32 PM, Victor said:

• Amend the "Close after time period" which will only close resolved requests and will delete timers once they're no longer required;
• If the request has been re-opened the closure timer is also deleted.

So the way it should work is like this:

• request is logged and progressed to resolution stage;
• once resolved the BP creates an auto-closure event using "Close after time period" node;
• next step in the BP wouldn be the new  "Suspend and wait for Status Change" node - BP suspends at this point.

When BP resumes you can have a decision node to check for the "new" status and branch the process as required. If the status changes from "resolved" to "open", then the auto-closure BP event created before is removed.

[Keith]

@Victor Great!! Sounds perfect. This will be another of the major moans from analysts taken care of

[Victor]

Just need to remind that dev diaries discuss potential features that is on our dev team attention... It also means that IF the feature is introduced at any point it might not have all the expected complexity and depth discussed (for example there might be potential technical challenges which could prevent a certain level of complexity at that point)... it might be subject to a partial deployment of functionality, or different functionality. Also there is a possibility (not likely though) that a certain feature we think of might get scrapped all together... The diary has been thought to give you an idea on what (and how) we are thinking of doing...to gather your thoughts (if any) and feedback and to give you an insight on future plans! Please don't take these diaries as a commitment from us to deliver a certain feature  You should use the 90 day roadmap available on portal for this purpose

[Keith]

@Victor Undestood! Backside firmly covered

[Victor]

Oh dear ... Just wanted to make sure I don't create the wrong expectations

[Martyn Houghton]

@Victor

What I was meaning by "Is there any plans to allow the ability of requests to be reopened at the service level" was "Is there any plans to allow the ability to restrict  tha ability of requests to be reopened at the service level, i.e. in terms of toggle setting to say that option to re-open is not displayed to the customer at all."

 

Cheers

Martyn

[Victor]

@Martyn Houghton

33 minutes ago, Martyn Houghton said:

"Is there any plans to allow the ability to restrict  tha ability of requests to be reopened at the service level, i.e. in terms of toggle setting to say that option to re-open is not displayed to the customer at all."

Not that I am aware of, not yet anyway, but this is why the dev diary initiative  ... All these aspects can be discussed and see how a certain feature/functionality would best fit our customer needs