Atención al cliente ágil: Cómo Scrum en un entorno de interrupción

Centros de llamadas. Centros de servicios. Mesas de ayuda. Probablemente definen la relación entre usted y su cliente como cualquier otra cosa que haga. Cuando están de cara al público, su impacto en la satisfacción del cliente es sólo superado por el producto o servicio al que dan soporte. Un mal servicio de atención al cliente hace que el negocio se vaya al traste.

Al atender a los clientes internos, pueden definir el funcionamiento de su organización. Una respuesta lenta significa productividad lenta, pérdida de ingresos y oportunidades, y puede ser perjudicial para la salud y la moral de la organización.

Pero los centros de servicio son lugares complicados. Su flujo de trabajo es inherentemente impredecible y depende de lo inesperado.

Por eso Scrum, con su enfoque tanto en el proceso como en el producto, es perfectamente adecuado para impulsar la eficacia y la capacidad del centro de servicio al tiempo que crea un proceso de gestión de incidencias ágil, eficaz y sólido.

La implantación también puede permitir a estos equipos internos ayudar a resolver problemas en lugar de limitarse a responder a ellos. Además, el servicio externo o los centros de llamadas pueden pasar de ser netamente negativos a netamente positivos en términos de generación de ingresos. Junto con el beneficio externo, vemos la satisfacción de los empleados y una mayor capacidad para generar valor más allá del ámbito de la asistencia directa.

Este estudio de caso expone un proceso probado de cinco pasos para implantar sistemáticamente Scrum en un centro de llamadas concreto. Este proceso, y sus resultados, se han reproducido también en otros centros de servicios. Estos pasos se enumeran secuencialmente. Pero, como el propio Scrum, pueden desplegarse orgánicamente, permitiendo que estos cambios se realicen de uno en uno y se repitan, o todos a la vez.

Paso 1 - Billetes: Un problema de prioridades

Nada define tanto un centro de llamadas como los tickets. El número de tickets que un centro puede procesar en un periodo de tiempo determinado suele ser una medida del éxito. Cuando se hace bien, cada ticket representa a un cliente, un problema y, en última instancia, indica si se ha encontrado una solución o si es necesario seguir trabajando.

Por todo ello, el Dr. Jeff Sutherland, cocreador de Scrum y fundador de Scrum Inc., afirma que cuando trabaja con un centro de llamadas "siempre empiezo por los tickets". A menudo encuentra los mismos dos problemas: Falta de priorización empresarial y falta de información.

Ambas cosas se pusieron de manifiesto cuando Sutherland tuvo que ayudar a un centro de atención al cliente de Intronis, proveedor líder de servicios de copia de seguridad en línea. El centro recibía el doble de llamadas de las que podía atender. "Mi primera pregunta", afirma Sutherland, fue: "Hábleme de sus tickets. ¿Están bien priorizados?".

La respuesta fue "primero en entrar, primero en salir".

Así que Sutherland se preguntó: "¿Va a generar eso más ingresos a la empresa?".

El equipo de asistencia respondió "no".

Es una constatación importante, aunque contraintuitiva. Pero no debería serlo. Sobre todo si se tiene en cuenta la regla del 80/20 establecida en el Principio de Pareto.

En este contexto, Pareto actúa de dos maneras;

Aproximadamente 80% del valor empresarial procede de 20% de clientes de servicios o centros de llamadas. Esto es cierto tanto si los tickets son generados internamente como por usuarios públicos. En cualquier otro caso empresarial, los clientes de alto valor reciben un trato preferente. Los centros de servicios no deberían ser diferentes.

Sólo 20% de clientes generan aproximadamente 80% de solicitudes de asistencia. Esto significa que la capacidad de los centros de servicio es devorada por solicitudes relativamente triviales, lo que crea un cuello de botella para las necesidades serias de soporte al cliente que pueden afectar y afectarán a los resultados de una organización.

El flujo de trabajo "primero en entrar, primero en salir" puede parecer más igualitario. Pero, como señala Sutherland, tiene un alto coste. "Cuando se hace esperar a los clientes importantes tanto como a los demás, se reducen los ingresos, repercute en las ventas y se ralentiza todo". Añade que "incluso los directores generales se ven atrapados" en esta trampa del primero en entrar, primero en salir. Así que la cuestión no es si los tickets deben priorizarse por valor de negocio, la cuestión es quién los prioriza y cómo.

Introduzca el Product Owneruno de los tres papeles en Scrum.

