Alors, à quoi sommes-nous confrontés lorsque nous avons pensé à développer notre propre système de billetterie? Problèmes principaux:
- Notre équipe a reçu chaque jour entre 1 et 1500 visites d'utilisateurs.
- Les statistiques pratiques faisaient défaut. Tout devait être noté manuellement dans divers documents.
- La principale difficulté: la plupart des demandes nécessitaient de vérifier le statut du compte du joueur, qui à l'époque n'était pas directement accessible - nous ne travaillions qu'avec les textes des demandes eux-mêmes et les adresses e-mail.
- Complexité et interface créées. Les solutions d'autres personnes sont le plus souvent peu pratiques, car elles ne sont pas adaptées à un jeu spécifique et aux règles de support technique d'une entreprise spécifique.
- Compte tenu de tout ce qui précède, payer pour un système tiers n'était pas très rentable.
Et nous prenons une décision historique: couper notre propre système de tickets! Quoi? Il y a de la force, il y a beaucoup d'idées, d'enthousiasme - plus que suffisant. Mais à ce moment-là, il n'y avait pas de processus correspondant: nous, l'équipe d'assistance, n'avions jamais rien commandé à l'équipe de développement de la boîte à outils interne et n'avons pas interagi étroitement avec elle.
Où commencer? Nous avons écrit en deux colonnes nos attentes vis-à-vis de l'outil (quelque chose dans le style «nous voulons recevoir des messages et y répondre») et des plaintes concernant la version actuelle («cette fenêtre est gênante, rendez-la plus pratique»), l'avons qualifiée de tâche technique et l'avons transmise aux développeurs. Le processus ultérieur a duré environ 3 mois. Il n'y a pas eu d'étape de test, toutes les erreurs ont déjà été trouvées par les développeurs ou le support lui-même lors de l'utilisation de l'outil.
Comme vous pouvez le deviner, cette crêpe est sortie grumeleuse. Nous l'avons essayé et avons pensé que les inconvénients du service acheté ne sont pas si graves. Et puis l'équipe du help desk commercial a proposé une intégration, dans laquelle elle recevrait des informations sur l'utilisateur du jeu et les transmettrait sous forme de tickets à notre support (cela résoudrait le problème principal). Cependant, certaines des conditions d'intégration étaient contraires aux exigences de sécurité adoptées par l'entreprise. Alors, quelles options nous avions:
- Faites une intégration non sécurisée avec le helpdesk commercial.
- Utilisez sa fonctionnalité simplifiée.
- Revenir au développement d'outils.
Nous avons pris le dernier chemin. Nous avons corrigé tout ce qui ne fonctionnait pas après la première itération et avons connecté le système de tickets aux jeux. Il avait des fonctionnalités de base: nous acceptions les candidatures et y répondions en envoyant des messages par courrier. Mais surtout, nous avons enfin la possibilité de voir l'identifiant du joueur dans le système de tickets, qui fait référence à notre autre outil interne avec le reste des informations de compte.
L'équipe qui a fourni le processus de développement comprenait initialement le propriétaire du produit, le PM et l'équipe de développement. Nous avons dessiné le design nous-mêmes, les développeurs ont édité et, dans la mesure du possible, testé le produit. Ensuite, les concepteurs UI / UX et QA se sont joints. En conséquence, le processus suivant s'est avéré: le client écrit ce qu'il veut, UI / UX indique la meilleure façon de le faire, les développeurs l'implémentent, les contrôles QA et le PM contrôle toute la chaîne et le calendrier.
Après avoir introduit un système de tickets avec des fonctionnalités minimales, nous avons commencé à l'améliorer et à l'adapter aux besoins et aux objectifs de l'entreprise. Au total, plus de 200 fonctionnalités ont été implémentées à ce jour, les principales sont listées ci-dessous.
- . , KPI , , . 7 50 .
- — ( ) .
- .
- .
- HTML- .
- -. - .
- .
- . , .
- - .
- , .
- ( new, waiting, answered, resolve close, inprogress, pending). ; , / ; ( ).
- .
- .
- , .
- Solutions installées par flux programmables, y compris notification des employés responsables en cas d'événement dans le système de billetterie.
Quelle était notre pile technologique:
- Application API Web NET écrite en C # en tant que backend;
- Client angulaire;
- MongoDB pour la base de données et ElasticSearch pour la recherche en texte intégral;
- Mailgun pour l'envoi de messages électroniques aux joueurs.
Vue générale du Support Ticket System
Résumons.
Avantages de développer votre propre système de tickets
- Un service d'assistance aiguisé pour votre entreprise pour résoudre les problèmes, simplifier les flux et suivre les indicateurs.
- Approfondir les connaissances sur le fonctionnement du système de tickets et sur le travail de l'équipe de support technique assis en face de vous.
- -. , - .
- , .
- .
- . , - , .
- . , , .
- , , .
- . , «» , , QA UI/UX- , .
- . — , . . 40 50–70 , 3–5 ( ). -, , , , . , , -.
- Nous devrons parcourir un chemin long et difficile. Nous avons changé plusieurs fois le processus de développement, nous nous sommes battus et avons mis en place, fabriqué et retravaillé. Au cours de ces 3,5 années, plus de 1 500 bogues ont été corrigés.
- Des changements structurels seront nécessaires. Il faut une équipe qui travaille pour soutenir les processus internes. Il faut séparer ceux qui produisent le produit de l'entreprise et ceux qui fabriquent les outils de back-office. Il est peu probable qu'il soit possible d'attirer les principaux développeurs pour créer un tel outil.
S'impliquer ou non dans cette entreprise dépend de vous. Et nous ne regrettons pas de nous être impliqués. C'était effrayant. Et c'était aussi terriblement intéressant.