# อีเมลอัตโนมัติตามทริกเกอร์: เชื่อมเหตุการณ์กับข้อความที่ใช่

URL หลัก: https://brew.new/th/blog/triggered-email-automations-guide
ผู้เขียน: Brew Team
เผยแพร่: 2026-08-20
อัปเดต: 2026-09-29

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

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

## กำหนดความหมายของเหตุการณ์ให้แม่นยำ

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

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

โมเดลระบบอัตโนมัติของ Brew เชื่อมทริกเกอร์เข้ากับขั้นตอนต่าง ๆ เช่น การส่งอีเมล ให้สร้างและตรวจทานฉบับร่าง แล้วเผยแพร่ระบบอัตโนมัติก่อนจะคาดหวังให้เหตุการณ์จากระบบที่ใช้งานจริงสั่งให้ระบบอัตโนมัตินั้นทำงาน ส่วนโฟลว์ตามวงจรชีวิตลูกค้าที่ควรสร้างก่อน ตั้งแต่การสมัครใช้งานไปจนถึงการกระตุ้นให้กลับมาใช้งาน ดูได้ในบทความ[อีเมลอัตโนมัติด้วย AI](/th/blog/ai-email-automation)

## อีเมลการตลาดกับอีเมลธุรกรรมต้องตรวจทานต่างกัน

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

ทำให้ข้อมูลบัญชีที่สำคัญหาได้ง่าย ใช้วัตถุประสงค์ของโดเมนผู้ส่งที่เหมาะสม และทดสอบการทำงานของสถานะการรับข่าวสาร อ่าน[คู่มืออีเมลธุรกรรม](/th/blog/transactional-emails)เพื่อดูความแตกต่าง และข้อกำหนดของผู้ให้บริการอีเมลที่ลิงก์ไว้

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

## อีเมลเตือนวันที่หกต้องใช้ข้อเท็จจริงของวันที่หก

สมมติว่าคุณต้องการเตือนผู้ทดลองใช้ที่ยังตั้งค่าไม่เสร็จหลังผ่านไป 6 วัน เหตุการณ์การสมัครใช้งานรู้แค่สิ่งที่เป็นจริงตอนสมัคร และคาดเดาไม่ได้ว่าผู้ใช้จะตั้งค่าเสร็จในวันพรุ่งนี้หรือไม่

สำหรับการตรวจในวันที่หกใน Brew นั้น โหนดตัวกรองหรือโหนดแยกเส้นทางตามเงื่อนไขอ่านฟิลด์ผู้ติดต่อปัจจุบันใน Brew ได้ผ่าน `contact.<name>` ให้กำหนดและซิงค์ฟิลด์ที่บอกสถานะการเริ่มใช้งานจริงและสถานะการรับข่าวสาร แล้วตรวจฟิลด์เหล่านั้นหลังช่วงรอ ส่วนฟิลด์ของเหตุการณ์อย่าง `payload.activated` ยังเก็บค่าเดิมจากเหตุการณ์ต้นทาง หากสถานะที่ต้องใช้อยู่นอก Brew ให้แอปพลิเคชันของคุณตรวจในวันที่หก แล้วส่งเหตุการณ์เตือนใหม่เฉพาะเมื่อผู้ใช้ยังเข้าเกณฑ์อยู่

กฎเดียวกันนี้ใช้กับเงื่อนไขอย่าง “ยังไม่ได้ซื้อ” หรือ “ยังใช้แพ็กเกจฟรีอยู่” ด้วย ส่วนรูปแบบที่ให้แอปพลิเคชันเป็นผู้ตรวจ อธิบายไว้ใน[บทความเรื่องลำดับอีเมลช่วงทดลองใช้](/th/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events)

## ตรวจสอบทั้งเส้นทาง

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

สำหรับผู้ให้บริการที่เชื่อมต่อไว้ ให้ใช้ชื่อเหตุการณ์จริงของผู้ให้บริการนั้น [หน้า Stripe](/th/browse/integrations/stripe) แสดงรายการเหตุการณ์ที่ Brew รองรับ และอธิบายว่าทำไมการตั้งค่า “ซิงค์ชื่อ-นามสกุล” จึงไม่เกี่ยวกับการเผยแพร่ระบบอัตโนมัติ

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