Enrutamiento de tickets en el CRM: cómo automatizar quién atiende qué

Fin de la tarde en una tienda a 300 km de la capital, y el POS de la caja 2 se apaga. No enciende más. La fila pasa a andar en una sola caja, los clientes ven la fila creciendo y se van, el impacto financiero es inmediato. La gerente registra el ticket en el portal de soporte del CSC (Centro de Servicios Compartidos), y la pregunta que decide el resto de la semana de esa tienda es: ¿quién va hasta allá a arreglarlo, y en cuánto tiempo?

La respuesta no era obvia, ni inmediata. El mantenimiento de TI de las tiendas estaba dividido entre tres empresas tercerizadas, cada una responsable de ciertos equipos en ciertas tiendas. Mandar el ticket a la empresa equivocada significaba perder un día entero para escuchar "eso no es con nosotros". Y todavía estaba el reloj: el contrato preveía plazos distintos según la distancia de la tienda hasta la capital. Te equivocas en eso y o le cobran al proveedor un SLA que nunca firmó, o la tienda espera tres días por un arreglo de ocho horas. Y mientras la información correcta no llega al equipo correcto, el cliente sigue mal atendido y la tienda sufre los impactos financieros.

Alguien tenía que tomar esa decisión para cada ticket. Y eran miles de tickets.

Ya presencié esto algunas veces, esa tienda de tu barrio donde siempre sacas del refrigerador un agua, un jugo. Un buen día el refrigerador deja de funcionar y desistes de la compra porque el agua no está fría. En mi caso, fueron seis meses viendo ese refrigerador descompuesto, y obviamente mi hábito cambió y nunca más compré ahí, incluso después de que finalmente lo arreglaron.

Qué es el enrutamiento de tickets

Ese acto de decidir el destino de cada ticket tiene nombre: enrutamiento de tickets. Es la etapa entre el cliente apretar "enviar" y el ticket aparecer en la fila de quien lo resuelve. Todo CRM hace alguna versión de eso, desde el help desk de la panadería hasta el contact center del banco.

En una operación pequeña, el enrutamiento es una persona. Ya fueron tantas visitas a clientes que esa escena ya me resulta común. El supervisor abre la fila en la mañana, le echa un ojo a cada ticket y reparte. Y está todo bien: para veinte tickets por día, automatizar eso está lejos de ser una prioridad. La vara cambia cuando el volumen crece. Con miles de tickets por día, repartir la fila se vuelve un empleo de tiempo completo, y de los malos: repetitivo, aburrido, de esos que hacen al ciudadano repensar cuál es el sentido de la vida. Una persona cansada manda el ticket del POS a la empresa de los monitores, se olvida de la prioridad, le aplica el plazo de la capital a una tienda del interior. No por incompetencia. Por ser humana, a las cinco de la tarde, en el ticket número ochocientos. (cuando lo aplica, ya que hacer el tracking de SLA sin un CRM es algo que exige cierta creatividad con hojas de cálculo)

Mil tiendas, tres proveedores, diez equipos

El caso que me enseñó el tamaño de este problema fue el de una cadena minorista con más de mil tiendas por todo Brasil. Diez tipos de equipo de TI por tienda: monitor, desktop, POS, impresora fiscal, lector de código de barras, y así. Tres proveedores dividiendo el mantenimiento de todo eso.

Ahí viene el detalle que cambia el juego: el proveedor correcto no dependía solo del equipo. Dependía del equipo y de la tienda. El mismo POS era atendido por una empresa en una región y por otra empresa en otra, según el contrato de cada proveedor. Si la regla fuera solo por equipo, una tabla de diez filas pegada en la pared resolvía. Con tienda y equipo juntos, la cuenta cambia: mil tiendas por diez equipos son diez mil combinaciones, cada una con un dueño.

Y encima de todo eso, el SLA. El contrato tenía tres franjas de plazo según la distancia a la capital: la tienda en la región metropolitana tenía un plazo, la tienda hasta 100 km tenía otro, y arriba de eso un tercero, porque hay arreglo que empieza con un técnico agarrando carretera. Nadie enruta eso de memoria. O mejor dicho: alguien lo enrutaba, y esa persona ya no daba abasto. La empresa contrató el CRM, pero sin la configuración adecuada, lo que antes se hacía en una hoja de cálculo ahora era una secuencia de clics en la interfaz del agente.

La matriz de proveedores

La parte buena: el cliente ya sabía responder quién atiende qué. La respuesta existía, viva y actualizada, en una hoja de cálculo. Cada fila decía: esta tienda, este equipo, este proveedor, este SLA.

En la reunión de discovery quedó claro cuál era el escenario. Los datos y los procesos ya estaban definidos, faltaba sacar la ejecución manual de ese enrutamiento para que la operación fuera escalable.

