El soporte interno que vive en emails, Teams y favores de pasillo

Piensa en cómo gestiona tu empresa las solicitudes internas. Probablemente así: un email a IT pidiendo acceso a una herramienta. Un mensaje suelto de Teams a la persona de RRHH que "siempre responde rápido". Una llamada a mantenimiento porque el aire acondicionado vuelve a fallar. Y un par de favores verbales que nadie apuntó en ningún sitio.

Si una empresa tratara así a sus clientes externos, perdería la cuenta en una semana. Internamente, sin embargo, lo aceptamos como normal.

El problema no es la buena voluntad de la gente, que sobra. El problema es estructural: las solicitudes dependen de la memoria de una persona concreta. Esa persona se va de vacaciones, enferma, cambia de equipo o, simplemente, olvida. Y la solicitud se evapora.

Aquí aparece la pregunta que da título a este artículo: cómo implementar un sistema de ticketing interno con SLA y escalado automático para digitalizar el soporte en tu empresa. No es solo cambiar de herramienta. Es cambiar de cultura operativa.

Qué hace un sistema de ticketing y por qué deja de ser opcional

Un sistema de ticketing centraliza las solicitudes de soporte. Cada petición entra como un ticket con identificador único, responsable, prioridad y trazabilidad completa. Suena básico. Lo es. Y aun así, muchas organizaciones de cien o doscientos empleados siguen tirando de bandeja de entrada compartida.

Lo que aporta el cambio:

• Trazabilidad real. Cada solicitud queda registrada: quién la abrió, cuándo, qué se hizo, quién la cerró. Se acabaron los "yo te lo mandé por email, no sé si te llegó".
• Datos para decidir. Volúmenes por categoría, picos estacionales, departamentos que generan más fricción, técnicos saturados. Información que permite reasignar recursos con criterio, no por intuición.
• Priorización honesta. El ticket más ruidoso deja de ganar. Gana el que tiene más impacto en el negocio.
• Conocimiento que se acumula. Las resoluciones documentadas alimentan una base de conocimiento que reduce el volumen futuro. Lo que se resolvió una vez, se resuelve dos veces más rápido.
• Reparto de carga. Las solicitudes ya no caen siempre sobre la misma persona "accesible". Se distribuyen por reglas.

Diseño del sistema: categorías, prioridades, SLA

Mapea las solicitudes reales, no las teóricas

Antes de tocar ninguna plataforma, siéntate con los equipos que dan soporte y pregunta: ¿qué te piden de verdad? Vas a descubrir que el 80 % del volumen entra en diez o quince categorías recurrentes. Ese es tu árbol de partida.

Un esquema realista para una empresa mediana:

IT y sistemas

• Accesos y permisos (altas, cambios, bajas).
• Hardware (averías, periféricos, renovaciones).
• Software (errores de aplicación, instalaciones, licencias).
• Conectividad (red, VPN, WiFi).
• Seguridad (phishing reportado, incidentes).

Recursos Humanos

• Nómina y beneficios.
• Vacaciones y permisos.
• Trámites administrativos y certificados.

Facilities y administración

• Mantenimiento de oficinas.
• Reserva de espacios.
• Proveedores y suministros.

Una regla práctica sobre las subcategorías: si tu formulario de apertura supera los siete u ocho campos obligatorios, los usuarios huirán al email. La fricción mata la adopción.

Cuatro prioridades, no quince

• Crítica: múltiples usuarios bloqueados o proceso de negocio detenido. Caída del ERP, sistema de facturación inaccesible.
• Alta: un usuario o equipo no puede hacer su trabajo. Existe workaround, pero pobre.
• Media: molestia operativa, no bloqueante. Impresora de planta caída, herramienta secundaria con fallos.
• Baja: consultas, mejoras, peticiones planificables a semanas vista.

SLA: compromisos medibles, no aspiraciones

Los SLA marcan dos tiempos: cuánto tarda el equipo en reconocer el ticket (primera respuesta) y cuánto en cerrarlo (resolución).

Prioridad	Primera respuesta	Resolución
Crítica	15 minutos	4 horas
Alta	1 hora	8 horas
Media	4 horas	24 horas
Baja	8 horas	72 horas

Un detalle que se olvida con frecuencia: cuenta en horario laboral. Un ticket medio creado un viernes a las 17:00 no debería marcar incumplimiento el sábado a las nueve de la mañana. Configura el calendario de servicio antes de activar SLA, o tu informe del primer mes será un desastre artificial.

Escalado automático: el seguro contra los olvidos

El escalado es lo que convierte un ticketing decente en uno fiable. Hay dos tipos.

Por tiempo

El sistema vigila el reloj de cada ticket y actúa antes de que el SLA explote:

• Al 50 %: aviso al agente asignado. "Eh, este se te está enfriando."
• Al 75 %: salto al responsable del equipo. Que reasigne o intervenga.
• Al 100 %: notificación a dirección. El ticket queda marcado como SLA incumplido en los informes mensuales.

