Wrong Service Used - Best way to handle

[Keith]

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

 

 

 

[Martyn Houghton]

@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

[HHH]

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.

[Keith]

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.

 

 

 

 

 

[nasimg]

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

[Keith]

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.

[HGrigsby]

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.

[samwoo]

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

[Keith]

 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

[Martyn Houghton]

@Keith

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

Cheers

Martyn

 

[Steven Cotterell]

@Martyn Houghton, cancellation reasons can be self defined...  check here...

Cheers

Steve.

[Keith]

@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'?

Cheers

Martyn

 

 

[Keith]

@Steven Cotterell Thanks!! You learn something new everyday

[Martyn Houghton]

@Steven Cotterell

Thanks, just added two new entries now, one for Incorrect Service and another for Internal Testing.

Cheers

Martyn

[James.Johnson]

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

[Martyn Houghton]

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

[Steve Giller]

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.

[Berto2002]

I'm experimenting with this approach which appears to work:

1. Create a Simple List with entries for all the Service Portfolio Services you would want your Agents to select if they altering the Service of a Request
2. In the Simple List, set the Value as the numerical ServiceID
3. Add a Human Task to allow the Agent to select an entry from the Simple List
4. Use that entry as the Variable input for the Update Request Service node action
5. [Optionally store that value in custom field or output to Timeline]
6. [Optionally have that Human Task expire so if the Agent doesn't exercise the option 'immediately' (2 mins?), workflow moves on; or they can just complete the task]

There are options there to also update the Business Process but I haven't experimented with that; it seems 'dangerous' as there could be all sorts of dependencies in other BPs and from their proper PCFs, etc that our testing regime could spiral.

Simply having the listed Service correct is helpful for all sorts of reasons for Agents during the workflow and for reporting afterwards, even if the BP in the background is incorrect.

I'm also toying with how I then systematically store these Service 'flips' for reporting.

Any feedback appreciated on improving this or alternate methods. It would sure be great to be able to do a lookup in the Human Task for a list of Services instead of having to duplicate that in Simple Lists, for example.

[Victor]

Feedback... umm...well, right, about this then:

27 minutes ago, Berto2002 said:

There are options there to also update the Business Process but I haven't experimented with that

I would say do not. A very simple reason for this is that it does not really work  ... I mean it partially works, is just that "update the process" is in essence a two-step action a) cancel the existing workflow and b) spawn the new one... the cancel bit does not currently (always) work so the request will end up with two workflows...