Entonces, ¿a qué nos enfrentamos que pensamos en desarrollar nuestro propio sistema de tickets? Problemas principales:
- Nuestro equipo recibió entre 1 y 1,5 mil visitas de usuarios todos los días.
- Faltaban estadísticas convenientes. Todo tenía que anotarse manualmente en varios documentos.
- La principal dificultad: la mayoría de las solicitudes requerían verificar el estado de la cuenta del jugador, que en ese momento no era accesible directamente; trabajamos solo con los textos de las solicitudes y las direcciones de correo electrónico.
- Complejidad e interfaz creadas. Las soluciones de otras personas suelen ser inconvenientes porque no están diseñadas para un juego específico ni para las regulaciones de soporte técnico de una empresa específica.
- Teniendo en cuenta todo lo anterior, pagar por un sistema de terceros no fue muy rentable.
Y tomamos una decisión trascendental: ¡cortar nuestro propio sistema de tickets! ¿Qué? Hay fuerza, hay muchas ideas, entusiasmo, más que suficiente. Pero en ese momento no había procesos relevantes: nosotros, el equipo de soporte, nunca habíamos pedido nada al equipo de desarrollo del kit de herramientas interno y no interactuamos de cerca con él.
¿Donde empezar? Escribimos en dos columnas nuestras expectativas de la herramienta (algo así como “queremos recibir mensajes y responder a ellos”) y quejas sobre la versión actual (“aquí hay una ventana inconveniente, hazla más conveniente”), la llamamos tarea técnica y la pasamos a los desarrolladores. El proceso posterior tomó alrededor de 3 meses. No hubo una etapa de prueba, todos los errores fueron encontrados por los desarrolladores o el propio soporte ya al usar la herramienta.
Como puedes adivinar, este panqueque salió grumoso. Lo probamos y pensamos que las desventajas del servicio comprado no son tan graves. Y luego el equipo de la mesa de ayuda comercial propuso una integración, en la que recibiría información sobre el usuario del juego y la transmitiría en tickets a nuestro soporte (esto solucionaría el problema principal). Sin embargo, algunas de las condiciones para la integración eran contrarias a los requisitos de seguridad adoptados por la empresa. Entonces, qué opciones teníamos:
- Realice una integración insegura con el servicio de asistencia comercial.
- Utilice su funcionalidad simplificada.
- Volver al desarrollo de herramientas.
Tomamos el último camino. Arreglamos todo lo que no funcionó después de la primera iteración y conectamos el sistema de boletos a los juegos. Tenía una funcionalidad básica: aceptamos solicitudes y les respondimos enviando mensajes al correo. Pero lo más importante es que finalmente tenemos la oportunidad de ver la identificación del jugador en el sistema de tickets, que se refiere a nuestra otra herramienta interna con el resto de la información de la cuenta.
El equipo que proporcionó el proceso de desarrollo inicialmente incluía al propietario del producto, al administrador de proyectos y al equipo de desarrollo. Dibujamos el diseño nosotros mismos, los desarrolladores editaron y, en la medida de lo posible, probamos el producto. Luego se unieron los diseñadores de UI / UX y QA. Como resultado, resultó el siguiente proceso: el cliente escribe lo que quiere, UI / UX dice cuál es la mejor manera de hacerlo, los desarrolladores lo implementan, verifica el control de calidad y PM controla toda la cadena y el tiempo.
Habiendo introducido un sistema de tickets con una funcionalidad mínima, comenzamos a mejorarlo y adaptarlo a las necesidades y objetivos de la empresa. En total, se han implementado más de 200 funciones hasta la fecha, las principales se enumeran a continuación.
- . , KPI , , . 7 50 .
- — ( ) .
- .
- .
- HTML- .
- -. - .
- .
- . , .
- - .
- , .
- ( new, waiting, answered, resolve close, inprogress, pending). ; , / ; ( ).
- .
- .
- , .
- Soluciones programables de instalación de flujo, incluida la notificación a los empleados responsables en caso de un evento en el sistema de tickets.
¿Cuál fue nuestra pila de tecnología?
- Aplicación de API web de .NET escrita en C # como backend;
- Cliente angular;
- MongoDB para base de datos y ElasticSearch para búsqueda de texto completo;
- Mailgun para enviar mensajes de correo a los jugadores.
Vista general del sistema de tickets de soporte
Resumamos.
Ventajas de desarrollar su propio sistema de tickets
- Agudizar la mesa de ayuda de su empresa en la resolución de problemas, simplificar el flujo y los indicadores de seguimiento.
- Profundización del conocimiento sobre el funcionamiento del sistema de tickets y sobre el trabajo del equipo de soporte técnico sentado frente a usted.
- -. , - .
- , .
- .
- . , - , .
- . , , .
- , , .
- . , «» , , QA UI/UX- , .
- . — , . . 40 50–70 , 3–5 ( ). -, , , , . , , -.
- Tendremos que recorrer un camino largo y difícil. Cambiamos el proceso de desarrollo varias veces, luchamos y levantamos, hicimos y reelaboramos. Durante estos 3,5 años, se han corregido más de 1500 errores.
- Se necesitarán cambios estructurales. Se necesita un equipo que trabaje para apoyar los procesos internos. Es necesario separar a los que elaboran el producto de la empresa de los que fabrican las herramientas de back office. Es poco probable que sea posible atraer a los desarrolladores principales para crear una herramienta de este tipo.
Involucrarse o no en este negocio depende de usted. Y no lamentamos habernos involucrado. Fue espantoso. Y también fue muy interesante.