Onboarding mejlsekvens: bygg den på händelser, inte dagar

En onboarding mejlsekvens fungerar när den reagerar på vad en ny användare gjorde, inte på hur många dagar som har gått. Bygg den kring en enda aktiveringshändelse, skicka varje mejl på grund av en signal och ge varje mejl ett villkor för när det ska sluta. Ett fast schema med dag 1, dag 3 och dag 7 är reservplanen, inte designen.

De flesta team gör tvärtom. De skriver fem mejl, lägger in fördröjningar och skickar. Sex veckor senare har aktiveringen inte rört sig, och ingen kan säga vilket mejl som är ansvarigt.

Börja med aktiveringshändelsen, inte välkomstmejlet

Sekvensen finns för att flytta en registrering till en mätbar handling. Välj den innan du skriver en enda rad kopia. "Skapade ett projekt" eller "skickade första API-anropet" duger. "Loggade in" duger inte.

Bestäm också tidsfönstret. Vår standard är aktivering inom 14 dagar från registrering, räknat per registreringskohort. Utan fönstret går det inte att jämföra två versioner av sekvensen.

Arbeta sedan baklänges. Lista stegen en användare måste ta för att nå händelsen, och ge varje steg högst ett mejl. Om ett steg saknar mejl gör användaren det på egen hand, eller så accepterar du att någon hoppar av.

Hoppa över mejlet med en funktionsrundtur. Det svarar på en fråga ingen ställde på dag två. Ett mejl, en handling, en länk.

Hur ser en minimal sekvens ut i praktiken?

Fem mejl täcker de flesta SaaS-produkter med provperiod. Här är formen vi ser hålla, med triggern för varje mejl.

• Välkomst: skickas på user.signed_up, inom några sekunder. Bekräftar kontot, namnger den enda första handlingen och länkar direkt dit.

• Påminnelse om första steget: skickas 24 timmar efter registrering, men bara om aktiveringssteg 1 inte har inträffat.

• Hjälp vid hinder: skickas när en känd felsignal dyker upp, till exempel en ogiltig API-nyckel eller en avbruten import. Det här är det värdefullaste mejlet i setet.

• Bevismejl: skickas på dag 3 till användare som började men inte slutförde. Ett kundresultat, ett tal med sitt sammanhang.

• Sista steget: skickas när användaren är en händelse från aktivering, eller på dag 7 som tidsbaserad reserv.

Lägg märke till att tre av de fem är villkorade. Välkomstmejlet är det enda som går till alla.

Välkomstmejl får också de bästa öppningsfrekvenser du någonsin kommer att se. Behandla siffran med misstro. Apple Mail Privacy Protection laddar bilder i förväg och blåser upp öppningarna för en stor del av listan. Följ klick-till-aktivering i stället.

Tidsbaserade utskick misslyckas med de användare som betyder mest

Ett rent tidsbaserat utskick skickar dag-tre-mejlet till en användare som aktiverade redan på dag ett. Den användaren får nu höra att göra något hen redan har gjort. Det känns som automation, för det är automation.

Det fallerar också åt andra hållet. En användare som har fastnat på steg två får ett glatt funktionsmejl i stället för hjälp. Sekvensen ser inte problemet, och därför kan den inte agera på det.

Lösningen är inte krånglig, men den kräver en händelsekälla. Beteendebaserade sekvenser behöver tre indata: händelseströmmen, ett tillstånd per användare och en regel som kontrollerar tillståndet före varje utskick.

{
  "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"]
}

Kontrollen send_if körs vid utskickstillfället, inte vid inskrivningen. Skillnaden spelar roll. Om du utvärderar villkoret när användaren går in i flödet har du byggt ett statiskt segment, och tillståndet hinner bli inaktuellt innan mejlet går ut.

Slutvillkoret är funktionen som folk glömmer

Varje sekvens behöver en regel som avslutar den. Den uppenbara är aktivering. Två andra missas oftast: avprenumeration från onboarding-strömmen och kontoradering eller att provperioden löper ut. Provperiodens slut är ett eget slutvillkor, eftersom användaren då ofta redan har bestämt sig och läser ett uppmuntrande mejl som ett försök att sälja.

Vi har sett sekvenser fortsätta skicka till användare som redan blivit betalande. Det är en bugg i slutvillkoret, och den kostar mer än en utebliven öppning. Den lär användaren att dina mejl inte hänger ihop med hens konto.

Skriv slutreglerna först och testa dem först. Spela upp några riktiga användartidslinjer genom flödet i en stagingmiljö och kontrollera att varje användare stannar där den ska. En sekvens med bra kopia men inga slutvillkor är sämre än en sekvens med enkel kopia och rena slut.

Varifrån kommer händelsedatan?

Kvaliteten på sekvensen beror på kvaliteten på signalen. Det finns tre vanliga källor, och de har olika latens och felmönster.

En analysplattform för produktdata, som Segment, vidarebefordrar händelser inom sekunder, men bara de händelser du har instrumenterat. Ett direkt webhook från din backend är det mest tillförlitliga, eftersom det skjuts från kodvägen som utför arbetet. Postgres change data capture ser allt som rör raden, även ändringar gjorda av adminskript, vilket kan vara en funktion eller en bugg.

