What will help you set up the process of working with user requests
Hello everyone! I am Yulia Trusova, a QA engineer at Avito. I would like to tell you about my experience in designing and implementing the process of working with user requests — SPT. Some colleagues tried to decipher this abbreviation as Support problem ticket, but it is not an abbreviation at all. It is an abbreviated name of the SUPPORT project in Jira, generated automatically, where we store tickets.
It was important for us to set up the user experience so that we could promptly respond to problems, provide solution options, and quickly fix errors. We also wanted to know the users' opinions on the implemented features and feature requests.
The article will be useful for those who design such processes or support them.
How does customer service work in Avito
The Customer Service Center employs more than 1,200 support and moderation agents. These departments work 24/7 to help customers at any time. But it is not only the support specialist who is involved in the request processing process – often, the help of technical teams is needed to resolve the user's issue.
As a result, we get the following chain of request processing:
The user contacts support.
A ticket incident is automatically generated in HelpDesk.
If a user reports a bug, the agent creates a problem ticket and links it to an incident ticket. The problem ticket is needed to aggregate similar incidents.
Based on the issue ticket, coordinators create a task in Jira in the SPT project and assign it to the required unit.
Schematically it looks like this ↓
Teams need to respond to the incoming ticket as quickly as possible: understand whether it applies to them, set a priority, provide a temporary solution, if there is one. This will help the coordinator quickly convey a workaround to the user so that he can continue using the service. To fix bugs, we adhere to the Zero Bug Policy: we use the P0-P4 scale, where P0 is the most serious bug. You can read more about the ZBP concept in my previous article.
Next, I will tell you about the important points that you should pay attention to when implementing a process that regulates the receipt and processing of requests from users.
Understanding areas of responsibility
The more teams there are, the harder it is to remember who is responsible for what. That's why we need a single source of information about this, which will be useful for support and colleagues inside for prompt communication on any issues.
We had a summary table in Confluence for this: it described areas of responsibility and channels in the corporate messenger. The teams maintained this table themselves. At first, we had to poke everyone with a stick and ask them to throw in data, but now most teams are great and promptly update information without reminders.
Single project in task tracker
A common space for all tickets simplifies life not only for process owners, but also for teams. Such a project is easy to manage, customize for your needs and collect metrics.
You can also set up integration with other systems to immediately fill tickets with technical details. This will help teams spend less time processing problems.
We divided tasks into three types: Bug, Crash, Feature. They were stored in the SPT project in JIRA. We had an integration with HelpDesk set up — this is the system in which the support works. It allowed us to:
Display a counter of the number of requests from users, which is updated when new requests are received.
Fall into raw appeals if some data is missing.
Display information about key customer requests and additional load on support.
All this allowed teams to more objectively prioritize problems and take them into work.
On the downside, it was impossible to transfer or clone tasks into your projects, because that would destroy all the custom fields.
Smart environment
If you want teams to stick to a process, make it easy for them and reduce the chances of them making mistakes or forgetting something.
A good task tracker allows you to customize the project to your needs. You can immediately set the priority, add a ticket to sprints, customize the flow so that it is impossible to transfer the status without filling in additional fields.
For example, to make it easier for the guys to analyze the reasons for problems in the future, we made it mandatory to fill in the bug reason field when changing the task status; automatically set the Due Date when setting the priority and set thresholds for the number of requests at which it is impossible to select a low priority.
This is a real lifesaver when we spend most of our time in work messengers and hardly look at our email. They don’t let us forget about routine things and remind us to perform certain actions.
Notifications can be:
process – all teams receive them (for example, if a new ticket appears),
customized – you can set them up for yourself,
in the form of summaries – monthly updates for team leads and managers.
They can be configured to drop into a specific team channel and provide hints on next steps.
For example, when we added an additional notification about an imminent violation of the response time (15 minutes), the number of violations decreased to a minimum.
Advice. To ensure that notifications are not missed and are processed more readily, add to the task link a short instruction on what exactly to do, or a link to a document with information on the process.
Documentation
Up-to-date documentation makes life easier for teams and those who support the process. It will take time to write, but it will quickly pay off – instead of answering colleagues' questions, you can send them links from the article.
We store documentation in Confluence. It consists of:
from the description of the full process – for those who want to know all the details,
from the brief outline – to refresh the main points,
from the support instructions,
from the FAQ on the main cases and technical features,
from life hacks and useful tips.
Notify support about changes
At the basic level, it's to warn colleagues about the rollout, at the advanced level, it's well in advance so that they have time to prepare internal news and tell support agents about it. If you warn support in advance, they will be able to provide the user with up-to-date information about the changes. This reduces the number of “false” tickets that are not bugs.
For example, we have a separate regulation on notifying support about changes, new features or A/B tests.
Support from above
If management monitors process metrics and asks tough questions of teams that are seriously disrupting the process, then it works much more efficiently.
For example, we did regular reviews, added process metrics to the overall technical and budget metrics of units or clusters, and linked them to the Team Maturity Model.
Reflection
You can endlessly fix bugs and put out fires, but it is better to take measures to prevent them.
For major problems, we tried to conduct timely analysis like LSR, and for the rest, we regularly looked at the metrics for the reasons for the occurrence of bugs and came up with action items for the future.
PR
To make the process work, you need to tell new and old employees about it and work on its reputation. Find teams that work well with the process, invite them to meetings and tell about their success story. You can use the following tools:
training: master classes, articles, onboarding,
support channel,
PR in internal communities, general meetings,
digests with excellent students and process violators,
badges.
To make sure all new employees were aware of the process, I created a course in our knowledge base. It was added to employee onboarding with a simple quiz at the end so that the guys could test their knowledge.
Support for process teams
Sometimes documentation does not answer all questions. In this case, your colleagues should be able to quickly get an answer to their question.
We had a separate support channel in the messenger for this purpose, to inform about updates and changes to the process, answer questions and collect suggestions for improvements and modifications.
On duty
Unfortunately, in the absence of on-duty personnel in teams, the rule of “collective irresponsibility” often works perfectly – team members rely on each other and violate all deadlines. Therefore, assigning on-duty personnel reduces the likelihood of missing or not responding to a new ticket in a timely manner.
We have always had the best results in teams that have on-duty workers – such teams worked with fewer overdue payments.
Metrics
To understand how things are going with a process, it is difficult to do without metrics.
Therefore, the analyst resource can be very useful. Not only external metrics are important for teams, but also technical ones, which are needed by the process owners themselves. This could be the share of tickets without an owner, the share of errors when setting a priority, or the share of duplicates.
When we were setting up the process, I was in charge of all the dashboards — I have a good understanding of SQL and Tableau. I added metrics for teams to cluster dashboards, where there were tabs with metrics in dynamics and with an operational tab — “what should have been done yesterday.” And for myself, I made a separate dashboard with technical metrics, which helped me see violations and bottlenecks in the process.
How to develop the process?
I have collected several tips that can help when setting up a process that regulates the receipt and processing of requests from users:
The process is dynamic, which means it will change over time. Therefore, it is important to keep your finger on the pulse and monitor external factors: audience growth, external circumstances, the emergence of new types of clients.
If you are setting up a process, don't forget to collect feedback from its users: the support team that creates tickets and the tech department that processes them.
Be open: communicate with your user colleagues, conduct surveys and CustDevs, look at internal metrics. This will help you quickly find imperfect and outdated areas of the process and improve them.
When implementing major changes, pilot them on loyal teams, and then decide to roll them out to everyone. Be prepared for the fact that not all of your improvement ideas will take off.
And also – think through possible risks and ways to mitigate them. For example, I had a map in Miro, where I collected all the feedback with the division of problems and suggestions with different categorization: problems from the support, tech, ASD. There you could also see the solution options and the steps already taken with the result. And I was also greatly helped by the diagram of the entire process with full detailing from the moment the user creates a request to the moment the fix is rolled out to production. It took a lot of time, but it clearly showed where improvements needed to be made.
And most importantly, don't be afraid of complex processes. Share your experience with colleagues, love your users and everything will definitely work out.
Finally, I want to thank my colleagues who helped me set up the process – especially support and shsv.
Good luck to everyone and fewer bugs!
