# Sekwencja powitalna: przykłady, terminy i warunki wysyłki

Kanoniczny adres URL: https://brew.new/pl/blog/welcome-email-sequence
Autor: Brew Team
Opublikowano: 2026-08-16
Zaktualizowano: 2026-09-29

Sekwencja powitalna pomaga nowemu subskrybentowi zrozumieć, co zrobić dalej. W produkcie SaaS może to być utworzenie pierwszego projektu. W sklepie – poznanie asortymentu. W newsletterze – wiedza o tym, co i jak często będzie przychodzić.

Zacznij od obietnicy złożonej przy zapisie. Każdy kolejny e-mail powinien pomagać ją spełnić. Terminy i liczba wiadomości zależą od produktu i odbiorców, a poniższe przykłady to punkty wyjścia do testów. Sekwencja powitalna to pierwsza z sekwencji cyklu życia opisanych w poradniku o [automatyzacji e-maili z AI](/pl/blog/ai-email-automation).

## Wybierz właściwe zdarzenie startowe

| Punkt startowy | Przydatna pierwsza wiadomość | Co sprawdzić |
| --- | --- | --- |
| Utworzenie konta | Jedno działanie konfiguracyjne | Czy najpierw powinna nastąpić weryfikacja adresu e-mail |
| Weryfikacja adresu e-mail | Powitanie i bezpośredni link do produktu | Unikaj dublowania e-maila weryfikacyjnego |
| Zapis do newslettera | Czego się spodziewać i jeden przydatny przykład | Zgoda odbiorcy i wybrane przez niego tematy |
| Rejestracja w sklepie | Produkty, porady lub obiecana oferta | Rzeczywiste warunki oferty i termin jej ważności |

Brew może uruchamiać sekwencje na podstawie własnych zdarzeń z backendu lub obsługiwanych integracji, takich jak [Supabase](/pl/browse/integrations/supabase) i [Clerk](/pl/browse/integrations/clerk). Zbuduj dane zdarzenia na podstawie schematu wybranego wyzwalacza i użyj jego rzeczywistego identyfikatora.

## Przykład powitania w SaaS

| E-mail | Wstępny termin | Zadanie | Warunek w chwili wysyłki |
| --- | --- | --- | --- |
| Powitanie | Po rejestracji lub weryfikacji | Pomoc w utworzeniu pierwszego projektu | Nowe konto |
| Pomoc w konfiguracji | Dzień 2 | Pokazanie jednego krótkiego przykładu | Brak aktywacji |
| Kolejny krok | Po aktywacji | Przedstawienie kolejnego przydatnego działania | Konto aktywowane |
| Przypomnienie o okresie próbnym | Przed końcem okresu próbnego | Wyjaśnienie, co będzie dalej | Nadal w okresie próbnym, bez płatności |
| Pytanie o postępy | Po odpowiednim czasie | Propozycja pomocy | Nadal spełnia warunki i ma zgodę na otrzymanie wiadomości |

Każdy e-mail buduj wokół jednego działania. Używaj prawdziwego docelowego adresu URL, jasnego tematu i adresu do odpowiedzi, który ktoś sprawdza. Unikaj ogólnikowego ponaglania i twierdzeń o wynikach, których nie zmierzono.

## Przykład powitania w newsletterze lub sklepie

W przypadku newslettera pierwsza wiadomość może dostarczyć obiecany materiał, określić rytm wysyłek i pokazać reprezentatywny artykuł. Późniejsza wiadomość może objaśnić preferencje dotyczące tematów albo przedstawić autora. Newsletter nie potrzebuje lejka aktywacji w stylu SaaS, żeby uzasadnić drugi e-mail.

W sklepie najpierw dostarcz obiecaną ofertę, a potem przydatne porady zakupowe. Dokładnie podaj wyłączenia i termin ważności. Po zakupie pozostałe przypomnienia o rabacie mogą stracić sens, więc przy sprawdzaniu warunków wysyłki uwzględnij stan zakupów.

## Określ reguły wyjścia, zanim napiszesz kolejne e-maile

Zdecyduj, co powinno blokować każdą wiadomość: aktywacja, zakup, wygasła oferta, usunięcie konta, wypisanie lub zmiana planu. Potem wdróż tę regułę w systemie, który faktycznie odczytuje bieżący stan.

W sekwencji Brew uruchamianej zdarzeniem warunek na `payload.activated` odczytuje pierwotne zdarzenie. Warunek na `contact.activated` odczytuje bieżące pole kontaktu w Brew w chwili wykonania kroku, także po kroku „Czekaj”. Zadeklaruj i synchronizuj to pole, a potem umieść warunek przed każdym przypomnieniem, które od niego zależy. Aktualizacja kontaktu ani późniejsze zdarzenie nie anulują automatycznie wcześniejszego uruchomienia.

Jeśli to, czy kontakt spełnia warunki, zależy od niesynchronizowanych danych konta lub konkretnego zakupu, zaplanuj sprawdzenie w swojej aplikacji. Gdy nadchodzi pora wysyłki, odczytaj miarodajny rekord i wywołaj osobne zdarzenie z przypomnieniem tylko wtedy, gdy reguła nadal jest spełniona. Zobacz [Zbuduj automatyzację](https://docs.brew.new/create-emails/build-an-automation#check-state-before-later-reminders).

## Zbuduj i sprawdź sekwencję

Opisz w Brew wyzwalacz, odbiorców, oczekiwane działanie i ton. Możesz też zacząć od publicznego przykładu z [galerii sekwencji](/pl/browse/flows). Traktuj jego harmonogram jako inspirację, a nie dowód, że ten sam rozkład wysyłek sprawdzi się u Twoich odbiorców.

Przejrzyj wygenerowany schemat i każdy e-mail. Sprawdź linki, nadawcę, wartości zastępcze personalizacji i przeznaczenie domeny. Wiadomość weryfikacyjna i promocyjny e-mail onboardingowy mogą podlegać różnym wymaganiom. [Poradnik FTC](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) wyjaśnia obowiązujący w USA test głównego celu, a [wymagania Gmail dla nadawców](https://support.google.com/mail/answer/81126) opisują zasady dotyczące uwierzytelniania, wskaźnika spamu i wypisywania.

## Testuj nie tylko optymistyczny scenariusz

Przetestuj rejestrację, powtórzone zdarzenie, brak danych do personalizacji i odbiorcę, który nie spełnia warunków. W przypadku warunków dotyczących kontaktu zaktualizuj synchronizowane pole w trakcie oczekiwania i sprawdź, czy przypomnienie zostanie pominięte. Przetestuj też brakujące pola. W przypadku przypomnień planowanych przez aplikację aktywuj konto lub dokonaj zakupu przed sprawdzeniem i upewnij się, że zdarzenie przypomnienia nie zostało wywołane. Sprawdź też obsługę wypisań i wyniki dostarczania.

Publikuj dopiero po przejrzeniu wiadomości i warunków wysyłki. Obok danych o dostarczeniach i kliknięciach śledź działanie, któremu sekwencja ma sprzyjać, np. ukończoną konfigurację albo pierwsze zamówienie. Zostaw wiadomości, które pomagają ludziom to zrobić, a resztę popraw.

Przykłady wdrożeń znajdziesz we wpisach o [budowaniu onboardingu z poziomu Cursor](/pl/blog/how-to-create-an-email-onboarding-sequence-from-cursor) i o [konwersji okresu próbnego na podstawie zdarzeń w produkcie](/pl/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).