How do you handle requests where input of the requester is necessary after a certain step, or where the requester can be prompted to change the initial parameters?

[Max Nowak]

Hi,

I'd like to know how you handle requests where additional input of the user might be required. Here are two examples I just recently encountered:

1. A customer wants requesters to be able to change the initial parameters of the request. In the simplest form, this would be changing the value of a field that was present on the original request form.

2. Another customer asked for a "multi-step" process, where the requester will submit their initial request, then the fulfiller will complete some tasks, and then the requester needs to submit additional information (which might be based on the information the fulfiller provded). An easy example of this would be ordering a laptop, where the fulfiller will look up the current stock of available laptops, and the requester will be prompted to select a laptop from the available stock afterwards.

Up until now I have always told customers that that's not possible, or at least not feasible. I've advised catalog items and their respective workflows to be straightforward, without requiring any further interaction of the requester, if possible, and that if the requester wants to make changes, that the original request has to be closed and a new request has to be opened. In part, that's because I didn't know how I would implement those requirements, apart from telling the customer to use additional comments to communicate in an unstructured way, i.e. the fulfiller comments with a list of available laptops, and the requester replies with the specific laptops he chooses.

But I'm wondering, is this really the case, or are there some of you out there, who (somehow) implemented workflows that support a back and forth between requester and fulfiller, with structured information? I have thought about using the form widget on the service portal to allow the requester to edit the parameters of his initial request, this would at least solve my first requirement (1. above), but I'm not sure.

[Mark Manders · Accepted solution]

Don't. You have been right so far, so don't change your way of advising. That list of available laptops should be available when filling the form, not because a fulfiller walks up to a closet and checks what's available. Have the choices available and if they are changing, make them generic (windows/mac, developer/non developer etc.). And the End users gets the laptop he is assigned to. If not to their liking: depending on company policy, exchange it or deal with it.

Your other use case: why? If you ask your end users a question and it's answered, why does he needs to change the answer? If this is a common thing requested by a company, find out the reason why that needs to happen. And once you got that reason: solve it by asking the questions upfront. If it's not a regular thing: use the comments. 

You are the guide and even though some times requests from customers seem to make real sense, it doesn't mean customization is the way to go. 

If my answer helped you in any way, please then mark it as helpful. If it resolved the issue, please mark it as correct.

Mark

[Max Nowak]

Hey Mark, thanks for your reply. It reinforced my current view of doing things.

Have a good day!