De product-update e-mailtemplate die gelezen wordt

De product-update e-mail die gelezen wordt, is de e-mail die naar iemand is gestuurd die precies vroeg wat hij aankondigt. Al het andere concurreert met de rest van de inbox op interessantheid, een wedstrijd die een release-aankondiging de meeste weken verliest. Dat ene feit zou de vorm van de e-mail moeten bepalen voordat er een woord geformuleerd is: wie ontvangt hem, en wat deed die persoon om op de lijst te komen.

Wat is een product-update e-mail?

Het is een bericht dat bestaande gebruikers vertelt wat er veranderd is in een product dat ze al gebruiken. Er zijn vier verschillende soorten, en ze als één lijst behandelen is waarom openingsratio’s dalen. Elke soort heeft een andere trigger, een ander publiek en een andere aanvaardbare frequentie.

De meeste teams bouwen alleen de derde, sturen die naar iedereen, en concluderen dat product-update e-mails niet werken. De eerste twee dragen bijna alle waarde, omdat de lezer een voorafgaande reden heeft om geïnteresseerd te zijn, en het bericht aankomt terwijl die reden nog leeft.

Deze vier rijen zijn allemaal geschreven voor klanten. Sales, support en customer success moeten ook weten wat er uitkwam, meestal in een andere vorm dan deze vier; interne release notes behandelt wat dat document zou moeten zeggen en waarom het vóór de klantgerichte notitie moet uitkomen.

E-mail is een van meerdere kanalen die een lanceringsaankondiging kan gebruiken, niet het enige. Hoe je een nieuwe feature aankondigt behandelt de andere, en hoe je daartussen kiest op basis van hoe groot de feature echt is.

Wat gaat er in de template?

Zes blokken, in deze volgorde. Het eerste is degene die het vaakst ontbreekt en degene die het werk doet.

Onderwerp:  <wat er veranderd is, in de woorden van de lezer>

1. Waarom je dit ontvangt
   "Je vroeg in maart om CSV-export." of
   "Je integratie roept /v1/invoices aan, dat verandert op 15 januari."

2. Wat er veranderd is
   Eén zin. Wat nu mogelijk is, of wat nu kapot gaat.

3. Wat je moet doen
   Vaak "niets". Zeg dat expliciet, laat het niet impliciet.

4. Waar je het ziet
   Een link naar het changelog-item, niet naar de homepage.

5. Wanneer
   De datum van uitgave, of vanaf wanneer het geldt.

6. Hoe je je afmeldt
   Eén klik, en direct gerespecteerd.

Blok 1 is het verschil tussen een bericht en een algemene uitzending. Een lezer die op de eerste regel te horen krijgt dat dit de oplossing is van iets wat hij persoonlijk heeft aangevraagd, leest de rest. Zonder dat blok zijn blokken 2 tot en met 5 een nieuwsbrief, hoe goed ook geschreven.

Houd het geheel onder ongeveer 150 woorden. De e-mail is een verwijzing naar het changelog-item, en het item is waar detail thuishoort. Een e-mail die het hele item reproduceert, geeft de lezer geen reden om te klikken, en jou geen signaal of het iemand iets kon schelen.

Welke onderwerpregels werken?

Noem de wijziging, niet de release. “CSV-export is live” wint van “update van september” omdat het eerste een feit is dat de lezer kan beoordelen en het tweede een container is. Versienummers in het onderwerp zijn nuttig voor aanroepers van een API en ruis voor iedereen anders, weer een reden om de publieken te scheiden.

Vermijd het beweren van een voordeel waarmee de lezer niet heeft ingestemd. “Je rapporten zijn nu sneller” beweert iets over zijn ervaring; “Rapporten van meer dan 10.000 rijen laden nu in minder dan een seconde” meldt een wijziging en laat hem beslissen of het ertoe doet.

Wanneer stuur je er een, en aan wie?

Stuur een gerichte notificatie op het moment dat het ding wordt uitgebracht, naar de mensen die het vroegen, individueel. Stuur een breaking-change-melding zodra de datum vaststaat en nog eens vlak ervoor, naar de daadwerkelijk betrokken accounts in plaats van de hele lijst. Stuur een digest alleen als je genoeg wijzigingen hebt dat een lezer anders iets zou missen, en laat mensen zich apart inschrijven.

De lijst die je bijna nooit zou moeten gebruiken, is “alle gebruikers”. Die verandert een specifiek bericht in een generiek bericht, en traint afmelding. Segmenteer op gedrag dat je al opslaat: wie erom vroeg, wie dit endpoint gebruikt, wie op dit plan zit.

Heb je toestemming nodig om hem te sturen?

