Jump to content

Linked request to problem


m.vandun

Recommended Posts

Hi @m.vandun

At the moment there isn't an option for the hold feature to cascade down to to the other linked requests.  We do have some changes in our backlog for resolutions and closures of linked requests to cascade down but I'm not sure if we had considered for 'on-hold'.   I would be interested to understand the scenario where you would want this to happen.  Usually I would see an incident or service request being put on hold while waiting for a response from a customer. If there was a linked change or problem to this incident, as these may have other linked incidents I would be concerned with putting the changes or problems on hold as they may still be worked on to provide a resolution for the other linked requests.  If a change or problem record was to be put on hold I'm not sure that putting the linked incidents and service requests on hold would be the correct thing to do as this will stop any associated response and resolution targets.

Regards,

James  

Link to comment
Share on other sites

Hi James,

We proivide support to external customers. We provide services to our customer which can have a bug or an issue which needs to be researched why this is happening. During this time it would be nice to put a ticket on hold as all associated requests would have to wait for this update. By leaving the requests open it would fill up the open incidents quickly and these requests would exceed the response and resolution targets. Also when a ticket is taken off hold you know you need to updtae the customer for instance.

Kind regards,

Mark

Link to comment
Share on other sites

One thing that may help toward this is we are planning a new feature that would allow for a type of sub-status and for each sub-status you will be able to define if that status pauses or starts the service level target timers (response and resolution).  For your example you would have a sub-status under Open called something like ''With Development'' and if required you could set this to pause the timers.

There will still a fair bit of work to do with automating the changing of these sub-statuses from a linked or parent request.  This is not currently scheduled for development, however I will keep you posted of the progress.

James

Link to comment
Share on other sites

James,

This seems similar to a request we have whereby we want to have a status to indicate that we are awaiting information from the customer. However we would want the status to revert automatically when an update is provided by the customer. We would use these status to give visibility to the incidents that need our attention.

hope this helps flesh out requirements for this important feature.

 

Keith

Link to comment
Share on other sites

Hi Keith,

This is exactly what we have been struggling with. (Colleague of poster)

90% of our requests require feedback from the customer before resolving/resuming working on the request. For now we just put requests on hold for a few days and rely on Hornbill notifications to have agents resume working on the requests. As you can imagine this is far from ideal. There is no way to distinguish the on-hold requests which are actually on-hold from the ones which are just awaiting feedback.

Link to comment
Share on other sites

It sounds like the sub-status feature would definitely help here.  You will be able to have things like "With Customer", "With Development", "Waiting Approval".  This feature is already in the development queue and not too far away from being worked on.  It may not contain all of the required automation, but it will provide a platform for which the automation can be built.

Regards,

James

  • Like 1
Link to comment
Share on other sites

Hi @James Ainsworth,

A few minutes ago we had a major incident, which involved all our customers. Another great improvement to this system would be that you are able to update all linked requests with the same update. At this moment I was busy for about 30 minutes to update 37 requests with the same message / email.

You are able to easily resolve the linked requests via the workaround option. When selecting the option accept sollution this resolves the request with the text supplied via the main problem request. In most cases - at least for us - there are updates in between before we can resolve a request of this magnitude.

Is this option already in the system?

Mark

Link to comment
Share on other sites

I have to agree with @Keith and  @m.vandun- multiple updating/ resolving/ putting on-hold individually is currently a major analyst hungry process. Its one I do struggle to see how you can allow to continue in a modern Servicedesk tool - anytime you get a major incident/problem, multiple tickets would flood your front line. We need a way of dealing with them quickly and efficiently - one by one doesn't make sense.

For example - we are using SCOM to generate tickets (eg. disk low on Server X) in our tests we created 100's of tickets which needed to be resolved individually - I wasn't popular with this team when I told them how to resolve them (one by one).

Link to comment
Share on other sites

  • 2 weeks later...

@James Ainsworth, @Gerry

We had a couple of bad days - email/ logon server issues which generated a lot of tickets that we need to update or resolve. My analysts are really complaining they can't continue to do this individually - I really need to give them a date when Hornbill will have this basic functionality.

Regards

Nasim

Link to comment
Share on other sites

  • 1 month 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
×
×
  • Create New...