Frontend upgrade for Jira. How and why we modernized the CROC service portal
At first, everyone worked with requests in regular Jira
Imagine the help desk of any large service company. This is roughly how everything works for us – the process of receiving and processing requests for maintenance or repair of equipment is generally standard:
The customer sends an email or creates a request in Jira – we receive a request with the status new. It is picked up by the 24-hour first line, and then we look at the serial number: is it beating or not, is it supported or not, we supplement the application with information and transfer it to specialized engineers.
An engineer joins. If necessary, he carries out additional diagnostics, orders spare parts and moves the request further from one status to another: in progress, awaiting delivery, etc.
When the work is completed, the customer is sent a notification asking him to evaluate the work. For him, this is where the path ends, but for us it can continue.
Engineers return unused spare parts to the warehouse, test the hardware and analyze the causes of the incident. Afterwards we send a request for closure from the engineer.
Finally, the first line evaluates the engineer’s work and closes the request completely. Next is the archive: we store all information about applications for at least three years.
According to data for 2023, we had 10,607 service requests: malfunctions involving the replacement or repair of equipment, requests for maintenance and prevention, consulting issues. That's 2,652 claims per quarter, 884 per month, 204 per week, an average of 29 claims per day and 0.02 per minute.
The lion's share of them came through the client portal based on Jira Service Desk, which we switched to in 2021 from HPSM, an outdated legacy solution that only works on the desktop and with a problematic update process. Jira has incorporated a lot of processes within the company. All projects are carried out in it, engineers are not scattered among 10 services for ordering and sending spare parts and solving requests, and clients can monitor all this. And everything would be fine, but questions started piling up for Jira too.
It’s convenient for the company and engineers, but not so much for customers
Through Jira Service Desk, customers created requests, saw their history, status and contractor, commented on the progress of work and connected new participants in the process. It turned out to be functional, but not always convenient. Increasingly, questions arose about the information content of applications and the correctness of displaying fields, but the most pressing problem was the issue of access control.
The internal Jira portal has a special feature: all projects that CROC is managing are visible there. They are available to all customers, and this is bad. The client would not see any confidential information, but he could create a request in someone else’s project by clicking in the wrong place, and remain in full confidence that everything is okay and support will soon sort everything out. And there is another direction, another department that is not aware of what is happening. And it seems that no one is to blame. But it took extra time to figure everything out, and SLAs can be tough.
In addition, Jira is unavailable during maintenance periods, re-implementations and updates. And this is important: we provide support 24/7 and the client expects that the portal will be available at any time.
Thinking about developing a separate client solution
So, we needed a new storefront for clients where they would manage requests. It was necessary to display more useful information there and thus remove frequent questions about:
status of applications;
frequency of calls;
SLA and terms of service provision;
the total number of applications for various types of equipment and for the contract as a whole.
I also wanted to give customers more independence – to make it so that they could immediately fill out a form, select the type of incident, indicate the priority, describe what happened and add participants to the request if necessary.
It is quite difficult to customize a boxed Jira Service Desk, especially in such a way as to achieve acceptable usability as a result. The labor costs for something beautiful and convenient would be enormous, so we decided to write a new frontend from scratch. This was facilitated by our constant practice of developing customer service, for which resources are allocated and there is a separate front-end development team specifically for the company’s tasks – to develop and adjust internal systems to new processes.
What did you want to do and how to change it?
To begin with, we prioritized everything and took on only the highest priority items in order to have time to implement an MVP made according to all the rules. We have compiled a table with the functions that we want to transfer to the new portal – what to add, what bugs to close. The main task was to develop a new, more accessible and friendly interface for customers to work with applications.
We needed to preserve the functionality of the old portal plus close the issues mentioned above: undesirable availability of all the company’s projects, the inability to display additional information fields for the client about his application (contract, serial number or SLA, description of the solution, and others).
We did this, keeping everything that worked conveniently before. We created a setup that uses the API to access Jira itself and work with the same requests. There is no need to create any additional entities – all this is just a visually beautiful display of the same requests that engineers are used to working with, and for which a business process has already been built.
How everything is organized, what had to be finished and how
Jira has an open API, and with its help, without any layers, the portal receives data from Jira and vice versa, it can write it to Jira, creating requests or adding comments.
However, this was not enough to realize all our wishes. As a result, we use the basic capabilities of this interface, such as registration, authorization, creating requests, and before that we process applications on the backend of the new portal. The backend is written in Java (Spring Boot), the front end is written using HTML, TypeScript, Angular.
For example, on the new portal we have improved the buttons for easy navigation through business processes. With their help, the customer can cancel his request, evaluate if it has already been resolved, or attract attention if the problem has become more acute, and if something went wrong, escalate. It seems like a simple thing, but the standard API does not allow you to navigate through a business process from the outside, so you had to write your own logic for them.
The biggest challenge was making the portal work quickly and responsively. At first glance, this does not seem to be a particularly difficult task, but as soon as we changed the logic to a role-based one, different from standard Jira, the pain began. Also, JQL search was slower than necessary, and the Java API for Jira Service Desk was very limited in functionality. I had to do everything from scratch and think about optimizing SQL queries. In addition, to achieve the required speed, we had to struggle with multithreading.
Another interesting thing from a technical point of view is the implementation of translations. Since the functionality of the Java API for Jira Service Desk is limited, we had to understand the structure of the database tables for translations in order to get up-to-date translations for various fields. In addition, we had to tweak Google Guava there in order to cache already found translations and not waste additional time searching for them.
However, Jira also has advantages as a backend. It is convenient because everything inside is customizable. We managed to make it so that to add a new button or field to the client portal, you don’t need to go to the front. Everything is configured in Jira and pulled from the project. As a result, our managers from different departments can configure the functionality of their sections of the client portal through a familiar interface.
Tests and preparation for launch
All this had to be done very quickly. Although the client portal update was long overdue, we had a rather limited time to launch and implement it. We prepared clickable layouts, tested them, choosing options for lists and request forms – the UI was treated responsibly from the point of view of developing a new system. Autotests are written in Java 11, the Maven collector is used. The test writing framework is TestNG, and Selenium WebDriver is also used. Autotests are carried out on the functionality of the client portal in the UI. Currently, approximately 75% of all regression tests on the client portal are covered.
UX testing was carried out on CROC employees not belonging to service departments. The company is large, and you can go to conventional accountants and collect an unbiased opinion from them.
About the features of the move
At first, not everyone was told about the move: a couple of months before the launch, active authors of applications were selected and letters were written to them with an offer to test the new client portal. At the same time, they stipulated that the old service also works, and all links still point to it. Feedback was collected through a simple form with the ability to rate and write a review.
So users highlighted many problem areas:
“Old cases are not saved. I want to see what they did and how: screenshots, logs, recommendations. Situations sometimes repeat themselves, but the case is no longer on the portal”
“When Jira responds to a case by mail, the status does not change; it remains in the client’s pending status. At the same time, it’s unclear – as if they are waiting for action, but in fact the case is in the work of an engineer.”
“There are loading restrictions. When downloading large logs, the engineer separately sends a link for downloading. It would be good if it was within the framework of the application – something can be thrown into the application itself, and the large file can be uploaded via the link in the application to a cloud drive, bypassing the engineer.”
Gradually, and taking into account feedback, we began to transfer other projects to the new portal, and change links in letters to authors and participants of requests. Using them, the first thing we did was introduce users to the new portal. And the next step was to put a banner on the old Jira portal that soon nothing would happen here – we were moving.
Clients tried to use the old portal until the last minute – force of habit. There were situations when they came to the service manager and asked to do it as it was, because it was unusual.
We didn’t wait for everyone to get used to it – we closed our old portal when we were sure that we had collected and taken into account all the constructive criticism. A tough step, but a certain percentage of users will always stick to the old and familiar. And it’s easier to pull the trigger than to maintain two versions of the application indefinitely.
The main features and benefits of the client portal
However, the difficulties were worth it. Now the portal provides complete and timely information to the client. The interface reflects in detail everything that happens with the application.
For example, previously the portal notified the client that the spare part had been sent. Now the delivery stages are displayed in the interface. Plans include integration with courier services and tracking of shipments.
The customer now has the opportunity to escalate the request, draw attention to it, or cancel it.
Clients said that they don’t use comments because it’s inconvenient. Now the entire comment history is displayed in the interface. There are attachments and downloads: you can select the required fields, view all applications from your organization and download them. Previously, this was only possible upon request through support service managers. And now customers can do it themselves in a couple of clicks.
It became possible to develop and customize the functionality of the portal – to add features that were not and could not be in the old version of the service desk. For example, flag indicators for new content.
Test results and future plans
Even at the design stage, we understood that we would need to collect metrics on key functions of the system: the number of people who started but did not complete registration, unfinished applications and customers who did not reach the conversion and decided to immediately call the first support line. We save, maintain and track all this. A month after implementation, we made a report and realized that creating a request was not working well.
Customers are in no hurry to create applications on the new portal, but mainly use viewing and commenting on already created ones. We increased the speed of processing the application after creation, looked towards adding fields, and removed bugs that were sent to us through the feedback form.
Just the other day we launched a mobile version of the portal and are planning to open a customer’s personal account. In addition to little things like changing your name, package actions will also be available there, for example, you can change contacts in all related company applications. This is another wish that we received through feedback. It is especially relevant for those clients who are localized in Russia and are forced to change their email domain, or, for example, thoroughly rebuild their corporate telephony. It seems like an insignificant feature, but it saves a lot of time, because otherwise you would have to re-register all the company’s accounts on the portal.
We have already closed the entire pool of blocking and critical requirements and have come to the conclusion that we are developing features for convenience. As a result, according to our calculations Service Competence Center, the number of applications from external users began to grow: immediately after the launch, for the period from January to mid-February 2023, we received 80 applications, and for the same period from the beginning of 2024 already 1 thousand. If last year 63% of users were satisfied with the portal, then by the beginning of 2024 this figure increased to 74%. Ratings for individual aspects of customer experience and for the portal as a whole are positive.
Moreover, some CROC divisions asked to deploy similar portals for their needs in order to create internal support requests or enter other tasks into Jira. The service created for clients began to be distributed within the company – a logical development of our ideas: to gradually automate, optimize and improve service. It is from such seemingly insignificant little things as the client portal that a positive client experience is formed.
Read more about the components of the CROC service:
This is the base. How CROC service engineers are upgraded
24 hours with CROC engineers on duty: we survive as best we can
Mountains ZIP. Why is our warehouse bursting with equipment and what do departed vendors have to do with it?
