# Cách tạo chuỗi email chuyển đổi dùng thử SaaS từ sự kiện sản phẩm

URL chính tắc: https://brew.new/vi/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events
Tác giả: Thomas Park
Ngày đăng: 2026-09-26
Ngày cập nhật: 2026-09-29

Email chuyển đổi dùng thử nên phản hồi theo những gì người dùng đã làm. Người chưa tạo dự án nào cần được hỗ trợ thiết lập. Người đã dùng sản phẩm hằng ngày cần được giải thích rõ về gói trả phí. Gửi cho cả hai người cùng một email đếm ngược là bỏ qua sự khác biệt đó.

Hướng dẫn này tách phần thiết kế chuỗi email khỏi logic ứng dụng quyết định ai sẽ nhận từng email.

## Chọn sự kiện kích hoạt

Hãy chọn một hành động cho thấy người dùng đã đạt được kết quả hữu ích đầu tiên với sản phẩm. Hành động đó phải đủ cụ thể để backend của bạn ghi nhận: một dự án được tạo, một lần nhập hoàn tất hoặc một đồng đội được mời. Chỉ riêng một lượt xem trang hiếm khi là đủ.

Hãy ghi nhận thời điểm đăng ký, thời điểm hết hạn dùng thử, trạng thái kích hoạt và trạng thái thanh toán trong hệ thống sở hữu những dữ kiện đó. Hãy xem các trường liên hệ trong nền tảng email là dữ liệu được đồng bộ, không phải bằng chứng cho thấy một luồng bắt đầu từ trước đang đọc trạng thái mới nhất.

## Mỗi email một nhiệm vụ

| Email | Khi nào hữu ích | Điều kiện kiểm tra khi đến hạn gửi |
| --- | --- | --- |
| Chào mừng | Sau khi đăng ký hoặc xác minh | Tài khoản tồn tại và được phép nhận email này |
| Hỗ trợ thiết lập | Khoảng hai ngày sau, điều chỉnh theo sản phẩm của bạn | Chưa kích hoạt |
| Hành động hữu ích tiếp theo | Sau khi kích hoạt | Đã kích hoạt và chưa hoàn thành hành động đó |
| Sắp hết hạn dùng thử | Trước hạn chót dùng thử thực tế | Vẫn đang dùng thử và tài khoản chưa thanh toán |
| Hỏi thăm lần cuối | Sau khi hết thời gian dùng thử, nếu phù hợp | Vẫn chưa thanh toán, đủ điều kiện và được phép nhận email tiếp thị |

Các mốc thời gian này là điểm khởi đầu để thử nghiệm, không phải những khoảng cách đã được đo lường là hiệu quả nhất. Hãy nêu rõ hạn chót dùng thử thực tế và điều gì sẽ xảy ra tiếp theo. Đừng tạo ra sự khan hiếm giả tạo hay ngụ ý rằng sẽ có khoản phí bị trừ khi tài khoản chưa có phương thức thanh toán nào.

## Chọn nguồn dữ liệu cho bước kiểm tra điều kiện

Trong một luồng kích hoạt theo sự kiện của Brew, `payload.activated` đọc sự kiện ban đầu, còn `contact.activated` đọc giá trị hiện tại của trường liên hệ trong Brew của người nhận vào lúc nút Bộ lọc hoặc nút Phân nhánh theo điều kiện được thực thi. Để bỏ qua email nhắc hoàn tất thiết lập sau khi người dùng đã kích hoạt, hãy khai báo trường kiểu Có/Không đó, giữ trường luôn được đồng bộ từ sản phẩm của bạn, rồi kiểm tra `contact.activated equals false` sau mỗi bước Chờ liên quan. Thiếu giá trị không giống với giá trị sai (false); hãy thử nghiệm riêng trường hợp này.

Những lần đọc này dùng dữ liệu liên hệ đã lưu trong Brew, không phải cơ sở dữ liệu của ứng dụng hay một yêu cầu trực tiếp tới Stripe. Việc nhận một sự kiện kích hoạt hoặc sự kiện thanh toán không tự động hủy lượt chạy đã bắt đầu trước đó. Sơ đồ cần có một điều kiện trước mỗi lượt gửi phụ thuộc vào trạng thái.

