Gestión de incidencias en una empresa: pasos y ejemplos

La gestión de incidencias en una empresa es el proceso que registra cada falla que interrumpe o empeora un servicio, le asigna un responsable y una prioridad, avisa a los afectados y la sigue hasta que el servicio vuelve a funcionar. Vale para el correo que deja de llegar, la caja que no emite comprobantes y la plataforma que tus clientes no pueden abrir.

El vocabulario viene de TI. ITIL, el marco de buenas prácticas que hoy publica PeopleCert y que va en su versión 5, define un incidente como una interrupción no planificada de un servicio o una baja en su calidad. Incidencia e incidente se usan como sinónimos. En Recursos Humanos la palabra tiene otro sentido: las ausencias, licencias médicas y horas extra que se cargan en la nómina. Esta guía trata de fallas de servicio.

Una empresa de 30 personas no necesita adoptar ITIL completo ni certificar a nadie para manejar bien sus incidencias. Le hacen falta cuatro palabras con el mismo significado para todos, seis pasos que alguien pueda seguir un lunes a las nueve con el teléfono sonando y un lugar donde quede escrito qué pasó.

Qué es una incidencia y qué no

Separar estas palabras ordena la fila. Si todo entra como “algo con sistemas”, el pedido de acceso a una carpeta que llegó a las 8:55 se atiende antes que el ERP caído que alguien reportó a las 9:00.

De las cuatro palabras de ITIL, problema es la que más se olvida en las empresas chicas. Alguien reinicia el router que se colgó y la incidencia queda resuelta. Que se cuelgue todos los lunes a la misma hora no lo anota nadie, y sin ese registro la causa nunca se busca. Los reclamos tienen su propio proceso, con respuesta formal y a veces plazos legales, descrito en sistema de gestión de reclamos.

El proceso en seis pasos, versión ITIL sin burocracia

1. Detectar y registrar

Una incidencia la avisa un sistema de monitoreo o la avisa una persona. En muchas empresas chicas solo existe la segunda vía, y el primer aviso llega por el canal más informal: un mensaje directo, un comentario en el pasillo, un audio de WhatsApp a quien sepa de sistemas.

La regla del primer paso: todo aviso termina en un ticket, con hora de entrada, quién avisó y qué vio. Las llamadas también. En Melonhelp, los correos y los chats de WhatsApp se vuelven tickets solos; en Slack, un mensaje se vuelve ticket cuando alguien reacciona con 🎟️ o menciona a @Melonhelp (cómo funciona en Slack); y una llamada se carga a mano con el botón Nuevo ticket de la bandeja. Sin registro no hay hora de inicio, y sin hora de inicio nadie sabrá después cuánto duró la falla.

2. Clasificar, priorizar y agrupar

Clasificar es decidir qué tipo de caso es (la tabla de arriba) y a qué área le toca. Priorizar es cruzar el impacto, a cuántas personas afecta, con la urgencia, qué tan rápido empeora si nadie hace nada. La matriz completa, con ejemplos para cada nivel, está en cómo priorizar tickets de soporte.

Agrupar es el paso que más se salta. Cuando se cae algo compartido pueden entrar diez reportes iguales en quince minutos, y cuatro personas terminan investigando lo mismo por separado. Diez reportes de la misma falla son una sola incidencia. Elige el ticket más completo como principal, ponle la prioridad que corresponde a la falla y trabaja solo ahí. En los demás, deja una nota interna con el número del principal.

Melonhelp todavía no fusiona tickets (está en el roadmap), así que esa nota es el vínculo. A diferencia de un duplicado del mismo cliente, que se cierra, aquí no cierres los secundarios: cada uno es una persona distinta que espera respuesta y que al final tiene que recibir el mensaje de cierre. Si un administrador crea un estado propio, como Esperando incidente, en Configuración, Estados y prioridades, con un filtro guardado los separas del resto de la bandeja sin perderlos de vista.

3. Asignar un responsable

Cada incidencia tiene un dueño con nombre y apellido, aunque no sea quien la arregla. Su trabajo es saber en qué está, decidir cuándo escalar y cuidar que se avise a tiempo. En una falla chica, dueño y técnico son la misma persona. En una grande, separarlos evita que el técnico deje de arreglar para contestar mensajes. Si el ticket principal cambia de manos, el historial registra quién lo tuvo.

4. Avisar antes de saber la causa

