Fecha: 24 de agosto de 2026
Todos los reportes de incidente miden cuándo volvió el servicio.
Ninguno mide cuándo volvió la operación, y ese segundo tramo suele ser más largo y más caro.
Hay un momento, en toda interrupción de comunicaciones, en el que alguien dice «ya está» y el equipo respira.
El servicio responde otra vez. La consola carga. Las llamadas entran. En el reporte, el incidente queda cerrado a esa hora, con su duración exacta y su causa raíz. Técnicamente, terminó.
Operativamente, acaba de empezar la parte difícil.
Lo que no pasó no desapareció
Durante una interrupción parece que todo se detiene. En realidad no se detiene nada: lo único que se detiene es la capacidad de responder.
Las llamadas siguieron entrando aunque nadie las contestara. Los mensajes siguieron llegando aunque nadie los leyera. Los formularios se siguieron enviando. Y las decisiones de los clientes se siguieron tomando, con o sin participación de la empresa.
Cuando el servicio regresa, todo eso sigue ahí. No se resolvió solo, no se canceló y no se distribuyó en el tiempo. Quedó apilado, esperando, y ahora compite por atención con lo que está entrando en este momento.
Esa es la primera característica de la segunda interrupción: no empieza desde cero, empieza desde una deuda.
Y cae sobre el mismo equipo
La segunda característica es más incómoda: no hay refuerzos.
El equipo que atiende la acumulación es el mismo que ya venía ocupado antes de la interrupción, y es el mismo que tiene que seguir atendiendo el flujo normal mientras se pone al día. No hay una segunda plantilla esperando a que ocurra un incidente.
Eso produce un efecto que cualquiera que haya operado un área de atención reconoce: durante los días siguientes a una interrupción, los tiempos de respuesta empeoran para todos, incluidos los clientes que no tuvieron nada que ver con el incidente original.
La interrupción afectó a quienes intentaron comunicarse durante esas horas. La recuperación afecta a todos los demás.
Está repartido en lugares distintos
La tercera característica es la que hace que la recuperación sea lenta incluso cuando el equipo trabaja bien: lo acumulado no está en un solo lugar.
Cuando una interrupción termina, casi todo el mundo revisa lo mismo primero: las llamadas perdidas. Es lo visible, es lo que el sistema de telefonía reporta, y es apenas una parte.
El resto quedó repartido. El chat del sitio web. El correo de contacto. El formulario. El buzón de voz. El mensaje que alguien alcanzó a ver y no a responder. Cada uno con su propio acceso, su propia bandeja y, en muchas organizaciones, su propio responsable.
La pregunta operativa entonces no es cuántos son. Son dos preguntas distintas:
¿Quién revisa cada uno? Y, más difícil: ¿quién decide cuál se atiende primero?
Revisar es trabajo, y se puede repartir. Priorizar es una decisión, y para tomarla hace falta ver todo al mismo tiempo. Sin eso, cada persona prioriza dentro de su propia bandeja y nadie prioriza el conjunto. El cliente que llevaba más tiempo esperando puede ser exactamente el último en recibir respuesta, no por negligencia, sino porque estaba en la bandeja que se revisó al final.
El costo que no aparece en el reporte
Cuando una empresa calcula lo que le costó una interrupción, casi siempre suma el tiempo de servicio caído multiplicado por algún indicador de ingreso.
Ese cálculo deja fuera el tramo más largo.
Hay al menos tres componentes que se pueden estimar con datos que la empresa ya tiene: el margen que la operación habría producido durante el periodo, las horas del equipo que no pudo atender ni vender ni cobrar, y el tiempo adicional que tomó procesar todo lo acumulado cuando el servicio regresó.
Y hay un cuarto que no se puede convertir en una cifra exacta: los clientes que no pudieron comunicarse y cuya decisión posterior nadie observa. No aparecen en ningún reporte porque no hicieron nada visible. Simplemente dejaron de intentar.
Reconocer que ese cuarto componente existe, aunque no se pueda medir, es lo que hace creíbles a los otros tres. Un cálculo que promete precisión sobre lo que no se puede medir se cae en la primera revisión seria.
Qué cambia cuando todo está en un solo lugar
Nada de lo anterior se resuelve con una herramienta. Se resuelve, en buena medida, con una decisión de arquitectura tomada antes: dónde vive la información de las comunicaciones.
Cuando la voz, el chat, el correo y los canales digitales corren sobre plataformas separadas, la recuperación es una suma de revisiones parciales. Cada área ve su parte. Nadie ve el conjunto. Y la priorización, que es la decisión que más impacto tiene sobre el cliente, se toma sin la información necesaria para tomarla bien.
Cuando todo corre sobre la misma plataforma, la operación cambia de forma concreta: hay un solo lugar donde ver qué quedó pendiente, un solo historial por cliente, y una sola cola desde la cual decidir el orden. Deja de ser un trabajo de reconstrucción y pasa a ser un trabajo de priorización.
Issabel reúne las comunicaciones en un solo lugar para que la operación pueda recuperar el control, priorizar lo pendiente y volver a trabajar con orden. Es una plataforma de código abierto, administrable desde un solo lugar, y con la información de todos los canales a la vista al mismo tiempo.
Lo que ninguna plataforma resuelve
Conviene decirlo con claridad, porque este texto podría leerse como el preámbulo de una venta.
Ninguna plataforma evita las interrupciones. Un enlace se puede caer, un proveedor puede fallar, un servidor puede detenerse y una actualización puede salir mal. Eso seguirá ocurriendo, aquí y en cualquier otra arquitectura.
Tampoco resuelve la parte que depende de las personas: que exista un procedimiento escrito, que más de un miembro del equipo sepa administrar la plataforma, que la configuración esté documentada fuera de la memoria de alguien y que haya un responsable claro de decidir el orden de atención cuando el servicio regresa.
Lo que cambia con una plataforma unificada no es si la interrupción ocurre. Es cuánto dura el tramo que viene después, y qué tan a ciegas se atraviesa.
Tres preguntas para esta semana
Si te llevas una sola cosa de este texto, que sean estas tres. Sirven para una conversación de veinte minutos con tu equipo de operación:
1. ¿Cuánto tardó nuestra operación en estar al día después de la última interrupción? No cuánto duró el incidente: cuánto tardamos en responder lo último que había quedado pendiente.
2. ¿Quién revisó cada canal, y en qué orden? Y si nadie lo recuerda con precisión, esa es la respuesta.
3. ¿Alguien decidió el orden de atención, o cada quien priorizó dentro de su propia bandeja?
Ninguna de las tres requiere presupuesto para responderse. Las tres requieren honestidad, que es un recurso más escaso.
Durante agosto estamos publicando una serie sobre continuidad operativa en las comunicaciones. La interrupción se mide en minutos. La recuperación, en decisiones.
→ Descarga el checklist de 15 preguntas para identificar de qué dependen realmente las comunicaciones de tu empresa: https://drive.google.com/file/d/1BOjy9dLg6Je1HP6TX_5vtJD3lK6Ln_Vl/view?usp=drive_link
Más información:
contacto@issabel.com
“I am honored to recognize Issabel, LLC with a 2023 Product of the Year Award for its commitment to excellence and innovation,” said Rich Tehrani, CEO, TMC.
Issabel® is developed and managed by Issabel® LLC. company formed by a group of professionals from different countries.
Our team is a leader in open source innovation with implementations and success stories in different continents. Our experience in developing these technologies has allowed us to develop, maintain and improve unified communications platforms.