Enhancement: Customers have asked for a portal button to close their own tickets (and Service Desk want it too)

[Berto2002]

We've noticed there are quite a lot of tickets were our users want to close one of their own tickets but they cannot. The use case is almost always "logged in error" or "no longer required" where they have a workaround or they can self-serve or the need has gone away or the issue has "fixed itself".

However, all a user can do is send an update and then the Owner has to respond and resolve/close; which takes time.

It would be a quick productivity gain across the board to have button that could be enabled to allow users to resolve/close/cancel their own IN or SR Requests. It would require a reason and we could have it resolve with a pre-set category.

[James Ainsworth]

Hi @Berto2002

There are a couple of settings related to the portals that allow for the cancellation of service requests

There isn't an option for canceling incidents at the moment.  Cancelation works best in this scenario as a customer may not be fully aware of the process that is in play on a request.  Canceling will also cancel tasks and the running workflow.  The problem with canceling is statistics and visibility.  A request that a support person has spent time on can all of a sudden be removed from sight and possibly something that they won't be credited for, having worked on it.  There can be any number of reasons or settings that prevent a member of the support team from resolving a request until certain actions have been completed such as completing tasks, closure categories, etc. These things can make a big difference in reporting and analytics.

I'll have a think to see if there are any alternative approaches to providing something that might help.

 

 

[Berto2002]

@James Ainsworth I really want this to be a "close" not cancel. As you say, cancel is brutal and it disappears from stats. Other use cases for a CLOSE:

1. A customer might just "call it a day" and say "don't worry, it's fine, I'll live with it" and want to close it. We would want that on the stats, including records of time and tasks we had expended.
2. Sometimes users log tickets when we have Major Incident and they know it's fixed long before the Service Desk have got through all the tickets resolving them manually; some users would be proactive about closing them. In fact that would be a majorly useful indicator for us if users started to close Incidents after a resolution, we could detect this and it would help validate the solution
3. Sometimes the resolution is provided by third parties and the user realises they have logged in the right place

The list goes on as to why we many want to have a "Close this Request" button. However, I can see the issues this might create if there are workflows mid flight. for example, closing (or cancelling) a new starter or leaver ticket would be a disaster of half-handled tasks we would not know about.

Thanks for thinking about it!

I have another use case which is related but I will start a separate thread on it and tag you because it's an opportunity for Hornbill I think.

[George Zippo]

+1 in terms of wanting our customers to be able to close their requests when they are no longer required without requiring our request owners from expending more time than necessary on these, however with acknowledgement to the following:

• Some Service Owners may not want this enabled and therefore we would need this to be configurable at a Service level not Globally.
• We should be able to report on these closed requests (ie retain visibility of the information available at the time of closing by customer)
• This is available for Incidents and Requests

 

[samwoo]

+1, with agreement to George's first point at the very least.

[Martyn Houghton]

We have been trying to achieve this using the existing functionality in the portals when the request status is set to resolved and the timers are paused, however, there is an existing know issue where the timers are not handled properly when using this function. By pausing the timer, if the customer confirms that the issue is not resolved before the status expires, the timers are unpaused and the request goes back to the analyst. If they respond that it is resolved or the period expires the request is auto-closed by the BPM.
 

Cheers

Martyn

 

[Berto2002]

@Martyn Houghton this is my current bypass for a type of ticket I don't track SLA and which I want to eventually then close without our involvement. It doesn't close on demand as such but one could reduce the wait period to shorter than 6 months.

The net effect of this for the customer is that it "resolves itself" every two updates but the customer can then add an update and reopen it and carry on. I use a notice to explain-away this behaviour. But when it then falls into disuse, it eventually drops off the list and closes.

 

This is one of the use-cases of wanting to have a close button for the customer. Essentially, we are allowing customers to log and track their own mini-issues in their team.

[Berto2002]

The set of buttons I would like to see which can then be acted-up on BPMs (currently we have no 'intelligent' capture of a Customer's Updates on a Request) and which are enabled/disabled per Service as appropriate:

1. Close (direct close if no outstanding Activities; else an alert to the Activity holder of the customers intent so they can enact it appropriately)
2. Escalate (appears after a trigger from the SLA)
3. Approve (appears if a node requires that person to approve something; could be given in the BPM to the Collaborator such as the Line Manager; perhaps can be an alternate vehicle for the External Auth node)
4. Hold (available any time and can be used by the customer to say their issue may have gone away and they want to stop IT wasting time until they advise; includes optional release date/time)

At present, the HB system implies that IT do all the work and it's thus one-way. By empowering users on their tickets I believe we would have a more engaged and interactive customer base and we would reduce our workload.

[Berto2002]

@Martyn Houghton did you +1 this?

[Martyn Houghton]

@Berto2002

+1 that we definitely need to make the customer and employee portals more interactive and give them outcome buttons which are dependent on the current stage/status. There can also be a 'reason' text field to capture their update, but in essence, we want the customer to categorise their response so the BPM can then act on it, rather than just coming off hold.

There was a fix applied in relation to unpausing timers at the resolution stage which we are still testing at the moment.

Cheers

Martyn

[Sam P]

+1 from me