Cuando las empresas adquieren herramientas de software ¿qué esperan de ellas? Guiados por el sentido común, podríamos pensar que una herramienta de software debe convertir un pesado proceso manual en otro automatizado y ágil. Como resultado, la información y conocimiento debe ser organizada por bases de datos y debe ser posible realizar búsquedas, hallar y accederla fácilmente.

Imaginemos por ejemplo un sistema para la gestión de relaciones (CRM) y su componente para la gestión de problemas. ¿Qué hacer? Pues bien, eéste puede almacenar casos según los reportan los clientes (titulo, descripción, etc.). El sistema asigna automáticamente un número por caso para facilitar las cosas. Se adscribe una prioridad por caso. Los casos son enviados a un sistema de colas o asignados directamente a una persona. Los procesos como la supervisión o instalación también pueden ser incluidos en el sistema.

Entonces, una vez que el sistema ha sido instalado, no habrá más problemas de seguimiento, de hojas Excel, ¡no más confusión!

Pero no nos engañemos. Recuerda la invitación de David Knight a “retar y cuestionar el ‘dar por hecho’ para poder revelar los peligros inmediatos al ‘sentido común’ (el enlace abre un PDF en inglés)”. Las organizaciones no esperan que un sistema para la gestión de problemas o cualquier otro herramienta de software solo automatice los procesos manuales. El fantasma que una solución de software es el héroe que resolverá todos los problemas empresariales es tan fuerte, que la gente olvida los fundamentos del funcionamiento de las maquinas. Como lo dice el poema de Kipling:

But remember, please, the Law by which we live,
We are not built to comprehend a lie,
We can neither love nor pity nor forgive.

Pero recuerda, por favor, la ley por la cual vivimos,
No estamos hechas para comprender la mentira,
No podemos ni amar, ni compadecer, ni perdonar.

Y mientras continuamos imaginando, pensemos en un proveedor de sistemas para la gestión de los recursos humanos (RRHH) que adquiere un sistema CRM, especialmente para facilitar el trabajo de los consultores de servicio al cliente (CSC, por sus siglas en inglés). Un día, Juan un representante de servicio al cliente, recibe una llamada informándole sobre un problema. Juan va directamente al sistema para la gestión de problemas y abre un caso. Al recordar la voz tranquila del cliente, Juan decide que la prioridad del caso es “baja”.

Pero, el teléfono suena otra vez y Juan recibe otra queja de un cliente. Obre otro caso. Durante el mismo día, Juan escucha además sobre problemas de instalación e integración que están enfrentando los clientes cuando implementan la última versión del sistema. El nuevo sistema CRM acumula más casos sobre problemas de clientes.
Una semana más tarde, el caso con la prioridad más baja no ha sido resuelto y el teléfono continúa sonando.

Los empleados de servicio al cliente están abrumados. No es ningún secreto, pero, ¿podrá una herramienta que da seguimiento a los problemas de apoyo al cliente ayudarle por si sola?

Propongo un flujo que puede complementar el sistema para la gestión de problemas. Sin embargo, estos no son consejos definitivos. Lo que quiero intentar es repensar la manera en que el flujo de trabajo puede acomodar la interacción en constante cambio entre el ser humano y la maquina. Además, debemos reconocer que en un mundo hambriento por atribuir significado a todo, una herramienta de software satisface este propósito primordialmente dentro de los procesos planeados.

Rebobine. Supongamos que el equipo de servicio al cliente diseña un flujo de trabajo flexible para resolver el proceso de gestión de problemas. Este nuevo flujo de trabajo no se enfoca en el sistema para la gestión de problemas y se armoniza con el sistema CRM para apoyar al equipo de servicio al cliente porque tiene sentido.

En este sentido, el equipo pensó que sería útil organizar la lista de problemas por categoría (dígase capacitación, desarrollo, IT, desarrollo de productos, otros). En cuanto entra un problema en el sistema, el representante de servicio al cliente le atribuirá una categoría.

Entonces cuando Juan recibe una llamada informando sobre un problema, este lo entra al sistema y le asigna una categoría. El siguiente paso será que Juan verifique la base de datos de servicio al cliente según la categoría, para ver si la solución ya existe. Si ya existe una solución, Juan puede aplicarla para cerrar el caso. De no ser así, el sistema asignará automáticamente el caso al departamento indicado (según la categoría a la que pertenece).

Para asegurar que el sistema no es sobrecargado sin necesidad, un representante de servicio al cliente con experiencia verifica que cada caso recibe el nivel apropiado de prioridad y que es asignado a la categoría apropiada. Esta persona deberá determinar la latencia de la respuesta. Por ejemplo, un día para los casos de mayor prioridad, dos días para una prioridad media y cuatro días para la prioridad baja.

Otra decisión importante que tomó el equipo fue la de establecer recordatorios antes de la fecha límite. Si no se cumple con las fechas límites o si el caso excede la capacidad del presentante de servicio al cliente para resolverlo, este puede ser automáticamente asignado a un supervisor. Esta persona puede bien sea formar un grupo para resolver el problema o hacerlo por sí misma.

Una vez resuelto el problema, se cierra el caso. Además, el caso puede ser transferido a una base de conocimientos una vez ha sido resuelto y editado.

Finalmente, Juan y sus colegas tienen mejores facultades con la herramienta para la gestión de problemas y su integración dentro del flujo de trabajo, en lugar de confiar en que esta realice el trabajo por sí misma.

Traducido del inglés por Claudia Gómez