Onboarding e-mailreeks: bouw op events, niet op dagen
Samenvatting
Een onboarding e-mailreeks werkt als hij reageert op wat een nieuwe gebruiker doet, niet op het aantal dagen dat voorbij is. Bouw hem rond één activatie-event en laat elke e-mail volgen op een signaal. Begin met een welkomstmail, voeg een nudge van 24 uur toe die alleen verstuurd wordt als de eerste actie ontbreekt, en bepaal de uitgangsregels voordat je de tekst schrijft. Meet click-to-activate tegen een holdout-groep, niet het openpercentage.
Een onboarding e-mailreeks werkt als hij reageert op wat een nieuwe gebruiker doet, niet op het aantal dagen dat voorbij is. Bouw hem rond één activatie-event, verstuur elke e-mail omdat er een signaal is, en geef elke e-mail een uitgangsconditie. Een vast schema met dag 1, dag 3 en dag 7 is het vangnet, niet het ontwerp.
Veel teams doen het omgekeerd. Ze schrijven vijf e-mails, zetten er vertragingen op en gaan live. Zes weken later is de activatie niet gestegen, en niemand kan zeggen welke e-mail daarvoor verantwoordelijk is.
Begin bij het activatie-event, niet bij de welkomstmail
De reeks bestaat om een aanmelding naar één meetbare actie te brengen. Kies die actie voordat je ook maar één zin schrijft. "Project aangemaakt" of "eerste API-aanroep verstuurd" telt. "Ingelogd" telt niet.
Leg ook het tijdvenster vast. Onze standaard is activatie binnen 14 dagen na aanmelding, geteld per aanmeldcohort. Zonder dat venster kun je twee versies van de reeks niet met elkaar vergelijken.
Werk daarna achteruit. Zet de stappen op een rij die een gebruiker moet zetten om dat event te bereiken, en geef elke stap hooguit één e-mail. Heeft een stap geen e-mail, dan doet de gebruiker het zelf, of je accepteert de uitval.
Sla de mail met de "rondleiding langs alle functies" over. Die beantwoordt op dag twee een vraag die niemand stelde. Eén e-mail, één actie, één link.
Hoe ziet een minimale reeks er in de praktijk uit?
Vijf e-mails dekken de meeste SaaS-producten met een proefperiode. Dit is de opzet die we zien standhouden, met de trigger bij elke e-mail.
Welkom: verstuurd bij
user.signed_up, binnen enkele seconden. Bevestigt het account, noemt de ene eerste actie en linkt er rechtstreeks naartoe.Nudge eerste actie: verstuurd 24 uur na aanmelding, alleen als het activatie-event van stap 1 nog niet is afgegaan.
Blokkade-hulp: verstuurd zodra een bekend foutsignaal verschijnt, zoals een ongeldige API-sleutel of een afgebroken import. Dit is de e-mail met de meeste waarde in de set.
Bewijs-mail: verstuurd op dag 3 naar gebruikers die begonnen maar niet afrondden. Eén klantresultaat, één getal met de context erbij.
Laatste-stap-duw: verstuurd wanneer de gebruiker nog één event van activatie verwijderd is, of op dag 7 als vangnet op basis van tijd.
Let op dat drie van de vijf voorwaardelijk zijn. De welkomstmail is de enige die naar iedereen gaat.
Welkomstmails halen ook de hoogste openpercentages die je ooit zult zien. Wees daar wantrouwig mee. Apple Mail Privacy Protection laadt afbeeldingen vooraf en blaast daarmee de opens op voor een groot deel van je lijst. Meet daarom click-to-activate.
Tijdgebaseerde drips falen bij de gebruikers die er het meest toe doen
Een pure tijdgebaseerde drip stuurt de dag-3-mail naar een gebruiker die al op dag 1 geactiveerd was. Die gebruiker krijgt te horen dat hij iets moet doen wat hij al heeft gedaan. Het leest als automatisering, en dat is het ook.
Het faalt ook de andere kant op. Een gebruiker die vastzit bij stap twee krijgt een vrolijke featuremail, geen hulp. De reeks ziet het probleem niet, dus kan ze er ook niet op reageren.
De oplossing is niet ingewikkeld, maar ze heeft een eventbron nodig. Gedragsreeksen hebben drie inputs nodig: de eventstroom, een staat per gebruiker, en een regel die die staat controleert vóór elke verzending.
{
"trigger": "user.signed_up",
"steps": [
{ "id": "welcome", "delay": "0s" },
{ "id": "first_action_nudge", "delay": "24h",
"send_if": "NOT event(project.created)" },
{ "id": "proof", "delay": "72h",
"send_if": "event(project.created) AND NOT event(first_send)" },
{ "id": "last_step", "delay": "7d",
"send_if": "NOT event(activated)" }
],
"exit_when": ["activated", "unsubscribed", "account.deleted"]
}De send_if-controle draait op het moment van verzenden, niet op het moment van inschrijving. Dat onderscheid doet ertoe. Evalueer je de voorwaarde bij het binnenkomen in de flow, dan bouw je een statisch segment, en is de staat tegen de tijd dat de mail vertrekt al verouderd.
De uitgangsconditie is de functie die iedereen vergeet
Elke reeks heeft een regel nodig die haar beëindigt. De voor de hand liggende is activatie. Twee andere worden vaak gemist: uitschrijving uit de onboardingstroom, en accountverwijdering of het aflopen van de proefperiode.
We hebben gezien dat reeksen gebruikers bleven mailen nadat ze betalend waren geworden. Dat is een bug in de uitgangsconditie, en die kost meer dan een gemiste open. Het leert de gebruiker dat je e-mails niet aan zijn account gekoppeld zijn.
Schrijf de uitgangsregels eerst en test ze eerst. Speel een paar echte gebruikerstijdlijnen door de flow in een staging-omgeving, en controleer dat elke tijdlijn stopt waar hij hoort te stoppen. Een reeks met goede teksten maar zonder uitgangen is slechter dan een reeks met eenvoudige teksten en schone uitgangen.
Waar komen de eventdata vandaan?
De kwaliteit van de reeks hangt af van de kwaliteit van het signaal. Er zijn drie gangbare bronnen, elk met een eigen latentie en eigen faalwijzen.
Een productanalysepijplijn zoals Segment stuurt events binnen seconden door, maar alleen de events die je hebt geïnstrumenteerd. Een directe webhook vanuit je backend is het betrouwbaarst, omdat hij afgaat vanuit het codepad dat het werk doet. Postgres change data capture ziet alles wat de rij raakt, ook wijzigingen door beheerscripts, en dat kan een feature zijn of een bug.
Kies één bron van waarheid voor het activatie-event en documenteer die naast de flowdefinitie, zodat de volgende engineer geen tweede bron toevoegt. Twee bronnen die enkele minuten uit elkaar lopen, leveren e-mails op die tegenspreken wat het product laat zien. Zo krijgt een gebruiker "Maak je setup af" nadat hij de setup al heeft afgerond.
Idempotentie speelt hier ook mee. Eventpijplijnen proberen opnieuw, dus hetzelfde project.created-event kan twee keer binnenkomen. Dedupliceert je sender niet op sleutel, dan krijgt de gebruiker dezelfde mail twee keer.
Customer.io is op dit model gebouwd: het neemt events op via een API, SDK's of een CDP, en triggert vanuit een workflowbouwer. Draai je op een andere stack, dan werkt hetzelfde patroon met elke sender die een trigger accepteert en voorwaarden evalueert op het moment van verzenden.
Transactioneel of marketing: kies bewust je stroom
Sommige onboardingmails zijn in de praktijk transactioneel. Een bericht "je API-sleutel staat klaar" of een e-mailverificatie mag niet wachten in een marketingwachtrij, en mag de verzendreputatie niet delen met een promotiecampagne.
Postmark maakt die splitsing tot ontwerpprincipe door berichtstromen op aparte infrastructuur te zetten. De redenering klopt, ook als je hun dienst niet gebruikt: een slechte promotieverzending mag nooit een wachtwoordreset vertragen.
Onze regel is eenvoudig. Kan de gebruiker niet verder zonder de e-mail, dan gaat hij over de transactionele stroom. Is de e-mail aanmoediging, dan gaat hij over de lifecycle-stroom, met een uitschrijflink die alleen die stroom raakt.
Voor lezers in de EU is die splitsing ook juridisch relevant. Een lifecycle-mail valt onder de regels van de AVG over toestemming of gerechtvaardigd belang, een transactionele mail meestal niet. Laat dat met je eigen jurist controleren, want wij zijn geen juridisch adviseur.
Verandert een developer-first sender de bouw?
Het verandert het startpunt. Bij een API-first sender leeft de reekslogica in je code of in een kleine worker, en levert de provider alleen af. Je krijgt versiebeheer, tests en code review voor je flows, en je verliest de visuele bouwer.
Resend kiest die route, met een REST API, officiële SDK's en React Email-templates. Voor een team dat e-mails al als componenten behandelt, is dat een logische keuze. Voor een growthteam dat teksten wil aanpassen zonder deploy, is het wrijving.
Wees eerlijk over wie de reeks bewerkt. Is het antwoord "growth, wekelijks", dan is een workflowbouwer de juiste keuze, ook als engineers er niet blij mee zijn. Is het antwoord "engineering, per release", houd de reeks dan in code.
Meet click-to-activate, niet opens
Het openpercentage is een zwak signaal voor deze taak. Mailprivacyfuncties blazen het op, en een open betekent niet dat de gebruiker iets deed. Drie getallen vertellen je meer.
Click-to-activate: van de gebruikers die op een bepaalde e-mail klikten, hoeveel bereikten het activatie-event binnen 24 uur.
Triggerlatentie: de tijd tussen het event en de verzending. Bij een blokkade-mail verliest elke vertraging van enkele minuten het moment.
Activatiepercentage tegen een holdout: houd een kleine groep aanmeldingen buiten de reeks en vergelijk hun activatie na 14 dagen met die van de rest.
De holdout is de enige manier om te weten of de reeks werkt. Zonder die groep schrijf je de e-mails activatie toe die er toch ook was gekomen.
We noemen hier geen benchmark voor het activatiepercentage, omdat de gepubliceerde cijfers van leveranciers met verschillende definities werken. Meet eerst je eigen uitgangspunt. Verander daarna één e-mail tegelijk.
Bouw je één reeks of meerdere?
Splits op instapconditie, niet op persona-labels. Een gebruiker die via een uitnodiging is aangemeld, heeft een andere eerste actie dan iemand die alleen kwam. Een gebruiker die data heeft geïmporteerd, is al over een grens gegaan die de anderen nog niet hebben bereikt.
Twee of drie instapwegen zijn meestal genoeg. Meer en de onderhoudskosten wegen zwaarder dan de winst, want elke weg heeft eigen uitgangen en tests nodig.
Een alles-in-één-platform kan het opzetwerk verminderen als het team klein is. Brevo bundelt e-mail, sms en een CRM onder één login, wat past bij teams die nog geen eventpijplijn willen bouwen. De keerzijde is dat het marketingdashboard centraal staat, en subseconde triggers zijn niet waar het voor geoptimaliseerd is.
Wat we als eerste zouden uitrollen
Zet het activatie-event en het venster van 14 dagen op één regel. Bouw de welkomstmail en de nudge na 24 uur, met een send_if-controle en een schone uitgang. Voeg vanaf dag één een holdout toe van 5 tot 10 procent.
Laat de bewijs-mail en de laatste-stap-duw liggen tot je twee weken data hebt. Voeg de blokkade-mail toe zodra je de meest voorkomende fout in je logs kunt benoemen. Welk foutsignaal in jouw product koppel je als eerste?