¿Te afectó la caída de Microsoft 365? Cómo reclamar y solicitar una compensación por el SLA

Qué debe saber la dirección antes de reclamar

La caída de Microsoft 365 de los días 12 y 13 de noviembre de 2026 afectó a distintos servicios y regiones, con impacto reportado sobre conexiones de Exchange Online y otros componentes del ecosistema. Eso no significa que todos los tenants estuvieran indisponibles durante el mismo número de horas. Para reclamar correctamente hay que distinguir tres realidades: la incidencia general publicada por Microsoft, el impacto técnico concreto en tu organización y las condiciones contractuales del servicio que contrataste.

Microsoft dispone de compromisos de nivel de servicio para determinados servicios online y de mecanismos para solicitar créditos si se cumplen las condiciones aplicables. En el canal CSP, la documentación oficial especifica que los créditos se calculan por el servicio afectado y la duración elegible; el hecho de que una organización tenga un paquete de Microsoft 365 no implica que toda la factura mensual pueda recuperarse. Tampoco es lo mismo un crédito contractual que una reclamación por perjuicios empresariales.

12 y 13 de noviembre de 2026: caída de Microsoft 365, alcance y evidencias

La incidencia se inició el jueves 12 de noviembre y se prolongó durante el viernes 13 para determinados usuarios y servicios. Las comunicaciones de seguimiento identifican problemas de acceso a buzones de Exchange Online y afectación potencial a otros servicios Microsoft 365. Fuentes que recogen las notificaciones oficiales documentan los identificadores EX1550543 y MO1550821, junto a comunicaciones sobre Teams. El problema provocó dificultades de conexión, errores intermitentes y una recuperación por fases.

La cobertura pública confirma que se trató de una incidencia amplia; no permite, por sí sola, asignar un número de horas de indisponibilidad a cada empresa. Algunas organizaciones pudieron perder acceso al correo durante un periodo prolongado; otras pudieron experimentar degradaciones parciales, retrasos o afectación de unos usuarios sí y otros no. Esa diferencia importa tanto para el análisis técnico como para cualquier solicitud de crédito.

La referencia útil para un cliente no es una captura de una noticia genérica ni un titular que habla de una caída “global”. Es el registro del incidente publicado por Microsoft, contrastado con los síntomas reales de su tenant. Para consultar la situación y el historial, Microsoft explica el uso de su panel Service Health y las características de cada aviso en su guía oficial de estado de los servicios.

¿Tengo derecho a compensación? Depende de tres filtros que no puedes saltarte

Microsoft ofrece compromisos de disponibilidad recogidos en sus acuerdos de nivel de servicio. Para algunos productos, el incumplimiento puede dar lugar a créditos de servicio si se cumplen los requisitos de elegibilidad, plazo, prueba y presentación. Sin embargo, existe una diferencia decisiva entre que Microsoft publique una incidencia, que tu organización haya experimentado un impacto y que ese impacto cumpla las condiciones contractuales concretas para recibir un crédito.

Este tercer paso es el que muchas empresas omiten. En su documentación del canal CSP, Microsoft recuerda que los avisos clasificados como advisory normalmente no generan créditos de SLA y que el panel de estado señala clientes potencialmente afectados, pero no acredita por sí solo la afectación concreta de una organización. También subraya que la evaluación se hace por servicio afectado y por duración elegible. Por eso la reclamación debe construirse desde los hechos, no desde la indignación.

Antes de hablar de cantidades, conviene consultar el documento oficial del SLA de Microsoft Online Services vigente para el servicio y contrato. En esa página Microsoft publica versiones actuales y archivadas. La modalidad de compra, el servicio concreto, el periodo cubierto y las exclusiones pueden alterar la evaluación. No presupongas que todas las suscripciones Microsoft 365 tienen las mismas condiciones para todos los componentes.

Cómo localizar la incidencia oficial en Microsoft 365 y guardar las pruebas

El primer movimiento debe hacerlo el administrador de Microsoft 365 o la persona que gestione el soporte del tenant. Microsoft ofrece un panel de estado que permite ver incidentes activos, historial y mensajes de evolución. Es una fuente más precisa que las redes sociales, porque permite localizar el identificador y las actualizaciones técnicas que deben acompañar a la reclamación. Si tu empresa no tiene acceso administrativo, pide a tu proveedor o equipo IT que facilite el extracto pertinente.

Accede a Microsoft 365 Admin Center con una cuenta que tenga los permisos adecuados. Dentro de Salud / Estado del servicio —la ubicación exacta puede cambiar con la interfaz— busca los mensajes correspondientes a las fechas 12 y 13 de noviembre de 2026. Revisa Exchange Online y los demás componentes que hayan tenido síntomas en la organización. La publicación general del incidente no debe reemplazar la comprobación del servicio exacto.

