การเชื่อมต่อระบบการจัดส่งของ Bigcommerce: ตัวเลือกสำหรับอัตราค่าจัดส่ง ใบจ่าหน้า และการติดตาม
การผสานรวมการจัดส่งของ BigCommerce มีหน้าที่แตกต่างกันสามประการ ได้แก่ การคำนวณอัตราค่าจัดส่งในขั้นตอนชำระเงิน การซื้อใบจ่าหน้าสำหรับการจัดส่งสินค้า และการติดตามพัสดุหลังจากส่งออกไปแล้ว สำหรับผู้ค้า การตั้งค่าที่เหมาะสมไม่จำเป็นต้องเป็นแอปเดียวที่สัญญาว่าจะทำได้ทุกอย่าง แต่ควรเป็นเวิร์กโฟลว์ที่เชื่อมต่อกัน ซึ่งวิธีการจัดส่งในขั้นตอนชำระเงิน การดำเนินการของคลังสินค้า บันทึกการจัดส่ง และการอัปเดตสำหรับลูกค้ายังคงสอดคล้องกัน
เริ่มจากส่วนของการจัดส่งที่กำลังมีปัญหาในวันนี้ ค่าธรรมเนียมที่ไม่คาดคิดในขั้นตอนชำระเงินควรตรวจสอบอัตราค่าจัดส่ง การแพ็กและการส่งออกที่ล่าช้าควรตรวจสอบเวิร์กโฟลว์ใบจ่าหน้า ส่วนการอัปเดตการจัดส่งที่ขาดหายควรปรับปรุงการติดตาม ปัญหาเหล่านี้อาจใช้ข้อมูลคำสั่งซื้อร่วมกัน แต่การแก้ปัญหาหนึ่งไม่ได้หมายความว่าจะสามารถแก้ปัญหาอื่นได้โดยอัตโนมัติ
การผสานรวมการจัดส่งแต่ละประเภททำอะไรได้จริง
ก่อนเลือกการผสานรวม ให้แยกข้อเสนอการจัดส่งที่ลูกค้ามองเห็นออกจากงานปฏิบัติการที่จำเป็นต่อการดำเนินการตามคำสั่งซื้อ ค่าจัดส่งที่เรียกเก็บในขั้นตอนชำระเงินไม่จำเป็นต้องเท่ากับจำนวนเงินที่คุณจ่ายภายหลังสำหรับใบจ่าหน้า และหมายเลขติดตามก็ไม่ใช่หลักฐานว่าผู้ให้บริการขนส่งได้รับพัสดุแล้ว
| ชั้นการผสานรวม | ความรับผิดชอบหลัก | สิ่งที่ต้องตรวจสอบ |
|---|---|---|
| อัตราค่าจัดส่งในขั้นตอนชำระเงิน | กำหนดวิธีการจัดส่งและค่าธรรมเนียมที่ผู้ซื้อเห็น | ต้นทางการจัดส่ง ปลายทาง ข้อมูลสินค้า สิทธิ์ในการใช้บริการ และพฤติกรรมสำรอง |
| ใบจ่าหน้าและการดำเนินการตามคำสั่งซื้อ | เปลี่ยนคำสั่งซื้อให้เป็นการจัดส่งและสร้างเอกสารที่จำเป็นสำหรับการส่งออก | บัญชีผู้ให้บริการขนส่ง การเลือกบรรจุภัณฑ์ ความเข้ากันได้กับเครื่องพิมพ์ และการเขียนข้อมูลการจัดส่งกลับ |
| การติดตามหลังการซื้อ | รวบรวมเหตุการณ์การจัดส่งและทำให้ความคืบหน้าของการจัดส่งเข้าถึงได้ | การบันทึกหมายเลขติดตาม การระบุผู้ให้บริการขนส่ง การส่งอัปเดต และการจัดการข้อยกเว้น |
ตลาดแอปอย่างเป็นทางการ ของ BigCommerce เป็นจุดเริ่มต้นสำหรับค้นหาการผสานรวมแบบสำเร็จรูป ส่วนเอกสารสำหรับนักพัฒนา เป็นจุดเริ่มต้นสำหรับตรวจสอบการเชื่อมต่อแบบกำหนดเอง รายการในตลาดเพียงอย่างเดียวไม่ควรถูกมองว่าเป็นการยืนยันว่าแอปนั้นรองรับทุกประเทศ บริการของผู้ให้บริการขนส่งทุกราย การกำหนดค่าขั้นตอนชำระเงิน หรือเวิร์กโฟลว์การดำเนินการตามคำสั่งซื้อที่คุณใช้งาน
เลือกแนวทางการผสานรวมให้สอดคล้องกับเวิร์กโฟลว์ของคุณ
ใช้การตั้งค่าการจัดส่งของแพลตฟอร์มเมื่อกฎไม่ซับซ้อน
หากข้อเสนอการจัดส่งของคุณเรียบง่าย ให้ตรวจสอบการกำหนดค่าการจัดส่งที่มีอยู่ในร้านค้าของคุณก่อน กำหนดปลายทางที่ให้บริการ วิธีการที่ผู้ซื้อควรเห็น และกฎทางการค้าที่อยู่เบื้องหลังวิธีการเหล่านั้น ก่อนเพิ่มระบบอื่น
ตัวอย่างเช่น ร้านค้าที่เรียกเก็บค่าจัดส่งภายในประเทศแบบมาตรฐานอาจต้องการโซนการจัดส่งและข้อยกเว้นที่ชัดเจนขึ้น แทนที่จะใช้เครื่องมือคำนวณอัตราภายนอก ส่วนร้านค้าที่จัดส่งสินค้าขนาดใหญ่จากหลายสถานที่มีปัญหาแตกต่างออกไป นั่นคือค่าธรรมเนียมแบบง่ายอาจซ่อนความแตกต่างที่สำคัญของต้นทุนการดำเนินการตามคำสั่งซื้อ
เหมาะที่สุดสำหรับ: ผู้ค้าที่มีพัสดุที่คาดการณ์ได้ ความซับซ้อนในการดำเนินการตามคำสั่งซื้อจำกัด และมีกฎการจัดส่งที่การกำหนดค่าที่มีอยู่สามารถรองรับได้ ควรเปลี่ยนไปใช้แนวทางอื่นเมื่อไม่สามารถแสดงตรรกะที่จำเป็นได้อย่างน่าเชื่อถือ ไม่ใช่เพียงเพราะแอปอื่นมีการตั้งค่ามากกว่า
ใช้การผสานรวมแบบสำเร็จรูปสำหรับงานดำเนินการตามคำสั่งซื้อที่ทำซ้ำได้
ควรพิจารณาการผสานรวมการจัดส่งแบบสำเร็จรูปเมื่อพนักงานต้องคัดลอกที่อยู่ เลือกบริการ ซื้อใบจ่าหน้า หรือกรอกหมายเลขติดตามซ้ำ ๆ คุณค่าของการผสานรวมอยู่ที่การลดการส่งต่องานและทำให้บันทึกคำสั่งซื้อสอดคล้องกับสิ่งที่จัดส่งจริง
อย่าคิดว่าการผสานรวมใบจ่าหน้าทุกรายการจะมีอัตราค่าจัดส่งในขั้นตอนชำระเงินให้ด้วย ในทำนองเดียวกัน อย่าคิดว่าแอปที่นำเข้าคำสั่งซื้อจะสามารถเขียนรายละเอียดการจัดส่งกลับไปยัง BigCommerce ได้ ขอให้ผู้ให้บริการสาธิตทิศทางการเคลื่อนย้ายข้อมูลที่จำเป็นแต่ละทิศทางโดยใช้เวิร์กโฟลว์ของคุณ
เหมาะที่สุดสำหรับ: ทีมที่ต้องการอินเทอร์เฟซการทำงานที่มีอยู่แล้วโดยไม่ต้องดูแลการผสานรวมของตนเอง แนวทางนี้ไม่เหมาะหากกฎสำคัญของคลังสินค้าต้องใช้วิธีแก้ไขด้วยตนเองจนลดทอนเวลาที่ประหยัดได้
ใช้การเชื่อมต่อแบบกำหนดเองเมื่อระบบอื่นเป็นผู้ดูแลการดำเนินการตามคำสั่งซื้อ
การผสานรวมแบบกำหนดเองอาจเหมาะสมเมื่อระบบจัดการคำสั่งซื้อ แพลตฟอร์มคลังสินค้า หรือผู้ให้บริการโลจิสติกส์บุคคลที่สามควบคุมการส่งออกอยู่แล้ว ในรูปแบบดังกล่าว BigCommerce อาจเป็นช่องทางการขายมากกว่าจะเป็นแหล่งข้อมูลหลักด้านปฏิบัติการสำหรับทุกการดำเนินการจัดส่ง
กำหนดว่าระบบใดเป็นเจ้าของที่อยู่ การตัดสินใจด้านบรรจุภัณฑ์ การซื้อใบจ่าหน้า การสร้างการจัดส่ง และการอัปเดตการติดตาม จากนั้นยืนยันการดำเนินการ API ข้อกำหนดการยืนยันตัวตน สิทธิ์ และข้อจำกัดของแพลตฟอร์มที่จำเป็นในเอกสารที่เกี่ยวข้อง
เหมาะที่สุดสำหรับ: ผู้ค้าที่มีข้อกำหนดด้านเวิร์กโฟลว์อย่างแท้จริงและมีความสามารถทางเทคนิคในการดูแลระบบ การพัฒนาแบบกำหนดเองไม่ได้มีต้นทุนถูกที่สุดเสมอไป เมื่อรวมการตรวจสอบ การสนับสนุน และการเปลี่ยนแปลงในอนาคตแล้ว
อัตราค่าจัดส่ง: ทำให้คำมั่นสัญญาในขั้นตอนชำระเงินตรงกับการดำเนินงานจัดส่ง
การผสานรวมอัตราค่าจัดส่งควรสร้างข้อเสนอการจัดส่งที่คุณสามารถดำเนินการได้ ไม่ใช่เพียงส่งคืนตัวเลข ก่อนทดสอบผู้ให้บริการ ให้บันทึกข้อมูลต้นทาง ปลายทาง สินค้า และบรรจุภัณฑ์ที่กำหนดสิทธิ์ในการใช้บริการและต้นทุน
- ต้นทาง: คลังสินค้าหรือพันธมิตรด้านการดำเนินการตามคำสั่งซื้อรายใดจะเป็นผู้ส่งคำสั่งซื้อ?
- ข้อมูลสินค้า: น้ำหนักและขนาดถูกต้องหรือไม่ และใช้หน่วยที่สอดคล้องกันหรือไม่?
- บรรจุภัณฑ์: การคำนวณใช้สินค้าแต่ละชิ้น กล่องที่เลือก หรือพัสดุโดยประมาณ?
- ปลายทาง: จะเกิดอะไรขึ้นกับพื้นที่ห่างไกล ตู้ไปรษณีย์ และสถานที่นอกพื้นที่ให้บริการ?
- กฎทางการค้า: คุณจะเรียกเก็บจำนวนเงินที่คำนวณได้ อุดหนุนค่าจัดส่ง หรือใช้เกณฑ์ส่งเสริมการขาย?
ค่าจัดส่งในขั้นตอนชำระเงินและต้นทุนใบจ่าหน้าอาจแตกต่างกัน เนื่องจากพัสดุ บริการ ต้นทาง หรือบัญชีที่ใช้ในการดำเนินการตามคำสั่งซื้อแตกต่างจากสมมติฐานในขั้นตอนชำระเงิน เปรียบเทียบทั้งสองด้านของคำสั่งซื้อทดสอบก่อนสรุปว่าการคำนวณอัตราค่าจัดส่งผิด
กำหนดพฤติกรรมเมื่อเกิดข้อผิดพลาดด้วย หากคำขออัตราค่าจัดส่งล้มเหลว ขั้นตอนชำระเงินควรแสดงทางเลือกที่กำหนดไว้ ลบวิธีการที่ได้รับผลกระทบ หรือหยุดคำสั่งซื้อ? ตัวเลือกที่เหมาะสมขึ้นอยู่กับว่าทีมของคุณสามารถดำเนินการตามทางเลือกนั้นได้หรือไม่ ค่าธรรมเนียมสำรองที่ยอมรับคำสั่งซื้อซึ่งไม่สามารถจัดส่งได้ไม่ใช่การกู้คืนที่ประสบความสำเร็จ
สำหรับคำสั่งซื้อระหว่างประเทศ ให้แยกค่าขนส่งออกจากอากรและภาษี อย่าอธิบายอัตราค่าจัดส่งว่าเป็นต้นทุนปลายทางแบบรวมทุกอย่าง เว้นแต่บริการที่รับผิดชอบจะคำนวณค่าใช้จ่ายที่เกี่ยวข้องอย่างชัดเจน และกระบวนการดำเนินการตามคำสั่งซื้อรองรับรูปแบบการชำระเงินที่ระบุไว้
ใบจ่าหน้า: ประเมินวงจรการส่งออกทั้งหมด
ควรทดสอบการซื้อใบจ่าหน้าตั้งแต่การนำเข้าคำสั่งซื้อจนถึงการยกเลิก ไม่ใช่เพียงการพิมพ์ครั้งแรกที่สำเร็จ คำถามด้านปฏิบัติการคือการผสานรวมทำให้งานคลังสินค้าและบันทึกของร้านค้าซิงโครไนซ์กันหรือไม่
ใช้รายการตรวจสอบการยอมรับต่อไปนี้:
- การนำเข้าคำสั่งซื้อ: ยืนยันว่าคำสั่งซื้อที่ถูกต้องพร้อมสำหรับการดำเนินการตามคำสั่งซื้อ และการแก้ไขได้รับการจัดการอย่างคาดการณ์ได้
- การสร้างพัสดุ: ทดสอบพัสดุเดียว หลายพัสดุ และคำสั่งซื้อที่จัดส่งเพียงบางรายการ
- การเลือกบริการ: ตรวจสอบว่าวิธีการที่ผู้ซื้อเลือกในขั้นตอนชำระเงินเชื่อมโยงกับบริการที่พนักงานคลังสินค้าซื้ออย่างไร
- การพิมพ์: ยืนยันว่าขนาดใบจ่าหน้า รูปแบบไฟล์ และการตั้งค่าการพิมพ์ทำงานกับอุปกรณ์จริงของคลังสินค้า
- การเขียนข้อมูลการจัดส่งกลับ: ตรวจสอบว่าข้อมูลติดตามและรายการสินค้าที่จัดส่งถูกต้องถูกส่งไปยังคำสั่งซื้อใน BigCommerce
- การพิมพ์ซ้ำและการยกเลิกใบจ่าหน้า: กำหนดวิธีป้องกันการซื้อซ้ำและวิธีจัดการใบจ่าหน้าที่ไม่ได้ใช้ตามกฎของผู้ให้บริการที่เกี่ยวข้อง
การทดสอบที่มีประโยชน์อย่างยิ่งคือการซื้อใบจ่าหน้าสำเร็จ แต่การอัปเดตคำสั่งซื้อในขั้นตอนถัดไปล้มเหลว พนักงานต้องมีวิธีกู้คืนที่อัปเดตคำสั่งซื้อได้โดยไม่ต้องซื้อใบจ่าหน้าอีกใบ จุดนี้เองที่การสาธิตอย่างราบรื่นอาจแตกต่างจากเวิร์กโฟลว์การใช้งานจริงที่เชื่อถือได้
ตรวจสอบด้วยว่าใครเป็นผู้รับผิดชอบการแจ้งเตือนลูกค้า หากทั้งการผสานรวมการจัดส่งและระบบอื่นที่เชื่อมต่อส่งข้อความการส่งออก ลูกค้าอาจได้รับการอัปเดตซ้ำหรือขัดแย้งกัน
การติดตาม: แยกบันทึกการจัดส่งออกจากการมองเห็นสถานะการจัดส่ง
การเขียนหมายเลขติดตามลงในคำสั่งซื้อช่วยแก้ปัญหาการบันทึกข้อมูล การรวบรวมเหตุการณ์จากผู้ให้บริการขนส่งในภายหลังช่วยแก้ปัญหาการมองเห็นสถานะ ธุรกิจของคุณอาจต้องการทั้งสองอย่าง แต่ควรประเมินแยกกัน
เวิร์กโฟลว์การติดตามที่มีประโยชน์จะรักษาความสัมพันธ์ระหว่างคำสั่งซื้อ การจัดส่ง พัสดุ ผู้ให้บริการขนส่ง และหมายเลขติดตาม ความสัมพันธ์ดังกล่าวมีความสำคัญเมื่อคำสั่งซื้อหนึ่งรายการมีหลายพัสดุ หรือเมื่อพัสดุเดินทางผ่านผู้ดำเนินการจัดส่งมากกว่าหนึ่งราย
สำหรับชั้นการติดตามที่นำโดยนักพัฒนา 17TRACK Tracking API เป็นตัวเลือกที่ควรประเมิน ส่วนเอกสาร API อย่างเป็นทางการ เป็นพื้นฐานสำหรับประเมินการลงทะเบียนการติดตามและการส่งเหตุการณ์ในเวิร์กโฟลว์แบบกำหนดเอง นี่เป็นกรณีการใช้งานด้านการติดตาม ไม่ใช่สิ่งทดแทนการคำนวณอัตราค่าจัดส่งในขั้นตอนชำระเงินหรือการซื้อใบจ่าหน้า
อย่าคิดว่าการมี API หมายความว่าจะมีตัวเชื่อมต่อ BigCommerce สำเร็จรูปให้ด้วย กำหนดว่ารายละเอียดการจัดส่งจะเคลื่อนย้ายจากร้านค้าหรือระบบดำเนินการตามคำสั่งซื้อของคุณเข้าสู่บริการติดตามอย่างไร อัปเดตจะไปถึงปลายทางอย่างไร และใครจะเป็นผู้ดูแลการเชื่อมต่อ
ก่อนเริ่มใช้งาน ให้ยืนยันการรองรับผู้ให้บริการขนส่งและบริการที่คุณใช้งานจริง เงื่อนไขการสมัครสมาชิกที่เกี่ยวข้อง และการกำหนดค่าการส่งอัปเดต จากนั้นทดสอบการสแกนที่ล่าช้า หมายเลขที่ไม่รู้จัก การอัปเดตซ้ำ และข้อยกเว้นด้านการจัดส่ง การผสานรวมการติดตามไม่สามารถสร้างการสแกนจริงจากผู้ให้บริการขนส่งที่ยังไม่เกิดขึ้นได้
เลือกผู้รับผิดชอบการติดตามภายในธุรกิจด้วย แดชบอร์ดข้อยกเว้นมีคุณค่าด้านปฏิบัติการจำกัด เว้นแต่จะมีผู้รับผิดชอบตรวจสอบการจัดส่งที่หยุดชะงักและตัดสินใจว่าจะติดต่อผู้ให้บริการขนส่งหรือลูกค้าเมื่อใด
เปรียบเทียบต้นทุนทั้งหมดโดยไม่พึ่งพาราคาที่โฆษณาไว้เป็นหลัก
เนื่องจากชั้นการผสานรวมเหล่านี้ทำงานแตกต่างกัน ให้เปรียบเทียบต้นทุนกับเวิร์กโฟลว์ที่คุณต้องการ แทนที่จะดูจากค่าสมาชิกที่โฆษณาเพียงตัวเลขเดียว
- ค่าซอฟต์แวร์: ระบุค่าสมาชิก โควตาการใช้งาน ค่าใช้เกินโควตา และฟีเจอร์ที่เรียกเก็บแยกต่างหาก
- ค่าจัดส่ง: แยกค่าไปรษณียากรและค่าปรับจากผู้ให้บริการขนส่งออกจากค่าซอฟต์แวร์
- การติดตั้งใช้งาน: รวมการตั้งค่า การทำความสะอาดข้อมูล การจับคู่บริการ การทดสอบ และการฝึกอบรมพนักงาน
- การดำเนินงานต่อเนื่อง: คำนึงถึงการแก้ไขด้วยตนเอง การซิงโครไนซ์ที่ล้มเหลว และผู้รับผิดชอบด้านการสนับสนุน
- ข้อกำหนดเมื่อยกเลิก: ตรวจสอบว่าคุณสามารถดึงบันทึกการจัดส่งและลบการเชื่อมต่อได้อย่างไรโดยไม่รบกวนคำสั่งซื้อที่เปิดอยู่
ขอให้ผู้ให้บริการแต่ละรายอธิบายว่าเหตุการณ์ใดนับรวมในการใช้งานที่เรียกเก็บเงิน คำสั่งซื้อ ใบจ่าหน้า พัสดุ หมายเลขติดตามที่ลงทะเบียน และคำขอ API ไม่ใช่หน่วยที่ใช้แทนกันได้ ใช้ช่วงเวลาที่สะท้อนการดำเนินงานของคุณเองเมื่อประเมินต้นทุน
ดำเนินโครงการนำร่องแบบครบวงจรขนาดเล็กก่อนเปลี่ยนระบบ
วิธีเลือกที่ดีที่สุดคือโครงการนำร่องแบบควบคุมโดยใช้คำสั่งซื้อที่สมจริง รวมพัสดุภายในประเทศทั่วไป คำสั่งซื้อหลายรายการ การจัดส่งแบบแยกส่วน และประเภทการจัดส่งระหว่างประเทศหรือผิดปกติที่มีความสำคัญต่อธุรกิจของคุณ
สำหรับการทดสอบแต่ละครั้ง ให้บันทึกข้อเสนอในขั้นตอนชำระเงิน บริการที่เลือก ผลลัพธ์ของใบจ่าหน้า บันทึกการจัดส่ง ปลายทางการติดตาม และการแจ้งเตือนลูกค้า เพิ่มกรณีล้มเหลวอย่างน้อยหนึ่งกรณี เช่น ที่อยู่ถูกปฏิเสธหรือการซิงโครไนซ์หยุดชะงัก
กำหนดความรับผิดชอบให้ชัดเจน ทีมอีคอมเมิร์ซอนุมัติพฤติกรรมในขั้นตอนชำระเงิน พนักงานคลังสินค้าอนุมัติการแพ็กและการพิมพ์ ฝ่ายสนับสนุนลูกค้าอนุมัติการมองเห็นสถานะการจัดส่ง และเจ้าของด้านเทคนิคอนุมัติสิทธิ์กับขั้นตอนการกู้คืน ตรวจสอบว่าการเชื่อมต่อแต่ละรายการได้รับข้อมูลลูกค้าใดบ้าง และให้สิทธิ์เฉพาะที่จำเป็นต่อหน้าที่ของการเชื่อมต่อนั้น
คำแนะนำเชิงปฏิบัติ: ทำให้การตั้งค่าเรียบง่ายเท่าที่การดำเนินงานของคุณอนุญาต ใช้การกำหนดค่าการจัดส่งที่มีอยู่เมื่อรองรับข้อกำหนด เพิ่มการผสานรวมด้านการดำเนินการตามคำสั่งซื้อเมื่อช่วยลดงานซ้ำ ๆ และเพิ่มชั้นการติดตามโดยเฉพาะเมื่อการมองเห็นสถานะการจัดส่งต้องมีเวิร์กโฟลว์ของตนเอง เชื่อมต่อแต่ละชั้นอย่างรอบคอบ แทนที่จะซื้อความสามารถที่ซ้ำซ้อนโดยอัตโนมัติ
คำถามที่พบบ่อย
ฉันจำเป็นต้องใช้การผสานรวมแยกกันสำหรับอัตราค่าจัดส่ง ใบจ่าหน้า และการติดตามหรือไม่?
ไม่จำเป็นเสมอไป การผสานรวมหนึ่งรายการอาจครอบคลุมหลายฟังก์ชัน ขณะที่อีกรายการอาจจัดการได้เพียงฟังก์ชันเดียว ตรวจสอบแต่ละฟังก์ชันที่จำเป็นแยกกัน รวมถึงการอ่านคำสั่งซื้อ การเขียนข้อมูลการจัดส่งกลับ และการส่งอัปเดตการติดตามในภายหลัง
การผสานรวมใบจ่าหน้าจะเปลี่ยนอัตราค่าจัดส่งในขั้นตอนชำระเงินโดยอัตโนมัติหรือไม่?
อย่าคิดเช่นนั้น การซื้อใบจ่าหน้าเกิดขึ้นระหว่างการดำเนินการตามคำสั่งซื้อ ขณะที่อัตราค่าจัดส่งในขั้นตอนชำระเงินจะแสดงก่อนวางคำสั่งซื้อ ยืนยันว่าการผสานรวมมีฟังก์ชันอัตราค่าจัดส่งในขั้นตอนชำระเงินหรือไม่ และทำงานกับการกำหนดค่าร้านค้าของคุณหรือไม่
ฉันสามารถเชื่อมต่อบัญชีผู้ให้บริการขนส่งของตนเองได้หรือไม่?
ขึ้นอยู่กับการผสานรวม ผู้ให้บริการขนส่ง สิทธิ์ของบัญชี และภูมิภาคการจัดส่ง สอบถามว่ารองรับบัญชีและบริการใดบ้าง สามารถใช้อัตราของบัญชีคุณได้หรือไม่ และใครเป็นผู้เรียกเก็บค่าไปรษณียากรกับค่าปรับภายหลัง
17TRACK สามารถแทนที่เครื่องมือใบจ่าหน้าของ BigCommerce ได้หรือไม่?
ควรประเมิน Tracking API ในด้านการมองเห็นสถานะการติดตาม ไม่ใช่ใช้แทนการซื้อใบจ่าหน้า เวิร์กโฟลว์แบบกำหนดเองสามารถเชื่อมต่อข้อมูลการจัดส่งกับบริการติดตามได้ โดยให้ระบบที่รับผิดชอบงานเหล่านั้นจัดการการคำนวณในขั้นตอนชำระเงินและการสร้างใบจ่าหน้าต่อไป
เหตุใดลูกค้าจึงอาจไม่เห็นความเคลื่อนไหวหลังได้รับหมายเลขติดตาม?
หมายเลขติดตามอาจมีอยู่ก่อนที่พัสดุจะได้รับการสแกนครั้งแรกจากผู้ให้บริการขนส่ง ความเป็นไปได้อื่น ๆ ได้แก่ หมายเลขไม่ถูกต้อง ปัญหาการระบุผู้ให้บริการขนส่ง หรือความล่าช้าในการแสดงเหตุการณ์ ตรวจสอบการส่งต่องานและข้อมูลผู้ให้บริการขนส่งก่อนสรุปว่าการไม่มีอัปเดตเป็นความล้มเหลวของซอฟต์แวร์
แหล่งข้อมูล
- BigCommerce App Marketplace — จุดเริ่มต้นอย่างเป็นทางการสำหรับระบุการผสานรวมแบบสำเร็จรูปและตรวจสอบรายการแต่ละรายการ
- BigCommerce Developer Documentation — เอกสารอ้างอิงอย่างเป็นทางการสำหรับตรวจสอบข้อกำหนดการผสานรวมแพลตฟอร์มและรายละเอียดการใช้งาน API
- 17TRACK Tracking API — เอกสารอ้างอิงผลิตภัณฑ์อย่างเป็นทางการสำหรับตัวเลือก API การติดตามที่กล่าวถึงในคู่มือนี้
- 17TRACK API Documentation — เอกสารอ้างอิงทางเทคนิคสำหรับประเมินเวิร์กโฟลว์การติดตามแบบกำหนดเอง
