How to move request to different services

[Giuseppe Iannacone]

is there a way to manage a request opened against a wrong service? let's say i have the service A and a service B. the request was initially assumed to be of competence of the service A. after the diagnosis you discover that the request was for service B. both service have different team support.

how can the request be moved from A to B?

[Victor]

@Giuseppe Iannacone

56 minutes ago, Giuseppe Iannacone said:

how can the request be moved from A to B?

It can't. You need to close the request raised against A and raise a new one against B.

Maybe the initial diagnosis can be done differently to ensure the request is raised against correct service?

[James Ainsworth]

You can also use the Linked Requests option to create a new linked request under the appropriate service.  This will copy over some of the original data and maintain a link to the original request if this needs to be referenced again. 

James

 

[Giuseppe Iannacone]

1 hour ago, Victor said:

@Giuseppe Iannacone

It can't. You need to close the request raised against A and raise a new one against B.

Maybe the initial diagnosis can be done differently to ensure the request is raised against correct service?

I supposed this would be your reply, but hey we are humans... there's no backfall plan for this situation? for example the service desk manager might be able?(it's clear to me it's not possible at the moment, but maybe in the future ? )

[Giuseppe Iannacone]

1 hour ago, James Ainsworth said:

You can also use the Linked Requests option to create a new linked request under the appropriate service.  This will copy over some of the original data and maintain a link to the original request if this needs to be referenced again. 

James

 

i was think to this approach too, but the user will at this point receive a new notification for a new request and moreover

if request 1 is raised against service A, then i raise request 2 linked to 1 and raised against service B, how can i make it happens that once the request 2 is resolved/closed the request 1 is resolved/closed at the same time?

[James Ainsworth]

Hi @Giuseppe Iannacone

Yes, depending on how you have set up your workflow it is possibly that the customer would receive a second email.  It might be possible to do a check in the BPM prior to the sending of the email to determine if an email should be sent or not.  But, I would also say that if a new request has been raised, the customer may actually want to get this email.  This way they have knowledge of their new reference number.  Once your new request has been raised under the correct service, the original request would now be a duplicate and under the wrong service so you may find that you are better off using the cancel option for this request.  This will keep it out of any statistics for the other service or prevent someone from that team accidentally picking it up and work on it.

James

 

[Victor]

@Giuseppe Iannacone I'll give you two reasons why moving requests between services or changing the service on requests is not advisable:

1. Services are closely tied to business processes. So let's take the example of service A and service B. Both services have different processes associated with them. If I raise a request against service A and progress the business process to a certain stage before realising the request has been raised against the wrong service. Assuming changing service is possible, this would raise the following questions: what happens with the current business process? Is it canceled, stopped or continued? When the service is changed, how the business process associated with service B is managed? Do we start it from the beginning, possible repeating tasks and sending same emails again? Do we start it from a certain point? I hope you understand the challenge in this scenario and why changing service would be almost impossible at this point.

2. Services can be supported by specific teams. This means request visibility is governed by this concept. Let's say service A is supported by team A and service B is supported by team B. Same scenario, a request is raised against service A where team A progress it to a certain point where the need for service change arise. Assuming changing service is possible, this would raise the following question: if team A and team B have visibility restrictions (i.e. requests managed by team A should not be visible for team B and vice-versa). How should the visibility of the request be managed? If the service is changed to service B, based on the visibility concept, thsi means the team B should not have visibility of the work done by team A at that point. Same with team A, which should not have visibility of the work performed forward by team B. This is not possible, to have "selective" visibility of specific sections of a timeline...