So what are we faced with that we are thinking about developing our own ticket system? Main problems:
- Our team received 1-1.5 thousand hits from users every day.
- Convenient statistics were lacking. Everything had to be noted manually in various documents.
- The most important difficulty: most of the requests required checking the status of the player's account, which at that time did not have direct access - we worked only with the texts of the requests themselves and email addresses.
- Created complexity and interface. Other people's solutions are most often inconvenient, because they are not tailored for a specific game and technical support regulations for a specific company.
- Considering all of the above, paying for a third-party system was not very profitable.
And we make an epoch-making decision - to cut our own ticket system! What? There is strength, there are plenty of ideas, enthusiasm - more than enough. But at that time there were no relevant processes: we, the support team, had never ordered anything from the internal toolkit development team and did not closely interact with it.
Where to start? We wrote out in two columns our expectations from the tool (something in the style of “we want to receive messages and respond to them”) and complaints about the current version (“here is an inconvenient window, make it more convenient”), called it a technical task and passed it on to the developers. The further process took about 3 months. There was no testing stage, all errors were found by the developers or the support itself already when using the tool.
As you might guess, this pancake came out lumpy. We tried it and thought that the disadvantages of the purchased service are not so serious. And then the team of the commercial help desk proposed an integration, in which it would receive information about the user from the game and transmit it in tickets to our support (this would solve the main problem). However, some of the conditions for integration were contrary to the security requirements adopted by the company. So what options we had:
- Make insecure integration with commercial helpdesk.
- Use its stripped-down functionality.
- Return to tool development.
We took the last path. We fixed everything that didn't work after the first iteration and connected the ticket system to games. It had basic functionality: we accepted applications and responded to them by sending messages to the mail. But most importantly, we finally have the opportunity to see the player ID in the ticket system, which refers to our other internal tool with the rest of the account information.
The team that provided the development process initially included the product owner, PM, and dev team. We drew the design ourselves, the developers edited and, as far as possible, tested the product. Then UI / UX designers and QA joined. As a result, the following process turned out: the customer writes what he wants, UI / UX says how best to do it, developers implement it, QA checks, and PM controls the entire chain and timing.
Having introduced a ticket system with minimal functionality, we began to improve and adjust it to the needs and goals of the company. In total, more than 200 features have been implemented to date, the main ones are listed below.
- . , KPI , , . 7 50 .
- — ( ) .
- .
- .
- HTML- .
- -. - .
- .
- . , .
- - .
- , .
- ( new, waiting, answered, resolve close, inprogress, pending). ; , / ; ( ).
- .
- .
- , .
- Programmable flow - installed solutions, including notification of responsible employees in case of an event in the ticket system.
What was our technology stack:
- .NET Web API application written in C # as a backend;
- Angular client;
- MongoDB for database and ElasticSearch for full-text search;
- Mailgun for sending mail messages to players.
General view of the Support Ticket System
Let's summarize.
Advantages of developing your own ticket system
- Sharpening the help desk for your company in solving problems, simplifying the flow and tracking indicators.
- Deepening knowledge about the functioning of the ticket system and about the work of the technical support team sitting across the wall from you.
- -. , - .
- , .
- .
- . , - , .
- . , , .
- , , .
- . , «» , , QA UI/UX- , .
- . — , . . 40 50–70 , 3–5 ( ). -, , , , . , , -.
- We'll have to go a long and difficult way. We changed the development process several times, swore and put up, made and reworked. More than 1,500 bugs have been fixed in these 3.5 years.
- Structural changes will be needed. A team is needed that works to support internal processes. It is necessary to separate those who produce the company's product and those who make back office tools. It is unlikely that it will be possible to attract the main developers to create such a tool.
To get involved in this business or not is up to you. And we do not regret that we got involved. It was scary. And it was terribly interesting too.