Un sistema de tickets centraliza las solicitudes de soporte en un canal único, con registro, prioridad, plazo y responsable. Elegir mal sale caro: la mayoría de los cambios de herramienta ocurren por falta de visibilidad de SLA y por exceso de clasificación manual, no por falta de funciones.
Cuando un equipo de TI o de soporte evalúa un sistema de tickets, la conversación suele empezar por las funciones y terminar en el precio. Eso invierte el orden correcto. Las funciones que no resuelven un problema concreto de la operación son ruido. El precio de una herramienta que no se adopta es el más caro de todos.
Esta guía presenta los 12 criterios que determinan si un sistema de tickets va a funcionar en una operación real, cómo verificar cada uno durante una demostración y los tres errores más frecuentes que aparecen después de firmar el contrato. Al final hay un checklist descargable para conducir la evaluación con cualquier proveedor.
Qué cambia cuando el ticket deja de entrar por correo
El correo electrónico es el sistema de tickets más usado en América Latina, aunque ningún equipo lo llame así. Las solicitudes llegan a una casilla compartida, alguien las lee, las responde o las reenvía, y el estado de cada una vive en la memoria del agente. Cuando ese agente falta, el estado desaparece. Cuando el volumen crece, la casilla colapsa.
La diferencia entre una casilla compartida y un sistema de tickets no es tecnológica: es de visibilidad y de responsabilidad. En un sistema de tickets, cada solicitud tiene un número, un responsable, una prioridad y un plazo. Esa información es visible para todo el equipo y para quienes supervisan la operación, sin necesidad de preguntar.
Visibilidad del SLA: en una casilla de correo, nadie sabe si una solicitud está dentro o fuera del plazo de respuesta acordado, porque el plazo no está definido ni medido. Un sistema de tickets define ese plazo por tipo de solicitud y genera una alerta antes de que venza, no después.
Reducción de la clasificación manual: en correo, alguien lee cada mensaje y decide si es urgente, quién lo atiende y en qué categoría va. En un sistema de tickets con reglas de clasificación automática, esa decisión la toma el sistema para los casos predecibles, y el agente interviene solo en los que requieren criterio.
Trazabilidad completa: cada acción sobre un ticket queda registrada: quién lo abrió, quién lo tomó, qué cambios se hicieron, cuándo se cerró. Eso es lo que hace posible auditar la operación, detectar patrones de error y mejorar con datos en lugar de con suposiciones.
El momento en que un equipo necesita un sistema de tickets no está marcado por el tamaño, sino por la señal: cuando las solicitudes se pierden, cuando el cliente pregunta por algo que nadie recuerda haber recibido, o cuando el tiempo de resolución no se puede medir porque no está registrado.
Los 12 criterios de evaluación
La tabla siguiente está diseñada para usarse durante una demostración. Cada criterio incluye la pregunta o prueba concreta que permite verificarlo en vivo, no en una presentación de slides. Un proveedor que no puede demostrar un criterio durante la demo probablemente no puede cumplirlo en producción.
| Criterio | Por qué importa | Cómo verificarlo en la demo |
|---|---|---|
| 1. Canal único de ingreso | Evita que las solicitudes se pierdan en correo, chat o llamadas sin registro. | Pida que le muestren cómo llega un ticket desde correo y desde formulario web. Verifique que ambos quedan en la misma cola. |
| 2. Colas y categorías configurables | Permite separar TI de RR. HH., urgente de normal, sin necesidad de un administrador para cada cambio. | Pida que creen una cola nueva durante la demo. Si requiere soporte técnico del proveedor, es un signo de alerta. |
| 3. SLA por tipo de solicitud | Sin SLA configurable, el sistema no puede decirle si está cumpliendo o no. | Pregunte: ¿puedo definir tiempos distintos para incidentes críticos y solicitudes de rutina? ¿Se genera una alerta antes de vencer? |
| 4. Escalamiento automático | Un ticket que vence sin respuesta tiene que moverse solo al siguiente nivel; no puede depender de que alguien lo note. | Simule un ticket que vence. Verifique que la escalada ocurre sin intervención manual y que queda registrada en el historial. |
| 5. Portal de autoservicio | Reduce el volumen de tickets repetitivos y el tiempo de primer contacto. | Navegue el portal como si fuera un usuario final. ¿Se entiende sin capacitación? ¿Muestra el estado del ticket en curso? |
| 6. Base de conocimiento integrada | Los agentes resuelven más rápido y los usuarios se autoatienden si el conocimiento está donde se necesita. | Pida que le muestren cómo se vincula un artículo de conocimiento a un tipo de ticket y cómo lo ve el usuario final. |
| 7. Reportes de volumen y cumplimiento de SLA | Sin datos, no hay mejora. El reporte mínimo es: tickets abiertos, cerrados, tiempo promedio y % de SLA cumplido. | Pregunte: ¿puedo exportar esto? ¿Puedo programar un reporte semanal por correo sin intervención técnica? |
| 8. Integraciones con el ecosistema existente | Un sistema aislado duplica el trabajo. Las integraciones más frecuentes son directorio activo, correo y monitoreo. | Lleve una lista de los sistemas que ya usa. Pida que confirmen cuáles tienen integración nativa y cuáles requieren desarrollo. |
| 9. Control de acceso por rol | El agente de nivel 1 no debería ver tickets de RR. HH. ni cerrar incidentes críticos sin aprobación. | Pida que le muestren la configuración de roles. Verifique que los permisos son granulares, no solo «admin» o «usuario». |
| 10. Historial y trazabilidad completa | Cada acción sobre un ticket debe quedar registrada: quién la hizo, cuándo y qué cambió. | Abra un ticket de prueba, haga varios cambios y revise el log. El historial debe ser inmutable y exportable. |
| 11. Soporte local y documentación en español | Un SLA de soporte del proveedor en inglés y en un huso horario distante se convierte en horas de equipo interno absorbidas. | Pregunte: ¿tienen soporte en español? ¿En qué horario? ¿Cuál es el SLA de respuesta para incidentes críticos de la plataforma? |
| 12. Modelo de licencia y costo de salida | Un modelo SaaS con contrato anual puede tener un costo de salida alto si los datos no son exportables o la migración es compleja. | Pregunte: ¿puedo exportar todos los tickets y adjuntos si decido cambiar? ¿En qué formato? ¿Hay costo de migración? |
Imprima o descargue esta tabla antes de su próxima demostración. Los criterios 3, 4 y 7 son los que más frecuentemente quedan sin verificar y son los que generan los cambios de herramienta más costosos.
Tres errores que aparecen después de contratar
Error 1: implementar demasiadas colas desde el inicio. La mayoría de los equipos diseña una estructura de colas que refleja el organigrama de TI, no el flujo real de solicitudes. El resultado es una clasificación compleja que los agentes evitan y los usuarios no entienden. La recomendación es empezar con una cola, medir el volumen por categoría durante 30 días y crear subcolas solo cuando el volumen lo justifique.
Error 2: definir SLAs sin medir primero la capacidad real. Un SLA de dos horas para incidentes críticos que el equipo nunca ha cumplido porque no tiene la capacidad para hacerlo es peor que no tener SLA: genera incumplimiento sistemático y credibilidad negativa. El SLA correcto es el que el equipo puede cumplir con la capacidad actual, con margen para mejorar progresivamente.
Error 3: no comunicar el nuevo canal a los usuarios. La herramienta puede estar perfectamente configurada y los usuarios seguir enviando correos directos a los agentes, que los responden fuera del sistema para no generar fricciones. La adopción del canal único requiere una comunicación explícita y, en muchos casos, el cierre o la redirección automática del canal informal previo.
Cómo saber si su operación ya lo necesita
No hay un umbral de tamaño que determine cuándo un equipo necesita un sistema de tickets. Hay cuatro señales operativas que lo indican con más precisión que cualquier métrica de tamaño.
Señal 1 — Pérdida de trazabilidad: cuando una solicitud se pierde entre correos y nadie puede reconstruir qué pasó con ella, la operación ya necesita un sistema de registro. El correo no guarda estado; solo guarda conversaciones.
Señal 2 — Incapacidad de medir el tiempo de resolución: si el equipo no puede responder cuánto tarda en promedio en resolver una solicitud de TI, no tiene los datos mínimos para gestionar la operación. La medición requiere un registro con timestamps, que el correo no provee de forma estructurada.
Señal 3 — Escalamientos que dependen de la memoria del agente: cuando la única forma de que una solicitud llegue al nivel correcto de atención es que alguien recuerde hacerlo, la operación está a un turno de vacaciones o enfermedad de dejar una solicitud crítica sin atender.
Señal 4 — Incapacidad de distinguir urgente de no urgente sin leer cada correo: si la clasificación de prioridad requiere que un agente lea el correo completo y haga una evaluación subjetiva, el tiempo de triage es un costo que se repite en cada solicitud que entra. Un sistema de tickets con reglas de clasificación automática elimina ese costo para los casos predecibles.
Por debajo de cinco personas atendiendo, la señal de trazabilidad no suele aparecer porque la comunicación es directa. La señal de que el equipo ya necesita una herramienta no es el tamaño: es cuándo alguien por primera vez no sabe qué pasó con algo que le pidieron.
Evaluación con Aufiero Informática
Aufiero Informática es distribuidora oficial de OTRS para América Latina. OTRS es un sistema de tickets de código abierto con versión empresarial, disponible en modalidad on-premise y SaaS, con soporte en español y presencia local en la región. Conozca OTRS con Aufiero.
Si su equipo está evaluando sistemas de tickets y desea usar los 12 criterios de esta guía en una demostración real con OTRS, Aufiero puede acompañar la evaluación y responder las preguntas de la tabla en vivo.
Preguntas frecuentes sobre sistemas de tickets
¿Qué es un sistema de tickets?
Es la herramienta que centraliza las solicitudes de soporte en un canal único, con registro, prioridad, plazo y responsable.
¿Cuál es la diferencia con una mesa de servicios?
El sistema es la herramienta; la mesa de servicios es la operación completa, con procesos e indicadores. Un sistema de tickets es el soporte tecnológico de una mesa de servicios, pero la mesa de servicios incluye también las personas, los procesos y los acuerdos de nivel de servicio.
¿Sirve para equipos pequeños?
Por debajo de cinco personas atendiendo normalmente no se justifica. La señal es la pérdida de trazabilidad, no el tamaño. Un equipo de tres personas con trazabilidad perfecta no necesita un sistema de tickets; un equipo de ocho con solicitudes que se pierden, sí.
¿Se puede empezar sin cambiar todo el proceso?
Sí, empezando por una cola y un SLA, y ampliando después. La implementación más exitosa es la que entra en producción con el mínimo de configuración necesaria para resolver el problema principal, y evoluciona con datos reales del uso.
¿Cuánto tarda una implementación?
Depende de la cantidad de colas e integraciones. Una operación con una cola y SLA simple suele entrar en semanas. Una operación con múltiples colas, integraciones con directorio activo y ERP, y flujos de aprobación puede tardar meses. La mayoría de las implementaciones que se extienden más de lo esperado lo hacen por falta de definición previa de los procesos, no por complejidad técnica.
