# วิธีสร้างลำดับอีเมลแนะนำการใช้งานจาก Cursor

URL หลัก: https://brew.new/th/blog/how-to-create-an-email-onboarding-sequence-from-cursor
ผู้เขียน: Philip Sørensen
เผยแพร่: 2026-09-25
อัปเดต: 2026-09-29

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

## เชื่อมต่อ Brew

เพิ่มเซิร์ฟเวอร์นี้ในการตั้งค่า MCP ของ Cursor หรือในไฟล์ `.cursor/mcp.json` ของโปรเจกต์:

```json
{
  "mcpServers": {
    "brew": { "url": "https://brew.new/api/mcp" }
  }
}
```

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

## กำหนดเกณฑ์ของการสมัครและอีเมลเตือนแยกจากกัน

ขอให้ Cursor หาโค้ดที่บันทึกบัญชีใหม่จนเสร็จสมบูรณ์ (commit) แล้วตัดสินใจว่าอะไรนับเป็นการเริ่มใช้งานจริง เช่น การสร้างโปรเจกต์แรก คู่มือนี้ตรวจการเข้าเกณฑ์ไว้ในแอปพลิเคชัน และใช้ทริกเกอร์ 2 ตัวที่แยกจากกัน:

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

ใช้ `save_trigger` กำหนดเพย์โหลดของแต่ละทริกเกอร์ รวมถึงสตริงอีเมลที่จำเป็นต้องมี แล้วบันทึก ID ทริกเกอร์จริงที่ได้กลับมา ชื่อที่ใช้แสดงอย่าง `user_signed_up` ใช้แทนตัวระบุของ API ไม่ได้

## สร้างและตรวจทานอีเมล

บรีฟแรกที่มีประโยชน์คือ:

```text
Create a welcome email for a new account.
One action: create a first project at https://app.example.com/projects/new.
Use the brand already selected in Brew. Do not invent statistics or testimonials.
Create a separate setup-reminder email for recipients our app confirms have not activated.
Leave both automations as drafts for review.
```

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

อย่าวางตัวกรอง `activated is false` ไว้ในเส้นทางเดียวกันแบบเส้นตรงก่อนอีเมลติดตามผลที่ใช้ `activated is true` เพราะเมื่อตัวกรองไม่ผ่าน ขั้นตอนทั้งหมดที่ตามมาจะหยุดไปด้วย ฟิลด์ของเหตุการณ์อย่าง `payload.activated` จะคงค่าเดิมหลังขั้นตอนรอ ทางเลือกอื่นนอกเหนือจากสูตรที่ให้แอปพลิเคชันจัดตารางเวลานี้ คือกำหนดและซิงค์ฟิลด์ผู้ติดต่อประเภทใช่/ไม่ใช่ (boolean) แล้วตรวจ `contact.activated` หลังขั้นตอนรอแต่ละขั้นที่เกี่ยวข้อง เงื่อนไขนั้นจะอ่านข้อมูลผู้ติดต่อปัจจุบันใน Brew ไม่ใช่ฐานข้อมูลของแอปพลิเคชันคุณ ดู[คู่มือลำดับอีเมลช่วงทดลองใช้](/th/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events)

## เชื่อมต่อแบ็กเอนด์

ดึงสคีมาเพย์โหลดของแต่ละทริกเกอร์ด้วย `get_trigger_contract` หรือสร้างสคีมาด้วย [CLI](https://docs.brew.new/api-reference/guides/typed-payload-contracts) แล้วเรียกทริกเกอร์การสมัครใช้งานหลังจากทรานแซกชันการสร้างบัญชี commit สำเร็จแล้ว

ตัวอย่างคำสั่ง shell นี้สมมติว่า `BREW_SIGNUP_TRIGGER_ID` เก็บตัวระบุที่ได้กลับมาตอนสร้างทริกเกอร์ และสคีมาของทริกเกอร์ประกาศ `firstName` ไว้:

```bash
curl --fail-with-body \
  "https://brew.new/api/v1/automations/triggers/${BREW_SIGNUP_TRIGGER_ID}/fire" \
  -H "Authorization: Bearer ${BREW_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: signup-example-account-123" \
  -d '{"payload":{"email":"alex@example.com","firstName":"Alex"}}'
```

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

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

## ทดสอบก่อนเผยแพร่

ใช้ `test_automation` กับผู้รับที่ควบคุมได้ ตรวจดู[การทำงานของการทดสอบในปัจจุบัน](https://docs.brew.new/create-emails/build-an-automation) และตรวจประวัติการทำงาน ทดสอบตัวจัดตารางเวลาของแอปพลิเคชันด้วย:

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

ตรวจวัตถุประสงค์ของโดเมนผู้ส่งและข้อกำหนดด้านความยินยอม จากนั้นเผยแพร่อย่างชัดเจนด้วย `save_automation` และ `published: true` เมื่อเผยแพร่แล้ว ระบบอัตโนมัติจะทำงานกับเหตุการณ์จริงได้

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