El Product Owner es responsable de conocer el valor empresarial relativo de los deseos y necesidades de los clientes. Y de priorizar un backlog basado en ese conocimiento.

Un Product Owner exitoso de un equipo de centro de servicio establece directrices claras para la priorización. Estas directrices se explican detalladamente y se comparten con el Equipo Scrum durante los Eventos Scrum y a través tanto del Product Backlog como del Sprint Backlog.

En el centro de llamadas de Intronis, Sutherland preguntó: "¿Quién va a ser el Product Owner?". El Director de Operaciones se ofreció voluntario. Conocían el valor empresarial relativo de los clientes y veían lo que significaba una priorización adecuada para el cliente, el centro de servicios y la empresa.

Paso 2 - Entradas: Información clave

Los tickets priorizados por sí solos aumentarán la satisfacción de los clientes clave. Pero si no aumenta el rendimiento, los clientes no priorizados se quedan esperando y descontentos. Un centro de atención al cliente ágil verá cómo su productividad y capacidad aumentan de forma que todos los tickets, priorizados o no, se gestionan de forma eficiente y satisfactoria.

En Intronis, la segunda serie de preguntas de Jeff Sutherland se centraba en los propios billetes. Qué contenían y qué les faltaba. Lo que descubrió fue que muchos de los tickets estaban incompletos. "Alguien cogía un ticket y decía que no podíamos trabajar en esto porque necesitábamos 'X' del cliente". Entonces se intercambiaban correos electrónicos. Se mantenían las llamadas. Finalmente se recopilaba la información necesaria.

Pero estos pasos adicionales hacían que los billetes tardaran más y se tramitaran menos.  Lo que frustraba tanto a los clientes como a los miembros del equipo.

Así que Sutherland trabajó con el equipo Scrum para crear una "Definición de Listo" - un conjunto establecido de información necesaria para que el equipo comenzara a trabajar en los tickets inmediatamente. El establecimiento de una "definición de listo" que fuera clara tanto para el equipo Scrum como para el cliente duplicó la capacidad del centro de llamadas. "Tras dos semanas de aplicación de esta definición de listo, el equipo pasó de hacer mil tickets a la semana a dos mil tickets a la semana". Pudieron duplicar su producción.

Pronto se observaron resultados similares en Intronis.

Paso 3 - Mapeo del flujo de valor y Scrumming del proceso

Scrum es conocido por fomentar la innovación no sólo en productos y servicios, sino también en el proceso que los proporciona. Así es como los equipos Scrum se vuelven hiperproductivos y consiguen el doble de trabajo en la mitad de tiempo o más. Scrum Masters son responsables de esta mejora continua del proceso. Ayudan al equipo Scrum a eliminar impedimentos, identificar y eliminar cuellos de botella y dependencias. Los Scrum Masters también sacan a la superficie cualquier problema que ralentice al equipo y que ellos solos no puedan superar.

En Intronis, Sutherland utilizaba mapeo del flujo de valorEl Scrum Master utilizó una técnica Lean habitual para identificar cuellos de botella e impedimentos. Empezó preguntándoles "¿qué ocurre cuando se empieza a trabajar en un ticket?".

El equipo estableció el siguiente sistema. "Recibimos una llamada de un cliente que suele durar unos cinco minutos. Entonces no solemos poder resolver el problema del cliente sin hablar con el Jefe de Soporte".

Por lo general, el Jefe de Asistencia tardaba unas dos horas en responder. Aquí estaba el primer cuello de botella.

Sólo después de eso, el Scrum Team Member que trabajaba en el ticket podía terminar el proceso con otra llamada de cinco minutos al cliente.

Armado con estos datos, Sutherland preguntó al Jefe de Soporte si podía ofrecer una respuesta más rápida. "Sí", contestó, "si es importante, puedo tardar una media de 10 minutos".

Era importante.

El aumento de eficacia del proceso podría duplicar su rendimiento. Sutherland lo explica así. "La eficacia original de su proceso es inferior a 10%". Pero si pudiera cumplir ese plazo de 10 minutos, la eficacia del proceso daría un salto espectacular. "La eficiencia del proceso es de 50%. Ahora", añade, "tienes un proceso muy ajustado. Funcionamiento ajustado."

Paso 4 - El patrón de interrupción

Otra mejora clave del proceso se produjo teniendo en cuenta el flujo de trabajo único de un centro de servicio. La mayor parte de su trabajo diario era desconocido y, por tanto, difícil de planificar. Difícil, pero no imposible.

