# วิธีสร้างลำดับอีเมลช่วงทดลองใช้ SaaS จากเหตุการณ์ในผลิตภัณฑ์

URL หลัก: https://brew.new/th/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events
ผู้เขียน: Thomas Park
เผยแพร่: 2026-09-26
อัปเดต: 2026-09-29

อีเมลที่ช่วยเปลี่ยนผู้ทดลองใช้เป็นลูกค้าควรตอบสนองต่อสิ่งที่ผู้ใช้ทำไปแล้ว คนที่ยังไม่ได้สร้างโปรเจกต์ต้องการความช่วยเหลือเรื่องการตั้งค่า ส่วนคนที่ใช้ผลิตภัณฑ์ทุกวันต้องการคำอธิบายที่ชัดเจนเรื่องแพ็กเกจแบบชำระเงิน การส่งอีเมลนับถอยหลังแบบเดียวกันให้ทั้งสองคนจึงมองข้ามความแตกต่างนี้ไป

คู่มือนี้แยกการออกแบบลำดับอีเมลออกจากตรรกะของแอปพลิเคชันที่ตัดสินว่าใครควรได้รับอีเมลแต่ละฉบับ

## เลือกเหตุการณ์ที่บอกว่าเริ่มใช้งานจริงแล้ว

เลือกการกระทำ 1 อย่างที่แสดงว่าผู้ใช้ได้ผลลัพธ์ที่มีประโยชน์ครั้งแรกจากผลิตภัณฑ์แล้ว และให้เจาะจงพอที่แบ็กเอนด์ของคุณจะบันทึกได้ เช่น สร้างโปรเจกต์แล้ว นำเข้าข้อมูลเสร็จแล้ว หรือเชิญเพื่อนร่วมทีมแล้ว การเปิดดูหน้าเว็บเพียงอย่างเดียวแทบไม่เคยพอ

บันทึกเวลาที่สมัครใช้งาน วันสิ้นสุดช่วงทดลองใช้ การเริ่มใช้งานจริง และสถานะการชำระเงินไว้ในระบบที่เป็นเจ้าของข้อเท็จจริงเหล่านั้น และให้มองฟิลด์ผู้ติดต่อในแพลตฟอร์มอีเมลเป็นข้อมูลที่ซิงค์มา ไม่ใช่หลักฐานว่าโฟลว์ที่เริ่มไปก่อนหน้ากำลังอ่านสถานะล่าสุดอยู่

## ให้อีเมลแต่ละฉบับมีหน้าที่เดียว

| อีเมล | ใช้เมื่อไร | เกณฑ์ที่ตรวจเมื่อถึงเวลาส่ง |
| --- | --- | --- |
| ต้อนรับ | หลังสมัครใช้งานหรือยืนยันอีเมล | มีบัญชีอยู่ และรับอีเมลนี้ได้ |
| ช่วยตั้งค่า | ราว 2 วันหลังจากนั้น ปรับตามผลิตภัณฑ์ของคุณ | ยังไม่เริ่มใช้งานจริง |
| การกระทำที่มีประโยชน์ขั้นต่อไป | หลังเริ่มใช้งานจริง | เริ่มใช้งานจริงแล้ว และยังไม่ได้ทำการกระทำนั้น |
| ช่วงทดลองใช้ใกล้สิ้นสุด | ก่อนวันสิ้นสุดช่วงทดลองใช้จริง | ช่วงทดลองใช้ยังไม่หมด และบัญชียังไม่ได้ชำระเงิน |
| ถามไถ่ครั้งสุดท้าย | หลังช่วงทดลองใช้สิ้นสุด หากเหมาะสม | ยังไม่ชำระเงิน ยังเข้าเกณฑ์ และได้รับอนุญาตให้รับอีเมลการตลาด |

