ไม่มีอินบ็อกซ์แยกสำหรับเอเจนต์ กฎ CAN-SPAM ยังเหมือนเดิม เกณฑ์ของ Gmail ก็เหมือนเดิม และยังต้องแยกอีเมลการตลาดกับอีเมลธุรกรรมออกจากกันในการส่งจริง
เอเจนต์เริ่มแคมเปญได้ผ่านโครงสร้างพื้นฐานการส่งชุดเดียวกับที่คนใช้ ส่วน Gmail ก็ยังเห็นผู้ส่ง โดเมน และตัวข้อความเหมือนเดิม
ผู้ให้บริการอีเมลให้คะแนนโดเมน, IP และอัตราการร้องเรียน แต่ไม่ได้ให้คะแนนว่าคนเป็นผู้กดส่งหรือไม่ หากเอเจนต์ส่งเนื้อหาโปรโมชันออกไปผ่าน IP สำหรับอีเมลธุรกรรม คุณก็จะเจอปัญหาเดียวกับที่ทำพลาดเองด้วยมือ เพียงแต่เกิดเร็วกว่า
บทความนี้เป็นส่วนเสริมของคู่มืออัตราการส่งถึง ไม่ได้มาแทนที่ บทความนั้นครอบคลุมชื่อเสียงผู้ส่ง การยืนยันตัวตน และการรักษาคุณภาพของรายชื่อ ส่วนบทความนี้ว่าด้วยข้อผิดพลาดที่เกิดขึ้นเมื่อซอฟต์แวร์เป็นผู้กดส่ง
CAN-SPAM ใช้กับข้อความเชิงพาณิชย์ ส่วนเกณฑ์วัตถุประสงค์หลักพิจารณาที่หัวเรื่องและเนื้อหา ไม่ได้ดูว่าใครเป็นคนพิมพ์
สำหรับข้อความที่ผสมใบแจ้งหนี้เข้ากับข้อเสนอ ให้ประเมินวัตถุประสงค์หลักของข้อความนั้น หัวเรื่อง ตำแหน่งของข้อมูลบัญชี และความโดดเด่นของโปรโมชันล้วนมีผล ส่วนท้ายสั้น ๆ ที่มีโปรโมชันไม่ได้ทำให้ใบแจ้งยอดบัญชีกลายเป็นข้อความเชิงพาณิชย์โดยอัตโนมัติ แนวทางของ FTC มีตัวอย่างให้ดู ข้อความเชิงพาณิชย์ต้องมีข้อมูลส่วนหัว (header) และหัวเรื่องที่ตรงตามความจริง ที่อยู่ทางไปรษณีย์ และช่องทางยกเลิกการรับข่าวสารที่ใช้งานได้จริง
ในทางกลับกันก็เช่นกัน อีเมลรีเซ็ตรหัสผ่านที่เอเจนต์สั่งส่งจากเหตุการณ์ด้านความปลอดภัยที่เกิดขึ้นจริงยังถือเป็นอีเมลธุรกรรม ตราบใดที่เนื้อหายังอยู่กับเหตุการณ์นั้น
ข้อกำหนดสำหรับผู้ส่งของ Gmail มีทั้งกฎสำหรับผู้ส่งทุกราย และกฎที่เข้มงวดกว่าสำหรับผู้ส่งอีเมลปริมาณมากที่ส่งถึงบัญชี Gmail ส่วนตัวราว 5,000 ฉบับต่อวัน ข้อกำหนดที่เข้มงวดกว่านี้ได้แก่:
p=none หรือเข้มงวดกว่านั้นList-Unsubscribe และ List-Unsubscribe-Postอีเมลธุรกรรมได้รับการยกเว้นจากกฎการยกเลิกในคลิกเดียว แต่ไม่ได้รับการยกเว้นจากการยืนยันตัวตน และไม่รอดจากการร้องเรียนว่าเป็นสแปม หากคุณใส่โปรโมชันลดราคาลงไปในเทมเพลตจนแน่น
Yahoo ขอให้ผู้ส่งอีเมลปริมาณมากแยกอีเมลการตลาดกับอีเมลธุรกรรมไว้บน IP ที่ต่างกัน และควรแยกโดเมนด้วย ตรวจว่าเอเจนต์จะใช้ตัวตนผู้ส่งใด แทนที่จะปล่อยไว้กับค่าเริ่มต้นที่ไม่ชัดเจน
ให้เอเจนต์ใช้ตัวตนผู้ส่งสำหรับอีเมลโปรโมชันกับแคมเปญและระบบอัตโนมัติ ซึ่งก็คือโดเมนที่คุณวอร์มอัปไว้ IP ที่คุณคาดไว้แล้วว่าการร้องเรียนจะมาลงที่นั่น และเฮดเดอร์ยกเลิกการรับข่าวสารที่คุณทดสอบแล้ว
แยกอีเมลธุรกรรมไว้บนตัวตนผู้ส่งอีกชุดหนึ่ง ใน Brew ตัวตนนั้นคือโดเมนที่ตั้งวัตถุประสงค์การส่งเป็นธุรกรรม และตัวอีเมลเองคือระบบอัตโนมัติที่เผยแพร่แล้วพร้อมทริกเกอร์ เอเจนต์เขียนเทมเพลตได้ แต่เส้นทางการส่งของแต่ละเหตุการณ์ยังควรเป็น POST /v1/automations/triggers/{triggerEventId}/fire พร้อมเพย์โหลด JSON ไม่ใช่ “ส่งฉบับร่างนี้ให้ทั้งรายชื่อ”
อย่าปล่อยให้เอเจนต์เลือกที่อยู่ From จากโดเมนที่ยืนยันแล้วกองหนึ่ง “เพื่อดูว่าอันไหนเข้าอินบ็อกซ์” เพราะนั่นคือวิธีที่ทำให้คุณสร้างชื่อเสียงผู้ส่งสองชุดไปพร้อมกัน โดยไม่เข้าใจชุดไหนเลย
ความผิดพลาดที่ต้องระวังไม่ใช่การพิมพ์ผิด แต่เป็นย่อหน้าที่อ่านลื่นไหลซึ่งอ้างตัวเลขที่คุณไม่เคยเผยแพร่ หรือหัวเรื่องที่ดูเหมือนใบเสร็จ
ก่อนปล่อยให้เอเจนต์ส่งเองโดยไม่ผ่านคิวตรวจทาน:
Cory Nelson จาก Harmonya เล่าให้ Noah Adelstein ฟังว่าเขาอ่านตรวจแคมเปญแรกแบบนี้ก่อนจะไว้ใจวงจรการทำงานนั้น นี่คือลำดับที่ถูกต้อง
ยืนยันตัวตนของโดเมน เลือกตัวตนผู้ส่งให้ถูกต้อง และตรวจทานแคมเปญแรกเทียบกับบรีฟที่อนุมัติแล้ว ตรวจสิทธิ์และการตั้งค่าการยืนยันของผู้ช่วย AI ด้วย เพราะไคลเอนต์ MCP แต่ละตัวขอการอนุมัติไม่เหมือนกัน
บรีฟที่ช่วยกันไม่ให้มีตัวเลขที่แต่งขึ้นเองอยู่ในวิธีบรีฟเอเจนต์อีเมล ส่วนการอ่านตรวจแคมเปญแรกของ Harmonya อยู่ในเรื่องที่ Harmonya เปลี่ยนจดหมายข่าวให้กลายเป็นการตลาดตามวงจรชีวิตลูกค้า