Välj en källa som sanningskälla för aktiveringshändelsen och dokumentera den bredvid flödesdefinitionen, så att nästa ingenjör inte lägger till en andra. Två källor som skiljer sig åt med några minuter ger mejl som motsäger produktens tillstånd. Så får en användare "Slutför installationen" efter att ha slutfört installationen.

Idempotens spelar också roll. Eventpipelines försöker om, så samma project.created kan komma två gånger. Om din avsändare inte deduplicerar på nyckel får användaren två utskick.

Customer.io bygger på den här modellen. Det tar emot händelser via ett API, SDK:er eller en CDP och triggar från en workflow-byggare. Om du redan kör en annan stack fungerar samma mönster med vilken avsändare som helst som accepterar en trigger och utvärderar villkor vid utskick.

Transaktionellt eller marknadsföring: välj ström medvetet

Vissa onboarding-mejl är transaktionella i praktiken. Ett mejl om att din API-nyckel är klar, eller en e-postverifiering, ska inte vänta i en marknadsföringskö, och det ska inte dela avsändarrykte med en kampanj.

Postmark gör uppdelningen till en designprincip genom att separera meddelandeströmmar på olika infrastruktur. Resonemanget håller även om du inte använder deras tjänst. Ett dåligt kampanjutskick ska aldrig försena en lösenordsåterställning.

Vår regel är enkel. Om användaren inte kan gå vidare utan mejlet hamnar det i den transaktionella strömmen. Om mejlet är uppmuntran hamnar det i livscykelströmmen, med en avprenumerationslänk som bara påverkar den strömmen.

Ändrar en utvecklarfokuserad avsändare bygget?

Den ändrar utgångspunkten. Med en API-först-avsändare ligger sekvenslogiken i din kod eller i en liten worker, och leverantören levererar bara. Du får versionshantering, tester och kodgranskning för dina flöden, och du förlorar den visuella byggaren.

Resend tar den vägen, med ett REST-API, officiella SDK:er och React Email-mallar. För ett team som redan behandlar mejl som komponenter är det en rimlig passform. För ett tillväxtteam som vill redigera kopia utan deploy är det friktion.

Var ärlig om vem som redigerar sekvensen. Om svaret är "tillväxt, varje vecka" är en workflow-byggare rätt val, även om ingenjörer ogillar det. Om svaret är "ingenjörer, per release" ska sekvensen ligga kvar i koden.

Mät klick-till-aktivering, inte öppningar

Öppningsfrekvens är en svag signal för det här jobbet. Integritetsfunktioner i e-post blåser upp den, och en öppning betyder inte att användaren gjorde något. Tre tal säger mer.

• Klick-till-aktivering: av användarna som klickade på ett givet mejl, hur många nådde aktiveringshändelsen inom 24 timmar.

• Triggerlatens: tiden mellan händelsen och utskicket. För ett hinderemejl förlorar allt efter några minuter ögonblicket.

• Aktiveringsgrad mot en kontrollgrupp: håll tillbaka en liten grupp registreringar från sekvensen och jämför deras aktivering inom 14 dagar med resten.

Kontrollgruppen är det enda sättet att veta att sekvensen fungerar. Utan den krediterar du mejlen för aktivering som hade skett ändå.

Läs resultatet med samma försiktighet som allt annat. Om kontrollgruppen aktiverar nästan lika ofta som den skickade gruppen är det sekvensen som saknar effekt, inte mätningen. Då är det bättre att korta flödet än att lägga till fler mejl, eftersom varje extra mejl kostar både uppmärksamhet och underhåll.

Vi anger inget riktmärke för aktiveringsgrad här, eftersom de publicerade siffrorna kommer från leverantörer med olika definitioner. Mät din egen baslinje först. Ändra sedan ett mejl i taget.

Ska du bygga en sekvens eller flera?

Dela efter ingångsvillkor, inte efter personaetiketter. En användare som registrerade sig via en inbjudan har ett annat första steg än en som registrerade sig själv. En användare som importerat data har redan passerat en linje som de andra inte har passerat.

Två eller tre ingångsvägar räcker oftast. Fler än så, och underhållskostnaden slår vinsten, eftersom varje väg behöver egna slutvillkor och egna tester.

En allt-i-ett-plattform kan minska installationsarbetet när teamet är litet. Brevo samlar mejl, SMS och ett CRM under en inloggning, vilket passar team som inte vill koppla upp en eventpipeline än. Avvägningen är att marknadsföringspanelen står i centrum, och subsekundtriggers är inte vad den är optimerad för.

Det här skulle vi skicka först

Skriv aktiveringshändelsen och 14-dagarsfönstret på en rad. Bygg välkomstmejlet och 24-timmarspåminnelsen med en send_if-kontroll och en ren utgång. Lägg en kontrollgrupp på 5 till 10 procent från dag ett.

Vänta med bevismejlet och sista-steg-utskicket tills du har två veckors data. Lägg till hindermejlet så snart du kan namnge det vanligaste felet i dina loggar. Vilken felsignal i din produkt skulle du koppla upp först?