Por complejidad

Cuando el agente detecta que el caso le supera, escala manualmente al siguiente nivel. La clave: el historial completo del ticket viaja con él. Nada de "cuéntame otra vez tu problema".

La estructura habitual:

• L1: primer contacto. Resuelve lo rutinario con la base de conocimiento. Accesos básicos, restablecimientos, FAQ.
• L2: técnicos especializados. Diagnóstico, intervención sobre el endpoint, casos no triviales.
• L3: ingeniería de sistemas. Infraestructura, configuraciones avanzadas, cambios en producción.

Si tu L1 resuelve el 65-70 % de los tickets sin escalado, la documentación funciona. Si está por debajo del 40 %, falta formación o falta base de conocimiento. O ambas.

Implementación: elegir plataforma sin enamorarse de ninguna

El mercado tiene opciones para cada tamaño y bolsillo:

• Equipos pequeños: Freshdesk, Zendesk o Jira Service Management en planes de entrada. Cubren ticketing, SLA básico y reglas de automatización sin reventar el presupuesto.
• Medianas: Jira Service Management o ServiceNow en configuraciones estándar. Workflows configurables, integración con Active Directory o Azure AD, reporting decente.
• Grandes con ITIL maduro: ServiceNow, BMC Helix o desarrollos sobre frameworks ITSM. Aquí la decisión depende más del ecosistema previo que del producto en sí.
• Open source: GLPI, osTicket o Zammad. Funcionan bien si tienes equipo técnico para mantenerlos. No son gratis: son "sin licencia".

Configuración mínima viable

Da igual qué plataforma elijas, esto no puede faltar:

Portal de autoservicio. Un único punto de entrada accesible desde el navegador y, mejor aún, integrado en Teams o Slack. Si el usuario tiene que abrir una pestaña nueva, salir de su contexto y recordar una URL, perderás adopción cada semana.

Formularios condicionales. Los campos cambian según la categoría. Un "acceso a herramienta" pide nombre del sistema y justificación. Una "avería de hardware" pide número de inventario y ubicación. No mezcles ambos en un formulario universal.

Asignación automática por reglas. Categoría, ubicación, idioma, departamento del solicitante. El triaje manual es un cuello de botella crónico que se elimina con tres reglas bien escritas.

Notificaciones útiles. El solicitante se entera de cada cambio de estado sin tener que perseguir a nadie. Los agentes reciben la información completa en la notificación, sin tener que entrar al ticket solo para leer el contexto.

Base de conocimiento integrada. Cuando el usuario empieza a escribir su ticket, el sistema le sugiere artículos relacionados. Una parte de los tickets se autorresuelve antes de existir.

Métricas que importan (y que se revisan)

Tener datos no sirve de nada si no los lees. Las que mueven la aguja:

• Volumen por categoría y departamento. Detecta dónde hay fricción crónica.
• Tiempo medio de primera respuesta y de resolución. Las dos, separadas. Confundirlas oculta problemas.
• Tasa de cumplimiento de SLA. Objetivo razonable: por encima del 90 %. Por debajo del 80 %, hay que actuar.
• Tasa de reapertura. Si los tickets vuelven, las resoluciones son superficiales. Síntoma claro de presión por cerrar.
• CSAT. Una pregunta al cerrar. Una. No envíes encuestas de diez ítems a empleados ocupados.
• Resolución en L1 vs. escalado. Termómetro de la madurez del primer nivel.

Revisa estas métricas en un comité mensual de quince minutos. Más tiempo es burocracia. Menos, abandono.

Errores que se ven una y otra vez

• Workflows barrocos desde el día uno. Empieza simple. Añade lógica cuando los datos lo pidan, no antes.
• No vender el sistema internamente. Si los empleados no entienden el beneficio personal, seguirán mandando emails directos. Comunica, forma, repite.
• SLA fantasía. Comprometer tiempos que el equipo no puede cumplir destruye la credibilidad en dos meses. Empieza generoso y aprieta cuando ganes velocidad.
• Métricas que nadie mira. El sistema genera datos. Si nadie los analiza, has comprado un cajón digital.
• Base de conocimiento abandonada. Una KB desactualizada es peor que no tener ninguna. Asigna propietario, marca artículos con fecha de revisión y elimina lo que ya no aplica.

Del email caótico al servicio interno medible

Profesionalizar el soporte interno no es comprar Jira y dar de alta usuarios. Es decidir, como organización, que los empleados merecen el mismo nivel de servicio que los clientes externos. Que las solicitudes no se pierden. Que los plazos se cumplen o se escala. Que el conocimiento se acumula en lugar de evaporarse cuando alguien cambia de empresa.

El retorno aparece en sitios que no esperabas medir: menos reuniones para "ver por dónde va aquello", menos repetición de incidencias idénticas, menos frustración acumulada entre departamentos. Y un equipo de soporte que, por primera vez, puede demostrar con datos lo que hace.

¿Listo para diseñar el tuyo? Hablemos de tu sistema de ticketing interno.