เชื่อม Shopify กับระบบขนส่งและโลจิสติกส์แบบ Custom: ต้องทำอะไรบ้างเมื่อจะต่อกับขนส่งไทย

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

บทความนี้อธิบายว่าโปรเจกต์นั้นประกอบด้วยอะไรบ้าง โดยอ้างอิงกลไกที่ Shopify เขียนไว้เอง คุณจะได้ประเมินความต้องการของตัวเองได้ก่อนไปขอใบเสนอราคาจากใคร

เชื่อมระบบขนส่งคืองาน 3 ชิ้น ไม่ใช่ชิ้นเดียว

คำว่า "เชื่อมขนส่ง" ซ่อนงานแยกกันสามชิ้นไว้ ร้านจำนวนมากต้องการแค่หนึ่งหรือสองชิ้น และการรู้ว่าต้องการชิ้นไหนช่วยประหยัดเงินได้จริง

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

ร้านที่ส่งราคาเดียวจากสต็อกของตัวเองผ่านเว็บพอร์ทัลของคูเรียร์ อาจไม่ต้องทำสักข้อ ร้านที่มีระบบคลังเอง มักต้องทำข้อสองและสาม ส่วนร้านที่มีตารางราคาซับซ้อนต้องทำข้อหนึ่ง ประเมินทีละข้อแยกกัน

งานชิ้นที่ 1: ราคาค่าส่งสดด้วย Carrier Service ของ Shopify

กลไกที่อยู่เบื้องหลังราคาค่าส่งสดตอนเช็กเอาต์คือ resource ชื่อ CarrierService ของ Shopify คุณลงทะเบียน carrier service กับร้านพร้อม callback_url ซึ่งเป็น endpoint สาธารณะที่คุณดูแลเอง เมื่อลูกค้าเข้าสู่หน้าเช็กเอาต์ Shopify จะส่งคำขอแบบ POST มาที่ endpoint นั้น บอกรายละเอียดของพัสดุ แล้ว endpoint ของคุณตอบกลับด้วยราคาที่จะแสดง

ข้อมูลที่ Shopify ส่งมาค่อนข้างครบ มีที่อยู่ต้นทางและปลายทาง และสำหรับแต่ละสินค้ามีชื่อ SKU จำนวน น้ำหนักเป็นกรัม ราคา และ ID ของสินค้าและ variant พร้อมสกุลเงินและ locale เพียงพอให้คิดราคาตามน้ำหนัก โซนปลายทาง ประเภทสินค้า หรือกฎใดก็ตามที่คำนวณจากฟิลด์เหล่านี้ได้

สิ่งที่คุณส่งกลับคือรายการราคา แต่ละรายการมี service_name และ description ที่ลูกค้าอ่านตอนเช็กเอาต์ มี service_code ที่ต้องคงเดิมทุกคำขอ มี currency และ total_price ในหน่วยย่อย

รายละเอียดสามข้อของดีไซน์นี้กำหนดวิธีสร้างการเชื่อมแบบ custom:

• ทำงานแบบเรียลไทม์ และมีนาฬิกาจับเวลา เอกสารของ Shopify กำหนดเวลาตอบไว้ที่ 10 วินาที เมื่อมีคำขอต่ำกว่า 1,500 ครั้งต่อนาที 5 วินาทีเมื่ออยู่ระหว่าง 1,500 ถึง 3,000 และ 3 วินาทีเมื่อสูงกว่านั้น และบอกว่านี่คือเพดานสูงสุด ไม่ใช่เป้าหมาย บริการคิดราคาที่ไปเรียก API ของขนส่งที่ช้าทุกครั้งที่มีคำขอ จะเปราะบางมาก
• ไม่มีการลองซ้ำ เอกสารระบุว่าถ้าหมดเวลาหรือเกิดข้อผิดพลาด ร้านจะใช้ราคาสำรอง และคำตอบต้องสำเร็จตั้งแต่ครั้งแรก ว่า endpoint ของคุณควรทำอย่างไรเมื่อ API ของขนส่งล่ม เป็นการตัดสินใจทางธุรกิจที่ต้องเลือกให้ชัด จะถอยไปใช้ตารางราคาล่าสุดที่รู้ หรือปล่อยให้ราคาสำรองของ Shopify ทำงาน
• ปฏิเสธได้ ถ้าส่งอาร์เรย์ว่างกลับไป หมายถึง "ตะกร้านี้ฉันไม่มีราคาให้" ใช้กับปลายทางหรือสินค้าที่ขนส่งไม่ให้บริการ

