Wait for Customer Response

[Steve Giller]

I think my search skills are lacking today, I can't seem to find anything I'm looking for!

Hopefully this is a simple request;
I want the Business Process to pause until a Customer completes a task (filling a box - literally!) and lets us know.
I have all my user tasks in place, they're flowing nicely, get the box, label it up, deliver it to the customer - now I need the whole thing to pause until the user says "It's full, come and collect it."
Is that as simple as it sounds and I'm just looking in the wrong place?

 

Cheers,

Steve.

[James Ainsworth]

Hi @DeadMeatGF

When a BPM task has been added to the workflow this will generally pause the workflow until that task has been completed.  I'm guessing that you are not looking to use a task for the  "It's full, come and collect it" and you are looking for other options to suspend the workflow until maybe the box has been collected.

This is a screenshot of the different suspend options that are available to you.  If not a task, you could use a suspend option such as "Wait for Off Hold" or if the collection of the box indicates the resolution of the request then possibly the "Wait for Request Resolution".  Let us know if any of these help.

 

Regards,

James

[Steve Giller]

That is more or less the functionality I need, but (with most of our customers) this won't drive people to the portal, they'll phone up and say "It's ready" rather than type an update into the timeline; and this won't specifically wait for the customer to say that the box is ready.
Additionally, because this is with different departments at different times they may not call the "correct" Service Desk which will frustrate those teams.
What I really need is similar to an Approval button that can only be clicked by the customer - and I can't work out how to set that up (or even if it can be - I'm just learning this!) If I use an authorisation node it works if the analyst clicks the button, but I can't get that working with the customer clicking it!

[James Ainsworth]

At the moment I can't think of any options that would provide a button that a customer on the portal can select to signify the that the box is full and ready for collection.  To use the authorizations the customer must have a full collaboration license.  I will do my best to see if I can come up with an alternative.

Regards,

James

[Steve Giller]

A human task with a "close or reopen" a resolved request only works if an analyst completes it, even though the customer sees and can click the buttons on the timeline - is this also because it requires a collaboration license or is it an issue with our setup (or a mistake in my process flow) do you think?
If the former this is currently a dead end, if the latter then we can use the same method to indicate the boxes are ready (once it's fixed!)

[Steve Giller]

To illustrate: if I set a Human Task as in the image, the customer sees button on the timeline: If they click the button, the timeline updates and the feedback triggers, but no further nodes appear to be processed until the analyst completes the task from their portal, regardless of whether the customer has taken any action. (This is actually for a Resolved call but the mechanism is the same)
Will a Suspend-Wait for Update node immediately following the human task trigger, to allow the task to progress?
Or have I simply mis-configured something and if I tweak it the flow will continue?

[James Ainsworth]

Hi @DeadMeatGF

Human Tasks also behave in a way that will suspend the workflow.  Having both a Human Task and a suspend and wait for update will result in having two separate suspensions and each node will require the appropriate action to proceed.

You will have to forgive me as I'm still trying to understand exactly what you are trying to achieve.  There is no coloration between the It's working and It's still broken buttons and the human tasks. The two buttons provide a way for a customer to confirm if a resolution has worked or not.  The human tasks are only for full users within Hornbill.  That is correct that a support person will be required to complete that task to proceed.  If you are wanting the customer to be able to close the request using the It's working button then I'm thinking that you just need to remove the human task for the analyst.  

Regards,

James

[Steve Giller]

That sounds good - forgive me (I'm new to this) but how do I give customers buttons without a Human Task? I've only seen them appear when I put a Human Task in the flow so far. Or do they simply appear automatically with a request resolution?

[Alex8000]

Hi @DeadMeatGF,

On request resolution the customer will automatically be presented with these buttons. Confirming resolution will close the request, marking it as not resolved will reopen it.

Hope this helps.
Alex

[Steve Giller]

Thanks @Alex8000 - that's the bit that isn't happening, but from this thread I'm pretty sure it's my code that's wrong. Can you post a screenshot of the correct nodes to take a call from Active to Resolved with the following branching for Reopened/Closed so I can compare mine, please?

[Guest]

Hi @DeadMeatGF

The two buttons will appear on the portal automatically when a request is resolved, like below:

 

A few things just to re clarify:

1) These have no connection to Human Tasks - this is an automated behavior for those who would like a 2 stage closure (Resolve/Closure)
2) Other than these options, there is not currently any way of presenting any other "Outcomes" on the portal for a customer to complete. So for example, if you had a human task whilst the request was still open, with the options "Happy/Not Happy" - an analyst could select one of these options through the human task on the customers behalf, but you cannot present those as options for the customer to complete on the portal. 

