El Mensajero de Malas Noticias: Redacte Actualizaciones Incómodas Sin Perder la Confianza
Por qué importa este prompt
How a setback is communicated changes customer and employee retention more than the severity of the setback itself. A vague, hedge-filled message about a delay reads as a signal that something worse is being hidden, which is what actually pushes clients to start quietly evaluating alternatives — even when the underlying relationship was healthy going in. Internally, a rambling, defensive layoff or cancellation announcement is the version of the message that gets forwarded, screenshotted, and remembered for years after the actual decision is forgotten.
Para qué lo usamos
You are a product manager who just learned that the client-facing integration promised for Q1 is being pushed to Q3, because the two engineers who were building it got reassigned last week to an urgent security patch. You have to tell the client's VP of Operations today, by email, before she hears about the delay secondhand from your account executive during tomorrow's renewal call.
Prompt
You are a seasoned [SENIOR MANAGER / INTERNAL COMMUNICATIONS LEAD / TEAM LEAD] who has delivered hundreds of difficult updates — project delays, budget cuts, canceled initiatives, negative decisions — without losing the trust of the people receiving them. CONTEXT: - What happened: [DESCRIBE THE SITUATION PLAINLY — what changed, why, what you already tried before it got to this point] - Who is affected: [DESCRIBE THE AUDIENCE, e.g., "my 6-person engineering team," "an enterprise client who pays for priority support," "the whole company, ~200 people"] - Relationship context: [DESCRIBE THE CURRENT STATE OF TRUST, e.g., "generally strong, this is our first real setback together" or "already strained from a missed deadline last quarter"] TASK — complete all three steps, in order, without skipping the self-critique: Step 1 — DRAFT. Write the message delivering this news. Lead with the actual news in the first two sentences — do not bury it under context or preamble. State the concrete impact on the reader before explaining the cause. Include one specific, concrete next step or remedy, even if the remedy is only partial. Step 2 — SELF-CRITIQUE. Now switch roles. Read your own Step 1 draft as the most skeptical, least charitable person who could receive it. List every sentence that could read as evasive, overly corporate, defensive, or like it is minimizing the problem. Flag any place where the lede was buried or excuses were front-loaded before the actual news. Be specific about which words or phrases trigger each flag — do not just say "tone could be better." Step 3 — REVISE. Produce a final version that fixes every issue flagged in Step 2. Do not introduce new hedging while fixing the old hedging. CONSTRAINTS: - No corporate hedge language: ban phrases like "due to unforeseen circumstances," "moving forward," "we take this seriously," "at this time" - Name the actual cause plainly, even if it is an internal mistake - Apologize at most once, and only if someone on our side is actually at fault - Maximum 2 sentences before the core news is stated - Match this tone/formality: [E.G., "casual Slack message to my own team" OR "formal email to an enterprise client's VP"] - Target length: [E.G., "under 150 words" OR "under 300 words"] OUTPUT FORMAT: 1. Draft v1 (the message) 2. Self-Critique (bulleted list, each bullet quoting the exact flawed phrase and naming the specific problem) 3. Final Revised Version (ready to send as-is)
Resultado
Draft v1:
Subject: Integration Delay — Moving From Q1 to Q3
Hi Sarah,
I need to tell you that the client integration we committed to for Q1 is now going to ship in Q3 instead. Due to an unexpected shift in our engineering priorities, the two engineers assigned to your integration were moved onto a critical security patch last week, and we don't expect to have resources back on your project until April.
We understand this is frustrating and we take this delay seriously. We want to assure you that we remain fully committed to delivering a high-quality integration, and we will keep you updated as things progress. Please let us know if you have any questions, and thank you for your continued patience and partnership.
Best,
[Name]
Self-Critique:
- «Due to an unexpected shift in our engineering priorities» — this is a vague corporate hedge. It never names the actual cause (a security patch pulled the engineers away). Reads as evasive.
- «we take this delay seriously» — banned boilerplate phrase. Adds zero information and signals a template response.
- «We want to assure you that we remain fully committed» — generic reassurance with no concrete action attached. Sounds defensive rather than helpful.
- «we will keep you updated as things progress» — no specific date or mechanism given. Reads as a brush-off, not a commitment.
- «thank you for your continued patience and partnership» — the message closes by asking the client for patience instead of ending on a concrete remedy. This minimizes the real inconvenience to her Q1 plans.
- The actual news (Q1 to Q3) is stated but delayed by «I need to tell you that» throat-clearing — tighten the opening.
- No interim remedy is offered anywhere — the message describes the problem but gives Sarah nothing she can use in the meantime.
Final Revised Version:
Subject: Integration Delay — Moving From Q1 to Q3
Hi Sarah,
Your integration is moving from Q1 to Q3. The two engineers assigned to it were pulled last week onto an urgent security patch for existing customers, and that patch takes priority through April.
I know this affects your own Q1 commitments to your team, so here's what we can do in the meantime: I can get you a working sandbox build of the current integration state by January 15, so your team can start testing against it even though the full release waits until Q3. I'll also set up a bi-weekly 15-minute check-in starting next week so you're not waiting until Q3 to hear anything.
I'm sorry for the disruption this causes on your side — happy to get on a call today if that's more useful than email.
[Name]
La mayoría de los consejos sobre cómo dar malas noticias se centran en el tono: sea empático, sea claro, sea amable. Ese consejo es correcto y, a la vez, inútil por sí solo, porque quienes escriben estos mensajes ya saben que deben sonar empáticos y claros. Lo que realmente descarrila un mensaje difícil es un lenguaje concreto y identificable: la frase evasiva que se cuela porque parece más segura, la excusa que se coloca antes de la noticia real, la promesa vaga de «te mantendremos informado» que no compromete a nada. Este prompt está diseñado para detectar esos fallos específicos, en lugar de dar un consejo genérico sobre el tono.
Por qué existe el paso de autocrítica
La mayoría de los prompts de escritura con IA se detienen después de producir un borrador. Este obliga a una segunda pasada en la que el modelo debe leer su propia salida como el destinatario más escéptico posible y nombrar, por escrito, cada frase que haría que ese destinatario confiara menos en el mensaje. Esto funciona porque un modelo de IA que redacta un mensaje y un modelo de IA que critica un mensaje aplican, funcionalmente, criterios de evaluación distintos: la pasada de redacción optimiza para «sonar profesional y completo», mientras que la pasada de crítica optimiza para «¿le creería esto un lector escéptico?». Ambos criterios a menudo entran en conflicto, y el lenguaje evasivo corporativo es exactamente lo que satisface el primero mientras falla en el segundo.
Por qué las restricciones prohíben frases específicas en lugar de dar orientación general
«Debido a circunstancias imprevistas», «nos tomamos esto muy en serio» y «de cara al futuro» están prohibidas por nombre y no por categoría, porque los modelos (y las personas) recurren de forma fiable a estas frases exactas cuando se les pide escribir algo difícil: son los clichés fundamentales de las malas noticias corporativas. Prohibirlas por nombre obliga al modelo a encontrar las palabras reales para lo que ocurrió, lo cual suele ser a la vez más honesto y más específico que la evasiva que reemplaza.
Por qué useCase y whyItMatters se mantienen separados
El caso de uso describe un escenario único y concreto: un retraso específico, una parte interesada específica, una presión de plazo específica. El argumento de «por qué importa» trata sobre el costo posterior de hacer esto mal en general: la confianza dañada se acumula silenciosamente, y un contratiempo mal gestionado a menudo causa más deserción que el contratiempo en sí. Mantener estos dos elementos separados es deliberado: un lector debe poder reconocer su propia situación en el caso de uso mientras entiende lo que está en juego a través del segundo campo, sin que ambos se repitan entre sí.
Cómo adaptarlo
Los tres campos entre corchetes —rol, contexto y audiencia— son suficientes para ejecutar esto en casi cualquier mensaje profesional difícil: un plazo incumplido, un recorte de presupuesto, un proyecto cancelado, una evaluación de desempeño negativa, incluso una disculpa personal que necesita mantenerse específica en lugar de genérica. La estructura (borrador, luego autocrítica escéptica, luego revisión) es la parte reutilizable; el contenido es cualquier cosa difícil que realmente necesite decir esta semana.