จังหวะเวลาเหล่านี้เป็นจุดเริ่มต้นสำหรับการทดสอบ ไม่ใช่ช่วงเวลาที่วัดแล้วว่าได้ผลดีที่สุด ให้ระบุวันสิ้นสุดช่วงทดลองใช้จริงและสิ่งที่จะเกิดขึ้นต่อไป อย่าสร้างความขาดแคลนขึ้นมาเอง หรือทำให้เข้าใจว่าจะมีการเรียกเก็บเงินทั้งที่ยังไม่มีวิธีการชำระเงินอยู่ในระบบ

## เลือกแหล่งข้อมูลสำหรับการตรวจเกณฑ์

ในโฟลว์ของ Brew ที่เริ่มจากเหตุการณ์ ค่า `payload.activated` จะอ่านจากเหตุการณ์ต้นทาง ขณะที่ `contact.activated` จะอ่านฟิลด์ผู้ติดต่อปัจจุบันของผู้รับใน Brew ตอนที่โหนดตัวกรองหรือโหนดแยกเส้นทางตามเงื่อนไขทำงาน หากต้องการข้ามอีเมลเตือนเรื่องการตั้งค่าหลังผู้ใช้เริ่มใช้งานจริงแล้ว ให้ประกาศฟิลด์ประเภทใช่/ไม่ใช่ (boolean) นั้น ซิงค์ค่าจากผลิตภัณฑ์ของคุณอยู่เสมอ และตรวจ `contact.activated equals false` หลังขั้นตอน “รอ” แต่ละขั้นที่เกี่ยวข้อง ค่าที่ขาดหายไม่เท่ากับ false จึงต้องทดสอบแยกต่างหาก

การอ่านค่าเหล่านี้ใช้ข้อมูลผู้ติดต่อที่ Brew เก็บไว้ ไม่ใช่ฐานข้อมูลของแอปพลิเคชันคุณหรือคำขอไปยัง Stripe แบบเรียลไทม์ การได้รับเหตุการณ์เริ่มใช้งานจริงหรือเหตุการณ์ชำระเงินไม่ได้ยกเลิกรอบการทำงานที่เริ่มไปก่อนหน้าโดยอัตโนมัติ กราฟระบบอัตโนมัติจึงต้องมีเงื่อนไขก่อนการส่งทุกครั้งที่ขึ้นอยู่กับสถานะ

สำหรับข้อเท็จจริงที่อยู่นอก Brew ให้แอปพลิเคชันของคุณตั้งเวลางานไว้ เมื่อถึงเวลา ให้อ่านข้อมูลบัญชีหรือใบแจ้งหนี้ปัจจุบัน แล้วส่งเหตุการณ์ที่กำหนดเองของ Brew แยกอีกรายการหนึ่งเฉพาะเมื่อผู้รับยังเข้าเกณฑ์อยู่ และใส่ข้อมูลปัจจุบันที่ต้องใช้ในการปรับเนื้อหาเฉพาะบุคคลไว้ในเหตุการณ์ใหม่นั้นด้วย

ตัวอย่างเช่น อีเมลเตือนที่แอปพลิเคชันตั้งเวลาไว้จะทำงานแบบนี้:

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

