Jump to content
Keith

Wrong Service Used - Best way to handle

Recommended Posts

We almost exclusively use the self service portal which in combination with users being restricted from some services, leads to requests sometimes being input under an incorrect service.

I see our analysts taking several approaches.

 

1. Cancel request and ask user to create correctly. (not very customer friendly)

2. Cancel the original request and raise a new request on the users behalf under the correct service. (causes some confusion on end users part to understand why their original request is cancelled)

3. Create a linked request of the correct type then cancel the original request.

4. Handle the issue under the incorrectly raised request (I hate when they do this :) )

 

How are you guys handing this and or enforcing thats its handled in a specific way?

 

Appreciate any input.

 

Keith

 

 

 

Share this post


Link to post
Share on other sites

@Keith

We have the same issue and approaches by our teams.

We tend to do numbers 2 and 3, as long as it is captured immediately after it being logged, but this will sometimes depend on the 'quality' of the information provided.

Else we end up with number 4 and use the linked services to at least have some linkage back to what service it should have been logged as.

 

We are focusing on improving the descriptions on the service/catalog items displayed on the portal to reduce the number of incorrectly logged requests. Plus trying to improve the initial information and assessment of the request early on so these are trapped earlier in the process and new request logged under the correct service. The idea being that we minimise option 4 as much as possible.

Cheers

Martyn

Share this post


Link to post
Share on other sites

We tend to do number 3 informing the customer that the request is related to another service before cancelling.
If the request is one that can be resolved quickly it tends to be number 4 with info as above.

Share this post


Link to post
Share on other sites

Thanks @Martyn Houghton & @HHH I'm glad to see that its not just our organisation that struggles with this. Thanks for your input.

I think that 3 is the option I want to try and enforce along with some text in the cancellation about how to raise the correct service in future.

 

 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Issue I have with 1. vs the others, is if you do anything other than resolving it with info on how to select the correct service/catalogue it, you may not have the info needed to complete the request. Plus you need the customer to raise it correctly next time.

If they are simple request (and all the info is there) then 3 is good.

Personally I would like the ability to edit the Service (I know this will be frowned upon by Hornbill)

Nasim

Share this post


Link to post
Share on other sites

Thanks Nasim, I would also LOVE!!! the ability to swap the service but I can see why this isn't possible - Different BPM, progressive capture, SLA, subscriptions etc etc. so this is one feature I won't hold out any hopes of seeing implemented.

Share this post


Link to post
Share on other sites

We have the same problem with the wrong service or CI being used and the service desk do option 3 (sometimes 2).   

It isn't always spotted until the ticket has been around for a while so sometimes 4 gets used.

Share this post


Link to post
Share on other sites

What I have trialled on a few tickets seem to have worked...

  1. Ticket comes in under the wrong Service and/or Catalog.
     
  2. Ticket stays in the wrong team, someone from that Team picks up the ticket
     
  3. They then create a Linked Request to the correct Service / Catalog
     
  4. Back to the original ticket, the user changes the Sub-Status (this bit i haven't actually done yet) to "Awaiting Linked Request Resolution" and puts the call on hold indefinitely (no end date).
     
  5. Someone picks up the Linked Request, does what they need to do with it and navigate to the Resolve action, in here they put in the resolution and advise the user they have logged the ticket under the incorrect service.
     
  6. They then click Resolve -> Resolve this and Linked Requests to resolve both tickets in one go.

Still thinking about the best approach to this though, but it seemed to work.  

Samuel

  • Thanks 1

Share this post


Link to post
Share on other sites

 Hi @samwoo I like your thought process but my concern would be that the user then has two requests open for essentially the same issue which may cause them some confusion. I can't help but think its just cleaner to cancel the initial request after linking it to a new request. 

Plus, I like that it is cancelled as I just ignore all cancelled requests in any reports so I'm not inflating my statistics with duplicated requests.

 

Regards

Keith

Share this post


Link to post
Share on other sites

@Keith

Perhaps we should request an additional option on the Cancel Screen - 'Incorrect Service'?

image.png.0af571fbd6825f7357d6686a48a6ba34.png

Cheers

Martyn

 

  • Like 1

Share this post


Link to post
Share on other sites

@Martyn Houghton That or the ability to add your own custom reasons would be good. 

 

Also, am I right in thinking that the customer doesn't get notified of the cancellation? I'm not seeing any mail template or setting for this.

 

 

 

28 minutes ago, Martyn Houghton said:

@Keith

Perhaps we should request an additional option on the Cancel Screen - 'Incorrect Service'?

image.png.0af571fbd6825f7357d6686a48a6ba34.png

Cheers

Martyn

 

 

Share this post


Link to post
Share on other sites

This has been a useful thread. I'm just starting out and could foresee a similar situation arising so have just updated the 'CancellationReason' simple list.

Thanks

James

  • Like 1

Share this post


Link to post
Share on other sites
22 hours ago, nasimg said:

Personally I would like the ability to edit the Service (I know this will be frowned upon by Hornbill)

@nasimg

Perhaps the approach here is just to have the ability to update the Service and Catalog Item on the existing request, but retain the currently assigned BPM process as is. This avoids the complication of trying to restart/reapply the workflow/timers, but from a reporting and security model point of view it would appear as expected. I suppose it depends on who specific your workflows are.

Cheers

Martyn

Share this post


Link to post
Share on other sites
21 hours ago, Martyn Houghton said:

@nasimg

Perhaps the approach here is just to have the ability to update the Service and Catalog Item on the existing request, but retain the currently assigned BPM process as is. This avoids the complication of trying to restart/reapply the workflow/timers, but from a reporting and security model point of view it would appear as expected. I suppose it depends on who specific your workflows are.

Cheers

Martyn

If a customer clicks on the "My Desk is broken" service rather than "My Desktop is broken" I'm pretty sure that keeping the same BPM would be fruitless.

I appreciate that's unlikely (but not impossible!) but hopefully illustrates why even the concept of changing from one Service to another is riddled with pitfalls.

Ultimately the goal is to have the customer guided to the correct Service rather than presenting them with a long list, which is, of course, the biggest challenge when you're designing what your customers see.

Share this post


Link to post
Share on other sites

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...