# วิธีส่งอีเมลตามวงจรชีวิตลูกค้าอัตโนมัติจากเหตุการณ์ Stripe

URL หลัก: https://brew.new/th/blog/how-to-automate-lifecycle-emails-from-stripe-subscription-events
ผู้เขียน: Philip Sørensen
เผยแพร่: 2026-09-18
อัปเดต: 2026-09-29

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

[การเชื่อมต่อ Stripe](/th/browse/integrations/stripe) ของ Brew ดูแลทั้งการเชื่อมต่อแบบ OAuth และการตั้งค่าเว็บฮุกให้ ส่วนคู่มือนี้อธิบายวิธีออกแบบงานอีเมลที่ต่อยอดจากการเชื่อมต่อนั้น หากเป็นโฟลว์ที่เริ่มจากเหตุการณ์ในผลิตภัณฑ์แทนการเรียกเก็บเงิน ดู[อีเมลอัตโนมัติด้วย AI](/th/blog/ai-email-automation)

## จับคู่เหตุการณ์หนึ่งกับข้อความหนึ่ง

| ผลลัพธ์ที่ต้องการ | เหตุการณ์ที่ใช้ได้ | สิ่งที่ต้องตรวจทานก่อนส่ง |
| --- | --- | --- |
| ต้อนรับผู้สมัครสมาชิก | `customer.subscription.created` | หลีกเลี่ยงอีเมลต้อนรับซ้ำจากเหตุการณ์เซสชันชำระเงิน |
| อธิบายว่าช่วงทดลองใช้กำลังจะสิ้นสุด | `customer.subscription.trial_will_end` | กำหนดสิ้นสุดที่แท้จริง และจะมีการเรียกเก็บเงินหรือไม่ |
| แจ้งว่าการชำระใบแจ้งหนี้ไม่สำเร็จ | `invoice.payment_failed` | ใบแจ้งหนี้ปัจจุบัน ลิงก์การเรียกเก็บเงิน และการแจ้งเตือนที่ Stripe ส่งอยู่แล้ว |
| อธิบายการเปลี่ยนแพ็กเกจ | `customer.subscription.updated` | ฟิลด์ใดเปลี่ยนไป และการเปลี่ยนแปลงนั้นสำคัญหรือไม่ |
| รับทราบการยกเลิก | `customer.subscription.deleted` | สิทธิ์การใช้งานสิ้นสุดเมื่อไร และลูกค้าขออะไรไว้ |
| อธิบายการคืนเงิน | `refund.created` | ฟิลด์เฉพาะของการคืนเงินที่มีในเหตุการณ์ |

ใช้[ข้อมูลอ้างอิงเหตุการณ์ของ Stripe](https://docs.stripe.com/api/events/types) ควบคู่กับสคีมาของทริกเกอร์ Brew ที่เลือก การอัปเดตการสมัครสมาชิกอาจหมายถึงการเปลี่ยนแปลงได้หลายแบบ จึงไม่ควรส่งอีเมลแจ้งเปลี่ยนแพ็กเกจทุกครั้งที่มีการอัปเดตโดยไม่ตรวจข้อมูลก่อน

## เชื่อมต่อและเผยแพร่อย่างรอบคอบ

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

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

สร้างระบบอัตโนมัติตัวแรกเป็นฉบับร่าง ตรวจดูอีเมลที่สร้างขึ้น และทดสอบกับผู้รับที่ควบคุมได้ก่อนเผยแพร่ ส่วนรายละเอียดการเชื่อมต่อ ให้ทำตาม[คู่มือการตั้งค่า Stripe](https://docs.brew.new/integrations/import/stripe) ทั้งนี้ Brew เชื่อมต่อกับบัญชี Stripe ที่ใช้งานจริง และเหตุการณ์จากโหมดทดสอบจะไม่เริ่มระบบอัตโนมัติ

## จัดการการชำระเงินไม่สำเร็จโดยไม่ส่งอีเมลเตือนที่ล้าสมัย

อีเมลแจ้งการชำระเงินไม่สำเร็จที่ส่งทันทีเริ่มได้จาก `invoice.payment_failed` อธิบายว่าเกิดอะไรขึ้น และลิงก์ไปยังหน้าการเรียกเก็บเงินของคุณเอง อย่าสัญญาว่า Brew จะลองเรียกเก็บเงินอีกครั้ง เพราะ Stripe เป็นผู้ดูแลการชำระเงิน

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

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

ทดสอบทั้งกรณีที่การชำระเงินกลับมาสำเร็จก่อนถึงเวลาตรวจ กรณีที่ใบแจ้งหนี้ยังไม่ได้ชำระ และกรณีที่งานถูกลองซ้ำ ใช้คีย์ idempotency เดิมสำหรับเหตุการณ์เดียวกันในเชิงตรรกะภายใน[ช่วงเวลาลองซ้ำที่ระบุไว้ในเอกสาร](https://docs.brew.new/api-reference/api/idempotency)

## ปรับเนื้อหาเฉพาะบุคคลจากฟิลด์ที่ประกาศไว้

Brew ซิงค์ฟิลด์การเรียกเก็บเงินเข้าสู่ผู้ติดต่อได้ รวมถึงสถานะการสมัครสมาชิกและแพ็กเกจ แต่เพย์โหลดของเหตุการณ์กับฟิลด์ผู้ติดต่อเป็นแหล่งข้อมูลคนละแหล่งกัน ให้อ่านสคีมาของทริกเกอร์ก่อนใช้ `amount`, `currency`, `invoiceNumber`, `previousPlan`, `newPlan` หรือ `failureMessage` เพราะไม่ใช่ทุกเหตุการณ์ที่มีฟิลด์เหล่านี้ครบ

ID ของออบเจ็กต์ Stripe จะถูกตัดออกจากเพย์โหลดของระบบอัตโนมัติ อย่าสร้าง URL ของพอร์ทัลลูกค้าจาก ID ใบแจ้งหนี้หรือ ID การสมัครสมาชิกที่คาดเดาเอาเอง ให้ใช้หน้าการเรียกเก็บเงินในแอปพลิเคชันของคุณที่ต้องยืนยันตัวตนก่อนเข้า หรือลิงก์ที่ตั้งใจส่งมาในเหตุการณ์ที่กำหนดเอง และทำตาม[คู่มือแท็กตัวแปร](https://docs.brew.new/create-emails/merge-tags)

## ให้แต่ละระบบรับผิดชอบหน้าที่เดียว

ตรวจสอบ[การตั้งค่าอีเมลถึงลูกค้าของ Stripe](https://docs.stripe.com/billing/revenue-recovery/customer-emails) แล้วกำหนดว่าระบบใดเป็นผู้ส่งใบเสร็จ อีเมลแจ้งการชำระเงินไม่สำเร็จ และอีเมลเตือน การเปิดระบบอัตโนมัติใน Brew ไม่ได้ปิดอีเมลของ Stripe ให้

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

## ตรวจให้ครบทั้งเส้นทาง

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

เริ่มจากเหตุการณ์ 1 รายการกับอีเมล 1 ฉบับที่ทดสอบแล้ว แล้วค่อยเพิ่มอีเมลเตือนที่ตามมา เมื่อการทดสอบของแอปพลิเคชันครอบคลุมการตรวจสถานะปัจจุบันและพฤติกรรมการลองซ้ำแล้วเท่านั้น