El primer aviso sale en los primeros 15 minutos, aunque todavía no sepas qué pasó. Lleva tres datos: qué está fallando y desde qué hora, qué puede hacer la persona mientras tanto y a qué hora llega la próxima actualización. Ese tercer dato frena la ola de “¿alguna novedad?”. Después, cumple la hora prometida aunque no haya nada nuevo. Tres textos de ejemplo para una caída del correo:

• Primer aviso. “Desde las 8:40 no estamos recibiendo correos. Ya estamos trabajando en esto. Si necesitas enviarnos algo urgente, escríbenos por este WhatsApp. Próxima actualización: 10:00.”
• Actualización. “Encontramos la causa y estamos aplicando la solución. Calculamos tener el correo funcionando antes de las 12:00. Lo que nos envíes por correo hasta entonces puede rebotar.”
• Cierre. “Desde las 11:30 el correo funciona con normalidad. Si nos escribiste entre las 8:40 y las 11:30 y te llegó un rebote, vuelve a enviarlo. Gracias por la paciencia.”

Para los clientes que escriben está el Aviso general de Melonhelp (Comunicaciones, Respuestas automáticas). Cualquier persona del equipo puede encenderlo sin permisos de administrador, y desde ahí quien escriba recibe el texto una sola vez por ticket, en el canal por el que llegó. Mientras está encendido, MIA y la respuesta de fuera de horario no contestan, y los números y correos que marcaste como del equipo no lo reciben. Todo el equipo ve en la parte superior de Tickets una barra naranja con la hora de activación, el nombre de quien lo encendió y un enlace para apagarlo. Si cambias el texto a mitad de la falla, quien vuelva a escribir recibe la versión nueva aunque ya haya recibido la anterior.

Tiene dos límites. Contesta a quien escribe y no le escribe primero a nadie. En Slack, además, solo actúa sobre mensajes que alguien ya convirtió en ticket. Si atiendes clientes en canales compartidos de Slack, desde Comunicaciones, Anuncios, un solo envío llega a todos los canales que agrupaste (cómo se arma ese grupo está en soporte a clientes por Slack Connect). Hacia adentro de la empresa, un mensaje fijado en el canal general alcanza.

5. Diagnosticar, escalar y buscar una solución temporal

La meta de la gestión de incidencias es que el servicio vuelva, y para eso muchas veces alcanza con una solución temporal: tomar pedidos en una hoja de cálculo mientras el sistema está caído, volver a la versión anterior del software, pasar al enlace de internet de respaldo. La causa de fondo se investiga después, como problema.

Escalar tiene dos direcciones. Hacia quien sabe más (el proveedor del ERP, el técnico de redes, el desarrollador de turno) cuando el primer nivel no encuentra la causa. Hacia arriba, a una gerencia, cuando la falla toca dinero, clientes grandes o datos personales. Fija de antemano cuánto se espera antes de cada escalamiento: si en 30 minutos nadie encontró la causa de una incidencia urgente, entra el siguiente nivel. El set de estados por defecto que ofrece Melonhelp incluye Escalado, que deja a la vista cuáles están en esa situación.

Cada hallazgo va como nota interna en el ticket principal. Esas notas no le llegan a nadie de afuera y quedan con su hora, así que al final son la cronología de la revisión. Si la falla expuso datos personales (una base filtrada, un correo enviado a la lista equivocada), escálala de inmediato a gerencia y a quien te asesore en lo legal: según el país, puede haber obligación de avisar a la autoridad y a las personas afectadas. El panorama por país está en protección de datos en Latinoamérica.

6. Resolver, verificar y cerrar

Antes de dar por resuelta una incidencia, pide a una o dos de las personas que la reportaron que prueben. El técnico que la arregló es el peor testigo. Después, en este orden: apaga el Aviso general si lo encendiste, responde en cada ticket secundario con el mensaje de cierre y cierra el principal con una nota de lo que se hizo. Cada respuesta sale por donde escribió esa persona: el hilo de Slack, el correo o el chat de WhatsApp.

WhatsApp agrega un plazo. Meta permite responder con texto libre durante 24 horas desde el último mensaje del cliente; con esa ventana cerrada, solo se pueden enviar plantillas aprobadas, según la documentación de la Cloud API. Si la falla fue larga, a quien escribió por WhatsApp hace más de 24 horas el cierre le llega como plantilla, y Meta la cobra por mensaje. Deja aprobada desde antes la plantilla de ticket resuelto, en Integraciones, WhatsApp, porque la revisión de Meta puede tardar hasta un día. Los costos por país están en plantillas de WhatsApp y costo por mensaje.