Lo que hicimos fue integrar esa hoja de cálculo con el CRM. Fue ingerida como un objeto personalizado, que es el nombre que los CRM le dan a una tabla tuya viviendo dentro del sistema: defines las columnas, cargas las filas y, lo más importante, las automatizaciones pueden consultarla. Le empezamos a decir matriz de proveedores, y se volvió la fuente de la verdad del enrutamiento entero.

Nada exótico: cuatro columnas y diez mil filas, ahora en un lugar donde la automatización alcanza.

La automatización (y el formulario que pregunta solo lo esencial)

Ahora el camino del ticket. La persona de la tienda entra al portal de soporte, que solo funciona con la sesión iniciada. Y aquí entra una decisión de diseño que rinde más de lo que parece: el formulario no pregunta en qué tienda está. No hace falta. El CRM tiene la función de organizaciones, donde cada usuario pertenece a una, y en nuestro diseño cada organización era una tienda. El ticket ya nace sabiendo de dónde vino. Un formulario bueno no pregunta lo que el sistema ya sabe: nombre de la tienda, dirección, teléfono, ID fiscal, todo eso ya vive en el registro de la organización. A la persona le quedó elegir el equipo en un desplegable de diez opciones y describir el problema.

En el momento en que el ticket se crea, la automatización entra en acción. Lee los dos campos que importan, tienda y equipo, y busca en la matriz la fila correspondiente. ¿La encontró? Hace dos cosas: asigna el ticket al grupo del proveedor de esa fila y aplica el SLA de esa fila. Los técnicos de los tres proveedores trabajaban como agentes dentro del CRM del cliente, cada empresa con su grupo, así que enrutar era entregar el ticket directo en la fila de quien lo resuelve, con el plazo de SLA ya corriendo y visible para todo el mundo. Del envío del formulario hasta que el ticket cae en la fila correcta: menos de un segundo, sin pasar por ninguna mano.

Cuando la matriz no tiene respuesta

¿Y cuando la búsqueda vuelve vacía? Pasa. El caso clásico era el equipo fuera de la lista: no todos los equipos de la tienda estaban en el contrato, solo los principales. Entonces cuando alguien abre un ticket por algo como un problema en el sensor de apertura de la puerta, la automatización no tiene cómo adivinar al dueño.

Para esos casos existía una fila de triage. El ticket sin coincidencia caía ahí, y el CSC del cliente, el centro de servicios compartidos, miraba caso por caso y decidía el destino a mano, cotizando con otros proveedores. Así el equipo del CSC gastaba atención solo en los tickets que de verdad pedían criterio, en vez de tener que actuar en los otros miles.

Quién cuida la matriz después

El enrutamiento automático tiene una dependencia que nadie puede olvidar: la matriz necesita acompañar al contrato. Tienda nueva, proveedor cambiando de región, franja de SLA renegociada: si la hoja de cálculo cambió y el objeto personalizado no, la automatización sigue enrutando, con toda la confianza, al lugar equivocado.

En nuestro caso los cambios eran raros, cosa de algunas veces por año, y el proceso siguió siendo el mismo del primer día: el cliente actualizaba la hoja de cálculo y nosotros la ingeríamos de nuevo. Simple y suficiente. Para una operación que toca las reglas todas las semanas yo recomendaría otra cosa: una aplicación dedicada, con una pantalla propia para editar las reglas directo, sin hoja de cálculo en el medio. Y existe un punto intermedio, que ya armamos para clientes con una necesidad parecida y sin ganas de invertir en la pantalla: un script que lee el Excel y actualiza el objeto personalizado por la API. La hoja de cálculo sigue siendo la fuente de la verdad, en el formato que el equipo de contratos ya domina, y nadie edita diez mil registros a mano.

Lo que cambió

Una de las cosas más gratificantes en la vida de un consultor es ver la sonrisa del equipo de soporte después de una automatización hecha con éxito. El tiempo entre abrir el ticket y que esté en la fila correcta cayó de "cuando alguien lo agarre" a inmediato, en cualquier horario, domingo incluido. El CRM que hasta ese momento era "caro" empezó a justificar su inversión. Esa es mi lucha personal, reducir la entropía en el soporte. Como les digo a mis colegas, mientras haya Excel, habrá caos en el mundo.

Al final, todo esto fue una hoja de cálculo, un objeto personalizado y una automatización que lee dos campos. Ninguna inteligencia artificial, ningún proyecto de seis meses. Si tu operación se parece a lo que conté aquí, ven a conversarlo con nosotros en Red Lotus.

Leandro es fundador de Red Lotus Tecnologia, especializada en la implementación, soporte y evolución de Freshdesk para equipos de soporte en Brasil.