En cada registro identifica el título del problema, su ID, el servicio afectado, la hora estimada de inicio, las actualizaciones y la resolución comunicada. Conserva tanto el resumen como las actualizaciones relevantes. Si el incidente ya no aparece como activo, revisa el historial. Cuando exista una revisión posterior del incidente, puede aportar contexto adicional sobre causa, mitigación y alcance.

No recopiles más datos personales de los necesarios. Una tabla agregada de usuarios afectados por servicio y ubicación suele ser más útil que almacenar capturas indiscriminadas de correos privados. El objetivo es demostrar la incidencia, preservar trazabilidad y facilitar una evaluación contractual, respetando las políticas internas de seguridad y privacidad.

También es importante no mezclar fallos internos con la caída del proveedor. Si en la misma semana hubo un cambio de tenant, problemas de red local, modificaciones de DNS, incidencias de acceso condicional o una migración, el expediente debe distinguir esos eventos. Solo se debería atribuir al incidente de Microsoft el periodo que pueda relacionarse razonablemente con sus servicios afectados. Esa separación mejora tanto la credibilidad de la reclamación como la calidad del informe técnico posterior.

Cómo reclamar si compras Microsoft 365 directamente o si tus licencias son CSP

Éste es el punto que más confusión genera. Una empresa puede trabajar a diario con un integrador, recibir soporte de otro proveedor y pagar las licencias a un tercero. En ese escenario, no basta con decir “nuestro partner se encarga”: hay que identificar quién mantiene la relación comercial de la suscripción y quién tiene capacidad de elevar la petición de crédito por el canal correspondiente.

Si las licencias se contrataron directamente con Microsoft, un administrador con permisos puede abrir una solicitud de soporte desde el centro de administración, explicar la incidencia y pedir que se revise la elegibilidad para un crédito de SLA. La documentación oficial de soporte señala que las organizaciones con suscripciones adquiridas directamente pueden contactar con Microsoft desde el centro de administración, mientras que las que compraron todas sus suscripciones por un partner deben contactar primero a ese partner.

Si las licencias son CSP, la ruta cambia. Microsoft indica que las solicitudes de crédito a través de Partner Center se presentan por proveedores CSP directos o indirectos autorizados, no por cualquier revendedor indirecto de manera autónoma. El cliente debe solicitar a su proveedor que evalúe y eleve la incidencia, y aportar la documentación adecuada. Que exista un partner de soporte distinto del proveedor de licencias no cambia por sí solo la ruta comercial de la solicitud.

La documentación de Microsoft para CSP exige, entre otros datos, el GUID del tenant, el identificador del incidente, pruebas de que el cliente sufrió la interrupción y constancia de que pidió expresamente el crédito. También puede requerirse el número de ticket, los periodos de caída, las ubicaciones y el número de usuarios afectados. Esta exigencia explica por qué no basta con enviar una noticia sobre la caída y solicitar una devolución genérica.

Las diez pruebas que más valor tienen al preparar la reclamación

Una reclamación sólida empieza con un expediente pequeño, claro y verificable. No necesita convertirse en un informe de cientos de páginas. Lo que sí necesita es trazabilidad: cuándo falló el servicio, a quién afectó, qué condiciones de la suscripción se aplican y qué registros relacionan la afectación con el incidente de Microsoft.

La tentación de recopilar únicamente capturas de redes sociales o titulares suele jugar en contra. Esas fuentes explican la dimensión pública de una caída, pero no prueban la duración específica que sufrió una empresa. Del mismo modo, un ticket interno puede mostrar que alguien no podía entrar en Outlook, pero no necesariamente que Microsoft incumpliera el SLA. Hay que conectar ambas capas: la oficial y la operativa.

Si tu empresa gestionó cientos de incidencias durante la interrupción, no es necesario adjuntar todas las conversaciones desde el primer momento. Puede resultar más útil una relación consolidada con ejemplos representativos y capacidad de ampliar evidencias si el proveedor las solicita. Conviene guardar una copia íntegra del expediente dentro de la organización, con fechas de apertura, respuestas, decisiones y escalados posteriores.

En contratos con distintas filiales, dominios o tenants, cada entidad puede presentar circunstancias diferentes. Antes de elevar una reclamación conjunta, confirma cuáles son las suscripciones, quién factura y qué usuarios quedaron afectados en cada entorno. Un expediente preciso suele ser más defendible que una declaración general de que “todo Microsoft dejó de funcionar”.

¿Hasta cuándo se puede reclamar? No conviene esperar al informe final

Microsoft publica una regla concreta para créditos por interrupciones gestionados en el canal CSP: en servicios distintos de Azure, la solicitud debe presentarse dentro del mes siguiente al cierre del mes de facturación en el que se produjo la incidencia. Para Azure se contempla un plazo diferente, por lo que no deben mezclarse ambos procedimientos. La fecha exacta depende del periodo de facturación aplicable y de las condiciones del servicio; no conviene convertir esa regla en una fecha universal sin revisar el contrato.

