While Jira has native email-processing, sometimes companies need more than what comes out-of-the-box.
For example, one of our clients has an existing business process that includes 3 teams of 5 people each managing over 300 total emails a day through a single mailbox.
This resulted in several issues that needed to be addressed in order to manage these threads:
- Since the emails were addressed to a common mailbox, the teams needed to figure out who would take ownership of each thread.
- Outlook often worked against them when it came to managing lengthy threads.
- During periods where the volume of emails were high and the need for fast replies was at its greatest, efficiency would decline.
Unfortunately, the company could not change this business process fundamentally without great pain which necessitated the need for some creative thinking. A whip-smart analyst had the idea that he could analyze the emails’ content and establish patterns from which incoming mails could be scored. He tested his theory by analyzing thousands of emails and then developed a model that grouped keywords with a relevance score to each team. Once he got enthusiastic support to find a way to apply his research, he eventually selected Valiantys to implement a solution with Jira.
The solution required Valiantys to:
- Create a Jira issue for each email thread, and add all replies to the issue as comments.
- Score each thread according to the developed model.
- Assign the issue to the right team member based on the thread’s score.
The proposed solution included Jira Server and the following plug-ins:
Creating the Jira tickets via email
In this use case, creating issues and comments from emails – while remaining true to the company’s processes – wasn’t possible with Jira out-of-box. To start, we didn’t have a way to connect any of these emails to Jira issue keys – a prerequisite to working with any of the out-of-box issue management features in Jira. Jira (and JEMH) depend on an issue key being present in the Subject of an email. Without this token, no match can be made.
However, email headers do tell us the things we need to know to associate the emails. In particular, Message-ID and In-Reply-To.
|Message-ID||A unique identifier for a digital message, most commonly a globally unique identifier used in email.|
|In-Reply-To||Message-ID of the message that this is a reply to. Used to link related messages together. This field only applies for reply messages.|
By capturing the Message-ID and In-Reply-To email header values and mapping them to Jira custom fields, email threads could be maintained inside of Jira.
Scoring the emails threads
The company and Valiantys collaborated to devise a way to map the model for their processes into Jira. The model broke down into first level groupings called Routes. Each Route had n-number of keywords and keyword groupings, each of which was given a score between 1-100.
Jira issues took the following structure:
- Keyword (Search Criteria – standard issue-type)
- Keyword + Lookup (Pairing – sub-task issue-type)
The model consisted of any number of Routes, expressed as Epics. Routes can have any number of Search Criteria, expressed as a standard issue-type. Search Criteria can have any number of Pairings, expressed as a sub-task issue-type of Search Criteria. Finally, each Pairing can identify any number of lookups expressed as Multi-Select List custom fields.
Developing the workflow for Jira emails
When an email arrives, a new custom Jira issue Email (standard-type) is created. On Create, its Message-ID and In-Reply-To values are mapped to custom fields. From there, scripting fast-tracks the Email through a set of workflow steps.
- Determine if the Email is a
- Thread – which has no In-Reply-To value
- Reply – which has an In-Reply-To value, and the In-Reply-To value matches the Message-Id of another issue already in Jira, or
- Promoted Reply – which has an In-Reply-To value, but the In-Reply-To value references an email that is not in Jira. This can occur when the mail address we are watching is added in the middle of thread. In this case, a message with an In-Reply-To value is treated as a Thread.
- Score the Email per the Model
- Create a Thread issue for each thread or promoted reply or add a Comment to a Thread issue for reply emails
- Score the Thread – subtotal scores for all emails in the thread
- Assign the Thread issue to the Team assigned to the Route with the highest score
- Transition the Thread issue to a Triage status
Smarter teamwork with Jira emails
A primary obstacle for each team was simply deciding who takes ownership of which email thread. Scoring theses threads made it possible to segment all incoming threads by team. While not 100% foolproof, it greatly reduced the amount of time each team spent coordinating with other teams. In the case where the model assigns an email thread to the wrong team, the issue can simply be assigned to the correct team during a daily triage meeting.
Dashboards helped by visualizing the distribution of threads among the teams – live data that leadership previously lacked. This ensures that work can be more evenly distributed and safeguards against threads being overlooked.
Periods of increased workload can be identified in real-time, so adjustments can be made regarding priority – a capability not-possible without scoring, segmentation, and visualization provided by dashboards.
All businesses manage work at least to some degree through email, yet in particularly for ITSM the need for order when too many emails are being received is a critical point to manage. If you need help setting up this use case – or something similar – in your Jira Software or Jira Service Desk instances, don’t hesitate to reach out to Valiantys.