# E-mailmarketing automatiseren: plan eerst de statuscontroles

Canonieke URL: https://brew.new/nl/blog/email-marketing-automation-guide
Auteur: Thomas Park
Gepubliceerd: 2026-08-19
Bijgewerkt: 2026-09-29

Een e-mailautomatisering is een herhaalbare beslissing over wanneer je een bericht verstuurt. De editor is daar maar één onderdeel van. Het event, de actuele status van de klant en de regels om te stoppen zijn net zo belangrijk als de tekst.

Voordat je een reeks uittekent, schrijf je op waarom elk bericht moet bestaan en wat het ongepast zou maken op het moment dat het wordt verstuurd.

## Definieer de trigger en de bijbehorende data

Een aanmelding, een afgeronde aankoop, een mislukte betaling of een mijlpaal in het product kan een automatisering starten. Geef het event een duidelijke betekenis. “Gebruiker actief” is vaag; “eerste rapport geëxporteerd” kan de applicatie vastleggen en testen.

Neem alleen de data op die het bericht nodig heeft, met stabiele ID’s en waar relevant een tijdstempel. Bepaal voor elke waarde welk systeem de eigenaar is. Bij de levering van events kunnen nieuwe pogingen plaatsvinden, dus gebruik de idempotentie die je integratie ondersteunt en test wat er gebeurt bij een dubbele levering.

De [integratie met Stripe](/nl/browse/integrations/stripe) levert gedocumenteerde events voor abonnementen en betalingen. Aangepaste events uit je applicatie kunnen mijlpalen dekken die specifiek zijn voor je product.

## Scheid een wachtstap van een controle op wie in aanmerking komt

Een wachtstap verandert wanneer de volgende stap wordt uitgevoerd. Op zichzelf werkt hij de feiten die de automatisering kent niet bij.

In een eventgestuurde flow in Brew maken filterstappen en splitsingen op basis van een voorwaarde onderscheid tussen eventdata en contactdata. `activated` of `payload.activated` leest het oorspronkelijke event. Een aanmeldpayload met `activated: false` kan morgen al achterhaald zijn. `contact.activated` leest het actuele contactveld van de ontvanger in Brew op het moment dat die voorwaarde wordt uitgevoerd, ook na een wachtstap.

Voor een herinnering om het instellen af te ronden definieer je een booleaans contactveld `activated`, houd je het gesynchroniseerd vanuit je applicatie en zet je na de wachtstap een filter `contact.activated equals false`. Een ontbrekende waarde is niet hetzelfde als false, dus test allebei. Zet een voorwaarde vóór elke latere herinnering die van deze status afhangt; een update van het contact of een nieuw event annuleert een lopende run niet automatisch.

Bij het uitlezen van het contact wordt je productdatabase of betaalprovider niet bevraagd. Hangt de vraag of iemand in aanmerking komt af van activiteit die niet wordt gesynchroniseerd, van een specifieke factuur of van de actuele inhoud van een winkelwagen, plan die controle dan in je applicatie. Lees op het moment dat de herinnering aan de beurt is het leidende record, en verstuur alleen een nieuw event voor wie in aanmerking komt als de herinnering dan nog zinvol is.

De [gids over reeksen voor de proefperiode](/nl/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events) behandelt beide aanpakken. De [documentatie over automatiseringen](https://docs.brew.new/create-emails/build-an-automation#check-state-before-later-reminders) legt uit hoe je in voorwaarden naar velden verwijst.

## Begin met één nuttige reeks

Een welkomstautomatisering kan het materiaal of de volgende stap leveren die je bij de aanmelding hebt beloofd. Een betalingsmelding kan een echte gebeurtenis in de facturering uitleggen. Een e-mail bij een mijlpaal in het product kan iemand helpen het resultaat te gebruiken van wat die net heeft afgerond.

Houd de eerste versie klein genoeg om alles goed te kunnen nalopen. Leg voor elk bericht de doelgroep, de trigger, de verplichte velden, de beoogde actie en de voorwaarden vast die een verzending moeten tegenhouden. Neem de inschrijfstatus en de afhandeling van suppressies mee in die controle.

In Brew bepalen gepubliceerde automatiseringen wat er wordt uitgevoerd. Een concept maken of bewerken is niet hetzelfde als het publiceren. Integratie-instellingen en de status van een automatisering hebben elk een eigen taak: zo regelt de Stripe-instelling **Volledige naam synchroniseren** het bijwerken van namen, niet of automatiseringen die door events starten, worden uitgevoerd.

## Test veranderingen in de status

Test een normale run, ontbrekende optionele velden, een dubbel event, een marketingcontact dat zich heeft afgemeld en een klant van wie de status verandert voordat een herinnering aan de beurt is. Werk bij contactvoorwaarden het veld in Brew bij tijdens de wachttijd en controleer of de latere voorwaarde de herinnering overslaat. Controleer bij herinneringen die je applicatie inplant of de applicatie geen nieuw event verstuurt als de klant niet meer in aanmerking komt.

Bekijk naast de gegevens van de run ook de echte e-mail. Controleer links, personalisatievelden, het verzenddomein en de exacte gepubliceerde versie. Een geslaagd triggerverzoek alleen bewijst niet dat het juiste bericht in de juiste inbox is beland.

## Herzie de automatisering als het product verandert

Een reeks die permanent loopt, kan ongemerkt verouderen als de stappen om iets in te stellen, de prijzen of de toegang tot het product veranderen. Geef elke reeks een eigenaar en controleer hem na elke relevante release.

Meet de beoogde uitkomst en de ongewenste effecten. Is het doel dat mensen het instellen afronden, volg die actie dan naast klachten en afmeldingen. Gebruik de [gids over metrics](/nl/blog/email-metrics-that-matter) om te voorkomen dat je openingen als bewijs ziet dat de automatisering heeft geholpen.