Case Study: Smart Request Processing System
i-Free is a Russian innovation company operating in the CIS since 2001 and internationally since 2006. The company develops and implements cutting-edge solutions in mobile and NFC technology, electronic finance, digital content distribution, electronic payments and micropayments, applications for smartphones and new network devices, digital products for the B2C market, and B2B projects in mobile marketing.
i-Free is headquartered in St Petersburg and also has offices in Moscow, Kiev (Ukraine), Minsk (Belarus), Almaty (Kazakhstan), Mumbai (India), Beijing (China) and Sao Paulo (Brazil). The company’s products and services are available to consumers and businesses in more than 100 countries. i-Free partners with the leading mobile operators in Russia and the CIS, with international mobile equipment vendors, banks, transnational brands, major media groups, publishers, and online resources.
i-Free needed a customized processing system for incoming requests to the juridical department on the basis of Atlassian’s JIRA. The main problem of this department was a necessity to process quite a lot of requests during a day from multiple channels such as email, contact form on the website or manual issue creation. So it was a real nightmare for them to create an issue in JIRA, then start progress, then each time leave comments about the progress on the issue and not get lost in this all.
The other problem was a necessity to create accounts for each contractor, so they can log in to JIRA and track progress on their requests. It was found quite inconvenient, as some contractors were not regular customers and it was rather inefficient from the point of user license utilization.
They needed a custom solution that would incorporate both simplicity of configuration and flexibility of use. Solution was an add-on for JIRA that enables activation of mail handler used to process incoming requests that were futher transformed into JIRA issues. Additionally, agents should be able to send quick responses to people who submitted the issue – contractors. The project also required customization of workflows and addition of custom transitions for calculating time when either agent or contractor were waiting for decision.
For remote management of requests, there was added the list with key phrases that are automatically processed by the mail handler as actions for starting progress on the issue, assigning the issue, and so on. So let’s see in details what was done.
Processing Incoming Requests
The company has allocated an email address for incoming requests. All requests can be sent directly to the email address or via the contact form on the corporative website. There also remained a capability to create tasks manually. The project coordinator tracks all the incoming requests and assigns tasks to agents responsible for their completion.
Once a new request comes to the email, it is automatically converted by the mail handler into a JIRA issue and added into the dedicated project. Here the project coordinator reviews the issue and assigns it to the appropriate worker. If an issue was created from the incoming email, this email address is displayed in the External Email field. If the request was created manually, the contractor’s contact email should be also specified.
The project coordinator decides and assigns the incoming tasks to the appropriate agent. He can also set the Approval Required option if the project coordinator wants to disallow the assigned agent to close the issue without the coordinator’s confirmation. If needed, the due date can be also changed.
Once the project coordinator assigns the task to the appropriate agent, this agent receives a corresponding notification about a new request. The agent can instantly respond to the contractor right from JIRA. There is a special Write to Client form that allows agents to send responses to contractors with a capability to add other participants or attach some files.
Working with Requests
Workflow of issue processing was a little bit changed, so the agent can indicate how much time they spend on the request and how much time the contractor has been providing feedback. Two special fields show amount of time that the agent spent on reviewing the request and amount of time that the contractor needed for reply.
When resolving issues, the agent needs to select status, which the issue is closed with. This is done for evaluation of service quality and satisfaction of the contractor with the resolution.
Both project coordinators and assigned agents can always view emails with the contractor on the dedicated Mail tab. This tab lists all emails that were sent by the contractor to the specific email address and all the replies from agents sent via the Write to Client from. The modified mail handler also correctly processes the mail attachments and automatically attaches them to the issue. Additionally, the mail handler processes body of each mail and identifies issues by the unique number assigned by JIRA. This is done to avoid situations when the contractor edits the email subject incuding the issue number, but the issue number is preserved in the email body.
There was also a customized field with due date, which was calculated automatically as 5 days after the request creation, so the project coordinator can instantly view the dead line.
If needed, the project coordinator can change the due date. Additionally, there was added a select box for quick selection of the appropriate category. This allows the project coordinator to quickly map the issue to the category for convenience of work.
Notifications and Command Macros
For better project coordination and request tracking, the existing notification system was extended with the number of automatic notifications. They were added for all basic operations with issues, such as request submittal, priority change, issue modification, addition or removal of attachments, issue reopening or watcher inclusion. For the newly added functionality, we have also added notifications for change of the due date, request resolution with the specific status, sending the incorrect macro command and so on.
If there are some overdue tickets, the project coordinator receives the email with the listing of overdue requests from contractors. Agents also receive the list of active tasks to focus on with the defined frequency. Reporters or contractors also receive notifications about update of the list with issue attachments, shift of the due date, issue resolution or reopening. Each user role receives the definite requests essential for being aware of the issue progress.
For easier request management, we added several macro commands that allow agents and the project coordinator to work with requests without accessing JIRA. This is very handy as there is no need to open JIRA all the time, locate the appropriate request, set the corresponding status and so on. This become possible with a set of macro commands inserted into the body of email messages. These commands are automatically processed by mail handler and futher executed as a command for performing the pre-defined action.
The add-on has simplified the user experience with JIRA as a request processing system. It has also optimized the migration to digital request system from old-fashioned paper work. The embedded mail form allows agents to immediately send replies from JIRA, if they have already logged in to it. If needed, they can work with the system and reply to contractors through their mail agents. This provides much more flexible and convenient management of incoming requests. An extended system of notifications enables continuous update on request progress and instant focus on pending issues.