Fintech ITSM improvement and cloud migration

Solution 

ITSM strategy optimization

Railsbank prepared a set of general requirements for our Atlassian team, and proceeding from them, we determined the way to properly implement them as well as suggesting relevant changes to the original strategy. 

Process analysis 

The customer’s Jira Service Management instance had three basic issue types, namely Feature, Bug, and Support, which proved insufficient to correctly process standard Incident, Problem, Change, and Service user requests and distribute them among support teams. The existing issue types also didn’t fully match the customer’s internal processes, such as service request management, knowledge management, incident management, change management, and other. 

Upon process analysis, we uncovered the following bottlenecks: 

• The limited number of intermediate statuses for tickets 
• The lack of user permissions 
• Approvals collected via various communication channels instead of Jira Service Management 

Customer service optimization

To streamline customer service processes, Itransition created and implemented five additional issue types and corresponding workflows. This also helped us introduce new, more fragmented statuses for requests, since Jira Service Management allows for only one workflow per issue type. 

We also set up workflows with approvals for various task types to improve the approval process transparency. Beyond that, our team created 19 new request types, configured the web portal and request forms for user support, and moved all the existing 15,000 tickets to the new workflows, issue and request types. 

Self-service enablement 

We appropriately classified all request types to make the navigation intuitive, simplified request routing, and enabled relevant labeling on wiki pages to simplify search. We also added the search feature to the support portal allowing users to easily look up their problem or question. All these configurations helped Railsbank to offer better self-service to their customers.

Ticket assignment automation

Since the customer has several support teams that process user requests, they needed the functionality for ticket assignment to groups, which the standard Jira Service Management lacked. Our experts suggested creating the additional Assignment Group field, delivered a proof of concept to demonstrate the idea, and implemented the field. 

We also set up the automatic assignment of tickets to groups depending on the user request type by creating a custom Assignment Group field for the Group Picker type. The field is also used for notifications, so that when a request is created or modified, users from a corresponding group could be notified. 

Additionally, we configured the system to set up ticket queues based on the Assignment group field values instead of the previously used employee filters. This modification allowed the customer to optimize request processing and automate tagging new support employees in tickets.  

Sensitive ticket data protection

Due to the presence of sensitive data in tickets, the customer needed to restrict access to requests for support team members. To achieve this, Itransition created the Ticket Type Agent role to be assigned to those agents who needed a limited access to requests. We also introduced the additional Read-Only Agent role that prevents the assignee from performing any actions on tickets. 

Beyond that, our team created a default security level, which the customer can attribute to all tickets to restrict their visibility, and additional security levels, each associated with a specific group of support employees and allowing access only to certain ticket types. When a ticket is created or updated, the system automatically assigns the appropriate security level to it depending on the request type, Assignment Group value, or label. On top of this, we made the security levels customizable further and taught the customer’s team how to expand the existing protection mechanisms. 

Automatic SLA calculation

As Railsbank customers are located across time zones and use different levels of service, the company needed to calculate SLAs for “Time to First Response” and “Time to Resolution” individually based on the value of these two parameters and their priority. 

For this, Itransition created two custom fields – Region and Service Level. When creating a request, the automation rule checks which organization it belongs to and sets the Region and Service Level values while the client defines the priority themselves. Then, based on these fields' values, the system sets up the appropriate SLA goal. In total, we created around 60 SLA goals and set up SLA report generation. 

Automation rules 

To automate workflows in Jira Service Management, Itransition created a total of 15 automation rules. Here are the most essential of them:

• When a ticket is labeled as "Awaiting approval", the system tags approvers.
• When a chargeback request ticket is set as “In progress”, the system tags the person who changed the status in the comments. 

• When the chargeback requests should be processed by the Treasury team, the tickets with the “In progress” status are automatically assigned to this group. 
• When the chargeback requests should be reviewed by the Risk Ops team, the tickets with the “Under Review” status are assigned to this group. 

• Tickets are automatically closed after having the “Resolved” or “Completed” status for five days. 
• Tickets change to “In Progress” when assigned to someone.
• Tickets change to the previous status after the customer replies.
• When the ticket’s Assignment Group field is modified, assignees that don’t belong to the group are removed. 

Additionally, we replaced the standard customer notifications template with a custom one, changing the default contents and giving it a more appealing look.

Cloud migration

Due to data security and compliance regulations, Railsbank couldn’t give us access to their server, instead backing up selected files in a secure file storage for us to load into the cloud environment after the migration. We also reserved domain names for Railsbank’s Jira and Confluence sites in advance.

Due to the tight schedule, we carried out Jira and Confluence migration in parallel, using the Cloud Migration Assistant tool. When migrating Confluence, we first deployed the customer’s version on our local server and then deployed the backup with all the data the customer previously extracted. Then we created a test cloud instance and migrated the data to it. After the Railsbank team completed user acceptance testing, we created a production instance and migrated data from the test environment there. 

For Jira migration, we first deployed the system locally, installed the dedicated plugin to restore data from the backup, and migrated it to the test cloud environment. Next, we validated the integrity of user, group and permissions data and deleted completed projects data using the Bulk Delete tool. Upon the customer’s user acceptance testing, we transferred the data to the production instance in the cloud.  

After migration, our team provided support services to the customer, ensuring seamless adoption of the cloud-based system.