Với những dữ kiện nằm ngoài Brew, hãy để ứng dụng của bạn lên lịch một tác vụ. Khi tác vụ đến hạn, hãy đọc trạng thái hiện tại của tài khoản hoặc hóa đơn và chỉ kích hoạt một sự kiện tùy chỉnh riêng tới Brew nếu người nhận vẫn đủ điều kiện. Hãy đưa dữ liệu hiện tại cần cho việc cá nhân hóa vào sự kiện mới đó.

Ví dụ, một email nhắc do ứng dụng lên lịch hoạt động như sau:

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

Hãy dùng ID thực tế của trình kích hoạt do Brew trả về và lược đồ đã khai báo của trình kích hoạt đó. Làm theo [hướng dẫn thiết lập tự động hóa](https://docs.brew.new/create-emails/build-an-automation) và [định nghĩa payload có kiểu dữ liệu](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Dùng cơ chế lũy đẳng được mô tả trong tài liệu cho những lần kích hoạt sự kiện được thử lại.

## Dùng Stripe cho những dữ kiện mà Stripe sở hữu

Nếu Stripe quản lý thời gian dùng thử, các sự kiện gói đăng ký của Stripe sẽ cung cấp bối cảnh thanh toán. [Tích hợp Stripe](/vi/browse/integrations/stripe) cung cấp các trình kích hoạt sự kiện được hỗ trợ, trong đó có `customer.subscription.trial_will_end`. Ứng dụng của bạn vẫn sở hữu dữ liệu kích hoạt sản phẩm, trừ khi bạn gửi riêng thông tin đó.

Với email nhắc liên quan đến thanh toán được gửi sau đó, hãy kiểm tra bản ghi hiện tại trên Stripe. Việc cập nhật thẻ thành công không chứng minh rằng hóa đơn đã được thanh toán. Hãy phối hợp với các email do chính Stripe gửi để khách hàng chỉ nhận một thông báo cho mỗi mục đích.

## Viết email sau khi đã có quy tắc về điều kiện

Hãy bắt đầu từ tình huống thực tế của người nhận. Giải thích một hành động hữu ích và dẫn liên kết thẳng tới đó. Email hỗ trợ thiết lập có thể đưa ra một ví dụ ngắn và một địa chỉ để trả lời. Email về gói trả phí nên mô tả giới hạn hoặc tính năng liên quan và mức giá thực, kèm liên kết tới bảng giá hiện tại.

Hãy giữ sự đồng ý nhận email tiếp thị, cách xử lý hủy đăng ký và mục đích của tên miền nhất quán với nội dung email. Việc đăng ký dùng thử không phải lý do để gửi email quảng cáo không liên quan.

## Chứng minh rằng điều kiện thoát hoạt động

Hãy thử xem điều gì xảy ra khi một liên hệ kích hoạt hoặc thanh toán trước mỗi bước kiểm tra điều kiện. Với điều kiện dựa trên liên hệ, hãy cập nhật các trường liên quan trong Brew trong lúc chờ và xác nhận email nhắc bị bỏ qua. Với bước kiểm tra do ứng dụng lên lịch, hãy xác nhận các tài khoản không đủ điều kiện không tạo ra sự kiện nhắc nhở nào. Hãy thử cả các lần thử lại, việc kéo dài thời gian dùng thử, xóa tài khoản, hủy đăng ký và trường hợp thiếu trường. Kiểm tra cả nhật ký của ứng dụng lẫn lịch sử thực thi trong Brew.

Hãy đánh giá tỷ lệ kích hoạt và chuyển đổi sang trả phí bằng dữ liệu sản phẩm, còn lỗi gửi thì bằng nền tảng email. Chỉ riêng tỷ lệ mở không cho biết chuỗi email có giúp ích cho người dùng thử hay không. Xem [thiết kế chuỗi email chào mừng](/vi/blog/welcome-email-sequence) để có thêm ví dụ, và [MCP hay REST](/vi/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use) để biết cách phân chia phần triển khai.