ในทางปฏิบัติ endpoint ราคาที่ทำมาดีจะตอบจากตารางราคาหรือแคชในเครื่องให้มากที่สุด และเรียก API ของขนส่งเฉพาะกรณีที่จำเป็นจริง ๆ

เงื่อนไขเรื่องแพลนที่ควรเช็กตั้งแต่ต้น

ราคาค่าส่งจากขนส่งภายนอก (carrier-calculated shipping) ไม่ได้มีในทุกแพลนของ Shopify ตามที่ Shopify ระบุ มีให้ในแพลน Advanced และ Plus ส่วนแพลนที่ต่ำกว่านั้น ต้องจ่ายรายปีหรือเสียค่าบริการเสริมรายเดือน เช็กเรื่องนี้ก่อนเริ่มออกแบบ มันเป็นรายการค่าใช้จ่ายที่ควรอยู่ใน business case และการมาพบตอนเปิดตัวเป็นเรื่องที่เลี่ยงได้

งานชิ้นที่ 2: ส่งต่อออเดอร์ให้ขนส่ง

เมื่อมีออเดอร์ Shopify จะสร้าง fulfillment order ขึ้นมา แต่ละอันคือสิ่งที่ต้องส่งจากหนึ่งโลเคชัน ถ้าสินค้าในออเดอร์เดียวอยู่สองโลเคชัน ออเดอร์นั้นจะมีสอง fulfillment order

สำหรับพาร์ตเนอร์โลจิสติกส์แบบ custom มักเป็นหนึ่งในสองรูปแบบ:

• Fulfillment service ลงทะเบียนพาร์ตเนอร์เป็น fulfillment service Shopify จะสร้างโลเคชันให้ และออเดอร์ที่ถูกกำหนดไปที่โลเคชันนั้นจะกลายเป็นคำขอ fulfillment ที่ระบบเชื่อมอ่านและทำต่อได้ เหมาะกับ 3PL ที่เก็บสต็อกให้คุณ
• แบบดึงข้อมูลเอง ระบบของคุณหรือเซอร์วิสเล็ก ๆ อ่านออเดอร์ที่ชำระแล้วผ่าน API หรือ webhook แล้วสร้างพัสดุกับขนส่ง เหมาะกับร้านที่เก็บสต็อกเองแต่จองพัสดุผ่าน API ของคูเรียร์

Shopify รองรับ webhook สำหรับ fulfillment order และเหตุการณ์ที่เกี่ยวข้อง ระบบเชื่อมจึงตอบสนองเมื่อมีอะไรเกิดขึ้นได้ ไม่ต้องคอยถามร้านตามเวลา การ polling ยังมีที่ของมัน คือเป็นตาข่ายนิรภัยเก็บเหตุการณ์ที่หลุดไป

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

งานชิ้นที่ 3: เลขพัสดุและสถานะ

เมื่อมีพัสดุแล้ว ขนส่งจะออกเลขพัสดุ และร้านต้องได้เลขนั้น ระบบเชื่อมสร้าง fulfillment ใน Shopify พร้อมแนบรายละเอียดการติดตาม ซึ่งเป็นสิ่งที่ทำให้อีเมลยืนยันการจัดส่งถึงลูกค้า fulfillment service ยังเปิด callback ให้ Shopify ดึงเลขพัสดุเองได้ เมื่อเปิดการรองรับ tracking ไว้

สถานะการจัดส่งเป็นอีกเรื่อง Shopify บันทึกว่าออเดอร์ถูกจัดส่งแล้วและเก็บรายละเอียดการติดตาม แต่สถานะอย่าง "กำลังนำส่ง" และ "ส่งสำเร็จ" มักมาจากฝั่งขนส่ง ร้านที่อยากให้สถานะเหล่านี้ขึ้นในบัญชีลูกค้าหรือแจ้งผ่าน LINE ต้องมี webhook หรืองาน polling จากฝั่งขนส่งป้อนเข้าขั้นตอนแจ้งเตือน ถ้าลูกค้าถามหาพัสดุบ่อยเกินกว่าที่ทีมตอบไหว งานชิ้นที่สามคือจุดที่ประหยัดเงินได้

ปัญหาเฉพาะของไทยที่ต้องตีราคาเข้าไป

