สแต็กเทคโนโลยีหลังการซื้อ: การติดตาม การคืนสินค้า การสนับสนุน และวิธีที่สิ่งเหล่านี้เชื่อมโยงกัน
A post-purchase tech stack เชื่อมต่อการติดตามการจัดส่ง การจัดการคืนสินค้า ฝ่ายสนับสนุนลูกค้า และระบบที่จัดเก็บข้อมูลคำสั่งซื้อและการชำระเงิน สำหรับทีมอีคอมเมิร์ซ เป้าหมายไม่ใช่การซื้อแอปแยกสำหรับทุกงาน แต่คือการทำให้เหตุการณ์การจัดส่ง คำขอของลูกค้า และการตัดสินใจคืนเงินเคลื่อนย้ายระหว่างระบบได้โดยไม่สูญเสียบริบทหรือทำให้เกิดการดำเนินการที่ขัดแย้งกัน
คู่มือนี้อธิบายว่าแต่ละชั้นควรรับผิดชอบอะไร ข้อมูลควรไหลระหว่างชั้นเหล่านั้นอย่างไร และควรทดสอบการเชื่อมต่อก่อนขยาย tech stack อย่างไร จุดเริ่มต้นที่มีประโยชน์ที่สุดคือเส้นทางลูกค้าเพียงหนึ่งเส้นทาง: คำสั่งซื้อถูกจัดส่ง มีบางสิ่งเปลี่ยนแปลง ลูกค้าต้องการความช่วยเหลือ และต้องมีผู้ตัดสินใจว่าจะดำเนินการอย่างไรต่อไป
สร้างระบบโดยยึดตามความรับผิดชอบ ไม่ใช่รายการแอป
เครื่องมือติดตามสามารถรายงานความคืบหน้าของการจัดส่งได้ แต่ข้อมูลอัปเดตการจัดส่งไม่ใช่ข้อมูลคำสั่งซื้อที่ครบถ้วน พอร์ทัลคืนสินค้าสามารถรับคำขอได้ แต่คำขอนั้นไม่ใช่หลักฐานว่ามีการคืนเงินแล้ว เจ้าหน้าที่ฝ่ายสนับสนุนสามารถอนุมัติข้อยกเว้นได้ แต่การตัดสินใจนั้นยังต้องส่งต่อไปยังระบบที่ดำเนินการ
ความแตกต่างเหล่านี้มีความสำคัญ เพราะระบบที่เชื่อมต่อกันอาจแสดงข้อมูลเดียวกันได้โดยไม่ได้มีอำนาจเหมือนกันในการเปลี่ยนแปลงข้อมูลนั้น กำหนดระบบที่เป็นแหล่งข้อมูลหลักสำหรับแต่ละระเบียน และให้ระบบอื่นอ้างอิงระบบดังกล่าว
| ชั้น | ความรับผิดชอบที่แนะนำ | ข้อมูลที่ต้องแลกเปลี่ยน |
|---|---|---|
| แพลตฟอร์มการค้า หรือระบบจัดการคำสั่งซื้อ | ตัวตนของคำสั่งซื้อ รายการที่ซื้อ การจัดสรรการดำเนินการตามคำสั่งซื้อ และสถานะเชิงพาณิชย์ของคำสั่งซื้อ | รหัสคำสั่งซื้อ รหัสรายการสินค้าในคำสั่งซื้อ จำนวน รายการอ้างอิงลูกค้า และความเชื่อมโยงกับการจัดส่ง |
| การติดตามการจัดส่ง | การมองเห็นการจัดส่งและการตีความเหตุการณ์การจัดส่ง | ข้อมูลอ้างอิงผู้ให้บริการขนส่ง หมายเลขติดตาม เวลาเหตุการณ์ สถานะ และข้อยกเว้น |
| การจัดการคืนสินค้า | คำขอคืนสินค้า การตรวจสอบนโยบาย รายการที่ได้รับอนุมัติ และสถานะเวิร์กโฟลว์การคืนสินค้า | รหัสการคืนสินค้า จำนวนสินค้า เหตุผล การอนุมัติ และผลการตรวจสอบ |
| ฝ่ายสนับสนุนลูกค้า | การสนทนากับลูกค้า การตรวจสอบ และข้อยกเว้นที่ได้รับอนุมัติ | รหัสทิกเก็ต บริบทคำสั่งซื้อที่เกี่ยวข้อง การตัดสินใจ และผู้รับผิดชอบการยกระดับปัญหา |
| ระบบคลังสินค้าและการชำระเงิน | การรับสินค้าและตรวจสอบทางกายภาพ การดำเนินการทางการเงินและการกระทบยอด | ผลการรับสินค้า การจัดการสินค้า ข้อมูลอ้างอิงการคืนเงิน และผลลัพธ์ของธุรกรรม |
นี่คือรูปแบบความเป็นเจ้าของที่แนะนำ ไม่ใช่ข้อกำหนดว่าต้องใช้ผลิตภัณฑ์แยกกันห้ารายการ แพลตฟอร์มเดียวอาจครอบคลุมหลายความรับผิดชอบได้ สิ่งที่ต้องทดสอบคือแต่ละสถานะสำคัญมีผู้รับผิดชอบที่ชัดเจนหรือไม่ และระบบอื่นสามารถแยกแยะการดำเนินการที่ร้องขอออกจากการดำเนินการที่เสร็จสมบูรณ์แล้วได้หรือไม่
การติดตามควรอธิบายความคืบหน้าของการจัดส่งโดยไม่ตัดสินใจเชิงพาณิชย์
ชั้นการติดตามเชื่อมโยงกิจกรรมของผู้ให้บริการขนส่งเข้ากับคำสั่งซื้อของลูกค้า ควรช่วยให้ลูกค้าเข้าใจว่าพัสดุอยู่ที่ใด และช่วยให้พนักงานรู้ว่าการจัดส่งใดต้องได้รับความสนใจ สำหรับการจัดส่งทางไปรษณีย์ การติดตามพัสดุไปรษณีย์ เป็นส่วนหนึ่งของชั้นการมองเห็นข้อมูลนี้ สถาปัตยกรรมโดยรวมยังต้องรองรับคำสั่งซื้อที่มีหลายพัสดุหรือใช้ผู้ให้บริการขนส่งหลายรายด้วย
จำลองคำสั่งซื้อและการจัดส่งแยกจากกัน คำสั่งซื้อที่มีสองหีบห่ออาจมีหีบห่อหนึ่งจัดส่งถึงแล้ว ขณะที่อีกหีบห่อยังอยู่ระหว่างการขนส่ง การทำเครื่องหมายว่าคำสั่งซื้อทั้งหมดจัดส่งถึงแล้วหลังจากเกิดเหตุการณ์การจัดส่งครั้งแรก อาจทำให้การแจ้งเตือนทำให้เข้าใจผิด การตอบกลับของฝ่ายสนับสนุนไม่ถูกต้อง และเกิดความสับสนว่าสินค้ารายการใดมีสิทธิ์คืนสินค้า
เก็บเหตุการณ์เดิมไว้ควบคู่กับสถานะที่สรุปแล้ว
สถานะที่แสดงต่อลูกค้า เช่น “อยู่ระหว่างการขนส่ง” อ่านได้ง่ายกว่าฟีดเหตุการณ์ของผู้ให้บริการขนส่ง แต่ทีมสนับสนุนอาจยังต้องใช้ข้อความเหตุการณ์เดิม สถานที่ และเวลาเพื่อสืบสวนปัญหา หากเป็นไปได้ ให้เก็บข้อมูลทั้งสองมุมมองไว้ และแยกให้ชัดเจนว่าผู้ให้บริการขนส่งระบุว่าเหตุการณ์เกิดขึ้นเมื่อใด กับเวลาที่ระบบของคุณได้รับข้อมูลนั้น
โดยทั่วไป ข้อยกเว้นในการติดตามควรเริ่มการตรวจสอบหรือเวิร์กโฟลว์ที่กำหนดไว้ ไม่ใช่อนุมัติการคืนเงินโดยอัตโนมัติ ความล่าช้า การพยายามจัดส่ง และพัสดุที่รายงานว่าจัดส่งแล้วแต่ไม่ได้รับ ล้วนต้องใช้การดำเนินการที่แตกต่างกัน นโยบายของผู้ค้าและกระบวนการตรวจสอบควรเป็นผู้กำหนดแนวทางแก้ไข
กำหนดผู้รับผิดชอบการแจ้งเตือน
ตัดสินใจว่าระบบใดจะส่งข้อความแต่ละประเภท หากแพลตฟอร์มการค้า แอปติดตาม และระบบอัตโนมัติของฝ่ายสนับสนุนต่างก็ส่งข้อมูลอัปเดตการจัดส่ง ลูกค้าอาจได้รับข้อความซ้ำหรือไม่สอดคล้องกัน จัดทำแผนผังการแจ้งเตือนที่ระบุทริกเกอร์ ผู้ส่ง กลุ่มผู้รับ เงื่อนไขระงับการส่ง และลิงก์ปลายทาง
ตัวอย่างเช่น ข้อความเกี่ยวกับความล่าช้าของการจัดส่งไม่ควรสัญญาว่าจะส่งสินค้าใหม่ เว้นแต่จะมีการอนุมัติการเปลี่ยนสินค้าแล้วจริง ๆ จุดประสงค์ของข้อความอาจมีเพียงการอธิบายสถานะล่าสุดและให้ช่องทางติดต่อขอความช่วยเหลือ
การคืนสินค้าต้องมีบริบทระดับรายการสินค้าและสถานะทางการเงินที่แยกต่างหาก
การคืนสินค้าเริ่มต้นจากสินค้าและการตัดสินใจตามนโยบาย ไม่ใช่แค่หมายเลขติดตาม ชั้นการคืนสินค้าต้องทราบว่าซื้ออะไรไป จำนวนเท่าใดที่ยังคืนได้ และการคืนสินค้าหรือคืนเงินก่อนหน้านี้มีผลต่อคำขอนี้หรือไม่
ก่อนนำระบบอัตโนมัติมาใช้ ให้กำหนดเหตุการณ์ที่ทำให้การคืนสินค้าเดินหน้า เวิร์กโฟลว์ที่ใช้งานได้จริงอาจแยกสถานะเป็น ส่งคำขอแล้ว อนุมัติคำขอแล้ว ส่งมอบพัสดุแล้ว ได้รับพัสดุแล้ว ตรวจสอบเสร็จแล้ว และร้องขอคืนเงินแล้ว ขั้นตอนจริงควรสอดคล้องกับการดำเนินงานของธุรกิจ
อย่ารวมขั้นตอนเหล่านี้ไว้ในป้ายกำกับเดียวว่า “คืนแล้ว” เหตุการณ์ที่ผู้ให้บริการขนส่งระบุว่าพัสดุคืนสินค้าถูกจัดส่งถึงแล้ว ไม่ได้ยืนยันด้วยตัวมันเองว่าพนักงานคลังสินค้าได้ตรวจสอบสิ่งของภายในแล้ว เช่นเดียวกัน คำขอคืนเงินไม่ได้ยืนยันว่าระบบการชำระเงินดำเนินการคืนเงินสำเร็จ
- สำหรับการคืนสินค้าบางส่วน: แลกเปลี่ยนรหัสรายการสินค้าและจำนวน ไม่ใช่เฉพาะยอดรวมของคำสั่งซื้อ
- สำหรับการเปลี่ยนสินค้า: กำหนดว่าใครจะสำรองสินค้า สร้างคำสั่งซื้อทดแทน และจัดการส่วนต่างราคา
- สำหรับการคืนเงินก่อนกำหนด: ระบุเหตุการณ์ที่เข้าเกณฑ์ การตรวจสอบความเสี่ยง ผู้มีอำนาจอนุมัติ และกระบวนการจัดการข้อยกเว้น
- สำหรับข้อยกเว้นด้านนโยบาย: บันทึกว่าใครอนุมัติข้อยกเว้นและอนุญาตให้ดำเนินการต่ออย่างไร
ใช้นโยบายที่เผยแพร่และข้อผูกพันที่เกี่ยวข้องเพื่อกำหนดสิทธิ์ในการคืนสินค้า การตั้งค่าซอฟต์แวร์ควรนำการตัดสินใจเหล่านั้นไปใช้งาน ไม่ใช่กลายเป็นนโยบายเองโดยที่ไม่มีใครสังเกต
ฝ่ายสนับสนุนคือชั้นการตัดสินใจสำหรับข้อยกเว้น
พื้นที่ทำงานของฝ่ายสนับสนุนควรรวบรวมบริบทที่เพียงพอเพื่อแก้ไขกรณีต่าง ๆ โดยไม่บังคับให้เจ้าหน้าที่ต้องรวบรวมข้อมูลคำสั่งซื้อจากแดชบอร์ดหลายแห่งใหม่ทั้งหมด แต่ไม่ได้หมายความว่าจะต้องคัดลอกทุกระเบียนไปไว้ในทุกทิกเก็ต
แผงข้อมูลคำสั่งซื้อที่มีประโยชน์ควรรวมความเชื่อมโยงกับการจัดส่ง เหตุการณ์ติดตามล่าสุดที่เกี่ยวข้อง รายการคืนสินค้าที่เปิดอยู่ ผลลัพธ์การคืนเงิน และการตัดสินใจก่อนหน้า นอกจากนี้ควรแสดงเวลาที่ข้อมูลได้รับการอัปเดตครั้งล่าสุดด้วย สถานะเก่าที่แสดงโดยไม่มีเวลาอาจดูเหมือนเป็นข้อมูลปัจจุบันและทำให้เจ้าหน้าที่ให้คำแนะนำผิด
แยกสิทธิ์การอ่านออกจากสิทธิ์ดำเนินการ เจ้าหน้าที่จำนวนมากอาจต้องดูประวัติการคืนเงิน แต่มีเพียงบางคนที่ควรมีอำนาจออกคำสั่งคืนเงินหรือยกเว้นสิทธิ์การคืนสินค้า การดำเนินการที่ส่งผลต่อเงินหรือสินค้าคงคลังควรมีบันทึกตรวจสอบและมาตรการป้องกันการดำเนินการซ้ำ
จัดเส้นทางกรณีต่าง ๆ ตามงานที่ต้องทำ การจัดส่งที่ไม่มีการเคลื่อนไหวล่าสุดอาจต้องตรวจสอบด้านโลจิสติกส์ ธุรกรรมคืนเงินที่ถูกปฏิเสธอาจต้องส่งให้ฝ่ายปฏิบัติการด้านการชำระเงิน การคืนสินค้าที่ได้รับแต่มีสิ่งของไม่ตรงตามคาดอาจต้องให้คลังสินค้าตรวจสอบ หมวดหมู่ทิกเก็ตจะมีประโยชน์ก็ต่อเมื่อเชื่อมโยงไปยังผู้รับผิดชอบที่ระบุชื่อและขั้นตอนถัดไป
ระบบเชื่อมต่อกันอย่างไร: ติดตามข้อยกเว้นหนึ่งกรณีตั้งแต่ต้นจนจบ
พิจารณาคำสั่งซื้อตัวอย่างที่มีสินค้าสองรายการซึ่งจัดส่งแยกเป็นคนละพัสดุ พัสดุหนึ่งมาถึง แต่อีกพัสดุเกิดข้อยกเว้นในการจัดส่ง ลูกค้าติดต่อฝ่ายสนับสนุนและต่อมาคืนสินค้าที่จัดส่งถึงแล้ว
- ระบบคำสั่งซื้อสร้างความสัมพันธ์: รายการสินค้าแต่ละรายการเชื่อมโยงกับการจัดส่งที่ถูกต้อง ฝ่ายสนับสนุนจึงเห็นว่าสินค้าที่ยังไม่ถึงไม่ได้อยู่ในพัสดุที่จัดส่งถึงแล้ว
- ชั้นการติดตามได้รับข้อยกเว้น: ระบบเก็บข้อมูลอ้างอิงการจัดส่งและรายละเอียดเหตุการณ์ไว้ เวิร์กโฟลว์จะสร้างหรืออัปเดตการตรวจสอบ แทนที่จะถือว่าคำสั่งซื้อทั้งหมดสูญหาย
- ฝ่ายสนับสนุนตรวจสอบกรณี: เจ้าหน้าที่ตรวจสอบการจัดส่งที่เกี่ยวข้องและบันทึกขั้นตอนถัดไปที่ตกลงกัน หากมีการอนุมัติการเปลี่ยนสินค้า ระบบคำสั่งซื้อจะได้รับคำสั่งแยกต่างหากเพื่อสร้างคำสั่งซื้อใหม่
- ลูกค้าขอคืนสินค้าที่จัดส่งถึงแล้ว: ระบบคืนสินค้าตรวจสอบสินค้าและจำนวนเทียบกับคำสั่งซื้อและกิจกรรมการคืนสินค้าที่มีอยู่
- คลังสินค้ารับและตรวจสอบสินค้าที่คืน: ผลการตรวจสอบแนบอยู่กับระเบียนการคืนสินค้า ไม่ได้อนุมานจากการติดตามพัสดุเพียงอย่างเดียว
- เวิร์กโฟลว์ทางการเงินดำเนินการตามแนวทางแก้ไขที่อนุมัติ: ผลการคืนเงินถูกเขียนกลับไป เพื่อให้ฝ่ายสนับสนุนและมุมมองการคืนสินค้าที่ลูกค้าเห็นไม่สับสนระหว่างการอนุมัติกับการดำเนินการเสร็จสิ้น
การเชื่อมต่อจะประสบความสำเร็จเมื่อผู้เกี่ยวข้องทุกฝ่ายเห็นผลลัพธ์เดียวกัน โดยไม่มีฝ่ายใดได้รับอนุญาตให้เขียนทับระเบียนนอกเหนือจากความรับผิดชอบของตน
รายละเอียดการผสานระบบที่ควรทดสอบ ไม่ใช่เชื่อจากการสาธิตการขาย
ตัวระบุร่วมและการจับคู่ระเบียน
ใช้ตัวระบุภายในที่คงที่เพื่อเชื่อมต่อคำสั่งซื้อ รายการสินค้า การจัดส่ง การคืนสินค้า และทิกเก็ต อย่าพึ่งพาอีเมลหรือหมายเลขคำสั่งซื้อที่แสดงเพียงอย่างเดียว กฎการจับคู่ควรรองรับกรณีที่หมายเลขติดตามถูกตีความตามบริบทของผู้ให้บริการขนส่ง และกรณีที่ลูกค้ามีคำสั่งซื้อที่กำลังดำเนินการหลายรายการ
การส่งเหตุการณ์และการกระทบยอด
ในกรณีที่รองรับ เว็บฮุกสามารถแจ้งระบบผู้รับเมื่อเกิดเหตุการณ์ได้ แต่ไม่ได้ขจัดความจำเป็นในการจัดการข้อความที่หายไป ล่าช้า ซ้ำ หรือมาถึงไม่เป็นลำดับ สอบถามว่าการส่งที่ล้มเหลวจะถูกลองใหม่อย่างไร และทีมของคุณจะกู้คืนเหตุการณ์หลังระบบหยุดทำงานได้อย่างไร
ทำให้การประมวลผลซ้ำปลอดภัย ตัวอย่างเช่น การได้รับอนุมัติการคืนสินค้าครั้งเดิมสองครั้งไม่ควรทำให้เกิดการคืนเงินสองครั้ง นอกจากนี้งานกระทบยอดควรเปรียบเทียบระเบียนสำคัญระหว่างระบบ เพื่อให้การแจ้งเตือนที่พลาดไปไม่ทำให้การคืนสินค้าหรือการคืนเงินค้างอยู่อย่างถาวร
การตรวจสอบสิทธิ์และขอบเขตข้อมูลลูกค้า
การค้นหาการติดตาม คำขอคืนสินค้า และการคืนเงินที่เจ้าหน้าที่ออกคำสั่ง ล้วนต้องการระดับการเข้าถึงที่แตกต่างกัน กำหนดว่าลูกค้าจะยืนยันสิทธิ์ในการดูหรือแก้ไขคำสั่งซื้ออย่างไร จะกำหนดสิทธิ์พนักงานอย่างไร และแอปพลิเคชันที่เชื่อมต่อแต่ละตัวจำเป็นต้องใช้ข้อมูลส่วนบุคคลใดจริง ๆ
ตรวจสอบการยืนยันตัวตนของเว็บฮุก การจัดเก็บข้อมูลรับรอง การเพิกถอนสิทธิ์การเข้าถึง การตั้งค่าการเก็บรักษาข้อมูล และบันทึกการตรวจสอบระหว่างการติดตั้ง หลีกเลี่ยงการคัดลอกข้อมูลลูกค้าแบบเต็มลงในบันทึก หากใช้ข้อมูลอ้างอิงภายในแทนได้
17TRACK อยู่ส่วนใดในสถาปัตยกรรม
สำหรับการประเมินที่มุ่งเน้น 17TRACK ให้เริ่มจากจุดเข้าสู่ผลิตภัณฑ์ที่ตรงกับงาน เว็บไซต์ติดตามสำหรับผู้บริโภค consumer tracking website เหมาะสำหรับการค้นหาการจัดส่งรายบุคคล ผู้ค้าที่ประเมินแอปติดตามคำสั่งซื้อสามารถดู รายการ 17TRACK บน Shopify ทีมที่ออกแบบการเชื่อมต่อแบบกำหนดเองสามารถดู ข้อมูล Tracking API และ เอกสาร API ส่วนความต้องการด้านการคืนสินค้าควรตรวจสอบแยกต่างหากที่ 17RETURNS
สิ่งเหล่านี้เป็นแนวทางการประเมินที่เกี่ยวข้อง ไม่ใช่หลักฐานว่าการเชื่อมต่อทุกอย่างในคู่มือนี้พร้อมใช้งานทันที ยืนยันฟิลด์ข้อมูล เวิร์กโฟลว์ที่รองรับ สิทธิ์ และเงื่อนไขทางการค้าสำหรับผลิตภัณฑ์ที่คุณตั้งใจใช้ อย่าสันนิษฐานว่าการเลือกผลิตภัณฑ์ที่เกี่ยวข้องจะซิงโครไนซ์ทิกเก็ตฝ่ายสนับสนุน การตรวจสอบของคลังสินค้า หรือผลลัพธ์การชำระเงินโดยอัตโนมัติ
เปิดตัวเวิร์กโฟลว์ที่เล็กที่สุดเพื่อแก้ช่องว่างที่มีอยู่จริง
เริ่มจากจุดส่งต่องานที่มีต้นทุนสูงที่สุดในการดำเนินงานปัจจุบัน หากเจ้าหน้าที่ต้องค้นหาสถานะการจัดส่งด้วยตนเองซ้ำ ๆ ให้จัดลำดับความสำคัญของบริบทการติดตามในฝ่ายสนับสนุน หากลูกค้าไม่สามารถทราบได้ว่าคืนสินค้าแล้วหรือได้รับเงินคืนแล้ว ให้จัดลำดับความสำคัญของการเชื่อมต่อระหว่างการคืนสินค้า คลังสินค้า และการชำระเงิน
ก่อนซื้อแอปพลิเคชันเพิ่มเติม ให้ทำแผนผังความสามารถที่มีอยู่แล้วในแพลตฟอร์มการค้าและระบบสนับสนุน เพิ่มเครื่องมือเฉพาะทางเมื่อสามารถแก้ช่องว่างที่กำหนดไว้ได้ และตรวจสอบเวิร์กโฟลว์ทั้งหมด แทนที่จะประเมินจากหน้าเว็บที่ลูกค้าเห็นเพียงอย่างเดียว
การทดสอบการยอมรับที่มีประโยชน์ควรรวมถึง:
- คำสั่งซื้อที่แบ่งออกเป็นการจัดส่งหลายรายการ
- ข้อมูลอัปเดตการติดตามที่มาถึงหลังเหตุการณ์ใหม่กว่า
- เหตุการณ์ซ้ำที่ต้องไม่ทำให้เกิดการดำเนินการทางการเงินซ้ำ
- การคืนสินค้าบางส่วนที่มีการคืนเงินก่อนหน้าในคำสั่งซื้อเดียวกัน
- การคืนเงินที่ล้มเหลวแต่ยังคงมองเห็นได้ในฝ่ายสนับสนุน
- ระบบผสานรวมขัดข้องชั่วคราวแล้วกู้คืน
- ข้อยกเว้นที่ดำเนินการด้วยตนเองและเขียนทับเวิร์กโฟลว์ปกติพร้อมบันทึกเหตุผล
กำหนดผู้รับผิดชอบสำหรับการทดสอบที่ล้มเหลวแต่ละรายการ และระบุว่าพนักงานจะทำงานอย่างไรเมื่อการผสานรวมไม่พร้อมใช้งาน การมีทางเลือกสำรองด้วยตนเองเป็นส่วนหนึ่งของการออกแบบ ไม่ใช่การยอมรับว่าระบบอัตโนมัติล้มเหลว
วัดผลลัพธ์ตลอดจุดส่งต่องาน
ติดตามจำนวนการติดต่อเกี่ยวกับการจัดส่งต่อคำสั่งซื้อที่จัดส่งแล้ว ระยะเวลาประมวลผลการคืนสินค้า ข้อผิดพลาดในการผสานรวมที่ยังไม่ได้แก้ไข และเวลาระหว่างการอนุมัติคืนเงินกับการยืนยันว่าดำเนินการเสร็จสิ้น กำหนดคำจำกัดความของแต่ละตัวชี้วัดอย่างชัดเจน ตัวอย่างเช่น แยกเวลาขนส่งสินค้าคืนออกจากเวลาประมวลผลของคลังสินค้า เพื่อให้ทีมที่รับผิดชอบดำเนินการกับผลลัพธ์ได้
เปรียบเทียบช่วงเวลาที่คล้ายกันและกลุ่มลูกค้าเท่าที่ทำได้ การที่จำนวนการติดต่อฝ่ายสนับสนุนลดลงไม่ได้หมายความว่าดีขึ้นโดยอัตโนมัติ หากลูกค้าสูญเสียช่องทางเข้าถึงความช่วยเหลือไปด้วย ใช้มาตรวัดประสิทธิภาพควบคู่กับกรณีที่ยังไม่ได้แก้ไข การติดต่อซ้ำ และหลักฐานว่าลูกค้าได้รับการแก้ไขปัญหาที่ถูกต้อง
คำถามที่พบบ่อย
ร้านค้าขนาดเล็กจำเป็นต้องใช้เครื่องมือติดตาม คืนสินค้า และสนับสนุนแยกกันหรือไม่
ไม่จำเป็น เริ่มจากความสามารถที่มีอยู่แล้วและปัญหาด้านการดำเนินงานที่ระบุได้ เครื่องมือแยกกันจะมีประโยชน์เมื่อการตั้งค่าปัจจุบันไม่สามารถให้การมองเห็นข้อมูล การควบคุมนโยบาย หรือการส่งต่องานที่เชื่อถือได้ การมีแอปพลิเคชันเพิ่มขึ้นโดยไม่มีความเป็นเจ้าของที่ชัดเจนอาจเพิ่มงานที่ต้องทำด้วยตนเอง
เหตุการณ์การติดตามควรเรียกใช้การคืนเงินโดยอัตโนมัติหรือไม่
เฉพาะภายใต้เวิร์กโฟลว์ที่ได้รับอนุมัติอย่างชัดเจนและมีการตรวจสอบที่เหมาะสม เหตุการณ์การจัดส่งอธิบายการเคลื่อนย้ายหรือกิจกรรมการจัดส่ง แต่ไม่ได้ยืนยันสิทธิ์ในการคืนเงินเสมอไป แยกเหตุการณ์ที่เป็นทริกเกอร์ การตัดสินใจอนุมัติ และการดำเนินการทางการเงินออกจากกัน
การเชื่อมต่อ API เพียงพอที่จะทำให้เครื่องมือสองตัวทำงานร่วมกันหรือไม่
ไม่เพียงพอ การเชื่อมต่อยังต้องมีตัวระบุที่เข้ากันได้ การจับคู่ฟิลด์ สิทธิ์ การจัดการความล้มเหลว และกฎสำหรับข้อมูลอัปเดตที่ขัดแย้งกัน ยืนยันว่าระเบียนใดสามารถอ่านหรือเปลี่ยนแปลงได้ และทดสอบเวิร์กโฟลว์ทางธุรกิจตั้งแต่ต้นจนจบ
การคืนสินค้าที่มีสถานะจัดส่งถึงแล้วสามารถแสดงว่าได้รับเงินคืนแล้วได้หรือไม่
ไม่สามารถสรุปจากหลักฐานดังกล่าวเพียงอย่างเดียว การจัดส่งไปยังที่อยู่สำหรับคืนสินค้า การรับเข้าคลังสินค้า การตรวจสอบ การอนุมัติคืนเงิน และการดำเนินการคืนเงินสำเร็จ เป็นเหตุการณ์ที่แตกต่างกัน ข้อความถึงลูกค้าควรระบุขั้นตอนที่ได้รับการยืนยันแล้วจริง
ใครควรเป็นเจ้าของ post-purchase stack
ผู้นำด้านอีคอมเมิร์ซหรือฝ่ายปฏิบัติการเป็นผู้รับผิดชอบโดยรวมที่เหมาะสม โดยมีทีมสนับสนุน โลจิสติกส์ การเงิน และเทคนิครับผิดชอบเวิร์กโฟลว์ของตนเอง ควรมีบุคคลหนึ่งทำหน้าที่ประสานงานความล้มเหลวระหว่างระบบ เพื่อไม่ให้ปัญหาค้างอยู่ระหว่างแผนก
แหล่งข้อมูล
แหล่งข้อมูลผลิตภัณฑ์และเอกสารอย่างเป็นทางการต่อไปนี้เป็นจุดเริ่มต้นสำหรับแนวทางการประเมิน 17TRACK ที่กล่าวถึงข้างต้น ตรวจสอบข้อกำหนดเฉพาะในการติดตั้งกับเอกสารและเงื่อนไขผลิตภัณฑ์ที่เกี่ยวข้อง
