วิธีทำให้การแจ้งเตือนการจัดส่งเป็นระบบอัตโนมัติ: ทริกเกอร์ ช่องทาง และเทมเพลตใน 6 ขั้นตอน
หากต้องการทำให้การแจ้งเตือนการจัดส่งเป็นแบบอัตโนมัติ ให้เชื่อมโยงเหตุการณ์การจัดส่งกับรายการคำสั่งซื้อ กำหนดว่าการเปลี่ยนแปลงสถานะใดควรส่งข้อความ เลือกช่องทางการจัดส่งที่ได้รับอนุญาต และแนบเทมเพลตกับแต่ละทริกเกอร์ จากนั้นเพิ่มการป้องกันการซ้ำ การจัดการข้อยกเว้น และการทดสอบก่อนเปิดใช้งาน ขั้นตอนทั้งหกด้านล่างจะแสดงให้ทีมอีคอมเมิร์ซเห็นวิธีสร้างเวิร์กโฟลว์ที่มอบข้อมูลอัปเดตที่เป็นประโยชน์แก่ลูกค้า โดยไม่ส่งการแจ้งเตือนซ้ำหรือทำให้เข้าใจผิด
คู่มือนี้จัดทำขึ้นสำหรับผู้ค้า ทีมปฏิบัติการอีคอมเมิร์ซ และนักพัฒนาที่รับผิดชอบการสื่อสารหลังการซื้อ จุดเริ่มต้นที่แนะนำคือการแจ้งเตือนที่เชื่อถือได้จำนวนไม่มาก ได้แก่ ผู้ให้บริการขนส่งรับพัสดุแล้ว กำลังนำจ่าย จัดส่งแล้ว และข้อยกเว้นที่ลูกค้าต้องดำเนินการ เพิ่มข้อความอื่นเฉพาะเมื่อข้อความนั้นตอบคำถามที่แตกต่างและชัดเจนของลูกค้า
1. เชื่อมโยงเหตุการณ์การติดตามกับคำสั่งซื้อและผู้รับที่ถูกต้อง
ใบปะหน้าพัสดุ การสแกนของผู้ให้บริการขนส่ง และการแจ้งเตือนลูกค้าเป็นคนละสิ่งกัน การสร้างใบปะหน้าไม่ได้ยืนยันว่าผู้ให้บริการขนส่งได้รับพัสดุแล้ว ระบบอัตโนมัติของคุณควรรักษาความแตกต่างนี้ไว้ตั้งแต่เริ่มต้น
เริ่มต้นด้วยการระบุระบบที่จะเป็นผู้ตัดสินใจเกี่ยวกับการแจ้งเตือน อาจเป็นเวิร์กโฟลว์การแจ้งเตือนของร้านค้า แอปพลิเคชันติดตามพัสดุ หรือบริการที่เชื่อมต่อกับระบบจัดการคำสั่งซื้อ กำหนดผู้รับผิดชอบหนึ่งรายสำหรับข้อความแต่ละประเภท เพื่อไม่ให้หลายระบบส่งข้อมูลอัปเดตเดียวกันอย่างอิสระ
แนวทางการนำไปใช้งานที่ทำได้จริงมีสองแบบ:
- การตั้งค่าผ่านแอป: ใช้แอปพลิเคชันติดตามสำหรับอีคอมเมิร์ซเมื่อทีมของคุณต้องการกำหนดค่าเหตุการณ์ที่รองรับและข้อความที่ส่งถึงลูกค้า โดยไม่ต้องสร้างการเชื่อมต่อทั้งหมดเอง สำหรับผู้ค้า Shopify รายการแอป 17TRACK เป็นจุดเริ่มต้นที่เหมาะสมสำหรับประเมินเวิร์กโฟลว์การติดตามและการแจ้งเตือนการจัดส่ง ยืนยันให้แน่ชัดถึงทริกเกอร์ ช่องทาง ตัวเลือกการปรับแต่ง และข้อกำหนดของแพ็กเกจก่อนกำหนดค่ากฎ
- การตั้งค่าผ่าน API: ใช้การเชื่อมต่อการติดตามเมื่อเหตุการณ์การจัดส่งต้องส่งต่อไปยังระบบคำสั่งซื้อที่มีอยู่หรือเวิร์กโฟลว์การส่งข้อความแบบกำหนดเอง 17TRACK Tracking API และ เอกสารอย่างเป็นทางการ เป็นแหล่งอ้างอิงที่เกี่ยวข้องสำหรับการนำไปใช้งาน ยืนยันกลไกการส่งเหตุการณ์ ฟิลด์ payload การยืนยันตัวตน และพฤติกรรมการลองใหม่สำหรับการเชื่อมต่อที่คุณต้องการใช้ การรับข้อมูลการติดตามและการส่งข้อความถึงลูกค้าเป็นหน้าที่ที่แยกจากกัน
ไม่ว่าคุณจะเลือกแนวทางใด ให้จับคู่การจัดส่งแต่ละรายการกับคำสั่งซื้อและผู้รับที่ถูกต้อง บันทึกภายในที่มีประโยชน์ควรประกอบด้วย:
- หมายเลขอ้างอิงคำสั่งซื้อและตัวระบุการจัดส่ง
- หมายเลขติดตามและตัวระบุผู้ให้บริการขนส่ง หากมี
- รายการสินค้าที่รวมอยู่ในการจัดส่งนั้น โดยเฉพาะสำหรับคำสั่งซื้อที่แบ่งจัดส่ง
- ข้อมูลติดต่อ ภาษา เขตเวลา และการตั้งค่าช่องทางของลูกค้า
- สถานะการจัดส่งล่าสุดที่ได้รับการยอมรับและเวลาที่เกิดเหตุการณ์
- ประวัติการแจ้งเตือน รวมถึงการแจ้งเตือนแต่ละรายการเกี่ยวข้องกับการจัดส่งใด
แยกเวลาที่เกิดเหตุการณ์ออกจากเวลาที่ระบบของคุณได้รับข้อมูลอัปเดต การสแกนที่ล่าช้าไม่ควรถูกเปลี่ยนเป็นการแจ้งเตือนใหม่แก่ลูกค้าโดยอัตโนมัติ นอกจากนี้ ให้เก็บคำอธิบายดั้งเดิมของผู้ให้บริการขนส่งไว้ควบคู่กับสถานะที่ทำให้เป็นมาตรฐาน เพื่อให้ฝ่ายสนับสนุนตรวจสอบเหตุการณ์ที่คลุมเครือได้
2. กำหนดทริกเกอร์ที่สะท้อนการเปลี่ยนแปลงการจัดส่งที่มีความหมาย
ทริกเกอร์ควรแสดงถึงการเปลี่ยนแปลงที่เกี่ยวข้องกับลูกค้า ไม่ใช่บันทึกการติดตามใหม่ทุกรายการ การสแกนหลายครั้งที่ศูนย์ปฏิบัติการอาจหมายถึง “อยู่ระหว่างการขนส่ง” ทั้งหมด การส่งการแจ้งเตือนสำหรับแต่ละรายการจะสร้างเสียงรบกวนโดยไม่ช่วยให้ลูกค้าตัดสินใจ
จับคู่เหตุการณ์ขาเข้ากับสถานะที่เข้าใจง่ายจำนวนไม่มาก ตารางต่อไปนี้เป็นเวิร์กโฟลว์ที่เสนอ ไม่ใช่พจนานุกรมสถานะสากลสำหรับผู้ให้บริการขนส่งทุกราย
| ทริกเกอร์ | เงื่อนไขการส่ง | วัตถุประสงค์ของข้อความ |
|---|---|---|
| สร้างใบปะหน้าแล้ว | ไม่บังคับ แยกความแตกต่างระหว่างการเตรียมพัสดุกับการที่ผู้ให้บริการขนส่งครอบครองพัสดุ | อธิบายว่ารายละเอียดการติดตามพร้อมแล้ว |
| ผู้ให้บริการขนส่งรับพัสดุแล้ว | เหตุการณ์ที่รองรับระบุว่าผู้ให้บริการขนส่งได้รับพัสดุแล้ว | ยืนยันว่าการจัดส่งเข้าสู่เครือข่ายของผู้ให้บริการขนส่งแล้ว |
| อยู่ระหว่างการขนส่ง | หมุดหมายเสริม ควรระงับการสแกนตามปกติที่เกิดซ้ำ | ให้ข้อมูลความคืบหน้าที่มีความหมาย ไม่ใช่ฟีดการสแกนทีละรายการ |
| กำลังนำจ่าย | สถานะขาเข้ารองรับการตีความนี้อย่างชัดเจน | ช่วยให้ลูกค้าเตรียมรับพัสดุ |
| ข้อยกเว้นในการจัดส่ง | พบปัญหาที่มีความหมายหรือการดำเนินการที่จำเป็น | อธิบายปัญหาและขั้นตอนถัดไปที่เป็นประโยชน์ |
| จัดส่งแล้ว | ผู้ให้บริการขนส่งรายงานว่าการจัดส่งนี้เสร็จสิ้นแล้ว | ยืนยันผลลัพธ์ที่รายงานและมอบช่องทางขอความช่วยเหลือ |
จัดการข้อยกเว้นอย่างรอบคอบกว่าหมุดหมายตามปกติ ความพยายามจัดส่งที่ไม่สำเร็จ ปัญหาศุลกากร ปัญหาที่อยู่ และเหตุการณ์ส่งคืนผู้ส่ง อาจต้องใช้คำแนะนำที่แตกต่างกัน หากเหตุการณ์ไม่ได้อธิบายว่าลูกค้าควรทำอะไร อย่าสร้างแนวทางแก้ไขขึ้นเอง
สำหรับกฎ “ไม่มีข้อมูลอัปเดตล่าสุด” ให้เลือกเกณฑ์เวลาที่เหมาะสมกับบริการและเส้นทาง แทนการใช้ช่วงเวลาเดียวกับทุกกรณี การไม่มีการสแกนไม่ได้พิสูจน์ว่าพัสดุสูญหาย ให้ส่งกรณีที่ไม่แน่นอนไปยังคิวตรวจสอบภายใน หรือส่งข้อมูลอัปเดตที่เป็นกลางและอธิบายสิ่งที่ทราบอย่างถูกต้อง
แยกวันที่คาดว่าจะจัดส่งออกจากสถานะการจัดส่ง ใส่วันที่คาดการณ์เฉพาะเมื่อมีแหล่งข้อมูลที่เชื่อถือได้ ระบุว่าเป็นการประมาณการ และหลีกเลี่ยงการแทนที่ข้อมูลที่ขาดหายด้วยคำมั่นสัญญาที่คำนวณขึ้นและการดำเนินงานของคุณไม่สามารถรองรับได้
3. เลือกช่องทางและกำหนดกฎการติดต่อ
ใช้ช่องทางเพราะเหมาะกับข้อความและความต้องการของลูกค้า ไม่ใช่เพียงเพราะช่องทางนั้นมีให้ใช้งาน อีเมลเป็นจุดเริ่มต้นที่ใช้งานได้จริงสำหรับข้อมูลอัปเดตโดยละเอียด ช่องทางที่รวดเร็วกว่าสามารถใช้กับการดำเนินการที่ต้องทำภายในเวลาจำกัดได้ แต่ต้องอยู่ภายใต้เงื่อนไขว่ามีการอนุญาต กฎของผู้ให้บริการ และข้อกำหนดในท้องถิ่นรองรับ
- อีเมล: เหมาะสำหรับบริบทของคำสั่งซื้อ ลิงก์ติดตาม คำอธิบายการแบ่งจัดส่ง และคำแนะนำในการติดต่อฝ่ายสนับสนุน ควรมีเวอร์ชันข้อความธรรมดาและตรวจสอบการแสดงผลบนมือถือ
- SMS: มีประโยชน์สำหรับการแจ้งเตือนสั้น ๆ ที่นำไปดำเนินการได้เมื่อได้รับอนุญาต ระบุผู้ส่ง ทำให้ข้อความตรงประเด็น และหลีกเลี่ยงการเปิดเผยข้อมูลคำสั่งซื้อที่ไม่จำเป็น
- การแจ้งเตือนแบบพุช: เหมาะเมื่อ ลูกค้าใช้แอปของคุณและเปิดใช้งานการแจ้งเตือนแล้ว ให้ลิงก์ไปยังการจัดส่งที่เกี่ยวข้องแทนหน้าหลักทั่วไป
- แอปส่งข้อความ: พิจารณาใช้เมื่อลูกค้าใช้งานช่องทางนั้นอยู่แล้ว และการนำไปใช้ของคุณเป็นไปตามข้อกำหนดด้านการอนุญาตและข้อความของแพลตฟอร์ม
- หน้าติดตาม: ใช้เป็นปลายทางอ้างอิงรายละเอียด ช่วยเสริมการแจ้งเตือนขาออก แต่ไม่สามารถทดแทนการแจ้งเตือนเมื่อจำเป็นต้องให้ลูกค้าดำเนินการ
จัดทำเอกสารเกี่ยวกับความสัมพันธ์ระหว่างช่องทาง ตัวอย่างเช่น คุณอาจใช้อีเมลสำหรับหมุดหมายตามปกติ และใช้ช่องทางมือถือที่ได้รับอนุญาตสำหรับปัญหาการจัดส่งที่ลูกค้าต้องดำเนินการ อย่าส่งทุกเหตุการณ์ผ่านทุกช่องทางที่มีโดยอัตโนมัติ
กำหนดการจัดการช่วงเวลาห้ามรบกวนและนโยบายช่องทางสำรอง ความล้มเหลวชั่วคราวของอีเมลไม่ควรอนุญาตให้ส่ง SMS โดยอัตโนมัติ ก่อนเปลี่ยนช่องทาง ให้ตรวจสอบว่าคุณมีข้อมูลติดต่อและการอนุญาตที่เหมาะสม และไม่มีระบบอื่นส่งข้อความนั้นไปแล้ว
ทำให้ข้อมูลอัปเดตการจัดส่งเป็นข้อมูลเชิงปฏิบัติการ การเพิ่มเนื้อหาโปรโมชันอาจส่งผลต่อวิธีที่ข้อความถูกจัดประเภทภายใต้กฎที่ใช้บังคับ ในสหรัฐอเมริกา คำแนะนำ CAN-SPAM ของ FTC อธิบายว่าวัตถุประสงค์หลักของข้อความมีความสำคัญเมื่อรวมเนื้อหาเชิงพาณิชย์และธุรกรรมเข้าด้วยกัน อย่าสันนิษฐานว่าทุกข้อความที่กล่าวถึงคำสั่งซื้อได้รับการยกเว้นจากข้อกำหนดอีเมลเชิงพาณิชย์
4. สร้างเทมเพลตพร้อมพฤติกรรมสำรองที่ชัดเจน
แต่ละเทมเพลตควรตอบคำถามสามข้อ: เกิดอะไรขึ้น สิ่งนี้หมายความว่าอย่างไรสำหรับการจัดส่งนี้ และลูกค้าควรทำอะไรต่อ ใช้ฟิลด์แบบมีเงื่อนไขเพื่อให้ข้อมูลที่ขาดหายไปถูกลบออกอย่างเรียบร้อย แทนการทิ้งตัวแทนที่ไม่สมบูรณ์ไว้
ตัวอย่างด้านล่างเป็นเทมเพลตตั้งต้น ตัวแปรในวงเล็บเหลี่ยมเป็นเพียงตัวอย่าง ไม่ใช่รูปแบบไวยากรณ์ของเทมเพลตสำหรับแพลตฟอร์มใดโดยเฉพาะ
อีเมลยืนยันว่าผู้ให้บริการขนส่งรับพัสดุแล้ว
หัวข้อ: การจัดส่งสำหรับคำสั่งซื้อ [order_number] ของคุณกำลังเดินทาง
สวัสดี [first_name]
[carrier_name] ได้รับการจัดส่งสำหรับคำสั่งซื้อ [order_number] ของคุณแล้ว คุณสามารถติดตามความคืบหน้าได้ที่นี่: [tracking_link]
[หากมีวันที่คาดการณ์ที่เชื่อถือได้: วันที่คาดว่าจะจัดส่ง: [estimated_delivery_date] วันที่นี้อาจเปลี่ยนแปลงได้]
[หากคำสั่งซื้อถูกแบ่งจัดส่ง: การจัดส่งนี้ประกอบด้วย [shipment_items] สินค้าอื่นในคำสั่งซื้อของคุณจะมีข้อมูลอัปเดตการติดตามแยกต่างหาก]
ข้อความแจ้งว่ากำลังนำจ่าย
ตามข้อมูลอัปเดตล่าสุดของผู้ให้บริการขนส่ง การจัดส่งสำหรับคำสั่งซื้อ [order_number] ของคุณกำลังนำจ่าย ตรวจสอบความคืบหน้าและรายละเอียดการจัดส่งที่มีได้ที่นี่: [tracking_link]
อย่าเพิ่มเวลาถึงที่รับประกัน เว้นแต่การดำเนินงานของคุณมีพื้นฐานที่มั่นคงเพียงพอสำหรับคำมั่นสัญญานั้น “กำลังนำจ่าย” เป็นสถานะที่มีการรายงาน ไม่ใช่การรับประกันว่าจะจัดส่งเสร็จภายในวันนั้น
ข้อความแจ้งข้อยกเว้นพร้อมขั้นตอนถัดไปที่ตรวจสอบแล้ว
หัวข้อ: ข้อมูลอัปเดตการจัดส่งสำหรับคำสั่งซื้อ [order_number]
ผู้ให้บริการขนส่งรายงาน [plain_language_issue] สำหรับการจัดส่งของคุณ [verified_next_step] ดูรายละเอียดล่าสุดได้ที่นี่: [tracking_link] หากต้องการความช่วยเหลือ โปรดติดต่อเราที่ [support_link]
หากยังไม่มีการยืนยันขั้นตอนถัดไป ให้แทนที่ประโยคนั้นด้วย: “เรายังไม่มีขั้นตอนถัดไปที่ยืนยันแล้ว โปรดตรวจสอบหน้าติดตามเพื่อดูข้อมูลอัปเดต หรือติดต่อทีมสนับสนุนของเรา” ระบุว่าทีมของคุณกำลังตรวจสอบเฉพาะเมื่อมีการมอบหมายให้ตรวจสอบจริงเท่านั้น
อีเมลแจ้งว่าจัดส่งแล้ว
หัวข้อ: การจัดส่งของคุณถูกระบุว่าจัดส่งแล้ว
[carrier_name] ระบุว่าการจัดส่งสำหรับคำสั่งซื้อ [order_number] ของคุณจัดส่งแล้วเมื่อ [delivery_date] ดูรายละเอียดการจัดส่งที่มีได้ที่นี่: [tracking_link] หากไม่พบพัสดุ โปรดติดต่อเราที่ [support_link] เพื่อให้เราช่วยตรวจสอบขั้นตอนถัดไป
ใช้ถ้อยคำในระดับการจัดส่งสำหรับคำสั่งซื้อที่แบ่งจัดส่ง “คำสั่งซื้อของคุณมาถึงแล้ว” อาจทำให้เข้าใจผิดเมื่อพัสดุอีกชิ้นยังอยู่ระหว่างการขนส่ง หากไม่มีชื่อผู้ให้บริการขนส่ง วันที่ หรือชื่อลูกค้า ให้ใช้ประโยคทางเลือกที่ผ่านการทดสอบแล้ว แทนการแสดงฟิลด์ว่าง
5. เพิ่มมาตรการป้องกันข้อความซ้ำ ล้าสมัย และทำให้เข้าใจผิด
ระบบอัตโนมัติต้องมีบันทึกสิ่งที่ดำเนินการไปแล้ว เวิร์กโฟลว์ที่เพียงส่งข้อความทุกครั้งที่มีเหตุการณ์เข้ามาอาจส่งการแจ้งเตือนซ้ำหลังการลองใหม่ หรือส่งข้อมูลเก่าหลังจากมีหมุดหมายใหม่กว่าแล้ว
- ป้องกันการประมวลผลซ้ำ: ใช้ตัวระบุเหตุการณ์ที่คงที่เมื่อมีให้ใช้งาน มิฉะนั้น ให้กำหนดคีย์ป้องกันการซ้ำจากฟิลด์ที่เหมาะสม เช่น การจัดส่ง ประเภทเหตุการณ์ และเวลาที่เกิดเหตุการณ์ แยกบันทึกว่าการแจ้งเตือนที่เกี่ยวข้องถูกกำหนดเวลาไว้หรือส่งไปแล้วหรือไม่
- ระงับการส่งสถานะซ้ำ: การสแกนหลายครั้งที่จับคู่กับสถานะเดียวกันสำหรับลูกค้าไม่ควรสร้างข้อความหลายรายการโดยอัตโนมัติ
- ตรวจสอบความเกี่ยวข้องของเหตุการณ์ก่อนส่ง: ประเมินข้อความที่อยู่ในคิวใหม่ก่อนส่ง ระงับการแจ้งเตือนว่าอยู่ระหว่างขนส่งที่เก่าแล้ว หากมีการรายงานว่าจัดส่งแล้ว
- จัดการการแก้ไขอย่างมีแบบแผน: เก็บประวัติเหตุการณ์เดิมและตรวจสอบการถดถอยที่เห็นได้ชัด อย่าสันนิษฐานว่าเหตุการณ์ที่มาถึงภายหลังใหม่กว่าหรือถูกต้องกว่าเสมอ
- ลองใหม่อย่างปลอดภัย: แยกความแตกต่างระหว่างการส่งล้มเหลวกับผลลัพธ์ที่ไม่ทราบแน่ชัด หากรองรับ ให้ใช้ฟีเจอร์ idempotency ของผู้ให้บริการเพื่อลดโอกาสที่การลองใหม่จะสร้างข้อความอีกฉบับ
- ปกป้องการจับคู่ผู้รับ: อย่าเชื่อมโยงการจัดส่งกับลูกค้าโดยอาศัยเพียงการจับคู่หมายเลขติดตามที่ยังไม่ได้ตรวจสอบ
- ส่งต่อข้อยกเว้นที่ยังแก้ไขไม่ได้: กำหนดผู้รับผิดชอบด้านปฏิบัติการ แทนการส่งคำเตือนเดิมให้ลูกค้าซ้ำ ๆ
สำหรับการเชื่อมต่อแบบกำหนดเอง ให้ปฏิบัติตามแนวทางที่ผู้ให้บริการระบุไว้เกี่ยวกับการยืนยันตัวตน การตอบรับเหตุการณ์ และการลองใหม่ ทำให้บันทึกการประมวลผลมีประโยชน์โดยไม่คัดลอกข้อมูลส่วนบุคคลที่ไม่จำเป็นลงไป ลิงก์ติดตามควรหลีกเลี่ยงการเปิดเผยคำสั่งซื้อหรือข้อมูลของลูกค้ารายอื่นเกินกว่าที่ผู้รับจำเป็นต้องทราบ
ลำดับการประมวลผลที่มีประโยชน์คือ: ตรวจสอบเหตุการณ์ ระบุการจัดส่ง อัปเดตสถานะ ตรวจสอบสิทธิ์ในการแจ้งเตือน เลือกช่องทางที่ได้รับอนุญาต แสดงผลเทมเพลต จัดคิวข้อความ และบันทึกผลลัพธ์ ตรวจสอบสิทธิ์อีกครั้งตอนส่ง หากข้อความรออยู่ในคิว
6. ทดสอบเส้นทางทั้งหมด จากนั้นเปิดใช้งานทีละน้อย
อย่าประเมินเวิร์กโฟลว์จากการดูเพียงว่าอีเมลทดสอบแสดงผลถูกต้องหรือไม่ ให้ทดสอบเส้นทางทั้งหมดตั้งแต่เหตุการณ์การจัดส่งไปจนถึงปลายทางของลูกค้า รวมถึงกรณีที่เกิดความล้มเหลว
- เส้นทางปกติ: การรับพัสดุ การขนส่ง การนำจ่าย และการจัดส่งเสร็จสิ้น สร้างข้อความตามที่ตั้งใจไว้
- เหตุการณ์ซ้ำ: การเล่นเหตุการณ์เดิมซ้ำไม่สร้างการแจ้งเตือนเพิ่มเติม
- เหตุการณ์ไม่เรียงลำดับ: การสแกนระหว่างขนส่งที่ล่าช้าไม่ทริกเกอร์การแจ้งเตือนเก่าหลังจากมีการจัดส่งแล้ว
- คำสั่งซื้อที่แบ่งจัดส่ง: แต่ละข้อความระบุการจัดส่งที่ถูกต้องและไม่ทำให้เข้าใจว่าสินค้าทั้งหมดมาถึงแล้ว
- ฟิลด์ที่ขาดหาย: ชื่อ ผู้ให้บริการขนส่ง วันที่คาดการณ์ หรือรายการสินค้าที่ไม่มี จะสร้างข้อความสำรองที่อ่านเข้าใจได้
- ข้อจำกัดด้านการติดต่อ: เวิร์กโฟลว์ปฏิบัติตามการตั้งค่าช่องทาง กฎการระงับ และช่วงเวลาห้ามรบกวนที่กำหนดไว้
- การส่งล้มเหลว: ที่อยู่ไม่ถูกต้อง ข้อผิดพลาดของผู้ให้บริการ และการลองใหม่ ให้ผลลัพธ์ที่ตรวจสอบย้อนกลับได้โดยไม่ส่งซ้ำอย่างควบคุมไม่ได้
- การดำเนินการของลูกค้า: ลิงก์ติดตามและลิงก์สนับสนุนทุกลิงก์นำไปยังปลายทางที่ต้องการบนมือถือ
เริ่มต้นด้วยกลุ่มการจัดส่งที่จำกัดและตรวจสอบประวัติข้อความควบคู่กับประวัติการติดตาม ให้เจ้าหน้าที่สนับสนุนมีวิธีดูว่าลูกค้าได้รับอะไร รักษาปุ่มหยุดชั่วคราวไว้ เพื่อให้ทีมสามารถหยุดกฎที่ผิดพลาดได้โดยไม่ต้องปิดการติดตามการจัดส่งทั้งหมด
ตรวจสอบสิทธิ์ในการแจ้งเตือน ความพยายามส่ง การยอมรับโดยผู้ให้บริการ ความล้มเหลว ข้อความซ้ำ และระยะเวลาระหว่างการรับเหตุการณ์กับการส่งข้อความ การยอมรับโดยผู้ให้บริการไม่ได้ยืนยันว่าลูกค้าอ่านข้อความ และอัตราการเปิดเพียงอย่างเดียวไม่ได้ยืนยันว่าเวิร์กโฟลว์ช่วยลูกค้าได้
ในการประเมินผลกระทบต่อลูกค้า ให้เปรียบเทียบอัตราการติดต่อที่เกี่ยวข้องกับการจัดส่งโดยใช้คำนิยามที่สอดคล้องกันและกลุ่มการจัดส่งที่เทียบเคียงได้ พิจารณาการเปลี่ยนแปลงของสัดส่วนผู้ให้บริการขนส่ง ปัญหาการจัดส่ง และปริมาณคำสั่งซื้อก่อนระบุว่าการเปลี่ยนแปลงเกิดจากการแจ้งเตือน
คำถามที่พบบ่อย
ควรส่งการยืนยันการจัดส่งเมื่อสร้างใบปะหน้าหรือไม่
คุณสามารถส่งข้อมูลอัปเดตเมื่อสร้างใบปะหน้าได้ แต่ต้องอธิบายอย่างถูกต้อง เช่น แจ้งว่ารายละเอียดการจัดส่งพร้อมแล้วหรือกำลังเตรียมการจัดส่ง ควรใช้ถ้อยคำที่ยืนยันว่าผู้ให้บริการขนส่งครอบครองพัสดุแล้วเฉพาะเมื่อมีเหตุการณ์ที่รองรับข้อความดังกล่าว
การแจ้งเตือนการจัดส่งทำงานโดยไม่มีการเชื่อมต่อ API ได้หรือไม่
ได้ เวิร์กโฟลว์ผ่านแอปอาจจัดการการเชื่อมต่อและกฎการแจ้งเตือนผ่านอินเทอร์เฟซของแอป ตรวจสอบเหตุการณ์ ช่องทาง การควบคุมเทมเพลต และการจัดการข้อยกเว้นที่มีอยู่ในการตั้งค่าที่คุณเลือก การเชื่อมต่อแบบกำหนดเองเหมาะสมกว่าเมื่อระบบที่มีอยู่ต้องใช้การกำหนดเส้นทางหรือเหตุผลในการตัดสินใจเฉพาะทาง
การจัดส่งแต่ละรายการควรได้รับการแจ้งเตือนกี่ครั้ง
ไม่มีจำนวนที่เหมาะสมแบบสากล ให้เริ่มจากหมุดหมายที่แตกต่างและมีประโยชน์ รวมถึงข้อยกเว้นที่ลูกค้าดำเนินการได้ ระงับการสแกนระหว่างขนส่งที่ซ้ำกัน และเพิ่มข้อความเฉพาะเมื่อข้อความนั้นมอบข้อมูลที่ลูกค้าต้องการ
ควรทำอย่างไรเมื่อการติดตามหยุดอัปเดต
ใช้กฎการตรวจสอบที่เหมาะกับบริการ แทนการประกาศว่าการจัดส่งสูญหาย ตรวจสอบเหตุการณ์ล่าสุด วันที่คาดว่าจะจัดส่งหากมี และกระบวนการปฏิบัติการที่เกี่ยวข้อง ส่งข้อมูลอัปเดตให้ลูกค้าเฉพาะเมื่อข้อมูลนั้นเพิ่มข้อมูลที่ตรวจสอบแล้วหรือขั้นตอนถัดไปที่เป็นประโยชน์
การแจ้งเตือนว่าจัดส่งแล้วสามารถปิดเคสสนับสนุนโดยอัตโนมัติได้หรือไม่
การสแกนว่าจัดส่งแล้วสามารถอัปเดตเคสได้ แต่ไม่ควรแก้ไขรายงานของลูกค้าที่ไม่ได้รับพัสดุโดยอัตโนมัติ ให้ถือว่าสถานะการจัดส่งของผู้ให้บริการขนส่งและปัญหาของลูกค้าเป็นบันทึกแยกกัน จากนั้นดำเนินการตามกระบวนการตรวจสอบของคุณ
แหล่งข้อมูล
- รายการแอป 17TRACK Shopify — แหล่งอ้างอิงผลิตภัณฑ์สำหรับประเมินการตั้งค่าการติดตามและการแจ้งเตือนผ่านแอป
- 17TRACK Tracking API — แหล่งอ้างอิงผลิตภัณฑ์สำหรับการเชื่อมต่อการติดตามผ่าน API
- เอกสาร 17TRACK API — แหล่งอ้างอิงการนำไปใช้งานสำหรับตรวจสอบพฤติกรรมและข้อกำหนดของการเชื่อมต่อที่รองรับ
- FTC: คู่มือการปฏิบัติตามกฎหมาย CAN-SPAM สำหรับธุรกิจ — คำแนะนำเกี่ยวกับอีเมลเชิงพาณิชย์และข้อความที่รวมเนื้อหาเชิงธุรกรรมกับเนื้อหาโปรโมชัน


