Automatic reopen ticket based on an email

[akbrekka]

On 24.10.2016 at 11:13 PM, James Ainsworth said:

Hi @m.vandun

We don't currently have any planned requirements that provide the automatic re-opening of a request based on an email.  As suggested by Ehsan, we can investigate to see what options could be provided.  Our experience in the past suggests that automatically opening a request on an email update can be problematic as the email may just be a simple Thank You email, an email sent in error, or even an out of office response from a closure notification email sent to the user.  Each of these could result in the request being reopened when you don't want it re-opened. Providing a key word in the subject could be considered, but then it is about educating the user base to know when to use this keyword.  

For now you should be able to have resolved or closed requests updated by email and then have the owner notified of the update.  The owner can then make that decision if re-opening the request is required or not.  

Regards,

James

Is there any change of plannes regarding this?
Our customer finds it very strange that this is not supported. They are used to other system being able to re-open requests within a Resolved (Not Closed) status. 
The typical scenario is that a case is resolved and customer get's an email about the resolution.
In a perfect world they then would go to the portal, but.... that's not happening often. They do a reply
When they do the reply, the request in a "waiting 5 days before auto-close" phase, and should have changed status from "Resolved" to "open", or an "update" state.
Eithout this functionality, operators have to monitor the Resolved list to track the updates. 

 

[Dan Munns]

@akbrekka You could add a substatus change in before the wait 5 days phase.

Say it's an on hold substatus of 'Waiting for Auto Close'. You can then set the status to change on ticket update. So from 'Waiting to Auto Close' (on hold status) to 'Customer Updated' (active status).

You can set these up under each service. You just need to make sure that the toggle switch is set to one for the sub statuses you want to react to customer responses.

 

[Victor]

On 09/02/2018 at 2:33 PM, akbrekka said:

They are used to other system being able to re-open requests within a Resolved (Not Closed) status.

@akbrekka in addition to @Dan Munns suggestion, everything you mentioned can now be achieved: have a request in resolved state/status and re-open on an update...   

This thread was created in Oct 2016... almost 1.5yrs ago.... many many many things changed and improved since  

[akbrekka]

On ‎09‎.‎02‎.‎2018 at 4:09 PM, Victor said:

@akbrekka in addition to @Dan Munns suggestion, everything you mentioned can now be achieved: have a request in resolved state/status and re-open on an update...   

This thread was created in Oct 2016... almost 1.5yrs ago.... many many many things changed and improved since  

As far as I can see there is still no way to move a request from resolved to open based on a Customer update.
Do you have an example of such configuration?

I can see that what @Dan Munns is suggesting could work, but that would need a complete change of the process and the use of statuses.

[Victor]

@akbrekka 

1 hour ago, akbrekka said:

As far as I can see there is still no way to move a request from resolved to open based on a Customer update.

Once request is resolved, have the BP in a suspended state, wait for an update (this node can also be set with an expiry timer (*) so it won't wait indefinitely). When the update happens, BP resumes and have the next node change the request status to open. Loop this sequence as many time as needed.

(*) If the BP resumes as a result of the suspend expiry you can have the BP go via another route...

With @Dan Munns suggestion you would need the request to be "On-Hold" rather than "Resolved" but apart from this, it is a viable solution.

Alos, just to make sure we have the same understanding, Resolved is not Closed, right? (saying this because Resolved is actually still an active state unlike Closed...)

[James Ainsworth]

Hi @akbrekka

In this post there is a great discussion on two stage closures which includes the re-opening of a request if a customer feeds back that the resolution doesn't work.  However, this does not account for your requirement which is to re-open when a customer sends an email. 

I'm not sure how we would differentiate between an email from a customer that says ''Thanks it is resolved'' from ''Thanks, but it is not resolved'' in order to automate this.  While this can be managed on the portals, I'm not so sure about an email.  Possibly you are looking for a simple notification to the owner of the request that an email update has been applied which would allow them to manually make the choice of re-opening, closing, or letting it expire?

Regards,

James 

[akbrekka]

Thanks for the feedback @James Ainsworth

From our point of view any feedback from customer (from email) is important to be aware of. Even if it is just a "Thanks, it's resolved".

Manual action is acceptable for these scenarios.  (Unlike the fact that case owner today is not aware of the customers update by email.)

If an incoming email to a request within resolved status, automatically changes the status to for instance "Customer update", the operator can check the feedback and either close it or re-open it.
When adding the ability for an "updated from customer" status, operators could activly check this queue and address requests properly.

Notifications, and escpecially email to case owner is not preferably cause it causes a lot of noise.