The evolution of technical support for Small Businesses in Rosbank. Part 2. Through thorns to the stars. But not at once

Hi all! My name is Andrey, and this is the second part of my story about the evolution of the technical support service for the internal CRM system at Rosbank.

In the first part, I told how we provided support to our employees via email within the internal CRM system PRO Business and focused on describing the three main problems that followed us and interfered with the support process.

This part will be devoted to the rather lengthy and complex process of transitioning employee support from mail to the internal SD helpdesk system. But, looking ahead, I will say that we did not stop there and decided to move on, so in the second half of the article I will also touch on the process of transition from SD to working with requests in Jira. So, let's begin.

I need to confess something to you…

From time to time, the leader of our small platform team and I held meetings where we discussed certain issues that directly related to the process of supporting our employees. These meetings cannot be called daily meetings in their literal sense, because they were held much less frequently than could be afforded. But, let’s just say, once every couple of weeks was enough for us.

Time passed. The number of employees of our bank has grown. At the same time, our internal teams, who were responsible for their specific area, developed and rolled out more and more functionality. And if at the first stages of support, all the pain with which the previous article ended did not manifest itself so strongly, and some of it could even be justified by my still insufficiently deep level of expertise, then after a certain period of time we realized that this could no longer continue and we urgently need to change.

And here I want to confess to you. As I said in the first article, our main channel for requests for PRO Business support was the 911 page with its rather simple feedback form, which flowed into an email to the team’s shared inbox. But nevertheless, in our SD helpdesk system our PRO Business had its own specific group, and we just switched to support via SD. This group was needed to navigate employee requests written in free form. Requests through SD were 15-20% of the total. I also processed them.

SD itself, as a general banking standard, is not bad at all. This is a fairly powerful system that allows you to make various downloads and generate reports based on specified parameters. Even inside the IT specialist’s interface, in the card of a specific request by its number, a great variety of different tabs are available that contain this or that information. These can be service fields, an appeal protocol (history of correspondence with the applicant user) and much more.

And here I will not award myself the merits of others, but will say directly and honestly that the first steps to transfer our support from mail to SD were taken not by me, but by my head of the IT department. He held a number of meetings with analysts and developers who were involved in the technical maintenance and support of SD, found out the main points and assigned the task to his colleagues to create a request template for employees of our system.

I won’t open America to anyone (but it’s worth remembering) if I say that any helpdesk system has its own specific templates through which any employee can get help or advice. This could be, for example, a template for a request to configure the operation of some specific software or check the operation of equipment at the software or hardware level. Or a template for contacting support of an adjacent system with which we are integrated to edit certain client data in it. Each system has its own template, and now there is one for ours. Loud applause, I present to you template D7742!

With banking standard to the global giant

So, we now have our own template in SD for employees to ask for help. It has a specific set of fields: topic, subtopic and textarea field for free description of the problem with attachments. And from that moment on, we began to provide technical support to PRO Business from there; At the same time, our mailbox passed the baton and lost its status as the main channel of requests.

But there was a short period of time during which we had a certain feeling that we had forgotten something or had not done enough work. We were interested in solving the problems that I described in the first part of this series of articles. For convenience, I will briefly list them again:

• We had to collect all the data accompanying the request (page, conditions for the bug, data for reproduction) in “crumbs”.

• We did not have the opportunity to see whether colleagues from internal teams accepted the request for work.

• There was no built-in system of priorities and SLAs, i.e. there was no understanding of how long it would take to resolve this or that incident.

And in the context of the second part of this series of articles, I will comment on them.

The first problem listed, namely the lack of all the necessary data in one place, has been solved. Ironically decided. Even though the employee sometimes might not immediately provide complete data, we saw the entire history of correspondence with him in one tab inside SD.

The second problem listed raised a large number of questions about the quality of the support provided:

• Who specifically took on the request: the technical support team or the specialized internal one?

• How to control the processing of a request?

• How to track hits that have been completed but not yet validated or verified by the user?

Let's leave these questions open for now.

With all this, there is one thesis. The fact is that all our internal teams use Jira for their work. I mentioned this in the first part of the article series and said that they have a series of tasks that go from status to status until the changes are fully implemented into the project. And what about those requests that require the intervention of analysts or developers? Create issues on their boards in Jira?

Here I want to smoothly lead to the fact that we had the idea to integrate our SD with Jira, namely: when creating a request using our template D7742, a request is made in Jira, and a task with the Incident type is created on the board of our platform team, with which we and we are carrying out further work.

Why was this particular type of task created chosen? Again, this is due to the internal teams that work on our PRO Business. We know that Jira has its own set of these types of issues. It could be a bug, task, incident and much more. And we needed to somehow select the tasks that come to us for support from the general pool of tasks for a specific team. In addition, it has its own workflow, which we customized specifically for the support needs.

For Jira, my team and I implemented new logic for working with user requests from SD:

1. An employee in SD creates a request using template D7742.

2. SD submits the issue (incident) data to Jira and creates an issue in our platform team board.

3. The support team conducts an initial analysis of the request and tries to resolve it independently. If her level of expertise is not enough for this, a clone of this task is created in the space of the product team, which is responsible for this functionality.

This is a custom mechanism implemented by our developer. For a clone task, we, support staff, assign it a priority, an executor (analyst or developer) and write comments on the request. Then it goes to the Jira board of the desired team.

In other words, through the mechanism of creating clones we solve our second problem, which has been hanging over us for a long time. By creating a clone, we can be sure that analysts and developers from this team will see this request and take it to work.

But is everything so good? But what about controlling the request execution time? What about our third problem?

We need a solution to the problem at any cost. But it's free.

In this entire life cycle chain, our SD comes first, and it is he who determines his terms according to the SLA (7-10 days). And in principle, it would be possible to focus on them, but we considered them too large and uncomfortable for users to broadcast them to our employees.

Therefore, we set about developing our own in-project SLAs to resolve the request for the PRO Business system. We sought a compromise between resolving incidents within product teams and developing business features for them, since these two areas of activity are obviously competing. We have determined that critical and high priority requests should definitely be resolved within no more than 1 business day. The SLA system clearly focuses teams on solving the problem and increases loyalty to the system of our users and clients.

Priorities are set in the original task and are automatically transmitted to all clones created from it.

It would seem that everything is fine. We have established interaction with employees who need our help. If we cannot resolve his request with support forces, we turn to colleagues for help through the mechanism of creating clones, in which analysts and developers give us the final answer, and we broadcast this answer to the employee in the original task.

But how can you ensure that the analyst and developer do not lose sight of the incident? Not at all because of personal reasons, but precisely due to the human factor. After all, in addition to his tasks in Jira, there are working meetings in corporate instant messengers on one topic or another, correspondence with colleagues from other departments.

At the same time, how to track the execution time of a particular clone in accordance with the above SLA table? Manually adding the current time to the time of creating a clone in Jira? May be. But I have a better way!

I will answer all these questions in the third and final part of the series of articles. I will also share some features to make the work of a support employee easier.

Thanks for reading, I'd love to read your comments.