El problema no es el volumen de tickets, es lo que hay dentro
Cuando una empresa empieza a crecer, el área de soporte rara vez se cae por un solo incidente grande. Se cae despacio, por acumulación. Llega un martes cualquiera y el equipo de sistemas tiene cuarenta solicitudes abiertas: tres cafeteras que no facturan, dos usuarios que olvidaron su contraseña, un vendedor que no encuentra un cliente en el sistema, un jefe que pide un reporte nuevo y —por fin— un error real que necesita revisión técnica.
Todas están en la misma cola. Y como el orden de llegada no distingue entre lo urgente y lo trivial, el error real se atiende después de haber reseteado siete contraseñas.
Ese es el problema que conviene resolver primero. No se trata de responder más rápido ni de contratar a más gente: se trata de que la mitad de esos tickets nunca debería haber llegado a un técnico. Este artículo explica cómo lograrlo con dos piezas que trabajan juntas: una base de conocimiento para autoservicio y una clasificación que separe lo que el sistema rompió de lo que la operación olvidó.
Los cuatro tipos de solicitud que llegan a la misma bandeja
Antes de elegir herramientas, conviene entender qué entra por la puerta. En la práctica, casi todo lo que llega a una mesa de ayuda cae en una de estas cuatro categorías:
1. Duda de uso
«¿Cómo registro una nota de crédito?», «¿dónde cambio el precio de un producto?». La respuesta ya existe; el usuario no sabe dónde está. Es el grupo más numeroso y el más fácil de eliminar con autoservicio.
2. Solicitud de cambio o configuración
«Agrúguenme un usuario», «cámbienme el formato de la factura», «necesito un reporte nuevo». No es una falla: es trabajo planificado que debe pasar por una aprobación, no por la cola de incidentes.
3. Problema de infraestructura o de terceros
El internet del local, la impresora, la firma electrónica que venció, el SRI que no responde. Nadie del equipo de software lo causó, pero igual frena la operación.
4. Error real del sistema
Un comprobante que no cuadra, un saldo que no cierra, una pantalla que devuelve un mensaje de error. Este es el único grupo que necesita análisis técnico profundo, y es el que siempre llega último.
La mayoría de las mesas de ayuda miden su desempeño sin haber separado estos cuatro grupos. El resultado es predecible: el indicador se ve aceptable —se cerraron sesenta tickets— mientras el problema que más costaba dinero llevaba cinco días esperando.
Cómo se ve una base de conocimiento que sí se usa
Casi todos los proveedores de software publican algún manual. Muy pocos logran que los clientes lo consulten antes de escribir. La diferencia rara vez está en la herramienta; está en cómo se escribe y dónde se pone.
Escribir para el problema, no para la pantalla
Un manual se organiza por menús: «Módulo de facturación → pestaña de comprobantes». Un usuario no busca así. Busca «no me deja facturar» o «sale error al guardar la factura». Si los artículos de ayuda están titulados con el lenguaje del usuario y no con el nombre del módulo, el autoservicio empieza a funcionar. Escribir quince artículos con los quince problemas más repetidos del último mes vale más que un manual de doscientas páginas que nadie abre.
Que la respuesta esté donde ocurre el problema
La ayuda escondida en un portal externo se usa poco. La que aparece dentro del sistema, en el momento y en la pantalla donde el usuario se atoró, se usa mucho. Un enlace a la guía justo al lado del campo de facturación resuelve más que una sección entera de preguntas frecuentes en el sitio web.
Medir cuáles artículos realmente evitan tickets
Una base de conocimiento sin medición es un adorno. Los dos datos que importan son simples: cuántas personas consultaron un artículo y cuántas, después de leerlo, abrieron un ticket de todas formas. Los artículos con muchas visitas y muchos tickets detrás están mal escritos. Los de muchas visitas y pocos tickets están haciendo su trabajo.
Actualizarla cuando cambia el sistema
Una ayuda desactualizada es peor que no tener ayuda: genera confianza y luego hace perder tiempo. Cada vez que se publica una versión nueva, los artículos afectados deberían revisarse como parte de la entrega, no como una tarea pendiente de la semana siguiente.
Separa el ticket que nace del sistema del ticket que nace de la operación
Aquí está, en mi experiencia, la decisión con más impacto y la que menos se discute. Muchas empresas mezclan en una sola mesa de ayuda dos conversaciones distintas:
- «El sistema no hace lo que debería» — es una conversación con el proveedor de software.
- «Mi equipo no sabe o no puede hacer algo» — es una conversación interna, con el área de sistemas o con el responsable de proceso.
Cuando las dos se mezclan, el proveedor recibe consultas de uso y el área interna recibe errores técnicos. Nadie tiene la información completa y ambos lados terminan creyendo que el otro es el problema.
El filtro de tres preguntas
Una forma práctica de separarlos, sin discusiones largas, es obligar a que quien reporta responda tres cosas:
- ¿Qué estaba intentando hacer? (el objetivo, no el botón)
- ¿Qué esperaba que pasara y qué pasó? (la diferencia concreta)
- ¿A cuántos usuarios les pasa? (uno solo o todo el equipo)
Con esas tres respuestas, la clasificación es casi automática. Si le pasa a una sola persona en una sola pantalla, es uso o permisos. Si le pasa a todo el equipo en el mismo proceso, es sistema o configuración. Si le pasa a todos y además nada responde, es infraestructura.
Un ticket que llega bien escrito se resuelve en la mitad del tiempo
La mayoría del tiempo perdido en soporte no se gasta resolviendo: se gasta preguntando «¿qué exactamente te sale?», «¿desde cuándo?», «¿me mandas una captura?». Si el formulario de creación del ticket pide esos datos desde el inicio, el técnico empieza a trabajar en el problema y no en la conversación.
Un flujo que ordena la semana del equipo de soporte
Con la base de conocimiento y la clasificación en su lugar, el recorrido de una solicitud queda así:
Paso 1 — Autoservicio antes de abrir el ticket
El usuario escribe su problema en lenguaje natural y el sistema le muestra los artículos relacionados antes de dejarlo crear la solicitud. Una parte de los casos se cierra aquí, sin intervención de nadie.
Paso 2 — Categoría obligatoria al crear
El formulario obliga a elegir entre duda de uso, solicitud de cambio, infraestructura o error del sistema. Nada entra como «otros»: cuando esa opción existe, se lleva el 40% de los tickets y no informa nada.
Paso 3 — Asignación por especialidad, no por turno
Las dudas de uso van a quien conoce el proceso; los errores técnicos, a quien puede revisar el sistema; las solicitudes de cambio, a una bandeja de aprobación con fecha comprometida. Repartir por «quien esté libre» garantiza que el técnico senior resuelva contraseñas.
Paso 4 — Respuesta con algo que el usuario pueda hacer
Cada respuesta debería incluir el estado del ticket y el siguiente paso concreto: qué falta, de quién depende y cuándo se volverá a contactar. «Estamos revisando» sin fecha es lo que hace que el usuario escriba tres veces más.
Paso 5 — Cierre con causa registrada
Al cerrar, se marca la causa real. Ese campo es el que después permite ver que el 30% de los tickets son variantes del mismo problema y justificar una corrección de fondo en lugar de seguir apagando incendios.
Paso 6 — Revisión mensual de los cinco problemas más repetidos
Esos cinco se convierten en artículos de ayuda, en un ajuste de configuración o en un cambio en la capacitación. El objetivo del mes siguiente es que esos cinco dejen de aparecer.
Qué debe tener una herramienta de autoservicio para no quedar en el olvido
Si la empresa va a invertir en una mesa de ayuda, conviene exigirle estas capacidades mínimas:
- Base de conocimiento integrada, no un PDF aparte, con búsqueda por lenguaje natural y sugerencias mientras se escribe el ticket.
- Categorías y subcategorías obligatorias, con campos distintos según la categoría (un error de sistema y una solicitud de usuario no piden los mismos datos).
- Estados visibles para el solicitante: abierto, en revisión, esperando información, resuelto. Sin esto, el usuario no tiene forma de saber si su solicitud existe.
- Historial por usuario y por empresa: saber que este cliente ya reportó tres veces lo mismo cambia el diagnóstico.
- Adjuntos desde el celular: una foto de la pantalla o del comprobante resuelve más rápido que un párrafo de descripción.
- Reportes de causa y reincidencia, no solo de tiempo de respuesta. El tiempo de respuesta dice cuán rápido contestamos; la reincidencia dice si estamos resolviendo.
- Acceso desde el teléfono, porque muchos usuarios reportan justo cuando están frente al problema, lejos de la computadora.
Cómo encaja SIVO Resuelve
SIVO Resuelve es la aplicación de tickets de soporte de SIVO, disponible para Android e iOS. Está pensada justamente para que ninguna solicitud se pierda: cada caso se registra, se asigna automáticamente a un responsable y se sigue paso a paso —creación, asignación, resolución, comunicación con el usuario y cierre— hasta que queda documentado.
Tres cosas de su diseño responden a lo que se planteó en este artículo:
- Clasificación por urgencia e impacto: permite que el equipo maneje su carga de trabajo con criterio en lugar de por orden de llegada.
- Comunicación dentro del ticket: el usuario ve el avance de su caso y el agente puede pedir información adicional sin perder el hilo por correo o WhatsApp.
- Historial y análisis de los tickets cerrados: la base para identificar tendencias, evaluar el desempeño del equipo y corregir procesos —y, sobre todo, para saber qué artículos de ayuda escribir.
Y como forma parte del ecosistema SIVO, el soporte puede mirar el caso sabiendo qué está pasando en el ERP: un ticket sobre un saldo que no cuadra deja de ser una conversación a ciegas.
Qué medir el primer trimestre (y qué no)
Cuando se implanta el autoservicio, casi todo el mundo mira el tiempo de respuesta. Es un buen número, pero incompleto. Estos cuatro dicen más:
- Porcentaje de tickets cerrados sin intervención humana: la medida directa de si la base de conocimiento sirve.
- Reparto por categoría: si más del 50% son dudas de uso, el problema no es el software, es la capacitación.
- Reincidencia sobre el mismo problema en 30 días: el indicador que revela si se está resolviendo o solo cerrando.
- Tickets que llegaron incompletos: si son muchos, el formulario está mal diseñado, no la gente.
Un objetivo razonable para un primer trimestre no es bajar todos los números; es lograr que la cola deje de ser una sola bolsa indiferenciada y que los errores reales del sistema lleguen primero. Con eso solo, el equipo de soporte deja de ser un centro de reclamos y empieza a ser parte de la operación.
Preguntas frecuentes
¿Sirve una base de conocimiento si somos una empresa pequeña?
Sí, y suele rendir más rápido. En una empresa pequeña no hay un área de soporte dedicada: las preguntas llegan al gerente o al contador, que son justamente quienes menos tiempo tienen. Diez artículos bien escritos liberan a esas personas de las consultas repetidas.
¿Quién debe escribir los artículos?
Quien resuelve el problema, no quien administra la herramienta. La mejor práctica es que cada ticket cerrado pueda convertirse en artículo con un botón, y que la revisión sea ligera: se publica y se corrige con el uso. Si hay que pasar por un comité, nadie escribe nunca.
¿El autoservicio reemplaza al soporte humano?
No. Lo reasigna. Elimina las consultas que no necesitaban a una persona y deja el tiempo libre para los casos que sí la necesitan: errores reales, decisiones de configuración y acompañamiento a usuarios nuevos.
¿Cuánto tarda en notarse el efecto?
Entre cuatro y ocho semanas si se empieza por los problemas más repetidos y se mide. Si se empieza escribiendo el manual completo desde cero, es probable que nunca se note.
Por dónde empezar esta semana
No hace falta un proyecto grande. Alcanza con cuatro acciones concretas:
- Revisar los últimos cien tickets y agruparlos en las cuatro categorías.
- Escribir los cinco artículos de ayuda que correspondan a los cinco problemas más repetidos.
- Cambiar el formulario de creación para que pida categoría, objetivo y alcance.
- Definir quién atiende cada categoría y qué plazo tiene cada una.
Con esos cuatro pasos, la siguiente semana de soporte ya se ve distinta. Y el error real que hoy espera cinco días empieza a atenderse el mismo día.
Si quieres ver cómo se ordena esto con una herramienta que ya trae la clasificación, la asignación y el seguimiento incluidos, puedes conocer SIVO Resuelve o revisar cómo se complementa con una mesa de ayuda bien implementada y con tiempos de respuesta que sí se cumplen.