Einsetzen, wenn Sie ein Update ausliefern und aktuellen Nutzern sagen müssen, was sich geändert hat und was sie tun müssen.
feature-release-note-email.md
Sie schreiben Produktkommunikation. Schreiben Sie eine Release-Note-E-Mail für bestehende Kunden.
Produkt: {{PRODUCT_NAME}}
Was sich geändert hat: {{CHANGES}}
Wer betroffen ist und wer nicht: {{AFFECTED_USERS}}
Handlung, die der Kunde ausführen muss, und bis wann: {{REQUIRED_ACTION_AND_DATE}}
Was entfernt, umbenannt wurde oder sich nun anders verhält: {{BREAKING_CHANGES}}
Wo die Dokumentation liegt: {{DOCS_LINK}}
Ausgabe in dieser Reihenfolge:
1. Betreff und Preheader, die die Änderung nennen, nicht die Begeisterung.
2. Eine einsätzige Zusammenfassung, die ein beschäftigter Kunde in der Vorschau lesen kann.
3. Abschnitt "Was Sie tun müssen". Wenn nichts, schreiben Sie "nichts" mit genau diesem Wort.
4. "Was sich geändert hat" als kurze Liste, jeder Punkt als vorher und nachher formuliert.
5. "Was entfernt oder umbenannt wurde", mit dem Migrationsweg für jeden Punkt.
6. Wo es Hilfe gibt.
Regeln:
- Breaking Changes stehen immer über den netten Extras.
- Daten müssen absolut sein, etwa 12. März 2026, nicht "nächste Woche".
- Beschreiben Sie eine Änderung nicht als Verbesserung, wenn sie etwas entfernt, auf das ein Kunde angewiesen war. Sagen Sie, was entfernt wurde.
- Keine Gedankenstriche, keine Marketingadjektive, keine Entschuldigungsfloskeln, keine Schlusszusammenfassung.
- Wenn eine von mir gegebene Änderungsbeschreibung mehrdeutig ist, führen Sie sie unter "Klärungsbedarf" auf, statt zu raten.
Ersetzen Sie jeden Platzhalter durch Ihre eigenen Angaben. Je genauer Sie sind, desto weniger erfindet das Modell.