Ejemplos de incidencias por tipo de empresa

La misma lógica de impacto, urgencia y solución temporal, aplicada a siete negocios distintos:

El caso del aire acondicionado muestra por qué impacto y urgencia son ejes separados: a las 15:00 nadie nota nada, y a las 16:00 se apagan los servidores. El del proveedor de internet tiene sus propias reglas, con cortes por zona y reclamos que corren con plazo legal; está desarrollado en atención al cliente para proveedores de internet y cooperativas.

Un caso de punta a punta: el lunes que el correo dejó de llegar

La empresa es inventada y la falla es de las más comunes. Una distribuidora de 90 personas, dos de ellas en TI, atiende a sus clientes por correo y WhatsApp en Melonhelp, y su gente pide ayuda a TI en el canal #ayuda-ti de Slack.

• 8:40. Los correos externos dejan de llegar. Nadie lo nota: el lunes empieza con reuniones.
• 9:02. Un vendedor escribe en #ayuda-ti que un cliente recibió un rebote. En diez minutos hay cuatro mensajes más en el canal y dos clientes preguntan por WhatsApp si llegó su orden de compra.
• 9:10. Camila, de TI, reacciona con 🎟️ al primer mensaje de Slack, lo deja como ticket principal con prioridad Urgente y se lo asigna. En los dos tickets de WhatsApp deja una nota interna con el número del principal y les pone el estado Esperando incidente.
• 9:14. Publica el primer aviso en el canal general de Slack y enciende el Aviso general en Melonhelp con el texto de la plantilla de caída del correo, que invita a reenviar por WhatsApp lo que se haya mandado por correo. A los dos clientes que ya habían escrito les responde ese texto a mano, porque el aviso automático sale cuando alguien escribe después de encenderlo.
• 9:35. Aparece la causa: el dominio venció el sábado y el proveedor lo suspendió el lunes a las 8:40. Con él dejaron de funcionar el correo y la página web. La renovación automática había fallado porque la tarjeta registrada en el proveedor del dominio estaba vencida. Lo anota en el ticket principal.
• 9:50. Escalamiento hacia arriba: solo la gerente de finanzas tiene una tarjeta corporativa a mano. Paga, el proveedor confirma la renovación y advierte que los registros pueden tardar horas en propagarse.
• 10:00. Actualización a la hora prometida: causa encontrada, solución aplicada, correo funcionando antes del mediodía.
• 11:30. Llegan los primeros correos. Camila pide a dos vendedores que se escriban desde una cuenta externa. Funciona.
• 11:45. Apaga el Aviso general, responde en cada ticket con el mensaje de cierre (sale al hilo de Slack o al chat de WhatsApp de cada uno) y cierra el principal.
• Jueves. Revisión de media hora, con tres acciones: una lista de todo lo que vence (dominios, certificados, licencias) con dos responsables por fila, una tarjeta corporativa para los pagos de TI y un recordatorio 30 días antes de cada vencimiento.

La incidencia duró poco más de tres horas, desde la primera falla hasta el cierre. El problema de fondo, que nadie sabía qué vencía ni cuándo, se resolvió el jueves, y esa acción es la que evita la próxima caída.

Incidente mayor: cuándo cambia el modo

Un incidente mayor afecta a toda la empresa o a muchos clientes a la vez, no tiene solución temporal o pone en juego dinero, datos personales o la reputación. Se maneja en un modo aparte, acordado antes y escrito en una página:

• Cualquiera del equipo puede declararlo sin pedir permiso. Bajar una falsa alarma cuesta poco; declarar tarde, mucho.
• Tres roles: quien coordina y no toca nada técnico, quien comunica (escribe los avisos y le responde a la gerencia) y quienes resuelven.
• Un solo lugar para coordinar, como un canal de Slack con la fecha en el nombre, separado del canal donde llegan los pedidos.
• Actualizaciones a hora fija, cada 30 o 60 minutos según la gravedad, aunque no haya novedades.
• Revisión obligatoria dentro de la semana.

En una empresa de 20 personas, quien coordina y quien comunica pueden ser la misma persona. Alguien tiene que mirar el conjunto mientras los demás arreglan; si todos están dentro del servidor, nadie le avisa al gerente comercial que tiene una presentación con un cliente a las 11.

Después del cierre: revisión y gestión de problemas

La revisión se hace dentro de la semana, dura media hora y no busca culpables. Si la conclusión es que Pedro se equivocó, la próxima vez Pedro esconderá su error y la próxima falla tardará más en salir a la luz. Cinco apartados alcanzan:

