# Plan de crisis en redes sociales: qué debe registrar tu equipo

> Define quién confirma los hechos, quién publica y cuándo llegará la próxima actualización mientras la respuesta sigue abierta.


**Un plan de crisis en redes sociales es el acuerdo operativo que define quién confirma cada hecho, quién puede emitir un aviso y cómo el equipo mantiene las actualizaciones hasta cerrar el incidente con evidencia.** Coordina a operación, atención al cliente y community manager cuando el estado del servicio y las preguntas públicas avanzan a ritmos distintos.

La guía organiza la coordinación de mensajes en redes desde la activación hasta el cierre documentado.

## Qué resuelve el plan

Una conversación crítica puede aparecer antes de que el equipo conozca su causa o alcance. El plan indica quién comprueba esos datos, quién los convierte en un mensaje público y cuándo volverá a informar. Define también cómo pasar la responsabilidad a otra persona y qué evidencia permite comunicar que el incidente terminó.

Cada tarea tiene su propio propósito. El [social listening](/es/guides/social-listening-que-es-ejemplos/) ayuda a detectar y analizar conversaciones como conjunto. La [moderación de comentarios](/es/guides/moderacion-comentarios-redes-sociales/) decide qué hacer con un comentario concreto. La [aprobación de contenido](/es/guides/flujo-aprobacion-contenido-redes-sociales/) revisa publicaciones planificadas antes de salir. El plan de crisis coordina los mensajes una vez que un hecho confirmado requiere una respuesta compartida.

Define de antemano qué hecho activa el plan y quién toma esa decisión, incluidos sus reemplazos. El criterio debe corresponder a la operación y a la capacidad real del equipo. Una cifra fija de menciones o una promesa de responder en diez minutos no funciona como regla universal para todas las marcas.

## Asigna responsables para cada dato

El equipo necesita una persona que lidere la coordinación y alguien que pueda verificar cada afirmación. Una persona puede asumir más de una tarea en un equipo pequeño; el registro debe mostrar quién es responsable en cada momento.

| Función | Qué confirma o decide | Qué registra |
| --- | --- | --- |
| Operación | Estado del servicio, alcance comprobado y señales de recuperación. | Fuente de la comprobación, hora y persona responsable. |
| Atención al cliente | Consultas recibidas y opciones de ayuda que ya están confirmadas. | Preguntas repetidas, respuesta vigente y casos que siguen abiertos. |
| Community manager | Redacción y publicación de avisos en los canales acordados. | Texto publicado, enlace, hora y preguntas derivadas. |
| Responsable del incidente | Activación, hora del próximo aviso, relevo y decisión sobre contenido promocional. | Decisión, motivo, responsable y hora de revisión. |

La persona que publica no debe completar con suposiciones los datos que operación todavía está verificando. Si la causa, el número de reservas afectadas o la hora de recuperación siguen pendientes, el registro debe decirlo así y asignar quién revisará cada punto.

## Muestra el estado y la próxima hora de actualización

Este caso es ficticio. El equipo confirmó que el servicio de reservas no está disponible. Todavía no sabe la causa, qué solicitudes podrían verse afectadas ni cuándo volverá el servicio.

**Dos avisos para el mismo incidente**

**Aviso sin siguiente paso**

Estamos revisando un problema con las reservas. Pronto tendremos novedades.

**Aviso con estado y horario**

Confirmamos que el servicio de reservas no está disponible. La causa y el alcance siguen en revisión. Publicaremos la próxima actualización el 6 de octubre de 2026 a las 14:30 UTC.

*Caso ficticio. La hora indica cuándo volverá a comunicarse el equipo, no cuándo se reparará el servicio.*

El segundo aviso separa lo comprobado de lo pendiente y fija la siguiente comunicación con fecha, hora y zona explícitas. El equipo elige un horario que pueda cumplir aunque la investigación siga abierta. Ese compromiso fija una hora para actualizar, no una hora de resolución. Si aparece un dato confirmado antes, el equipo puede publicar antes y conservar la próxima hora de control.

## Mantén un registro de hechos, decisiones y relevo

El registro de trabajo conserva la versión vigente del incidente. Cada hecho debe incluir una fuente y una hora de verificación. Cada pregunta pendiente necesita una persona responsable y un momento para revisarla.

| Entrada | Qué anotar | Cuándo se cierra |
| --- | --- | --- |
| Hecho confirmado | Dato exacto, fuente de operación y hora con zona. | Cuando una nueva comprobación confirme o corrija el dato. |
| Pendiente | Pregunta abierta, persona que la revisará y próxima comprobación. | Cuando la fuente responsable aporte evidencia. |
| Aviso público | Texto, canal, enlace y fecha y hora de publicación. | Al registrar la siguiente actualización. |
| Contenido promocional | Continuar, pausar o reanudar; motivo, responsable y próxima revisión. | Cuando la persona responsable confirme la decisión. |
| Relevo | Último aviso, hechos vigentes, pendientes, siguiente hora y responsable entrante. | Cuando quien recibe el turno confirme que se hizo cargo. |
| Cierre | Criterios acordados, evidencia, alcance demostrado, quién la verificó, hora y seguimiento abierto. | Cuando operación confirma los criterios para el alcance declarado y el equipo publica el cierre. |

