Interne Release Notes: Wer noch wissen muss, was kam
5 Min. Lesezeit
Jeder andere Artikel in diesem Hub geht davon aus, dass die Leserin einer Release Note eine Kundin ist. Support, Vertrieb und Customer Success lesen auch, oder versuchen es, und die meisten von ihnen erfahren, was ausgeliefert wurde, indem zuerst eine Kundin danach fragt. Diese Reihenfolge ist verkehrt, und sie ist auch in den meisten Unternehmen der Standard, weil der Release-Prozess in dem Moment endet, in dem die kundenseitige Notiz rausgeht, und niemand einen zweiten, kleineren Schritt für die Leute gebaut hat, die eine Stunde später Fragen dazu beantworten müssen.
Was ist eine interne Release Note, und wie unterscheidet sie sich von einer kundenseitigen?
Es ist ein kürzeres Dokument, geschrieben für Leute, die das Produkt schon gründlich kennen, das ihnen sagt, was sich geändert hat und was in ihrem konkreten Job zu tun ist. Ein Support-Mitarbeiter braucht nicht die geschliffene Rahmung, die eine kundenseitige Ankündigung nutzt; er muss wissen, wie die Änderung gerade im Produkt aussieht, was die wahrscheinlichste Frage dazu sein wird, und ob offene Tickets betroffen sind. Eine kundenseitige Notiz verkauft die Änderung. Eine interne rüstet jemanden aus, damit sie den Umgang damit beherrscht.
| Publikum | Was sie wissen müssen | Wo sie es brauchen |
|---|---|---|
| Support | Was sich im UI geändert hat, wahrscheinliche Fragen, betroffene offene Tickets | Wo sie ohnehin schon nachsehen |
| Vertrieb | Was es für einen Deal entblockt, was es noch nicht kann | Wo sie sich auf Gespräche vorbereiten |
| Customer Success | Was bestehenden Kundinnen gesagt werden sollte, und wer danach gefragt hat | Wo sie Outreach planen |
| Führung | Was gegen das Versprochene ausgeliefert wurde, und wann | Eine kurze, wiederkehrende Zusammenfassung, nicht pro Release |
Warum erfahren interne Teams so spät von Launches?
Weil der Release-Prozess meist um ein Artefakt herum gebaut ist, die kundenseitige Notiz oder den Changelog-Eintrag, und alles Interne wird als Konsequenz aus dem Lesen dieses einen Dokuments angenommen. Das stimmt nicht. Support-Mitarbeiterinnen sind mit dem Ticket vor sich beschäftigt, nicht damit, ein Changelog nach Kontext zu durchsuchen, und eine für eine Kundin geschriebene Notiz lässt oft genau das operative Detail weg, das eine Mitarbeiterin braucht, etwa welchem Plan das Feature zugeordnet ist oder wie die Fehlermeldung aussieht, wenn es fehlschlägt. Bis eine Kundin danach fragt, liest die Mitarbeiterin dieselbe öffentliche Notiz, die die Kundin gerade gelesen hat, ohne jeden Vorsprung.
Was sollte eine interne Release Note sagen, was eine kundenseitige nicht sagt?
Die operativen Details, die eine kundenseitige Notiz absichtlich weglässt. Welche Pläne oder Accounts es haben. Wie es aussieht, wenn etwas schiefgeht, und was einer Kundin gesagt werden soll, die darauf stößt. Ob es offene Tickets oder Requests schließt, und welche, damit eine Mitarbeiterin, die an einem verwandten Ticket arbeitet, weiß, dass sie nachsehen sollte. Wer im Team es verantwortet, falls eine Frage über die Notiz hinausgeht. Nichts davon gehört in die kundenseitige Version, die geschrieben ist, um einmal von jemandem außerhalb des Unternehmens gelesen zu werden; all das ist genau das, was jemand, der dieselbe Frage vierzigmal pro Woche beantwortet, tatsächlich braucht.
Interne Notiz: Bulk-CSV-Export (Release am 08.09.2026)
- Nur für Team- und Enterprise-Pläne. Free und Pro sehen keine
Änderung.
- Häufiger Fehler: Exporte über 50.000 Zeilen laufen in ein
Timeout; bekanntes Problem, Fix separat verfolgt. Der Kundin
raten, nach Datumsbereich zu filtern.
- Schließt 14 offene Requests mit dem Tag `bulk-export`.
Antwortvorlage im geteilten Dokument.
- Verantwortlich: Platform-Team, #platform-eng für alles über
diese Notiz hinaus.Vier Zeilen, auf die eine Support-Mitarbeiterin sofort reagieren kann, von denen keine in den öffentlichen Changelog-Eintrag für dasselbe Feature gehören würde.
Wer sollte sie schreiben, und wann?
Wer auch immer die kundenseitige Notiz schreibt, ist meist die richtige Person, weil sie den vollen Kontext schon hat, aber es sollte ein separater, kurzer Durchgang sein statt der Versuch, ein Dokument beide Zielgruppen bedienen zu lassen. Sie zu verschmelzen erzeugt entweder eine kundenseitige Notiz voller interner Details oder eine interne Notiz, die zu poliert ist, um wirklich nützlich zu sein, und in der Praxis geht es schneller, zwei kurze Dokumente zu schreiben, als ein Dokument dazu zu verhandeln, zwei Zielgruppen gleichzeitig zu bedienen. Das Timing zählt mehr als die Autorschaft: die interne Notiz muss vor der kundenseitigen rausgehen, und sei es nur um ein paar Stunden, damit Support nie von einer Änderung am selben Ort erfährt wie eine Kundin.
Wo sollte sie liegen, damit Support sie im Moment eines Tickets tatsächlich findet?
Dort, wo das Team ohnehin schon nachsieht, wenn ein Ticket reinkommt, nicht in einem separaten Changelog, das niemand einen Grund hat, proaktiv zu öffnen. Ein Support-Team, das eine geteilte Wissensdatenbank nutzt, braucht die Notiz dort, verlinkt von der Stelle, an der Tickets zu diesem Produktbereich schon getaggt werden. Ein Team, das in einem geteilten Kanal lebt, braucht sie dort gepostet, durchsuchbar, im Moment, in dem sie relevant ist, statt in einem täglichen Digest begraben, den sie einmal überfliegen. Das kundenseitige Muster aus gezielter Benachrichtigung versus Digest gilt auch hier: eine interne Notiz zu einer konkreten, bevorstehenden Änderung sollte das Team direkt erreichen, nicht auf eine wöchentliche Zusammenfassung warten, die ankommt, nachdem das erste Ticket schon da ist.
Braucht sie dieselbe Sorgfalt bei der Überprüfung wie die externe?
Weniger, und das ist Absicht. Eine kundenseitige Notiz vertritt das Unternehmen öffentlich und verdient einen sorgfältigen Redigierdurchgang; eine interne Notiz existiert, um schnell und konkret zu sein, und sie am selben Politur-Maßstab zu messen ist meist genau das, was Teams dazu bringt, sie gar nicht erst zu schreiben. Eine schnelle, etwas raue interne Notiz, die eine Stunde vor dem Launch rausgeht, schlägt eine polierte, die am Tag danach ankommt, nachdem das erste Support-Ticket schon verwirrt reingekommen ist.
FAQ
Sollten interne Release Notes denselben Freigabeprozess durchlaufen wie kundenseitige? Nein. Ein leichterer, schnellerer Durchgang ist der Punkt. Denselben Review zu verlangen macht aus einer taggleichen internen Notiz eine für die nächste Woche, bis wann Support die Frage schon ohne sie beantwortet hat.
Wer verantwortet interne Release Notes, wenn es keine dedizierte interne Kommunikationsrolle gibt? Wer auch immer die kundenseitige Notiz schreibt, als zweiten, kurzen Durchgang direkt danach. Es braucht keine separate Verantwortliche, nur die Gewohnheit, die kundenseitige Notiz nicht als einziges Artefakt eines Releases zu behandeln.
Brauchen interne Release Notes ein eigenes Changelog oder Archiv? Ein durchsuchbarer Ort schlägt ein chronologisches Archiv, durch das niemand scrollt. Hat Support schon eine Wissensdatenbank, gehört die Notiz dorthin, zum Feature getaggt, statt in ein separates internes Changelog, das nur jemandem hilft, der das Ausliefer-Datum schon kennt.
Was ist das Risiko, interne Release Notes bei kleinen Änderungen zu überspringen? Kleine Änderungen sind genau die, nach denen Support ohne Vorwarnung gefragt wird, weil eine kleine Änderung selten eine unternehmensweite Ankündigung bekommt. Die Größe der Release Note sollte mit der Größe der Änderung skalieren; sie sollte nie auf null fallen, nur weil die Änderung klein war.
Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft. Wenn etwas nicht stimmt, sagen Sie es uns, und wir korrigieren es.