Wait for Request Update > Reopened Outcome

[will.good]

Hi,

 

In our Business Process, requests are in Resolved State for 5 days and then auto close. We have noticed with a few requests lately that they have auto closed even after the customer has reopened the request.

My thoughts are that the decision node, seeing that the request has been reopened would go down the No Match route and stop the 'wait for request update' timer (to stop the request from closing) but this is not the case.

Does anyone have any suggestions on how to make it behave this way?

 

[James Ainsworth]

Prior to the decision node, you have "wait for request update".  Is that the automation being used?  I'm assuming that just before this, the ticket is being set to resolved.  The "wait for request update" is looking for an update from the Update Action on a request.  If a customer is using the option to say Yes or No to the resolution being successful, this doesn't count as an update using the Update Action.  I'm not sure what impact that this might have on the decision node as I can't see the entire workflow.  

In place of the "wait for request update", I would use the "wait for status change".  The expiry can still be used to set to closed after a set time if there has bee no change to the status.  The customer responding to the prompt to the resolution working or not, will change the status to either closed or open, depending on what they select.  Equally, an agent could manually change the status if they are talking directly to the customer.  I hope that makes sense.  Documentation found here.

[will.good]

Hi @James Ainsworth

Is this how you would expect the wait for status change to be used? Specifically the decision node after it.

I have tried your suggestion, but It seems to bypass the wait for status change node and just reopen it straight away, for some reason.

[James Ainsworth]

Hi @will.good

I can't see what is behind the "success" decision, but in almost all cases when checking for "success" it simply means that the previous node completed without error or with all the info it needs to continue.  This will always be the case so it will always take that route.  I would suggest that you can remove the node for set status = open.  and the expression for that path should be to check that "status is open". 

I'm afraid that it is difficult to say exactly what is best for you as I'm not aware of how you want to work or what your desired outcome is for the process.  These are the scenarios that I believe you are looking to manage.  The decision node needs at minimum a check for expires, a check for status is open, and a check for status is closed.

1. After X days it closes automatically - follows the route for "expired" - sets ticket to closed.
2. Before X days a customer says the resolution didn't work - ticket is automatically set to open - status change detected - follows the route for "status is open"
3. Before X days a customer says the resolution did work - ticket is automatically set to closed - status change detected - follows the route for "status is closed"
4. An agent manually closes - status change detected - follows the route for "status is closed"
5. An agent manually opens - status change detected - follows the route for "status is open"