La pausa o reanudación de contenido promocional es una decisión operativa separada. Registra qué piezas revisó el equipo, quién decidió y cuándo volverá a evaluar la decisión. Reanuda una pieza cuando la persona responsable confirme que sigue siendo adecuada para el estado actual; el plan no necesita ordenar una pausa automática para todas las marcas.

Al cambiar de turno, el responsable saliente entrega el último mensaje publicado, sus fuentes, los datos pendientes, la próxima actualización acordada y el nombre o rol de quien la asumirá. La persona entrante confirma el relevo. Así el compromiso horario continúa aunque cambie quién publica.

## Cierra después de comprobar la recuperación

Antes de una incidencia, acuerda con operación qué señales cuentan como recuperación y qué parte del servicio comprueba cada una. En el ejemplo, una reserva de prueba demuestra solo el recorrido que se probó. Registra el resultado, la hora y el alcance; deja abiertos los flujos que todavía no se han comprobado. El community manager comunica exactamente ese estado.

El cierre del registro guarda los criterios acordados, la evidencia, el alcance demostrado, quién lo comprobó, la última actualización pública y cualquier seguimiento que continúe. Comunica la recuperación hasta el alcance que las comprobaciones respaldan. Si algunos flujos siguen sin verificar, conserva ese estado como pendiente. Una conversación menos intensa en redes tampoco confirma que el servicio esté restablecido.

El Government Communication Service del Reino Unido presenta PRIMER como un marco para planificar, ensayar, ejecutar, mantener, evaluar y recuperar las comunicaciones de emergencia. Su alcance es la comunicación pública; aquí sirve como referencia para planificar continuidad y revisión, no como obligación para marcas. [Lee el Emergency Planning Framework Primer](https://www.communications.gov.uk/publication/emergency-planning-framework-primer/).

El Social Media Playbook del Government Digital Service describe el proceso de escalamiento y los ejercicios de escenario que usa esa organización. Es una referencia de coordinación del gobierno británico, no una regla universal para equipos comerciales. [Consulta el Social Media Playbook](https://www.gov.uk/guidance/social-media-playbook).

## Descarga y adapta la plantilla

La plantilla conserva los campos para responsables, hechos confirmados, preguntas abiertas, siguiente actualización, decisión promocional, relevo y evidencia de cierre. Adáptala a los canales y funciones de tu equipo antes de necesitarla. También puedes [descargar el plan de crisis editable en texto](/blogs/social-media-crisis-plan/plan-es.txt).

#### Completa el plan para tu equipo

```text
Incidente y fecha de activación: [nombre, fecha, hora y zona].
Criterio de activación: [hecho que lo activa y quién decide].
Responsable del incidente y reemplazo: [rol, contacto interno y respaldo].
Canales acordados: [cuentas y formatos que se usarán].
Operación: [quién confirma el estado y dónde registra la evidencia].
Criterios operativos de recuperación: [señales acordadas con operación y alcance].
Atención al cliente: [quién verifica respuestas y opciones de ayuda].
Community manager: [quién publica y registra los avisos].
Hechos confirmados: [dato, fuente, responsable y hora de verificación].
Preguntas pendientes: [pregunta, fuente que se consultará, persona responsable y próxima comprobación con zona].
Aviso público: [hechos confirmados, pendientes, opción de ayuda confirmada, canal y texto].
Próxima actualización pública: [fecha, hora y zona explícitas].
Publicación: [responsable, enlace y hora].
Contenido promocional: [piezas revisadas, decisión, motivo, responsable, hora de revisión y condición para reanudar].
Relevo: [último aviso y enlace, hechos, pendientes, próxima hora, responsable entrante y confirmación de recepción].
Cierre: [criterios acordados, evidencia y alcance demostrado, persona que verificó, hora, enlace y seguimiento con responsable y próxima comprobación].
```

El ejemplo y la plantilla son elaboración editorial de HeyMark. Puedes editar el archivo con cualquier aplicación de texto; no crea publicaciones ni se conecta con el producto.

## Planifica el próximo post en HeyMark.

Guarda la idea, revisa el texto con tu equipo y mira cómo le fue después en las cuentas que conectaste.

[Empezar gratis](https://app.heymark.ai) · [Ver cómo funciona](https://heymark.ai/es/#product)

## Recursos para desarrolladores y agentes

- [Documentación MCP de HeyMark](https://heymark.ai/es/mcp/)
- [llms.txt](https://heymark.ai/llms.txt)
- [Contenido completo del sitio para modelos de lenguaje](https://heymark.ai/llms-full.txt)
- Endpoint del protocolo MCP: `POST https://mcp.heymark.ai`
- Metadatos OAuth del recurso protegido: [/.well-known/oauth-protected-resource](https://mcp.heymark.ai/.well-known/oauth-protected-resource)
- MCP server card: [/server-card](https://mcp.heymark.ai/server-card)