Por ello, Sutherland les aconsejó que utilizaran un Sprint Backlog que lo tuviera en cuenta. 90% de su capacidad se asignarían en un "Búfer de interrupción"; un método para permitir que el trabajo emergente, en este caso, los billetes, se introduzca en el Sprint y se trabaje a medida que llega.  Esto permite la flexibilidad y capacidad de respuesta que los centros de servicio necesitan para utilizar un modelo de atención al cliente ágil y aumentar la satisfacción del cliente.

El otro 10% del Sprint Backlog se centraría en las mejoras del proceso. Éstas iban desde el uso de un KaizenDesde un experimento para ver si un cambio específico en el proceso aumentaría la productividad, la eficiencia, la felicidad del equipo Scrum, etc. hasta la creación de un calendario de seguimiento de los aumentos repentinos de las solicitudes de asistencia para que el equipo Scrum pudiera ayudar a analizar la causa raíz. En Intronis, dice Sutherland, esto llevó a un "almuerzo informal semanal en el que los desarrolladores y los equipos de asistencia hablaban de los problemas graves de la plataforma y averiguaban cómo solucionarlos" y cómo evitar problemas similares en el futuro.

Y a medida que aumente la eficiencia de los procesos y la velocidad del equipo, ese colchón se irá reduciendo. Esto permite al centro de servicios ampliar sus ventas a los clientes actuales o llamarles proactivamente para preguntarles si hay algo en lo que puedan ayudarles ese día.

Paso 5 - Uso de los eventos Scrum en los centros de llamadas

Cada uno de los cinco eventos Scrum desempeña un papel importante en cualquier aplicación. He aquí cómo trabajan juntos en un centro de servicios.

El Sprint: Son lo más breves posible. En muchos casos, no duran más de una semana y siguen una cadencia de lunes a viernes. Esto permite una rápida inspección y adaptación a las mejoras del proceso, al tiempo que permite que la mayor parte del trabajo se centre en las peticiones de los clientes y en el servicio al cliente.

Planificación de sprints: Este acto sustituyó a una reunión habitual de los lunes por la mañana. Scrum-ificándolo hizo que la reunión fuera más eficiente, efectiva y corta. El equipo Scrum se aseguró de que el Product Backlog estuviera listo y de que todo el mundo tuviera clara la(s) mejora(s) del proceso en la(s) que estaban trabajando en este Sprint.

Diario Scrum: El Equipo Scrum utilizó estos eventos para alinearse con el Objetivo del Sprint, con 10% de su backlog dedicado a la mejora de procesos y replanificar el Sprint Backlog según lo requiriera el flujo de trabajo. Esto impulsó tanto la eficacia como la saturación de la comunicación.

Retrospectiva Sprint: Este evento se celebró los viernes por la tarde. Los equipos del centro de servicios Scrum utilizaron la métrica de la felicidad para obtener datos sobre cómo se sienten todos en relación con la empresa, su trabajo y las mejoras de los procesos que les harían sentirse mejor. La retrospectiva fue breve, ya que se utilizó principalmente para priorizar las mejoras de los procesos e identificar los elementos de máxima prioridad que debían incluirse en el Backlog para la semana siguiente, junto con las pruebas de aceptación.

Revisión de Sprint: Aquí, el equipo Scrum analizó el trabajo realizado durante la semana y tomó nota de los aumentos en el volumen de entradas para futuros proyectos. análisis de la causa raízy evaluó la(s) experiencia(s) de mejora del proceso emprendida(s) durante el sprint.

Resultados

Antes de volverse ágil e implantar Scrum, el centro de llamadas de Intronis recibía el doble de llamadas de clientes de las que podía atender. Seis meses después de implantar Scrum, su capacidad de gestión de llamadas había aumentado en 400%.

Los equipos del centro de llamadas Scrum tenían suficiente exceso de capacidad para convertirse en una segunda fuerza de ventas. Los datos de satisfacción del cliente se dispararon, ya que el equipo llegaba a los clientes de forma proactiva antes de que ellos mismos se pusieran en contacto con ellos.  Además, los miembros del equipo Scrum se mostraron más contentos y comprometidos.

Ya se llamen centros de llamadas, centros de ayuda, centros de servicio o soporte, estos grupos desempeñan un papel fundamental en muchas organizaciones. Cuando se vuelven ágiles y utilizan Scrum, cambian las reglas del juego.

Mejores resultados. A partir de ahora.

Desde las empresas de Fortune 100 hasta las nuevas empresas, Scrum Inc. transforma las empresas en empresas ágiles. Programe una consulta rellenando el siguiente formulario o llámenos al 617-225-4326.