# Konverze zkušebních verzí SaaS: e-mailová sekvence z událostí v produktu

Kanonická URL: https://brew.new/cs/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events
Autor: Thomas Park
Publikováno: 2026-09-26
Aktualizováno: 2026-09-29

E-mail, který má zkušební verzi proměnit v placený účet, by měl reagovat na to, co uživatel udělal. Kdo ještě nezaložil projekt, potřebuje pomoct s nastavením. Kdo produkt používá každý den, potřebuje jasné vysvětlení placeného tarifu. Když oběma pošleš stejné odpočítávání, tenhle rozdíl ti unikne.

Tento návod odděluje návrh sekvence od aplikační logiky, která rozhoduje, kdo má jednotlivé e-maily dostat.

## Vyber aktivační událost

Vyber jednu akci, která ukazuje, že uživatel v produktu dosáhl prvního užitečného výsledku. Musí být dost konkrétní, aby ji tvůj backend dokázal zaznamenat: založený projekt, dokončený import nebo pozvaný kolega. Zobrazení stránky samo o sobě málokdy stačí.

Čas registrace, konec zkušební verze, aktivaci a to, jestli účet platí, zaznamenávej v systému, který je u těchto faktů zdrojem pravdy. Pole kontaktu v e-mailové platformě ber jako synchronizovaná data, ne jako důkaz, že dřívější sekvence čte aktuální stav.

## Dej každé zprávě jeden úkol

| Zpráva | Kdy se hodí | Podmínka ověřená v okamžiku odeslání |
| --- | --- | --- |
| Uvítání | Po registraci nebo ověření | Účet existuje a smí tuto zprávu dostat |
| Pomoc s nastavením | Zhruba o dva dny později, podle tvého produktu | Zatím bez aktivace |
| Další užitečná akce | Po aktivaci | Aktivace proběhla, tato akce zatím ne |
| Konec zkušební verze | Před skutečným koncem zkušební verze | Zkušební verze pořád běží a účet není placený |
| Závěrečný dotaz, jak to jde | Po skončení zkušební verze, pokud je to vhodné | Pořád bez platby, splňuje podmínky a smí dostávat marketingové e-maily |

Tato načasování jsou výchozí body pro test, ne změřené nejúspěšnější intervaly. Uveď skutečný konec zkušební verze a co bude následovat. Nevyvolávej falešný dojem nedostatku a nenaznačuj, že dojde k platbě, když účet nemá uložený žádný platební prostředek.

## Vyber zdroj pro kontrolu podmínek

V sekvenci v Brew spouštěné událostí čte `payload.activated` původní událost, kdežto `contact.activated` čte aktuální hodnotu pole kontaktu příjemce v Brew v okamžiku, kdy se provádí uzel Filtr nebo uzel podmíněného rozdělení. Pokud chceš po aktivaci připomínky nastavení přeskočit, deklaruj toto pole typu ano/ne, průběžně ho synchronizuj ze svého produktu a po každém relevantním kroku Čekání kontroluj `contact.activated equals false`. Pole bez hodnoty není totéž co pole s hodnotou ne, takže je otestuj zvlášť.

Tato čtení vycházejí z kontaktu uloženého v Brew, ne z databáze tvé aplikace ani z aktuálního dotazu do Stripe. Přijetí události o aktivaci nebo platbě dřívější běh automaticky nezruší. Graf proto potřebuje podmínku před každým odesláním, které závisí na stavu.

U faktů mimo Brew nech úlohu naplánovat svou aplikaci. Když nastane její čas, přečti aktuální stav účtu nebo faktury a samostatnou vlastní událost do Brew vyšli, jen pokud příjemce pořád splňuje podmínky. Do této nové události přidej aktuální data potřebná pro personalizaci.

Připomínka naplánovaná v aplikaci funguje třeba takhle:

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

Neboli: po potvrzení registrace se vyšle uvítací událost. Když nastane čas úlohy pro připomínku, aplikace načte aktuální stav účtu. Pokud už účet prošel aktivací nebo je zaplacený, úloha skončí, aniž by vyslala událost pro e-mail; pokud pořád splňuje podmínky, vyšle událost pro připomínku nastavení s aktuálními daty.

Použij skutečné ID spouštěče, které ti Brew vrátí, a deklarované schéma spouštěče. Postupuj podle [návodu k vytváření automatizací](https://docs.brew.new/create-emails/build-an-automation) a dokumentace k [typovaným schématům payloadu](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Při opakovaném vysílání událostí použij zdokumentovaný mechanismus idempotence.

## Stripe používej pro fakta, u kterých je zdrojem pravdy

Pokud zkušební verzi spravuje Stripe, jeho události předplatného dodávají kontext o platbách. [Integrace Stripe](/cs/browse/integrations/stripe) nabízí spouštěče pro podporované události, včetně `customer.subscription.trial_will_end`. Zdrojem pravdy o aktivaci v produktu ale zůstává tvoje aplikace, pokud tuto informaci neposíláš zvlášť.

U pozdější připomínky související s platbou zkontroluj aktuální záznam ve Stripe. Úspěšná aktualizace karty není důkaz, že je faktura zaplacená. Slaď to s e-maily, které posílá sám Stripe, aby zákazník ke každému účelu dostal jen jedno upozornění.

## E-mail piš až po stanovení podmínek

Začni skutečnou situací příjemce. Vysvětli jednu užitečnou akci a odkaž přímo na ni. E-mail s pomocí s nastavením může nabídnout krátký příklad a adresu pro odpovědi. E-mail o placeném tarifu by měl popsat relevantní limit nebo funkci a skutečnou cenu a odkázat na aktuální ceník.

Souhlas s marketingem, chování odhlášení i účel odesílací domény musí odpovídat zprávě. Registrace do zkušební verze neopravňuje k nesouvisejícím propagačním e-mailům.

## Ověř, že pravidla pro ukončení fungují

Pro každou kontrolu podmínek otestuj, co se stane, když kontakt ještě před ní projde aktivací nebo zaplatí. U podmínek na kontaktu během čekání aktualizuj příslušná pole v Brew a ověř, že se připomínka přeskočí. U kontrol plánovaných v aplikaci ověř, že účty, které podmínky nesplňují, nevyvolají žádnou událost připomínky. Otestuj také opakované pokusy, prodloužení zkušební verze, smazání účtu, odhlášení a chybějící pole. Zkontroluj logy aplikace i historii běhů v Brew.

Aktivaci a konverzi na placený tarif vyhodnocuj podle dat z produktu, selhání doručení podle e-mailové platformy. Míra otevření sama neukáže, jestli sekvence uživateli ve zkušební verzi pomohla. Příklady najdeš v článku o [návrhu uvítacích sekvencí](/cs/blog/welcome-email-sequence) a rozdělení implementace popisuje článek [MCP vs. REST](/cs/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use).