[Automatic reopen ticket based on an email]

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. 

 

[Automatic reopen ticket based on an email]

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.

[Automatic reopen ticket based on an email]

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. 

 

[Working in mobil app makes requests still show as yellow-coded in web request list]

There seem to be a missing link between the mobile app and the web client.

When an operator/agent uses the mobile app to read/do changes on a request he owns, the request will still be showing as "yellow-coded" in the request list in web brower.

This maked the supervisor believe the operator have not yet seen that there is work to do on the request.

Is this s feature or a bug?