Un proceso de decisión
The Kanso Filter.
Seis preguntas antes de que un cambio se entregue.
Lo aplicamos antes de recomendar cualquier cambio en un equipo de servicio. La mayoría de los cambios que fracasan no lo hacen en el desarrollo. Se entregan sin una respuesta clara a una de estas seis preguntas. El filtro obliga a dar esas respuestas antes de que empiece el trabajo, cuando todavía es barato actuar sobre ellas. Úselo en sus propias decisiones, en las propuestas de proveedores y en las nuestras.
Por qué existe
Empezó como un recuento del trabajo que no llegó a ningún lado.
Seguíamos viendo cómo se entregaban cambios que añadían un flujo de trabajo, una integración, una pantalla, y seis meses después, los números por los que se evaluaba al equipo no se habían movido. El esfuerzo era real. El resultado, no. Así que anotamos las preguntas que, a posteriori, habrían detenido cada uno de esos cambios antes de que nadie los desarrollara. Esa lista es el filtro. Es deliberadamente directo: si un cambio no puede responder estas preguntas, lo honesto es no hacerlo.
Cada pregunta detecta un modo de fallo antes de que se entregue.
01
¿Elimina un paso?
Los pasos son clics, campos de formulario, búsquedas, traspasos y decisiones que el equipo tiene que tomar.
02
¿Mueve una métrica que usted controla?
Tiempo de gestión, esfuerzo del cliente, CSAT, resolución en el primer contacto, valor de vida. Elija la que se usa para evaluar al equipo, no la más fácil de medir.
03
¿Mejora la precisión o la calidad?
Debe ser medible. Nombre la métrica antes del despliegue.
04
¿Minimiza la carga de mantenimiento?
Sopese el mantenimiento continuo, los puntos únicos de fallo y la deuda técnica que el equipo carga después, no solo el tiempo que ahorra.
05
¿La solución nativa supera a la personalizada?
Los roadmaps de las plataformas avanzan más rápido que el código personalizado.
06
¿Puede nombrar la métrica que debería mover, y cómo la medirá?
Nombre la medida y la ventana antes de empezar, para poder saber después si funcionó.
Qué hacer a continuación
Decida en base a la mejora sustancial, no al coste ahorrado.
Un cambio se gana su lugar cuando mueve una métrica que usted controla lo suficiente como para notarlo. El coste ahorrado es un factor, no la prueba. Si no puede nombrar la métrica, el objetivo y la ventana antes de empezar, no podrá saber después si el cambio funcionó, y así es como un cambio falla silenciosamente: nadie estableció la medida que lo habría demostrado. Así que fállo rápido. Elimine la idea débil en la fase de preguntas, donde cuesta una tarde, no después del desarrollo, donde cuesta un trimestre. El objetivo del filtro es invertir esa tarde.
Pruébelo ahora
Puntúe su cambio.
Responda cada pregunta para el cambio que está evaluando. El veredicto se actualiza a medida que avanza. Nada de lo que escriba sale de su navegador.
01
¿Elimina un paso?
02
¿Mueve una métrica que usted controla?
03
¿Mejora la precisión o la calidad?
04
¿Minimiza la carga de mantenimiento?
05
¿La solución nativa supera a la personalizada?
06
¿Puede nombrar la métrica que debería mover, y cómo la medirá?
Veredicto provisional
0 de 6 respondidas afirmativamente
Se ejecuta completamente en su navegador. No vemos sus respuestas ni las almacenamos.
Cómo usarlo
Recorra las seis preguntas en orden. Luego decida.
- Las seis afirmativasSe entrega.
- Cuatro o cincoSe entrega con notas explícitas sobre las carencias.
- Menos de cuatroNo se entrega. El alcance no es el adecuado, o el cambio no generará suficiente valor para justificar el mantenimiento.
Por qué fracasan los cambios
Un cambio rara vez fracasa porque se haya desarrollado mal.
Fracasa porque nadie nombró la métrica que debía mover, por lo que después nadie podía saber si lo había hecho. O porque el mantenimiento superó silenciosamente el valor aportado. O porque la plataforma entregó lo mismo de forma nativa tres meses después y el desarrollo personalizado se convirtió en un pasivo.
La solución no es más disciplina en el desarrollo. Es decidir bien antes de desarrollar. Elija la métrica que controla, acuerde el objetivo y la ventana, y compruebe primero si la solución nativa le lleva la mayor parte del camino. Si un cambio no puede demostrar una mejora sustancial, la decisión correcta suele ser no hacerlo.
Ejemplo práctico
Desplegar IA de auto-etiquetado en Zendesk.
El filtro aplicado, línea a línea, a una decisión real.
| # | Pregunta | Veredicto | Notas |
|---|---|---|---|
| 01 | ¿Elimina un paso? | Sí | Elimina el etiquetado manual en el 80% de los tickets. |
| 02 | ¿Mueve una métrica que usted controla? | Sí | Un enrutamiento más rápido reduce el tiempo hasta la primera respuesta; ~45 seg × 30.000 tickets/mes = 375 horas devueltas a la cola. |
| 03 | ¿Mejora la precisión? | Tal vez | Necesita comparación con la línea base antes de la puesta en producción. |
| 04 | ¿Minimiza la carga de mantenimiento? | Tal vez | Reentrenamiento trimestral del modelo (pequeño), sin un nuevo punto único de fallo, pero debe ganarse su lugar. |
| 05 | ¿La solución nativa supera a la personalizada? | Tal vez | Compruebe primero el auto-etiquetado nativo de Zendesk. |
| 06 | ¿Puede nombrar la métrica que debería mover, y cómo la medirá? | Sí | La precisión de etiquetado y enrutamiento se nombra desde el inicio, y se rastrea semanalmente frente a una línea base. |
| Resultado del filtro | Se entrega si la solución nativa no cubre la taxonomía. En caso contrario, use la nativa. | ||
¿Tiene un cambio que está evaluando?
Financiamos un número limitado de evaluaciones de Maturity Mapping para equipos con un problema de servicio activo. Solicítelo indicando la métrica que quiere mejorar, y si no encaja, se lo diremos.