Una vez, el departamento de Soporte comercial de Social Discovery Group enfrentó el enorme desafío de eliminar una acumulación de 1500 tickets que se habían acumulado durante cuatro años. Administrar un volumen tan alto de problemas fue una tarea seria, y constantemente nos encontramos luchando para mantenernos al día con los KPI. A pesar de nuestros mejores esfuerzos, los boletos seguían mezclándose de un sprint a otro, dejando a los clientes frustrados y sintiéndonos abrumados. En este artículo, nos gustaría compartir nuestra experiencia al abordar esta tarea aparentemente imposible, recordándonos el legendario sexto trabajo de Hércules. Lo guiaremos a través de los desafíos que enfrentó el equipo de SDGroup y los pasos que tomamos para reconstruir los procesos de nuestro departamento. Adoptamos el enfoque STATIK, que demostró ser increíblemente efectivo para ayudarnos a eliminar el retraso y brindar el alivio que tanto necesitaba nuestro equipo. Entonces, si está buscando información práctica para abordar una acumulación de tickets, ¡siga leyendo! Cómo terminamos con la cola de 1500 boletos Como departamento de Soporte Comercial, somos responsables de manejar los tickets que contienen quejas y sugerencias de los clientes sobre nuestros servicios. Por ejemplo, si un cliente experimenta dificultades con el sistema de pago en nuestro sitio web, puede plantear un problema con el equipo de soporte técnico de SDG. Los colegas recopilan toda la información relevante, incluidos los pasos de reproducción de problemas y las capturas de pantalla, y crean un ticket en Jira, asignándolo a nuestro departamento. Luego realizamos pruebas adicionales para asegurarnos de que el problema no sea una falla temporal del cliente, sino un problema real de nuestro lado. Si se confirma, creamos un informe de error, lo priorizamos y lo enviamos al equipo de desarrollo para su resolución. En promedio, solíamos recibir 20-30 boletos diarios. Pasamos de 2 a 3 horas reproduciendo el problema, pero cada vez que necesitábamos ayuda de otros departamentos, como detalles del caso, reinicios del servicio, datos de la base de datos o análisis del equipo de desarrollo, nuestras tareas tendían a atascarse. Nuestros colegas a menudo no podían responder con prontitud, y no había un equipo separado de desarrolladores asignados a nuestros informes de errores. Además, nuestros tickets de desarrollo tenían menor prioridad en comparación con las tareas comerciales. Como resultado, incluso los tickets de alta prioridad podían quedar sin resolver durante algunos meses, mientras que las tareas de menor prioridad permanecían en el tablero durante años. Como puede ver, este flujo generaba demasiada incertidumbre en el cumplimiento de los plazos, lo que generaba insatisfacción tanto para nosotros como para nuestros clientes. La situación generó varios problemas: Los clientes estaban estresados y frustrados cuando sus problemas no se resolvían lo suficientemente rápido y no podíamos proporcionar un cronograma claro. Nuestro equipo de soporte estaba frustrado, ya que los clientes exigían actualizaciones para problemas sin resolver casi todos los días. El equipo de soporte nos escribió y recibió la misma respuesta: "El problema aún no está resuelto". Nuestro equipo estaba sobrecargado y no podía retomar tareas antiguas y vincularlas como casos recurrentes. Nos desesperamos al ver la enorme cantidad de 1500 tareas sin resolver en nuestro tablero. Sabíamos que necesitábamos cambiar nuestro enfoque para avanzar. Así es como se veía el ciclo de vida de los boletos durante ese período. Echemos un vistazo a algunos de los problemas que encontramos al administrar la acumulación de problemas: El equipo de soporte carecía de scripts para documentar y filtrar problemas rápidamente. Las tareas en el estado "Nuevo" a menudo se quedaban estancadas en el limbo. Cuando no teníamos suficiente información o acceso para resolver el problema, pasaba al estado "Escalado" y buscábamos ayuda de colegas en otros departamentos. Desafortunadamente, pueden tardar semanas o incluso meses en responder. Y, a veces, nos perdimos los comentarios debido al abrumador volumen de tareas entrantes. Una vez que finalmente verificamos el problema, lo cambiamos al estado "En espera de solución". Debido a la escasez crónica de recursos de desarrollo, estos tickets podrían permanecer sin resolver durante años. Los clientes no cerraron los tickets, esperando que recibiéramos más recursos en el futuro. La acumulación sustancial de tareas resultó en duplicados. Fue difícil fusionarlos y cerrarlos, ya que a menudo nos costaba recordar qué tareas se habían iniciado en años anteriores. Este enfoque mal organizado resultó en una acumulación de . 1.500 tickets sin resolver durante cuatro años El enfoque STATIK y el sexto trabajo de Hércules Nos dimos cuenta de que nuestro departamento estaba demasiado enfocado en procesar tickets en lugar de abordar el objetivo principal de resolver los problemas de los clientes: mejorar su lealtad hacia los productos de Social Discovery Group y detectar vulnerabilidades en nuestros servicios y sitios web. Quizás se pregunte: "¿Por qué no contratar más personal si no puede manejar la carga de trabajo?" Sin embargo, la experiencia ha demostrado que al establecer procesos eficientes, podemos prescindir de recursos adicionales. Del mismo modo, Hércules completó su trabajo solo al redirigir el flujo del río hacia los establos de Augias, que los limpiaron en solo un día. Para simplificar nuestro tablero de tickets, nos remitimos al libro de Mike Burrows e implementamos el enfoque STATIK, una estrategia sistemática para ejecutar el método Kanban. "Kanban from the Inside" Al implementar el enfoque STATIK, seguimos estos : cinco pasos y llegamos a la conclusión de que los clientes deben estar satisfechos con el soporte brindado. Para lograr esto, debemos asegurarnos de lo siguiente: 1. Identificamos las expectativas de los clientes de nuestro departamento de Soporte Comercial La transparencia en nuestro trabajo en la tarea permite a los clientes entender qué está pasando con sus solicitudes en un momento dado. Prontitud de nuestro trabajo en las tareas, brindando un tiempo definitivo para la retroalimentación en cualquier estado de la cuestión. La fuente interna es lo que nos estorba y causa frustración en nuestro propio trabajo. 2. Definimos las fuentes internas y externas de insatisfacción. La fuente externa es lo que causó frustración a nuestros clientes y obstaculizó su experiencia. Examinamos los tickets enviados a nuestro departamento y los categorizamos según los departamentos de los que procedían, su frecuencia y las expectativas de los clientes en cuanto a tiempos de respuesta y soluciones. 3. Analizamos las fuentes y la naturaleza de nuestra carga de trabajo. En esta etapa, evaluamos qué tan eficientemente estábamos manejando los tickets y determinamos cuántas tareas podíamos manejar de manera realista en una semana. 4. Evaluamos nuestras capacidades actuales. Además, calculamos el tiempo promedio que tomó pasar desde el inicio del ticket hasta la liberación de la corrección de errores en producción. 5. Reconstruimos el ciclo de vida del ticket y creamos un nuevo proceso. Nuestro ciclo de vida inicial del boleto Utilizando los conocimientos adquiridos, hemos desarrollado un nuevo ciclo de vida de tareas. A continuación, implementamos un enfoque integral para resolver todos los problemas mencionados anteriormente. Tomamos los siguientes pasos: Creamos scripts para nuestro equipo de soporte para filtrar tareas en el nivel inicial. Introdujimos un estado temporal "Volver al reportero" para las tareas que requerían la participación del cliente para investigar el problema. Si no se proporcionaba la información necesaria en un plazo de tres días, la tarea se cerraría automáticamente. Eliminamos el estado "Escalado" y lo reemplazamos con un estado más específico de "Confirmación de problema". Pasamos más de dos meses revisando y cerrando tareas duplicadas, dejándonos con solo 800 tickets únicos de los 1500 con los que comenzamos. Implementamos acuerdos de nivel de servicio (SLA) y establecimos temporizadores para cada estado. El estado "Confirmación del problema" tenía un temporizador de 7 días, mientras que el estado "Desarrollo" tenía un temporizador de 30 días. Tener tareas en el estado de "Confirmación de problema" nos motivó a hacer ping a nuestros colegas para obtener una respuesta. Cambiamos nuestro enfoque de comunicación, usando mensajes privados o hilos de Slack en lugar de comentar en Jira. Esto redujo el tiempo de respuesta a un día en comparación con las semanas que tomaba antes. Aunque no pusimos un temporizador en el estado "En espera de solución", asignamos más tiempo para la comunicación y el debate con el cliente. Si una tarea se consideraba inviable, informamos al cliente y priorizamos las tareas más importantes. Esto llevó a una reducción del 50% en las tareas en espera. Además, comenzamos a organizar reuniones en las que los clientes podían explicar la importancia de una tarea, lo que nos ayudó a priorizar mejor nuestra carga de trabajo. Para el estado "Desarrollo", configuramos un temporizador de 30 días y limitamos la cantidad de tareas en este estado a cuatro. Esto nos ayudó a concentrarnos en corregir el error dentro del marco de tiempo establecido y evitar abrumarnos con el ruido visual innecesario de 20 a 40 tareas en el estado "Desarrollo" en el tablero. Para garantizar que nuestras prácticas sean sostenibles, incorporamos el principio del percentil 90, lo que significa que el 90 % de las tareas deben completarse a tiempo, según lo determinen los cronómetros para cada estado. Supervisamos esto utilizando el gráfico de control de Jira y el complemento Jira-helper para construir el percentil 90. Finalmente, introdujimos una motivación adicional para el equipo, prometiendo una bonificación si se seguía el principio del percentil 90, tal como Augias le prometió a Hércules una décima parte de sus caballos como bonificación. Al implementar este nuevo enfoque y reconstruir los procesos de nuestro departamento, finalmente pudimos abordar un problema que nos había atormentado durante cuatro largos años. La solución no requirió tiempo, esfuerzo o presupuesto adicional, pero redujimos significativamente la cantidad de tareas acumuladas. En solo cinco meses, con un equipo de solo dos empleados inteligentes, logramos reducir la cola de 1500 boletos a solo 150. Esta experiencia nos ha enseñado la importancia de identificar la causa raíz de un problema para abordarlo de manera efectiva. También ha subrayado la importancia de contar con procesos bien diseñados, ya que los procesos deficientes conducirán inevitablemente a una acumulación de problemas, como descubrimos de primera mano. Escrito por Dimitri Andrews, ingeniero de pruebas de software en Social Discovery Group

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Developers: Build Less. Deliver More. [Learn how]	

Abordar los establos de Augean de la atención al cliente: nuestra historia de éxito

Demasiado Largo; Para Leer

Social Discovery Group

STORY’S CREDIBILITY

Guide

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

Abordar los establos de Augean de la atención al cliente: nuestra historia de éxito

Demasiado Largo; Para Leer

Social Discovery Group

STORY’S CREDIBILITY

Guide

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS