# Så bygger du en mejlsekvens för SaaS-provperioder med produkthändelser

Kanonisk URL: https://brew.new/sv/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events
Författare: Thomas Park
Publicerad: 2026-09-26
Uppdaterad: 2026-09-29

Ett mejl som ska konvertera en provperiod bör utgå från vad användaren har gjort. Den som inte har skapat något projekt behöver hjälp att komma igång. Den som har använt produkten varje dag behöver en tydlig förklaring av den betalda planen. Skickar du samma nedräkning till båda missar du den skillnaden.

Den här guiden skiljer på hur du utformar sekvensen och den applikationslogik som avgör vem som ska få varje mejl.

## Välj en aktiveringshändelse

Välj en handling som visar att användaren har nått produktens första användbara resultat. Gör den så specifik att din backend kan registrera den: ett skapat projekt, en slutförd import eller en inbjuden kollega. En sidvisning räcker sällan ensam.

Spara tidpunkten för registreringen, provperiodens slut, aktiveringen och betalstatusen i det system som äger de uppgifterna. Se kontaktfälten i e-postplattformen som synkroniserad data, inte som bevis för att ett flöde som startade tidigare läser aktuell status.

## Ge varje meddelande en enda uppgift

| Meddelande | När det är användbart | Villkor som kontrolleras när det är dags |
| --- | --- | --- |
| Välkomstmejl | Efter registrering eller verifiering | Kontot finns och får ta emot det här meddelandet |
| Hjälp att komma igång | Ungefär två dagar senare, anpassat efter din produkt | Inte aktiverad |
| Nästa användbara steg | Efter aktiveringen | Aktiverad och har inte slutfört det steget |
| Provperioden tar slut | Före provperiodens faktiska slutdatum | Provperioden är fortfarande aktiv och kontot har ingen betald plan |
| Sista avstämning | Efter att provperioden har tagit slut, om det passar | Fortfarande utan betald plan, uppfyller villkoren och får ta emot marknadsföring |

De här tidpunkterna är utgångspunkter för ett test, inte uppmätta intervall som har visat sig fungera bäst. Ange provperiodens faktiska slutdatum och vad som händer sedan. Skapa inte konstgjord knapphet och antyd inte att kunden kommer att debiteras när det inte finns någon betalningsmetod registrerad.

## Välj källa för villkorskontrollerna

I ett händelsestyrt flöde i Brew läser `payload.activated` den ursprungliga händelsen, medan `contact.activated` läser mottagarens aktuella kontaktfält i Brew när ett filter eller en villkorsstyrd förgrening körs. För att hoppa över påminnelser om att komma igång efter aktiveringen deklarerar du det booleska fältet, håller det synkat från din produkt och kontrollerar `contact.activated equals false` efter varje relevant väntesteg. Ett saknat värde är inte samma sak som false; testa sådana fall separat.

De här läsningarna använder kontakten som är sparad i Brew, inte din applikations databas eller ett direktanrop till Stripe. Att Brew tar emot en händelse om aktivering eller betalning avbryter inte automatiskt en tidigare körning. Flödet behöver ett villkor före varje utskick som beror på en status.

För uppgifter som finns utanför Brew låter du din applikation schemalägga ett jobb. När det är dags läser jobbet det aktuella kontot eller den aktuella fakturan och skickar en separat anpassad händelse till Brew, men bara om mottagaren fortfarande uppfyller villkoren. Ta med den aktuella data som behövs för personaliseringen i den nya händelsen.

En påminnelse som applikationen schemalägger fungerar till exempel så här:

```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
```

Använd det faktiska utlösar-id:t som Brew returnerar och utlösarens deklarerade schema. Följ [guiden om att konfigurera automatiseringar](https://docs.brew.new/create-emails/build-an-automation) och [typade nyttolastkontrakt](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Använd den dokumenterade idempotensmekanismen för händelser som skickas om.

## Använd Stripe för de uppgifter som Stripe äger

Om Stripe hanterar provperioden ger prenumerationshändelserna därifrån sammanhanget kring faktureringen. [Integrationen med Stripe](/sv/browse/integrations/stripe) ger tillgång till de händelseutlösare som stöds, bland annat `customer.subscription.trial_will_end`. Aktiveringen i produkten ägs fortfarande av din applikation, om du inte skickar den informationen separat.

För en senare påminnelse som gäller betalning kontrollerar du den aktuella posten i Stripe. En lyckad uppdatering av kortuppgifterna bevisar inte att en faktura har betalats. Samordna med Stripes egna mejl så att kunden får ett meddelande per syfte.

## Bestäm villkoren först, skriv mejlet sedan

Utgå från mottagarens faktiska situation. Förklara en användbar handling och länka direkt till den. Ett mejl om att komma igång kan erbjuda ett kort exempel och en adress att svara till. Ett mejl om den betalda planen bör beskriva den begränsning eller funktion som är relevant och det verkliga priset, med en länk till aktuella priser.

Se till att samtycket till marknadsföring, hanteringen av avregistreringar och domänens syfte stämmer med meddelandet. En registrering för en provperiod ger inte rätt att skicka orelaterad marknadsföring.

## Bevisa att utträdena fungerar

Testa vad som händer när en kontakt aktiveras eller betalar före varje villkorskontroll. Med kontaktvillkor uppdaterar du de relevanta fälten i Brew under väntetiden och kontrollerar att påminnelsen hoppas över. Med kontroller som applikationen schemalägger ser du till att konton som inte uppfyller villkoren inte ger upphov till någon påminnelsehändelse. Testa också nya försök, förlängda provperioder, raderade konton, avregistreringar och saknade fält. Granska både applikationens loggar och körningshistoriken i Brew.

Utvärdera aktivering och konvertering till betalande kunder med hjälp av din produktdata, och leveransfel med hjälp av e-postplattformen. Öppningsfrekvensen ensam visar inte om sekvensen hjälpte en användare med provperiod. Läs om [hur du utformar välkomstsekvenser](/sv/blog/welcome-email-sequence) för exempel och om [MCP kontra REST](/sv/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use) för hur implementationen delas upp.