
Então, o que estamos enfrentando para pensar em desenvolver nosso próprio sistema de tickets? Principais problemas:
- Nossa equipe recebeu de 1 a 1,5 mil acessos de usuários todos os dias.
- Faltavam estatísticas convenientes. Tudo teve que ser anotado manualmente em vários documentos.
- A principal dificuldade: a maioria dos pedidos exigia a verificação do estado da conta do jogador, que na altura não era acessível directamente - trabalhávamos apenas com os textos dos próprios pedidos e endereços de email.
- Complexidade e interface criadas. As soluções de outras pessoas costumam ser inconvenientes, porque não são feitas sob medida para um jogo específico e regulamentos de suporte técnico para uma empresa específica.
- Considerando tudo isso, pagar por um sistema de terceiros não era muito lucrativo.
E tomamos uma decisão que marcou época - cortar nosso próprio sistema de tickets! O que? Há força, muitas idéias, entusiasmo - mais do que suficiente. Mas naquela época não havia processos relevantes: nós, a equipe de suporte, nunca havíamos pedido nada para a equipe de desenvolvimento do kit de ferramentas interno e não interagíamos de perto com ela.
Onde começar? Escrevemos em duas colunas nossas expectativas em relação à ferramenta (algo no estilo "queremos receber mensagens e respondê-las") e reclamações sobre a versão atual ("aqui está uma janela inconveniente, torne-a mais conveniente"), chamamos de tarefa técnica e a repassamos aos desenvolvedores. O processo adicional demorou cerca de 3 meses. Não houve fase de testes, todos os erros foram encontrados pelos desenvolvedores ou pelo próprio suporte já ao utilizar a ferramenta.
Como você pode imaginar, esta panqueca saiu irregular. Experimentamos e pensamos que as desvantagens do serviço adquirido não são tão graves. E então a equipe do help desk comercial propôs uma integração, na qual receberia informações sobre o usuário do jogo e as transmitiria em tickets para o nosso suporte (isso resolveria o problema principal). No entanto, algumas das condições de integração foram contrárias aos requisitos de segurança adotados pela empresa. Então, quais opções tínhamos:
- Faça integração insegura com helpdesk comercial.
- Use sua funcionalidade reduzida.
- Retorne ao desenvolvimento da ferramenta.
Pegamos o último caminho. Corrigimos tudo que não funcionava após a primeira iteração e conectamos o sistema de tickets aos jogos. Tinha funcionalidades básicas: aceitávamos inscrições e respondíamos enviando mensagens para o correio. Mas o mais importante, finalmente temos a oportunidade de ver o ID do jogador no sistema de tickets, que se refere a nossa outra ferramenta interna com o resto das informações da conta.
A equipe que forneceu o processo de desenvolvimento incluiu inicialmente o proprietário do produto, o PM e a equipe de desenvolvimento. Nós mesmos desenhamos o design, os desenvolvedores editaram e, na medida do possível, testamos o produto. Então, os designers de UI / UX e o controle de qualidade se juntaram. Como resultado, o seguinte processo resultou: o cliente escreve o que deseja, UI / UX diz a melhor forma de fazê-lo, desenvolvedores implementam, verificações de QA e o PM controla toda a cadeia e o tempo.

Tendo introduzido um sistema de tickets com funcionalidade mínima, começamos a melhorá-lo e adaptá-lo às necessidades e objetivos da empresa. No total, mais de 200 recursos foram implementados até o momento, os principais estão listados abaixo.
- . , KPI , , . 7 50 .
- — ( ) .
- .
- .
- HTML- .
- -. - .
- .
- . , .
- - .
- , .
- ( new, waiting, answered, resolve close, inprogress, pending). ; , / ; ( ).
- .
- .
- , .
- Fluxo programável - soluções instaladas, incluindo notificação dos funcionários responsáveis em caso de evento no sistema de tickets.
Qual era a nossa pilha de tecnologia:
- Aplicativo NET Web API escrito em C # como backend;
- Cliente angular;
- MongoDB para banco de dados e ElasticSearch para pesquisa de texto completo;
- Mailgun para enviar mensagens de correio aos jogadores.

Visão geral do sistema de tickets de suporte
Vamos resumir.
Vantagens de desenvolver seu próprio sistema de tickets
- Agilizando o help desk da sua empresa na resolução de problemas, simplificando o fluxo e os indicadores de acompanhamento.
- Aprofundar o conhecimento sobre o funcionamento do sistema de tickets e sobre o trabalho da equipe de suporte técnico sentado na sua parede.
- -. , - .
- , .
- .
- . , - , .
- . , , .
- , , .
- . , «» , , QA UI/UX- , .
- . — , . . 40 50–70 , 3–5 ( ). -, , , , . , , -.
- Teremos que percorrer um caminho longo e difícil. Mudamos várias vezes o processo de desenvolvimento, lutamos e montamos, fizemos e retrabalhamos. Mais de 1.500 bugs foram corrigidos nesses 3,5 anos.
- Mudanças estruturais serão necessárias. É necessária uma equipe que trabalhe para apoiar os processos internos. É preciso separar quem fabrica o produto da empresa e quem fabrica ferramentas de back office. É improvável que seja possível atrair os principais desenvolvedores para a criação de tal ferramenta.
Envolver-se ou não neste negócio é com você. E não lamentamos ter nos envolvido. Foi assustador. E foi terrivelmente interessante também.