ใช้ ID ทริกเกอร์จริงที่ Brew ส่งกลับมา และสคีมาที่ประกาศไว้ของทริกเกอร์นั้น ทำตาม[คู่มือการตั้งค่าระบบอัตโนมัติ](https://docs.brew.new/create-emails/build-an-automation)และ[สคีมาเพย์โหลดแบบมีไทป์](https://docs.brew.new/api-reference/guides/typed-payload-contracts) และสำหรับการส่งเหตุการณ์ซ้ำเมื่อมีการลองใหม่ ให้ใช้กลไก idempotency ตามที่เอกสารระบุไว้

## ใช้ Stripe กับข้อเท็จจริงที่ Stripe เป็นเจ้าของ

หาก Stripe เป็นผู้ดูแลช่วงทดลองใช้ เหตุการณ์การสมัครสมาชิกของ Stripe จะให้บริบทด้านการเรียกเก็บเงิน [การเชื่อมต่อ Stripe](/th/browse/integrations/stripe) มีทริกเกอร์จากเหตุการณ์ที่รองรับ รวมถึง `customer.subscription.trial_will_end` ส่วนการเริ่มใช้งานจริงในผลิตภัณฑ์ยังเป็นข้อมูลของแอปพลิเคชันคุณ เว้นแต่คุณจะส่งข้อมูลนั้นแยกเข้ามา

สำหรับอีเมลเตือนเรื่องการชำระเงินในภายหลัง ให้ตรวจข้อมูลปัจจุบันใน Stripe การอัปเดตบัตรสำเร็จไม่ได้พิสูจน์ว่าใบแจ้งหนี้ได้รับการชำระแล้ว และควรประสานกับอีเมลที่ Stripe ส่งเอง เพื่อให้ลูกค้าได้รับการแจ้งเตือนเพียงฉบับเดียวต่อหนึ่งวัตถุประสงค์

## เขียนอีเมลหลังกำหนดกฎการเข้าเกณฑ์

เริ่มจากสถานการณ์จริงของผู้รับ อธิบายการกระทำที่มีประโยชน์ 1 อย่าง และลิงก์ไปยังสิ่งนั้นโดยตรง อีเมลเรื่องการตั้งค่าอาจมีตัวอย่างสั้น ๆ และที่อยู่สำหรับตอบกลับ ส่วนอีเมลเรื่องแพ็กเกจแบบชำระเงินควรอธิบายขีดจำกัดหรือฟีเจอร์ที่เกี่ยวข้องและราคาจริง พร้อมลิงก์ไปยังหน้าราคาปัจจุบัน

ทำให้ความยินยอมรับอีเมลการตลาด การทำงานของการยกเลิกการรับข่าวสาร และวัตถุประสงค์ของโดเมนสอดคล้องกับเนื้อหาอีเมล การสมัครทดลองใช้ไม่ได้เป็นเหตุผลให้ส่งอีเมลโปรโมชันที่ไม่เกี่ยวข้อง

## พิสูจน์ว่าเงื่อนไขการออกจากลำดับทำงานได้

ทดสอบว่าจะเกิดอะไรขึ้นเมื่อผู้ติดต่อเริ่มใช้งานจริงหรือชำระเงินก่อนถึงการตรวจเกณฑ์แต่ละจุด หากใช้เงื่อนไขของผู้ติดต่อ ให้อัปเดตฟิลด์ที่เกี่ยวข้องใน Brew ระหว่างช่วงรอ แล้วยืนยันว่าอีเมลเตือนถูกข้าม หากใช้การตรวจที่แอปพลิเคชันตั้งเวลาไว้ ให้ยืนยันว่าบัญชีที่ไม่เข้าเกณฑ์ไม่ทำให้เกิดเหตุการณ์เตือน และทดสอบการลองใหม่ การขยายช่วงทดลองใช้ การลบบัญชี การยกเลิกการรับข่าวสาร และฟิลด์ที่ไม่มีค่าด้วย ตรวจทั้งบันทึกของแอปพลิเคชันและประวัติการทำงานใน Brew

วัดการเริ่มใช้งานจริงและการเปลี่ยนเป็นลูกค้าแบบชำระเงินด้วยข้อมูลผลิตภัณฑ์ของคุณ และวัดความล้มเหลวในการนำส่งด้วยแพลตฟอร์มอีเมล อัตราการเปิดเพียงอย่างเดียวไม่ได้บอกว่าลำดับอีเมลช่วยผู้ทดลองใช้ได้หรือไม่ ดูตัวอย่างได้ที่[การออกแบบลำดับอีเมลต้อนรับ](/th/blog/welcome-email-sequence) และดูการแบ่งงานในการนำไปใช้ได้ที่ [MCP กับ REST](/th/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use)