Cómo gestionar solicitudes de soporte que llegan por WhatsApp y Teams

Son las once de la mañana y el chat de WhatsApp de la mesa de ayuda ya acumula más de 60 mensajes nuevos. Hay una foto borrosa de una impresora con una luz roja, un audio de 40 segundos pidiendo acceso a un sistema, tres personas preguntando si alguien vio su mensaje de ayer y, entre todo eso, un aviso de que el sistema de facturación dejó de funcionar. Nadie lo marca como urgente ni hay una forma clara de priorizarlo. El mensaje sigue bajando entre los demás y recién dos horas después, cuando Finanzas escala el problema directamente al gerente de TI, alguien se da cuenta de lo que pasó.

Esta escena se repite todos los días en empresas medianas y grandes de Chile. Equipos de TI, RRHH y operaciones atienden cientos de solicitudes por WhatsApp o Teams, aunque esos canales nunca fueron pensados para funcionar como una mesa de ayuda. No tienen una cola de tickets, prioridades, responsables ni una forma sencilla de saber qué solicitudes siguen pendientes.

El problema tampoco nació de una mala decisión. Estos canales se fueron convirtiendo en soporte de manera bastante natural. Son rápidos, todos ya los tienen instalados y, para quien necesita ayuda, escribir un mensaje resulta mucho más fácil que abrir un ticket o completar un formulario. El problema aparece cuando ese mismo canal que funcionaba bien con pocas solicitudes empieza a recibir decenas o cientos al día. Ahí, lo que antes era práctico empieza a convertirse en desorden.

Por qué el chat reemplazó al ticket, y por qué eso ya no alcanza

Un estudio del Instituto de Seguridad del Trabajo de Chile, realizado sobre una organización de más de 1.170 trabajadores del rubro salud, encontró que un 65% de los encuestados reconoce que WhatsApp le genera exceso de información en el trabajo. El mismo estudio muestra que, si bien un 71,8% coincide en que la aplicación permite resolver problemas con mayor rapidez, un 26,3% está en desacuerdo con esa misma afirmación, lo que confirma algo que cualquier jefe de soporte interno intuye a diario, la experiencia con estos canales es dispareja y depende enteramente de si la persona alcanzó a leer el mensaje a tiempo.

Esa dispersión es el problema de fondo. Un ticket de soporte interno no debería depender de si alguien vio la notificación antes de que otros 15 mensajes la empujaran hacia arriba. Cuando la mesa de ayuda opera sobre chats, cada solicitud vive y muere según el orden en que llegó, no según su urgencia real. Un problema de acceso menor puede quedar arriba en la pantalla mientras una caída de sistema queda enterrada, simplemente porque el primero se escribió cinco minutos después.

El costo real de un ticket que nadie clasificó

La falta de estructura no es solo una molestia de organización, tiene un costo medible en tiempo. Un análisis de Jitbit sobre 1.000 empresas encontró que el tiempo promedio de resolución de un ticket de soporte es de 82 horas, es decir, tres días y diez horas. El mismo estudio calcula que un técnico de soporte gestiona en promedio 21 tickets al día cuando trabaja de forma manual, sin apoyo de clasificación automática.

Esos números explican por qué, en la práctica, cuando una mesa de ayuda interna recibe su carga diaria repartida entre WhatsApp, Teams y quizás también correo, la capacidad del equipo se agota rápido y las solicitudes más simples terminan compitiendo por atención con las más críticas. No hay forma de ver de un vistazo cuántas solicitudes están abiertas, cuántas llevan más de un día sin respuesta o cuál área concentra más carga. El jefe de soporte se entera de que algo se atrasó cuando el afectado ya escaló por otro canal, casi siempre molesto y casi siempre con razón.

Y el desgaste no termina ahí. Cuando un trabajador no recibe respuesta a tiempo, la reacción natural es reenviar el mensaje, escribirle directamente a otra persona del equipo o abrir una segunda conversación paralela sobre el mismo problema. Eso multiplica el volumen de mensajes sin multiplicar la capacidad de resolverlos, y termina alimentando el mismo desorden que originó el atraso.

De chats sueltos a tickets estructurados

El Agente de Ticketing de AgentLayer convierte los mensajes que llegan por WhatsApp o Teams en tickets estructurados, clasificados y priorizados de forma automática. Cada solicitud que hoy se pierde en un hilo de chat pasa a tener un registro propio, con la urgencia y el área correspondiente asignadas desde el primer momento, sin que un supervisor tenga que leer manualmente cada mensaje para decidir qué es crítico y qué puede esperar.

Esto cambia la forma en que trabaja el equipo de soporte. En lugar de revisar un chat que crece sin pausa, el jefe de soporte interno ve una cola de solicitudes ya ordenada por prioridad, con trazabilidad de cuánto tiempo lleva abierta cada una y quién es responsable de resolverla. La persona que reportó el problema, además, deja de tener que insistir para saber si su mensaje llegó a alguien, porque el ticket existe de forma independiente al chat donde partió.

Una parte del problema de clasificación tiene que ver también con saber a quién le corresponde cada solicitud, algo que en muchas empresas depende del organigrama informal que cada trabajador antiguo tiene en la cabeza. Cuando esa información vive dispersa entre manuales desactualizados y el conocimiento de unas pocas personas, un agente como Atlas complementa el trabajo del Agente de Ticketing, porque mantiene accesible y actualizado el conocimiento interno sobre roles, procesos y responsables que permite enrutar cada solicitud a quien realmente puede resolverla.

Ordenar antes de escalar

Ningún equipo de soporte interno necesita prometer resultados que no puede sostener, y tampoco es realista pensar que un canal de mensajería vaya a desaparecer, porque los trabajadores seguirán prefiriendo escribir por WhatsApp o Teams antes que entrar a un sistema aparte. La diferencia está en lo que ocurre detrás de ese mensaje, si se transforma en una solicitud con dueño, plazo y prioridad, o si simplemente queda flotando entre las decenas de conversaciones del día.

AgentLayer trabaja bajo una metodología de piloto a producción en 30 días, pensada justamente para que un equipo de soporte interno pueda probar este tipo de automatización sobre su propio volumen real de mensajes, antes de comprometerse a un cambio mayor. Para un jefe de soporte interno o un gerente de TI que hoy revisa 40 chats abiertos y no sabe cuál de ellos esconde el próximo problema urgente, esa prueba acotada suele ser el primer paso más razonable.