La recomendación práctica es iniciar el expediente cuanto antes. Si la organización todavía no dispone del informe final del incidente, puede comenzar por reunir las pruebas y expresar formalmente su intención de reclamar, siguiendo las instrucciones del proveedor. La documentación posterior podrá ayudar a confirmar el alcance, pero no debería utilizarse como excusa para agotar los plazos. En organizaciones con varias suscripciones y proveedores, la coordinación puede requerir más tiempo del previsto.

El crédito SLA no es una indemnización por las ventas perdidas: así debes entender el importe

En un entorno B2B, una caída de correo, colaboración y herramientas de productividad puede tener consecuencias serias: presupuestos que no salen, clientes que no reciben respuesta, expediciones que no se confirman, aprobaciones que se retrasan o equipos que pierden horas. Sería tentador calcular ese perjuicio y trasladarlo directamente a Microsoft como solicitud de abono. Sin embargo, esa no es la lógica ordinaria de un crédito SLA.

Según la documentación oficial para CSP, los créditos dependen del servicio afectado y de la duración elegible, y se prorratean conforme a las condiciones correspondientes. Si una organización contrató un paquete que incluye varios servicios y únicamente uno fue afectado en el periodo considerado, no se debe suponer que tiene derecho a recuperar toda la cuota. Tampoco se debe extrapolar sin revisar el contrato un porcentaje general leído en una tabla ajena.

Pongamos un caso ilustrativo sin asignar porcentajes contractuales: una empresa tiene varios cientos de usuarios con Microsoft 365. El viernes descubre que parte de su plantilla no pudo utilizar el correo correctamente durante un periodo de la incidencia. El equipo financiero quiere saber si el valor de las horas improductivas puede reclamarse. Para el expediente de SLA, el dato más útil no es multiplicar el coste horario de cada empleado por la interrupción: es identificar el servicio contratado, las licencias pertinentes, la disponibilidad afectada y las reglas oficiales de crédito.

Eso no significa que el coste interno carezca de importancia. Debe medirse por separado para el análisis de riesgo, continuidad y priorización de inversiones. La dirección necesita conocer dos cifras distintas: el crédito contractual que eventualmente se apruebe y el coste empresarial que la organización soportó. Confundirlas provoca frustración, expectativas irreales y decisiones de continuidad mal planteadas.

Qué enviar a tu proveedor: una solicitud clara, técnica y sin promesas imposibles

La forma de solicitar la revisión del crédito también cuenta. Un mensaje útil evita acusaciones genéricas y resume con precisión el alcance. Debe permitir a la persona de soporte identificar el servicio, el tenant, la fecha y las pruebas sin tener que reconstruir la historia completa. Si existen varios interlocutores, conviene establecer un único responsable de expediente para no perder decisiones ni fechas.

Este modelo es orientativo. No hace falta utilizar exactamente estas palabras, pero sí dejar constancia explícita de la petición de revisión y crédito. En el canal CSP, Microsoft señala expresamente la necesidad de evidenciar que el cliente solicitó un crédito SLA, de modo que no conviene limitarse a una incidencia abierta con el texto “no funciona Outlook”.

En la comunicación inicial no es necesario afirmar que existe un incumplimiento ya demostrado si todavía no se ha calculado la disponibilidad conforme al SLA. La fórmula “solicitud de evaluación de elegibilidad” es más rigurosa y ayuda a que la conversación empiece donde debe: en los hechos y el contrato. Cuando la respuesta sea desfavorable, pide una explicación que identifique el servicio, la condición aplicada y la razón de no elegibilidad. De esa forma, el expediente se cierra con trazabilidad y no con una respuesta ambigua.

La pregunta que importa al CIO: ¿qué hacemos si Microsoft 365 vuelve a fallar mañana?

Una reclamación puede devolver una parte de la factura de un servicio si se cumplen las condiciones. Pero ninguna devolución recupera automáticamente una jornada laboral, una operación crítica no ejecutada o una venta que se perdió porque el equipo no pudo responder. Para una dirección de tecnología, la consecuencia más útil de una caída es descubrir qué procesos dependen de Microsoft 365 y cómo responder cuando el proveedor atraviesa una indisponibilidad. La conversación deja de ser puramente contractual y pasa a ser de continuidad.

El primer paso consiste en construir un inventario de procesos dependientes: comunicaciones con clientes, servicio al usuario, aprobación de pedidos, documentación compartida, reuniones internas, gestión de incidencias, firma o colaboración con proveedores. Después se debe identificar qué sucede cuando Exchange Online no está disponible, cuando Teams sufre degradación o cuando SharePoint no permite consultar documentos. No todas las áreas requieren la misma respuesta, pero todas deberían saber qué alternativa utilizar.

