# E-mailreeks voor SaaS-proefgebruikers bouwen met productevents

Canonieke URL: https://brew.new/nl/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events
Auteur: Thomas Park
Gepubliceerd: 2026-09-26
Bijgewerkt: 2026-09-29

Een e-mail voor de conversie van proefgebruikers hoort in te spelen op wat de gebruiker heeft gedaan. Wie nog geen project heeft aangemaakt, heeft hulp bij het instellen nodig. Wie het product elke dag gebruikt, heeft een duidelijke uitleg over het betaalde abonnement nodig. Stuur je die twee mensen hetzelfde aftelbericht, dan mis je dat verschil.

Deze gids houdt het ontwerp van de reeks gescheiden van de logica in je applicatie die bepaalt wie welke e-mail krijgt.

## Kies een activatie-event

Kies één actie waaruit blijkt dat de gebruiker het eerste nuttige resultaat in het product heeft bereikt. Maak die specifiek genoeg om in je backend vast te leggen: een aangemaakt project, een afgeronde import of een uitgenodigde teamgenoot. Een paginaweergave is op zichzelf zelden genoeg.

Leg het moment van aanmelding, het einde van de proefperiode, de activatie en de betaalstatus vast in het systeem dat eigenaar is van die feiten. Zie contactvelden in het e-mailplatform als gesynchroniseerde data, niet als bewijs dat een eerder gestarte flow de actuele status leest.

## Geef elk bericht één taak

| Bericht | Wanneer het nuttig is | Voorwaarde op het verzendmoment |
| --- | --- | --- |
| Welkom | Na aanmelding of verificatie | Het account bestaat en mag dit bericht ontvangen |
| Hulp bij het instellen | Ongeveer twee dagen later, afgestemd op je product | Nog niet geactiveerd |
| Volgende nuttige actie | Na activatie | Geactiveerd en die actie nog niet afgerond |
| Einde proefperiode | Vóór de echte einddatum van de proefperiode | De proefperiode loopt nog en het account is niet betaald |
| Laatste check-in | Na het einde van de proefperiode, als dat past | Nog niet betaald, komt in aanmerking en mag marketing ontvangen |

Deze timings zijn startpunten voor een test, geen gemeten best presterende tussenpozen. Noem de echte einddatum van de proefperiode en wat er daarna gebeurt. Verzin geen schaarste en suggereer geen afschrijving als er geen betaalmethode bekend is.

## Kies de bron voor je controles op wie in aanmerking komt

In een eventgestuurde flow in Brew leest `payload.activated` het oorspronkelijke event, terwijl `contact.activated` het actuele contactveld van de ontvanger in Brew leest op het moment dat een filterstap of een splitsing op basis van een voorwaarde wordt uitgevoerd. Wil je na de activatie geen herinneringen over het instellen meer sturen, definieer dan dat booleaanse veld, houd het gesynchroniseerd vanuit je product en controleer na elke relevante wachtstap `contact.activated equals false`. Een ontbrekende waarde is niet hetzelfde als false; test die apart.

Die voorwaarden lezen het opgeslagen contact in Brew, niet de database van je applicatie of een live verzoek aan Stripe. Een binnenkomend activatie- of betaalevent annuleert een eerdere run niet automatisch. De flow heeft een voorwaarde nodig vóór elke verzending die van de status afhangt.

Voor feiten buiten Brew laat je je applicatie een job inplannen. Is die aan de beurt, lees dan het actuele account of de actuele factuur en verstuur alleen een apart aangepast event naar Brew als de ontvanger nog in aanmerking komt. Neem in dat nieuwe event de actuele data op die je voor personalisatie nodig hebt.

Een herinnering die je applicatie inplant, werkt bijvoorbeeld zo:

```text
Signup committed → fire welcome event
Reminder job becomes due → read current account
  Already activated or paid → finish without firing an email event
  Still eligible → fire setup-reminder event with current data
```

Gebruik de echte trigger-ID die Brew teruggeeft en het gedeclareerde schema van de trigger. Volg de [handleiding voor het opzetten van automatiseringen](https://docs.brew.new/create-emails/build-an-automation) en de documentatie over [getypeerde payloadcontracten](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Gebruik het gedocumenteerde idempotentiemechanisme voor events die je opnieuw verstuurt.

## Gebruik Stripe voor de feiten waarvan Stripe eigenaar is

Beheert Stripe de proefperiode, dan leveren de abonnementsevents van Stripe de context over facturering. De [Stripe-integratie](/nl/browse/integrations/stripe) biedt ondersteunde eventtriggers, waaronder `customer.subscription.trial_will_end`. Je applicatie blijft eigenaar van de activatie in het product, tenzij je die informatie apart doorstuurt.

Controleer voor een latere herinnering over een betaling het actuele record in Stripe. Een geslaagde update van de kaart bewijst niet dat een factuur is betaald. Stem af met de e-mails die Stripe zelf verstuurt, zodat de klant per doel één melding krijgt.

## Schrijf de e-mail pas na de regel voor wie in aanmerking komt

Begin bij de echte situatie van de ontvanger. Leg één nuttige actie uit en link er direct naartoe. Een e-mail over het instellen kan een kort voorbeeld en een antwoordadres bieden. Een e-mail over het betaalde abonnement beschrijft de relevante limiet of functie en de echte prijs, met een link naar de actuele prijzen.

Zorg dat de toestemming voor marketing, de afhandeling van afmeldingen en het doel van het domein passen bij het bericht. Een aanmelding voor een proefperiode rechtvaardigt geen promotionele e-mail die er niets mee te maken heeft.

## Bewijs dat het uitstromen werkt

Test wat er gebeurt als een contact activeert of betaalt vóór elke controle op wie in aanmerking komt. Werk bij contactvoorwaarden tijdens de wachttijd de betreffende velden in Brew bij en controleer of de herinnering wordt overgeslagen. Ga bij controles die je applicatie inplant na of accounts die niet in aanmerking komen geen herinneringsevent opleveren. Test ook nieuwe pogingen, verlengde proefperiodes, verwijderde accounts, afmeldingen en ontbrekende velden. Bekijk zowel de logs van je applicatie als de uitvoeringsgeschiedenis in Brew.

Beoordeel activatie en conversie naar een betaald abonnement met je productdata, en bezorgfouten met het e-mailplatform. Openratio’s alleen laten niet zien of de reeks een proefgebruiker heeft geholpen. Zie [het ontwerp van welkomstreeksen](/nl/blog/welcome-email-sequence) voor voorbeelden en [MCP versus REST](/nl/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use) voor de taakverdeling in de implementatie.