So if you have a Human Task, it allows you to give the option for your analysts to close a request, and even put an expiry date on the task so after a certain time period, it will complete itself. An example is as below (again, the Human task is for the analysts benefit only):

However - as you have mentioned, there are some loopholes in this approach, primarily the fact the a customer can in effect "Close" or "Reopen" the request via the portal using their own mechanism (the buttons). As these have nothing to do with the Business Process, it almost bypasses the next actions so for example:

a) Request is in a Resolved State - the customer clicks "Its working" - The result is that the status of the request is Closed, but there is still a task outstanding
b ) Request is in a Resolved State - the customer clicks "Its still broken" - The result is that the status of the request is Open, but there is still a "Happy to Close" task outstanding (which may well still expire if you have set this) and the BPM has not changed its progress

So as you can see, neither situation is ideal. We have been looking into this carefully and I'm please to say that to rectify this, we have a new feature that will be delivered in the next 90 days - which is likely to introduce a "Suspend - Wait for Status Change" node. This means the BPM can continue on a route you define based purely on the status of the request, without worrying who and how it was changed. This will also be able to accommodate an expiry date, much like a Human Task so you could set any requests that have been "Resolved for 7 Days" for example, to be set to closed. 

[Steve Giller]

Awesome.

Thanks for clearing up my misunderstanding, and for the upcoming improvement.

[Steve Giller]

After getting back to this and "having a play" I've discovered that my mistake on the resolution/confirmation part was that I was not following that with a Suspend/Wait for Closure node - this gives me the functionality I require except for the fact that there is no expiry on that node.

If the Suspend/Wait for closure node could have an expiry time in the same way that a Human Task does that would really streamline the process; as it stands we have to either have the analyst checking all resolved calls to see if they've been in that state for a certain amount of time, or (not tested this yet) combine this node with a Human Task that will override it once the expiry time is reached.

[Dan Munns]

Hi @DeadMeatGF,

You can set an auto close node as attached if that is what you are looking for (set to 5 minutes in the image for testing)

We have an auto close on our incidents to give users time to fully test all resolutions.

 

[Steve Giller]

That could be the one - does it still leave the resolved/unresolved buttons on the customer's timeline or is it a replacement for them?

[Dan Munns]

No the users still get the buttons and if they click close it closes automatically, if they click 'it's still broken' it reopens the call.

I am just having issues with the resolution timer as I have the timer stop as the last node but when a resolution is added it closes the timer anyway. I am sure it is just how I have set up the BPM though.

[Steve Giller]

My issue is that no matter what values I put in, the call closes off after about 10 seconds - so I need to use this node in conjunction with another?

[Dan Munns]

I put a suspend - await request closure straight after the auto close node so the BPM sits there until the auto close node changes the status to closed, then the BPM continues.

[Steve Giller]

With you, thanks @Dan Munns.
I will get the hang of these new nodes! (One day!!!)

[Dan Munns]

I still haven't!

Still, i like to learn new things (good job really)

[Steve Giller]

The only question now is - is there a way for the Business Process to know whether the closure was due to the timeout, or the customer clicking the button?

[Dan Munns]

In the timeline you can tell. Either closed by <userID> or closed by System Internal Context.

You could then create a report based on call closed by: and filter on System Internal Context. That would tell you how many calls the system closed due to timeout.

You could then assume that anything the system hasn't closed was closed by the user.

 

[Steve Giller]

It was for the Process rather than reports, so I could send an email saying "You closed it" or "You didn't respond so I closed it" - not a biggie, though.

[Dan Munns]

On my closure email I have a line which says something like 'If you are still having an issue please log onto the web portal here <link>. Please note that your call will be closed in 2 days time if you do not respond on the portal.'

[Steve Giller]

That's the route I'm going down - it would be nice to be specific, but it's not essential.