1. 1Cronología. Primera falla, primer reporte, primer aviso, causa encontrada, servicio restablecido, cierre.
2. 2Impacto. Cuántas personas o clientes, cuántos tickets entraron y cuánto duró.
3. 3Causa. La técnica y la de proceso: por qué falló y por qué nadie lo vio venir.
4. 4Qué funcionó y qué no. El aviso salió a tiempo, el escalamiento tardó, faltaba un número de teléfono.
5. 5Acciones. Cada una con dueño y fecha. Una acción sin dueño queda en buena intención.

La cronología sale de las notas del ticket principal. Si conectaste Claude a Melonhelp por MCP, puedes pedirle que lea ese ticket y sus comentarios y arme la línea de tiempo; el conector es de solo lectura, así que no cambia nada (cómo conectarlo).

Cuando la misma incidencia aparece tres veces en un mes, ábrela como problema: un ticket aparte, sin la urgencia de la falla, con alguien a cargo de encontrar la causa. Mientras no haya solución definitiva, escribe la solución temporal como Plantilla de respuesta, en Configuración, para que cualquiera del equipo responda lo mismo. ITIL llama error conocido a ese problema con causa o solución temporal documentada que todavía no tiene arreglo de fondo. Si usas MIA, suma la solución temporal también al conocimiento del agente en Melonhelp Agents y la IA podrá darla sola la próxima vez.

Para saber si la gestión mejora mes a mes, mira cuatro números:

• Tiempo hasta el primer aviso. Desde el primer reporte hasta que los afectados saben que alguien lo está viendo.
• Tiempo de resolución. Desde el primer reporte hasta que el servicio vuelve. Usa la mediana: una sola caída de un día desfigura el promedio del mes.
• Incidencias repetidas. Cuántas tuvieron una causa que ya conocías.
• Tickets por incidencia. Cuántos reportes generó cada falla. Si baja con el tiempo, tus avisos están llegando antes.

En Melonhelp, los reportes del plan Equipo muestran el tiempo medio de primera respuesta y de resolución, el cumplimiento del SLA y los tickets por canal, categoría, equipo y hora, con exportación a CSV y Excel. En la tendencia diaria, el día de una incidencia grande se ve como un salto de tickets creados. Cómo fijar los plazos que vas a medir está en cómo medir el SLA de soporte.

Dónde encaja un sistema de tickets, y dónde no

Un sistema de tickets hace bien esta parte:

• Que ningún reporte se pierda, llegue por correo, Slack, WhatsApp o teléfono.
• Un responsable, una prioridad y un plazo por caso, con el reloj del SLA corriendo en horario laboral.
• Responderle a cada afectado por su canal y dejar la historia escrita.
• Medir cuántas incidencias hubo, de qué tipo y cuánto tardaron.

Y esta otra necesita herramientas distintas:

• Detectar la falla antes que tus usuarios. Eso lo hace un sistema de monitoreo.
• Despertar de madrugada al técnico de guardia con llamadas y escalamientos automáticos.
• Publicar una página de estado del servicio.
• Gestionar cambios con aprobaciones, inventario de equipos o una base de configuración (CMDB).

Melonhelp Tickets cubre la primera lista (el SLA y los reportes, desde el plan Equipo) y nada de la segunda. Tampoco fusiona tickets ni tiene etiquetas libres todavía, y la integración con Microsoft Teams está en camino, así que si tu empresa pide ayuda por Teams hoy no te sirve como entrada. Si tu área de TI necesita procesos ITIL formales con inventario y gestión de cambios, una suite ITSM como GLPI, Jira Service Management o Freshservice es mejor opción. La comparación, con precios, está en sistema de tickets para soporte técnico y en alternativas a GLPI; si te enredan los nombres, en help desk vs service desk vs sistema de tickets.

En Melonhelp Tickets la cuenta se mide en tickets, con agentes ilimitados: 250 al mes entran en Esencial, de US$29 al mes, y 1.000 en Equipo, de US$70 al mes, que agrega SLA y reportes (precios). La prueba de 14 días no pide tarjeta, y plan gratis no hay. MIA, la IA que responde dentro de Tickets, cuesta US$79 al mes, sin cargo por resolución, y necesita un plan de Melonhelp Agents, que a diferencia de Tickets sí tiene versión Free. Durante un Aviso general MIA no responde, así que no improvisa explicaciones sobre una falla que todavía nadie entiende.

Preguntas frecuentes