Call centers con buena experiencia de cliente se basan en procesos en continua adaptación - cortesía de Pixabay |
Una pila de producto de procesos consiste en elementos que hagan evolucionar el proceso, estos elementos pueden consistir en deficiencias y mejoras. Los elementos más grandes de la pila son los problemas que hay detrás de deficiencias y mejoras, son puntos de relación donde a nuestros clientes les "duele" o no les es agradable pasar, se los conoce como "pain points". La estructura de tipos de elementos de la pila propuesta es la siguiente:
- Tema: Pain points o puntos de dolor de nuestros clientes
- Epic: Causas raíz, cada una de ellas tiene un impacto y valor propio
- Historias de usuario: Soluciones a las causas raíz que sean implementables en los procesos
Historias de usuario que tratan pain points del proceso de facturas |
Una historia de mejora puede tratar de cambiar el texto de una comunicación a nuestro cliente y mejorar la difusión del mensaje del 30% al 70% por ejemplo.
Una historia que trata de resolver una deficiencia puede ser mejorar la claridad y transparencia en la apertura de la incidencia, como por ejemplo informar al cliente del numero de incidencia.
En una pila de procesos hay más historias exploratorias que en una pila de un producto de software, dado que sus elementos influyen directamente en la relación con los clientes, es clave validar toda idea e iniciativa de forma rápida antes de implementarla. De la misma manera los criterios de aceptación son más bien criterios de éxito, hay que encontrar el proceso idóneo para gran parte de nuestros clientes, es imposible que lo vaya a ser para todos, quizá 3 de cada 4 sea un objetivo excelente y factible.
Equipo de procesos ante su pila de producto |
Entre estos especialistas puede haber expertos en los procesos existentes, frontliners que son comerciales y profesionales de los call centers para proporcionar feedback de primera mano sobre el funcionamiento de las mejoras de procesos, su facilidad de uso y el propio feedback de los clientes, y dado que probablemente la mitad de procesos pasen por modificaciones en las aplicaciones de software, alguien de TI para realizar una evaluación preliminar de posibles soluciones técnicas e impactos en sistemas.
Mi experiencia con estos equipos no constructores de software ha sido sorprendente, son menos binarios que los equipos de TI y la consolidación de Scrum en su forma de trabajar ocurre muy rápidamente, suelen decir que Scrum es una forma natural de trabajar.
Un miembro de un equipo de procesos me dijo que deberían de hacer sprints de una semana, ya que de esta forma el ciclo de feedback del cliente seria más corto y podrían encontrar las mejoras en los procesos de forma más rápida... ¡en Servicio al Cliente habían interiorizado los valores y prácticas de Scrum!
Este post también lo publiqué en el blog de Scrum Manager, y también "apareció" en el blog de PMIdeas, hecho que me halaga ya que muestra la repercusión de mis posts. :-D
Iba a saltarte al cuello al leer el título, pero al leerlo he cambiado de idea. Veo que el Scrum no está enfocado a la operación, si no a la propia función. Es decir, ¿Cómo podemos mejorar?.
ResponderEliminarPorque intentar gestionar una operación con Scrum me parece un error.
Tal y como lo planteas, un aplauso!
Si, cuando en enero me dijeron que primero formaría y luego acompañaría a los equipos de servicio al cliente no sabía si tenia sentido. Luego entendí que se trataba de mejora de procesos, aún sigo con ellos y me esto ha abierto Scrum y Agile a las posibilidades fuera de TI.
EliminarUn abrazo, gracias por escribir,
Alex