How tickets in support turn into tickets in Jira

When users of our mobile email clients contact us in support, in most cases they think that they are almost directly communicating with the developers. This is certainly not the case. Immediately dot the E: if the tickets from the support service fell to the developers in the form in which they come from users, then the developers would turn into support. Therefore, tickets pass through a number of “filters”: first, three support service lines, then they are sent for examination (it is decided whether this can be a product problem and whether there is enough data to analyze it), and then get to testers for reproduction, which results in already final task in Jira for developers. By the way, a few units of tickets get to the examination, from which to the developers in the form of tasks comes 2-5 times less, depending on the project.

What data do we collect and what path do user calls and reviews go before getting to the developers?

Mobile applications have their own usage and update features. In order not to lose the trust of users, you can not just wait for them to send bug reports. Users do not like to do this - many, faced with the application's bug, simply swear and close it, or may complain in social networks, leave feedback on the market. Therefore, we collect feedback not only through the application’s built-in support contact form or to the developers. We also automatically monitor reviews in the App Store and Google Play, messages and comments in social networks, and still collect data sent via the form to Help Mail.Ru.
')
Appeals from mobile applications are accompanied by logs, crash dumps and other information, so sometimes developers still act as support, because Support cannot always use this information to solve a problem on the user's side.

Ticket path

So, the user in the feedback form in the application clicked the button “Send report”. At this point, the application has already generated a list of information about the device, useful and necessary for diagnosis. This includes the gadget model, operating system version, device language, hardware, and other information. On the example of Mail.Ru Mail application for Android:



All this data, along with the text of the request, goes to one of the service mailboxes, depending on the specific application (Mail.Ru or myMail) and the operating system (iOS or Android). When contacting Help Mail.Ru, everything happens the same way - the service generates a letter and sends it to the support box.

Please note that on the report sending screen there is a tick “Attach application logs”. If it is set, the application will automatically pack the recorded logs in a .zip archive and attach this file to the application before sending the application.

Our CRM system picks up a letter with all the data from the mailbox, including the attached screenshots and log files, and automatically forms an application to the support service.



We also automatically pull up user reviews from Google Play in CRM: the system uses the open Google Play Developer API to collect reviews along with complete information about devices, including the application version, device model, screen resolution, RAM, etc. Since the App Store there is no open API, we process reviews from this app store in the web interface for developers.

There is no limit to perfection, so in the future we plan to add to the CRM applications the function of collecting information about the user's subscription to the pushes. We will take data directly from the push server and display tickets in the interface. This will allow you to automatically receive information about the settings of push-notifications in the application, about the settings of the quiet mode and the status of the inclusion of notifications for each mail folder, both at the time of writing the application and at the current time.

The application created in the CRM system is reviewed by support service specialists. If necessary, they ask the user for missing information, such as a script for reproducing the problem or screenshots. Then the application within the CRM system is moved to the appropriate queue (folder) depending on the subject of the problem:

• Authorization
• Attachment attachments.
• View attachments.
• Avatars.
• Synchronization.
• Notification.
• Reading letters.
• and so forth

If the problem is technical in nature and has not been previously encountered , after receiving all the necessary details from the user, the support service creates a task in Jira. This is done through the Jira API literally in one click in the interface of the CRM system: based on the queue (folder), the system puts a request into its project and automatically transfers all data from the CRM ticket to the Jira task, including a description of the problem, the history of correspondence with the user attachments. Then the system puts down the labels, on the basis of which the tasks on the Jira boards are automatically sorted by components.

Next, the task gets into testing, from where there are three outcomes and three corresponding Jira buttons in the task:

• The tester needs additional data to isolate the problem . He writes a comment for customer support, which appeals to the user for information. This comment is broadcast from Jira to a CRM ticket, and only the support team can see it.
• The tester sets the task for correction . It translates the task into the waiting status of the fix, and the data goes to the developers. At the same time, Jira requires the tester to link to the Jira task; after its input, the task is translated into a CRM-ticket, which is visible only to the support team.
• The tester closes the task for any reason (for example, the problem has already been fixed in the last update).

If the problem is not related to an error in the application , then information about it and possible solutions is returned to the support service and adds to the knowledge base.

What is the profit?

Perhaps someone had a question: “Why is it so difficult to complicate the process of collecting and processing user requests?”. We answer - thanks to this:

• Each problem turns into a separate task with structured and understandable information . In this case, support services, testers and developers are working together to solve the problem.
• It is easy to track bug bug fixes and user responses that we fixed everything .

Further plans:

• Automatic closing of Jira tasks with reports and tickets in the CRM system after fixing the bug. Perhaps we will add an automatic response to the user that the bug is fixed.
• Counter of user complaints in bug tasks: semi-automatic update of the number of complaints for each problem.