Un aguacero deja sin energía la zona. El operador de internet tiene una falla que dura cuatro horas. Se bloquea una vía y media jornada de la mañana no llega a tiempo. Nada de esto es excepcional, ni en Colombia ni en ningún otro sitio donde opere un centro de servicios. Lo excepcional es encontrarlo escrito en el contrato antes de que ocurra.
La continuidad es la parte del acuerdo que se lee cuando ya falló. Nadie pregunta por ella en la primera reunión: no vende, alarga la negociación y hablar de caídas mientras se firma parece de mal gusto. Después se convierte en la conversación más tensa del año, con una operación detenida y dos versiones de quién debía hacer qué.
Continuidad no es redundancia
Se confunden con frecuencia. Redundancia es duplicar un recurso: una segunda conexión, una planta eléctrica, un servidor espejo. Continuidad es una decisión previa sobre qué se sostiene, en qué orden y en cuánto tiempo, sabiendo que no todo se puede sostener a la vez.
Un plan que promete que todo sigue igual no es un plan, es una declaración de intenciones. El plan útil dice lo contrario: durante una contingencia se atiende primero esto, se degrada aquello y esto otro se detiene. Un caso de seguridad del usuario no espera; una encuesta de satisfacción sí. Escribir esa jerarquía en frío, con el cliente presente, es la mitad del trabajo.
La otra mitad son los tiempos. Cuánto puede tardar la operación en volver a un servicio mínimo y cuánto en volver a la normalidad. Son dos cifras distintas y ambas deben ser acordadas, no estimadas por el proveedor a solas.
Un plan de continuidad que no prioriza no es un plan: es una lista de deseos con membrete.
Los escenarios que sí ocurren
Los planes suelen imaginar catástrofes y olvidar lo cotidiano. La mayoría de las interrupciones reales de una operación tercerizada caben en una lista corta y poco dramática:
- Energía. Cortes de red, mantenimientos programados del operador, fallas internas del edificio.
- Conectividad. Caída del enlace principal, degradación de la calidad que vuelve inviable la voz aunque el chat siga funcionando.
- Plataformas de terceros. El CRM, la telefonía o la herramienta de tiquetes del cliente se caen. El proveedor no controla nada y aun así tiene el equipo sentado.
- Ausentismo masivo. Clima, orden público, transporte, brotes de salud. Afecta el turno, no la infraestructura.
- Incidente de seguridad o de accesos. Credenciales bloqueadas, una VPN caída, un cambio en el lado del cliente que nadie avisó.
- Edificio inaccesible. Poco frecuente y el que más rápido revela si el plan existía.
Vale la pena notar que tres de los seis no son fallas del proveedor. Eso no las hace irrelevantes: la operación se detiene igual y alguien tiene que decidir qué se hace con el equipo mientras tanto.
Sitio, casa o los dos
El trabajo desde casa suele presentarse como el plan de contingencia por defecto. Funciona, pero tiene condiciones que conviene revisar antes de darlo por hecho.
La primera es que la casa también falla: la energía y el internet domiciliario son, en promedio, menos estables que los de un sitio con respaldo. La segunda es el equipamiento: enviar a alguien a su casa sin diadema, sin equipo asignado y sin canal de soporte no es continuidad, es dispersión. La tercera es de seguridad de la información: hay procesos que, por acuerdo con el cliente o por la naturaleza del dato, no pueden salir de un ambiente controlado. Si ese es el caso, el plan tiene que resolverlo con otra cosa, no con una excepción improvisada el día del incidente.
La lógica inversa también aplica. Una operación totalmente remota necesita respuesta para el escenario en que falla la casa de varias personas a la vez, que es exactamente lo que pasa cuando el evento es regional. Ahí el respaldo es un sitio físico, aunque sea pequeño, o una segunda ciudad.
Lo primero que se rompe es la coordinación
En casi todos los incidentes que se manejan mal, la tecnología se recupera antes que la comunicación. El equipo del cliente se entera por un usuario final, no por su proveedor. O se entera tres horas después, cuando ya escribió en un canal que nadie está leyendo porque justamente ese canal es el que se cayó.
Un plan de continuidad que sirve responde cuatro preguntas con nombre propio: quién declara la contingencia, a quién avisa, en cuánto tiempo y por qué canal alterno. Ese canal alterno importa: si la notificación depende del correo corporativo y el incidente es de conectividad, la notificación no existe. Un número de celular escrito en el contrato es poco elegante y muy efectivo.
Después viene la cadencia: cada cuánto se actualiza el estado mientras dura el evento, aunque la actualización sea "seguimos sin solución". El silencio durante una caída hace más daño que la caída.
Qué pasa con el SLA mientras dura
Aquí es donde la mayoría de los contratos se vuelven ambiguos. La cláusula de fuerza mayor se copia de una plantilla, queda redactada de forma amplia y termina cubriendo cualquier cosa que el proveedor no quiera responder. Conviene lo contrario: una definición estrecha, con ejemplos, y una regla explícita sobre las métricas.
Esa regla puede ser excluir las horas del evento del cálculo del período, o medirlas aparte y reportarlas. Lo que no debería pasar es que el evento desaparezca del reporte mensual: si se borra, la tendencia deja de ser legible y nadie aprende nada. Esto se conecta directamente con cómo se escribe un SLA cumplible: un indicador sin regla de excepción se incumple por razones ajenas y pierde autoridad para el resto del año. Nada de esto constituye asesoría legal; la redacción concreta debe revisarla un abogado en cada caso.
Un plan que no se ensaya no existe
La diferencia entre un proveedor que tiene continuidad y uno que tiene un documento de continuidad se ve en una sola pregunta: cuándo fue el último simulacro y qué salió mal.
Hay tres niveles de ensayo y los tres sirven. El de mesa reúne a los responsables y recorre el escenario hablando, sin mover nada; sirve para descubrir que dos personas creían que la decisión era del otro. El parcial mueve un grupo pequeño al modo alterno durante unas horas. El completo traslada la operación entera y es el único que revela los cuellos de botella reales, como que la planta arranca pero no alimenta el aire acondicionado del piso.
Lo importante no es la frecuencia que se pacte, sino que exista un informe posterior con hallazgos y responsables, y que ese informe llegue al comité con el cliente. Es material natural de la gobernanza del contrato: sin un espacio donde se revise, el simulacro se convierte en un trámite anual.
Qué pedir por escrito
- La lista de escenarios cubiertos y, explícitamente, los que no lo están.
- La prioridad de servicios durante la contingencia: qué se atiende, qué se degrada y qué se suspende.
- Los tiempos acordados para llegar a servicio mínimo y para volver a la normalidad.
- El protocolo de notificación: quién declara, a quién, en cuánto, por qué canal alterno y con qué cadencia de actualización.
- El tratamiento de las métricas durante el evento y su registro en el reporte.
- El calendario de simulacros y el compromiso de compartir los hallazgos.
- Las condiciones del trabajo en casa como respaldo: equipos, conectividad mínima, reglas de seguridad y procesos excluidos.
Cómo lo trabaja smartBPO
Levantamos la matriz de escenarios con el cliente antes del arranque, no después del primer incidente, y priorizamos los servicios en frío: qué se sostiene, qué se degrada y qué se detiene. Dejamos por escrito quién declara la contingencia de cada lado, con nombre y canal alterno, y una cadencia de actualización mientras el evento esté abierto. Combinamos sitio y trabajo en casa según lo que permita cada proceso, en lugar de aplicar una sola regla a toda la operación. Ensayamos y compartimos el informe del ensayo, incluido lo que no funcionó. Y no ofrecemos disponibilidad perfecta: ofrecemos una respuesta acordada, medida y revisable, que es lo único que se puede sostener cuando el evento llega sin avisar.