Voor bestaande klanten is een update over een dienst die ze gebruiken meestal een andere juridische vraag dan marketing naar een prospect, en het antwoord hangt af van waar ze zich bevinden en wat je hun bij aanmelding hebt verteld. In de EU is de relevante vraag welke rechtsgrond uit artikel 6 van de AVG van toepassing is, en in de Verenigde Staten dragen commerciële berichten specifieke eisen die zijn vastgelegd in de CAN-SPAM-nalevingsgids van de FTC. Beide eisen in de praktijk hetzelfde: zeg wie je bent, maak het doel duidelijk, en laat mensen kunnen stoppen.

Wat de grondslag ook is, houd transactionele en marketingstromen gescheiden op verzendniveau. Een breaking-change-melding waarvoor een klant zich heeft afgemeld omdat hij dezelfde lijst deelde met een promotionele digest, is een supportincident dat op zijn datum wacht.

Hoe ziet dit ingevuld eruit?

De gerichte notificatie, de meest waardevolle product-update e-mail en degene die de meeste teams nooit bouwen:

Onderwerp: CSV-export is live

Hoi Dana,

je vroeg in maart om CSV-export.

Het is vanochtend live gegaan. Rapporten hebben nu een
Exporteer-knop die een CSV van de huidige weergave genereert,
filters inbegrepen.

Niets te doen aan jouw kant. Het staat al aan voor je account.

  Details: example.com/changelog#csv-export
  Uitgebracht: 2 september 2026

Je ontvangt dit omdat je erom vroeg. Afmelden voor
verzoek-updates: <link>

Negentig woorden, en de lezer weet op de eerste regel waarom dit aankwam. Vergelijk dit met dezelfde wijziging in een maandelijkse digest, waar hij verschijnt als een van de negen punten en Dana geen reden heeft om te merken dat haar eigen verzoek is uitgegaan.

Wat moet je meten?

Niet alleen de openingsratio. Voor een gerichte notificatie is de vraag of de persoon die vroeg terugkwam en het ding gebruikte, dus het getal om te volgen is de klik naar het item en of dat account de functie binnen een week gebruikt. Voor een breaking-change-melding is het dekking: welk aandeel betrokken accounts opende vóór de datum, en met wie je individueel hebt opgevolgd.

Een digest is de enige van de vier waar een openingsratio veel betekent, en zelfs daar is hij nuttiger als trend tegen zijn eigen geschiedenis dan tegen een sectorbenchmark. Verschillende soorten product-update e-mails hebben verschillende taken, dus een gemiddeld cijfer over alle soorten beschrijft niets waarop je kunt handelen.

Hoe verschilt dit van release notes?

Release notes zijn een document dat beschikbaar blijft. De e-mail is een leveringsmechanisme dat eenmalig gebeurt. Dezelfde wijziging produceert beide, en de e-mail zou korter moeten zijn dan het item waarnaar hij verwijst. Beste praktijken voor release notes behandelt het document, en changelog vs release notes behandelt welke je aan het schrijven bent.

De relatie die het waard is om goed te krijgen: het changelog-item is de canonieke tekst en de e-mail citeert hem. Wanneer die twee uit elkaar lopen, vindt de lezer die klikt een andere beschrijving van de wijziging en vertrouwt hij beide niet meer. Eerst het item publiceren en daaruit de e-mail genereren elimineert de afwijking door constructie. Changeloop werkt aan zijn kant op dezelfde manier: een item wordt eenmaal beoordeeld en gepubliceerd op de pagina, de feed en de widget, en de persoon die erom vroeg via de widget wordt op de hoogte gebracht op het GitHub-issue dat van haar feedback werd gemaakt, en in de widget zelf. Changeloop verstuurt de e-mail niet; je e-mailtool citeert het gepubliceerde item.

FAQ

Hoe vaak moet een product-update e-mail uitgaan? Zo vaak als er iets specifieks is dat de ontvanger wil weten, wat voor een gerichte notificatie elke keer is dat zijn verzoek wordt uitgebracht en voor een digest maandelijks maximaal.

Moet de e-mail het hele changelog-item bevatten? Nee. Eén zin en een link. Het item is de canonieke versie, en een volledige kopie in de e-mail betekent twee teksten die op elkaar afgestemd moeten blijven.

Welke openingsratio moet ik verwachten? Vergelijk elke soort met zichzelf in plaats van met een benchmark. Een gerichte notificatie en een maandelijkse digest zijn verschillende producten, en ze middelen verbergt het enige cijfer dat de moeite waard is om te volgen.

Heb ik een aparte lijst nodig voor breaking changes? Ja, en het moet de lijst zijn waarvan mensen zich niet achteloos kunnen afmelden zonder het gevolg te begrijpen, want het is de lijst die hen een storing kost.

De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.

Meer op changeloop: Changelog-voorbeelden, Documentatie voor ontwikkelaars