Un buen plan no se limita a guardar una lista de teléfonos de emergencia. Debe definir responsables, canales alternativos, mensajes preaprobados, procedimientos para atender a clientes críticos, maneras de registrar temporalmente operaciones y criterios para volver a los sistemas habituales. Los equipos necesitan saber cómo actuar sin improvisación y sin crear riesgos innecesarios de protección de datos por salir de las herramientas corporativas.

También resulta esencial saber qué depende de servicios de terceros. Si el ticketing, el portal de clientes o un proceso de autenticación utilizan servicios afectados por la misma incidencia, puede haber fallos en cadena. Un canal alternativo solo sirve si no comparte exactamente las mismas dependencias que el canal primario. Por eso la evaluación debe combinar arquitectura, contratos, experiencia del usuario y operación real.

El objetivo no debe ser asegurar que nunca habrá una interrupción: ninguna plataforma seria puede prometerlo. El objetivo empresarial es reducir el impacto de los incidentes que inevitablemente pueden producirse. Esto incluye reconocer qué procesos toleran una degradación temporal y cuáles necesitan redundancias, medidas manuales transitorias o un diseño de continuidad más exigente.

¿Una copia de seguridad de Microsoft 365 habría evitado esta caída? No necesariamente.

Después de una interrupción importante es habitual que aparezca una recomendación automática: “Necesitamos más backup”. Conviene matizarla. Las copias de seguridad sirven para determinados escenarios de recuperación de datos, borrado, corrupción o restauración, dependiendo de la cobertura contratada. Pero una copia de seguridad no restablece por sí sola la conectividad de Exchange Online, Teams o los sistemas de autenticación cuando existe una incidencia del proveedor.

La disponibilidad de una aplicación y la recuperabilidad de sus datos son dos propiedades distintas. Una empresa puede disponer de copias muy completas y, aun así, sufrir una interrupción del correo por un fallo del servicio. Y puede tener el correo funcionando con normalidad, pero necesitar recuperar documentos borrados por error. Ambos riesgos merecen controles; ninguno debe usarse como argumento comercial para vender la solución equivocada.

Por eso sería un error aprovechar la incidencia para afirmar que un partner o un producto de backup “impide las caídas de Microsoft”. Un partner puede ayudar a diseñar continuidad, facilitar soporte, verificar configuraciones, mejorar monitorización y preparar alternativas, pero no controla la disponibilidad global de la infraestructura de Microsoft. Lo que sí puede hacer es reducir la dependencia operativa, acelerar el diagnóstico y ordenar la respuesta cuando surge un problema.

Para profundizar en productividad, colaboración, seguridad y protección del entorno, puedes consultar el hub de Microsoft 365 para empresas. La guía de reclamaciones responde al derecho contractual y al procedimiento; la planificación de continuidad y la recuperación de información abordan otros riesgos que merecen un análisis propio.

Una caída de Microsoft 365 no es solo un asunto del departamento técnico

Cuando se produce una indisponibilidad extensa, el departamento de sistemas suele concentrarse en restablecer el servicio, atender incidencias y explicar lo que ocurre. Es una tarea imprescindible, pero insuficiente. Finanzas necesita entender el posible crédito; compras debe identificar el contrato y los interlocutores; operaciones debe dimensionar el impacto; dirección necesita decidir si el riesgo asumido es razonable. Sin esa coordinación, la organización puede resolver la urgencia técnica y olvidar las mejoras que habría podido impulsar después.

Además, si la empresa trabaja en varias sedes o países, conviene no asumir que todos los equipos vivieron la misma afectación. Un mismo incidente puede producir errores intermitentes en algunos usuarios y afectar de manera más severa a otros. El expediente de reclamación y la revisión de continuidad se benefician de una descripción agregada por servicios, sedes y periodos, en lugar de un relato único que borra todas las diferencias.

Esta coordinación permite transformar una crisis operativa en una revisión útil del modelo de servicio. No significa culpar al integrador por una caída ajena a su infraestructura. Significa exigir claridad sobre responsabilidades: quién comunica, quién abre tickets, quién recopila evidencias, quién escala, quién documenta el cierre y quién ayuda a que el negocio pueda seguir operando mientras se recupera el servicio.

Respuestas claras sobre la caída, el SLA y los créditos de Microsoft

Documentación que conviene consultar antes de presentar una reclamación

Para tomar decisiones informadas, consulta siempre la documentación de Microsoft correspondiente al servicio, a la fecha y al tipo de contratación. Los resúmenes periodísticos son útiles para conocer el contexto general, pero no sustituyen el contrato ni el historial del incidente en tu propio tenant. Estos recursos ayudan a preparar una evaluación responsable y permiten ampliar el análisis sin depender de afirmaciones genéricas sobre compensaciones.