ระบบเชื่อมทั่วไปมักไม่คิดเรื่องที่ทำให้การขนส่งในไทยต่างออกไป:

• เก็บเงินปลายทาง (COD) ถ้าเปิด COD ค่าธรรมเนียม การเก็บเงิน และรอบการนำส่งเงิน ล้วนเป็นส่วนหนึ่งของระบบเชื่อม ไม่ใช่เชิงอรรถ สถานะการชำระเงินของออเดอร์ใน Shopify ต้องมีวิธีกำหนดไว้ชัดว่าสะท้อนการเก็บเงินสดของคูเรียร์อย่างไร
• ราคาตามโซนและเกาะ จังหวัดห่างไกลและเกาะมักมีค่าบริการเพิ่ม นี่คือเหตุผลคลาสสิกที่ตารางราคาแบบคงที่ใช้ไม่ได้และต้องมี endpoint คิดราคา
• ที่อยู่ภาษาไทย ช่องจังหวัด อำเภอ และตำบลต้องตรงกับที่ขนส่งตรวจสอบ เช็กเอาต์ที่รับข้อความอิสระจะสร้างพัสดุที่ถูกปฏิเสธ
• ขนส่งหลายเจ้า หลายร้านมีตัวเลือกช้าแต่ถูก และเร็วแบบพรีเมียม บางครั้งจากคนละคูเรียร์ endpoint คิดราคาตอบหลายตัวเลือกจากหลายแหล่งใน response เดียวได้
• การเข้าถึง API ของขนส่ง ไม่ใช่ทุกคูเรียร์ที่เปิด API สาธารณะ บางเจ้ากั้นไว้หลังบัญชีเชิงพาณิชย์หรือปริมาณขั้นต่ำ ยืนยันสิทธิ์เข้าถึง ทดสอบ credential และดูคุณภาพเอกสารก่อนตกลงขอบเขตงาน คำถามข้อนี้ข้อเดียวเปลี่ยนประมาณการได้มากกว่าข้ออื่น

สร้างเอง ซื้อ หรือตั้งค่า?

คำตอบที่ถูกที่สุดคือสิ่งที่มีอยู่แล้ว จึงควรไล่ตามลำดับนี้:

1. มีแอปใน Shopify App Store สำหรับขนส่งเจ้านี้ที่ทำได้ตามต้องการไหม? ถ้าจัดการราคา ใบปะหน้า และการติดตามได้ดีพอ ก็ใช้เลย
2. แอปขนส่งแบบหลายเจ้าครอบคลุมแล้วหรือยัง? แอปแบบ aggregator เชื่อมคูเรียร์หลายเจ้าพร้อมกัน และอาจเพียงพอสำหรับร้านที่มีตัวเลือกไม่กี่อย่าง
3. แก้ด้วยกฎการจัดส่งใน Shopify เองได้ไหม? ราคาเหมาตามโซนและขั้นน้ำหนัก ตั้งในหลังบ้านได้โดยไม่ต้องเขียนโค้ด
4. ถึงตอนนั้นค่อยทำ custom เหมาะเมื่อขนส่งไม่มีแอป เมื่อตรรกะราคาซับซ้อนเกินกว่ากฎรองรับ เมื่อร้านต้องคุยกับระบบคลังหรือ ERP หรือเมื่อส่งพัสดุมากพอที่การทำมือแพงกว่าการสร้าง

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

โปรเจกต์ที่ดูสมเหตุสมผลเป็นอย่างไร

การเชื่อมระบบขนส่งแบบ custom ที่บริหารดี มักผ่านขั้นตอนเหล่านี้:

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

คำถามที่ควรตอบก่อนขอใบเสนอราคา

คุณจะได้ประเมินที่เร็วและแม่นขึ้น ถ้าบอกได้ว่า:

• ใช้ขนส่งหรือพาร์ตเนอร์โลจิสติกส์เจ้าไหน และมีบัญชีกับ API credential อยู่แล้วหรือยัง
• ต้องการงานไหนบ้างระหว่างราคา การส่งต่อออเดอร์ และการติดตามพัสดุ
• ขายแบบ COD หรือไม่ และกระทบยอดอย่างไร
• แพลน Shopify ที่ใช้ และปริมาณออเดอร์ต่อวัน ทั้งปกติและช่วงพีก
• มีระบบคลังสินค้าหรือ ERP อยู่หลังร้านหรือไม่

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