JIRA Service Desk seems to be designed for internal customers. Is JIRA Service Desk a good match for the following use case (our current setup working this way is with an old version of Helpspot)?
1. Customers who can send a customer request are in the thousands. We do not even know their emails. We do not even know if they are fake emails or one-time emails.
2. Customers requiring support fill a form in our website with three fields: Title, Description, Attachment, and Reply-To email. Our current website code creates an email with this data and sends it to Helpspot.
3. When a new case is received, the support agent receives a notification.
4. The support agent logs in to handle the notification. When she adds a public comment, the customer receives an email with her answer.
5. For the customer it seems a regular email. To reply it, she simply clicks Reply in her email program types texts and clicks Send.
6. The support agent receives a notification, logs in and types another public comment.
7. The customer receives an email that seems to continue the mail thread.
In other words, from the Customer point of view, except for the initial web form, it seems as she is exchanging emails with another person using gmail or outlook. From the Agents point of view it seems as if the customer was adding comments to a case in our Helpdesk system.
Is JIRA Service Desk prepared to support this use case? It is important that the customer experience is that she is simply emailing someone, and that JIRA is not confused by the presence of the whole thread in the email that is exchanged. It also has to support clearly the exchange of attachments (that is, with which comment each attachment came).
If this use case is supported by JIRA Service Desk, is there any "How to" document explaining how to set up this particular use case?
Hi Josep, a little late, but here goes - going through your list:
Remote email-only interaction with JIRA/ServiceDesk can be done with JEMH, Service Desk doesnt support email only users at the moment. Remote senders cannot use JIRA interactively, but through JEMH can use a proxy account to create issues, comments made by JIRA users via service desk or standard JIRA UI result in issue event notifications.
An automated source of email format makes it possible for JEMH Field Processors (content handlers) to process the text. Specifically, the Regexp Field Processor can be configured to extract content (through regular expressions) for particular 'fields' that are mapped to JIRA properties/custom fields.
JEMH has an Event Listener for those notifications that you can configure just 'non-JIRA' email users to receive updates. You have control over the 'type' of events that result in notifications, so you can reduce the 'chatter' to remote parties to just key event types 'commented','resolved' etc, so can ignore 'updates'. You could use JEMH for JIRA notifications also, or not.
You can customize the notification content through JEMH TemplateSets that group subject/text and html content of a notification, if you stick to text, this is pretty simple. The only provisio is that the subject contains the issue key to allow association with original issue (this is automatic).
Regarding the point about associating attached files with comments, JEMH has inbound capabilities to automatically add to each 'email' comment that contained attachments, a small wiki markup table with direct links to attached files and images. JEMH also supports inclusion of JIRA user attached files for distribution to remote email only users.
There is a JEMH/ServiceDesk how to.
Hi Andy, thank you for the pointers.
I have one additional question:
Does JEMH somehow "hide" the previous thread items in the issue comments so that each new comment shows the information added to the thread by the customer replay?
In other words, that if I am the customer, I see an email with say, 5 interactions and if I am an agent I see 5 comments, but without text from previous comments or emails being unnecessarily duplicated as the thread progresses (i.e. in the email there is only one instance of each previous stage in the conversation).
when users reply to mail, most mail clients will present the replied to content in a particular way, and will be culled by default. JEMH also has customizable on-comment regular expressions that match the start of any 'unique' combination of client/language etc. It has to be generic because the format of replied to content is not a standard.
The intent is that JIRA will neatly represent the 'new' content only and not include historic content.
You can try Customer Case for JIRA Cloud:
It allows you to use two communication channels - email and web-interface for submitting tickets and issues. Your customers can send their problems and replies to the specific emails, and these emails will be converted into tickets or comments.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG