Qué incluye el PR de crisis para un proyecto Web3
El PR de crisis organiza qué comunicar, a quién y en qué orden cuando un incidente amenaza la confianza en tu proyecto. El trabajo puede abarcar rumores o FUD, un exploit, una vulnerabilidad bajo revisión, una suspensión o un delisting anunciado por una plataforma. La prioridad es separar hechos confirmados, preguntas abiertas y afirmaciones que todavía no se pueden sostener.
El alcance se acuerda con tu equipo y puede incluir:
- Una declaración de espera para reconocer la situación sin adelantarse a la investigación.
- Mensajes clave y respuestas a preguntas previsibles de usuarios, medios y socios.
- Un mapa de públicos, canales y responsables de aprobación.
- Revisión de comunicados o publicaciones que el equipo ya haya preparado.
- Un calendario de actualizaciones ligado a hitos verificables.
No sustituimos una auditoría técnica, asesoría legal ni la comunicación directa con un exchange o proveedor. Coordinamos el lenguaje público con las personas responsables de esas áreas para evitar que un mensaje contradiga una investigación, una obligación o una decisión operativa. Si necesitas contexto más amplio, consulta PR y medios o el servicio de gestión de reputación.
¿Qué debe decir una declaración inicial?
Una declaración inicial debe confirmar que el equipo conoce el asunto, describir solo lo comprobado y explicar cuándo o dónde compartirá una actualización. Su objetivo no es cerrar el caso: es ofrecer una referencia fiable mientras se recopila información.
Antes de redactarla, pedimos al equipo que reúna una cronología básica y responda estas preguntas: ¿qué ocurrió y cuándo se detectó?, ¿qué sistemas o usuarios podrían estar afectados?, ¿qué medidas se han tomado?, ¿quién puede validar cada dato? Si hay un incidente técnico, el equipo de seguridad debe confirmar el estado antes de publicar conclusiones. Si hay un delisting, hay que distinguir entre una notificación oficial, una revisión en curso y una especulación pública.
Una declaración útil suele incluir:
- Reconocimiento del asunto con palabras directas y sin minimizarlo.
- Información confirmada, atribuida a una fuente interna responsable.
- Acciones que el proyecto ya inició, sin presentarlas como una solución definitiva.
- Un canal y un criterio para las próximas actualizaciones.
Si todavía no hay respuesta completa, una declaración de espera puede reducir el vacío informativo sin inventar una causa. Para preparar comunicados de otro tipo, puedes revisar el servicio de comunicados de prensa.
Cómo cambia la respuesta ante FUD, exploits o delistings
La respuesta cambia según el tipo de incidente y la evidencia disponible: un rumor exige verificación, un exploit requiere coordinación técnica y un delisting exige precisión sobre el estado de la decisión. Aplicar un mismo texto a los tres casos puede confundir a la comunidad y crear compromisos que el proyecto no puede cumplir.
| Escenario | Prioridad de comunicación | Información que conviene validar |
|---|---|---|
| FUD o acusaciones públicas | Corregir afirmaciones concretas sin amplificar rumores | Evidencia, cronología y portavoz autorizado |
| Exploit o vulnerabilidad | Alinear el mensaje con quienes investigan y responden | Sistemas afectados, medidas confirmadas y orientación a usuarios |
| Delisting o revisión de listado | Explicar el estado real y separar hechos de interpretaciones | Aviso recibido, alcance y canal oficial de consulta |
Para cada escenario acordamos quién aprueba los mensajes, qué preguntas requieren una respuesta técnica y cuáles deben esperar. Si se publica información nueva, se actualiza el mensaje maestro en lugar de abrir versiones contradictorias en distintos canales. La activación de comunidad y las campañas de participación solo tienen sentido si ayudan a compartir información útil; no deben desplazar una explicación factual ni presionar a quienes hacen preguntas legítimas. Para gestionar FUD en la comunidad, consulta también esta guía de respuesta a FUD.
Cómo coordinamos la respuesta y sus entregables
La respuesta se coordina con un responsable del cliente y las personas que conocen los hechos, para que cada mensaje tenga una fuente de validación y una ruta de aprobación. El trabajo empieza con una sesión de contexto y continúa con borradores, revisión y seguimiento de los hitos acordados.
En la preparación, identificamos el incidente, los públicos afectados, los canales activos y cualquier comunicación previa. Después proponemos un mensaje central y una declaración inicial. El cliente confirma hechos y autorizaciones; nosotros ajustamos el lenguaje para que sea comprensible, coherente y prudente. Una vez aprobado, preparamos adaptaciones para los canales seleccionados y respuestas a preguntas previsibles.
El proyecto puede incluir estos materiales, según el alcance convenido:
- Cronología de hechos confirmados y pendientes de verificación.
- Mensaje central, declaración de espera y preguntas frecuentes.
- Guía breve para portavoces y respuestas para consultas de medios.
- Secuencia de actualizaciones y responsable de cada aprobación.
- Resumen de publicaciones y preguntas recibidas durante el seguimiento acordado.
El plazo depende de que el equipo pueda aportar información y aprobar textos. Para establecer expectativas desde el inicio, definimos quién responde fuera del horario habitual, qué cambios requieren nueva validación y cuál es el canal interno para escalar preguntas sensibles. Para preparar comunicaciones con medios, puedes combinar este trabajo con artículos patrocinados en medios cripto.
Qué puede resolver el PR y qué queda fuera de su control
El PR puede hacer que la respuesta pública sea clara, consistente y fiel a los hechos disponibles; no puede decidir por una plataforma, verificar por sí solo un exploit ni sustituir la investigación técnica o legal. Esta distinción importa especialmente cuando hay una revisión de listado o una comunicación oficial pendiente.
Una redacción rigurosa ayuda a reducir contradicciones y permite corregir información errónea con contexto. No elimina preguntas legítimas ni convierte una afirmación no verificada en un hecho. Las decisiones de exchanges y plataformas, sus procesos de revisión, el criterio editorial de los medios y la respuesta de terceros quedan fuera de nuestro control. Tampoco podemos prometer que una declaración cambie el resultado de una investigación, revierta un delisting o genere cobertura favorable.
Para mantener el proceso responsable, acordamos estas reglas antes de publicar:
- No atribuir causas hasta que el equipo competente las confirme.
- No presentar medidas en curso como una resolución completa.
- Corregir con claridad si aparece evidencia que cambia el relato.
- Derivar consultas técnicas, legales o de seguridad a la persona autorizada.
Si el caso requiere corregir datos visibles en perfiles o páginas de listado, el saneamiento del perfil de listado puede ser una línea de trabajo complementaria, con un alcance distinto al de comunicación.
Cómo preparar al equipo antes de que surja una crisis
Preparar una base de comunicación antes de un incidente permite empezar con responsables y materiales claros, en lugar de improvisar bajo presión. No hace falta anticipar todos los escenarios: basta con acordar cómo se verifican los hechos, quién puede aprobar una declaración y dónde se publicarán las actualizaciones.
Reúne un paquete accesible para las personas responsables que incluya contactos internos, descripción actualizada del producto, enlaces a canales oficiales y una lista de especialistas que puedan confirmar datos técnicos. Añade procedimientos existentes para vulnerabilidades, soporte a usuarios y consultas legales. Si hay un canal oficial para avisos o actualizaciones, indica quién puede publicar y quién conserva el acceso.
También conviene preparar una plantilla de declaración de espera, pero no rellenarla con causas o promesas hipotéticas. Úsala como estructura, no como respuesta automática: cada incidente necesita hechos propios. Para evaluar qué preguntas pueden surgir, revisa comentarios de la comunidad, consultas recurrentes de usuarios y temas sensibles que el equipo ya haya abordado.
El resultado práctico es una ruta de decisión: quién detecta, quién valida, quién aprueba y quién publica. Si quieres integrar esa preparación en un plan de comunicación más amplio, explora PR y medios y el servicio de entrevistas y perfiles de fundadores.
Precios
| Servicio | Precio | Cotización |
|---|---|---|
| Guía sobre FUD | bajo solicitud |
Precios iniciales en USD. Paquetes a medida y descuentos por volumen bajo solicitud. Pago en USDT, USDC, BTC, ETH, SOL, TON o con el token de tu proyecto.
Cómo trabajamos
- 1. Recibimos el contextoComparte qué ocurrió, qué se ha publicado y quién puede confirmar los hechos. Señala cualquier investigación técnica o consulta legal en curso.
- 2. Acordamos responsables y públicosDefinimos quién valida y aprueba cada mensaje, qué grupos necesitan información y cuáles son los canales pertinentes.
- 3. Redactamos la primera respuestaPreparamos una declaración inicial y respuestas a preguntas previsibles, separando con claridad lo confirmado de lo pendiente.
- 4. Revisamos y publicamosEl equipo competente valida los hechos y la persona autorizada aprueba el texto antes de su publicación.
- 5. Actualizamos según la evidenciaRevisamos nuevas preguntas y hechos, y ajustamos el mensaje con el equipo para evitar versiones desalineadas.
Preguntas frecuentes
¿Qué información necesitan para empezar?
Necesitamos un resumen de lo ocurrido, los mensajes públicos relacionados y los nombres o funciones de quienes pueden verificar los hechos. Si existe una investigación técnica o legal, indícanos quién la lleva y qué información puede comunicarse. También acordamos quién aprueba los textos y qué canales usa el proyecto.
¿Cuánto tarda en prepararse una respuesta?
El tiempo depende de cuánto se haya verificado y de la disponibilidad de quienes deben aprobar el mensaje. Primero reunimos los hechos y redactamos una declaración inicial; después se revisan las adaptaciones y las preguntas frecuentes. Si faltan datos críticos, podemos preparar una declaración de espera que no anticipe conclusiones.
¿Pueden responder si todavía no sabemos qué causó el incidente?
Sí. La declaración puede reconocer el asunto, explicar que el equipo está verificando lo ocurrido e indicar cómo compartirá novedades. No atribuye una causa ni presenta una hipótesis como confirmada. Así se comunica lo que sí se sabe mientras las personas responsables continúan la revisión.
¿Pueden conseguir que un exchange revierta un delisting?
No podemos decidir ni influir en el resultado de la revisión de una plataforma. Podemos ayudarte a describir con precisión el estado conocido, preparar respuestas para usuarios y medios y coordinar mensajes con el equipo que mantiene el contacto oficial. La decisión y el proceso de revisión corresponden a la plataforma.
¿Qué ocurre si se confirma un exploit durante la comunicación?
Alineamos el mensaje con las personas responsables de seguridad y con las indicaciones que el proyecto haya autorizado para los usuarios. La declaración debe diferenciar lo confirmado de lo que sigue bajo análisis y evitar detalles que puedan interferir con la respuesta técnica. Los cambios importantes se incorporan a los mensajes y preguntas frecuentes.
¿Qué resultados pueden garantizar en una crisis?
Podemos comprometernos con los materiales y tareas incluidos en el alcance acordado, como preparar declaraciones, coordinar revisiones y mantener mensajes consistentes durante el seguimiento convenido. No podemos garantizar que una plataforma cambie una decisión, que un medio publique una versión concreta o que desaparezcan las críticas. Esas respuestas dependen de terceros y de la evidencia disponible.
Cuéntanos sobre tu proyecto
Responde cuatro preguntas rápidas y en menos de una hora te enviamos un plan, plazos y un rango de presupuesto. Todo es confidencial.
Cargando el formulario…