Cuando se diseña un proceso, se debe partir siempre del caso más sencillo. Ese caso en el que todo va bien, todo el mundo sabe qué hacer y cuándo. Luego hay que ir añadiendo las diferentes ramificaciones, y los «por si acasos». Pero incluso si añadimos «por si acasos» suele haber una situación que se suele obviar… y esa es cuando el proceso se aplica mal.
Os pongo un ejemplo que tiene que ver con el soporte a usuarios. Imaginemos que tenemos dos aplicaciones para introducir tickets de usuarios ¿Por qué tenemos dos? Por mill motivos que no vienen al caso. Lo importante aquí es que nuestra organización usa una aplicación con su propio flujo de trabajo para cierto tipo de tickets y otra aplicación para otro tipo. Cada una tiene su propio interfaz, su propio equipo de soporte detrás, sus propios KPIs, SLAs y demás.
Cada proceso funciona correctamente y tiene definidos todos esos «por si acasos» en sus propios grupos de trabajo. Ahora bien, ¿qué ocurre cuando un usuario introduce el ticket en la aplicación que no es?
Puede ser que en cada uno de esos flujos haya una categoría para tickets erróneos, con su propio KPI incluso. Ahora bien, si cada proceso funciona bien de manera independiente, lo más normal es que sean ignorantes de la otra aplicación y sus otros usuarios. Después de todo, el objetivo de cada equipo de soporte es tener a sus usuarios contentos. Si un usuario del otro sistema ha venido a nuestra aplicación es su problema, y no tenemos ni que introducirlo en nuestro SLA. Es como si alguien llamara al equipo de soporte de Microsoft pidiendo una pizza: No se le hará ningún caso, se cerrará el ticket directamente y aparecerá en los informes como una llamada a un número equivocado.
Ahora bien, ¿es eso lo que queremos para nuestros usuarios? Si alguien se ha equivocado al contactar lo ideal sería que el primer operador que se de cuenta de ello informara al usuario y le diera indicaciones de dónde debe crear el ticket, o dónde puede obtener más información. Sin embargo eso no forma parte de ningún contrato de servicios, KPIs ni similar. De hecho, cómo mucho vamos a incluir en el contrato un indicador de cuán contentos están nuestros usuarios, pero no de cuán contentos están los que llaman por error… no tiene sentido (casi)
Diseñando una estructura de usuario, si hay varias opciones, ¿qué pasa si un usuario se confunde de camino? Debería estar en los KPI. Y los operadores deberían tener instrucciones claras, e igual hace falta una estructura que redirige al usuario en la dirección correcta.
Esto desde luego requiere un esfuerzo: para empezar obligamos a los diferentes sistemas de soporte a saber que existen otros, y a incluir esa posibilidad en sus contratos e informes. También requiere que haya una pequeña parte de conocimiento en los procesos sobre las otras aplicaciones de soporte, y eso normalmente no hace falta. Además tendríamos que incluir el esfuerzo del posible mantenimiento de ese conocimiento, ya que puede variar a lo largo del tiempo y no podemos hacer responsables al equipo A de que se mantenga al día de la evolución de otros equipos de soporte.
Aquí hay que valorar el esfuerzo que nos supone tener no sólo a nuestros usuarios contentos, si no también a las personas que nos contactan aunque no sean nuestros usuarios. Y eso lo debemos equilibrar con el beneficio que obtenemos de esas personas que no son nuestros usuarios. ¿Es uno de nuestros objetivos el que esas personas estén contentas? ¿Obtenemos algún beneficio con ello?
