ดักจุดตายสัญญาให้บริการระบบบริหารจัดการคลังสินค้าอัตโนมัติบนคลาวด์ (Cloud Warehouse Management System - WMS SaaS Agreement)
SLA การันตี Order Picking & Inventory Accuracy 99.9%, การเชื่อมต่อ API กับ ERP/E-commerce และความรับผิดกรณีระบบซิงก์สต๊อกผิดพลาด (Over-selling Liabilities), มาตรการป้องกันข้อมูลสูญหาย (RPO 15 นาที / RTO 2 ชั่วโมง), และกลไก Exit Strategy โอนย้าย Master SKU Data ภายใน 14 วัน ✓

ภูมิทัศน์สัญญาให้บริการระบบบริหารจัดการคลังสินค้าบนคลาวด์ (WMS SaaS) ในประเทศไทย

การเติบโตของธุรกิจ Omnichannel และการค้าปลีกสมัยใหม่ในประเทศไทย ทำให้การบริหารจัดการคลังสินค้าต้องพึ่งพาระบบอัตโนมัติบนระบบคลาวด์ (Cloud WMS) เพื่อเชื่อมต่อข้อมูลระหว่างคลังสินค้า physical กับช่องทางการขาย e-Commerce, ERP, และระบบโลจิสติกส์ภายนอก

อย่างไรก็ดี สัญญาให้บริการ WMS SaaS ในท้องตลาดมักเป็นสัญญาสำเร็จรูปที่ยกร่างขึ้นโดยผู้ให้บริการ ซึ่งมักแฝงข้อสัญญาจำกัดความรับผิด ยกเว้นความเสียหายเชิงพาณิชย์ และตัดสิทธิการเรียกร้องค่าเสียหายอันเกิดจากความผิดพลาดของระบบซิงก์ข้อมูล ส่งผลให้ผู้ใช้บริการแบกรับความเสี่ยงทางกฎหมายและธุรกิจไว้เพียงฝ่ายเดียว

ผลกระทบเชิงธุรกิจ Business Consequences

ความผิดพลาดของระบบ WMS ส่งผลกระทบอย่างร้ายแรงต่อการดำเนินธุรกิจใน 3 มิติหลัก:

• สต๊อกในระบบเพี้ยนจนส่งสินค้าผิดเป็นพันออเดอร์: การคำนวณ Cycle Count ผิดพลาด หรือ Picking List ในระบบไม่ตรงกับตำแหน่งจัดเก็บจริง ทำให้เกิดการจัดส่งสินค้าผิด SKU ส่งสินค้าช้า หรือส่งสินค้าไม่ครบถ้วน ก่อให้เกิดต้นทุนการตีกลับและการจัดส่งใหม่
• ร้านค้าถูกแพลตฟอร์มระงับบัญชีเพราะส่งของไม่ได้: การซิงก์ข้อมูลสต๊อกผ่าน API ล่าช้า (Latency) ในช่วงที่มีคำสั่งซื้อสูง ส่งผลให้ระบบเปิดขายสินค้าที่ไม่มีอยู่จริง (Over-selling) เมื่อต้องยกเลิกคำสั่งซื้อจำนวนมาก ร้านค้าจะถูกลงโทษจากแพลตฟอร์ม มาร์เก็ตเพลส ปรับเงิน ลดเกียรติยศร้านค้า หรือถูกระงับบัญชีผู้ขาย
• ข้อมูลสินค้าหายไปหมดเพราะเซิร์ฟเวอร์ล่ม: หากผู้ให้บริการไม่มีระบบสำรองข้อมูลตามมาตรฐาน RPO/RTO ที่เหมาะสม เมื่อเกิดเหตุระบบล้มเหลว ข้อมูล Master SKU, บาร์โค้ด, ล็อตสินค้า และประวัติการรับเข้า-จ่ายออกอาจสูญหายทั้งหมด และหากสัญญาไม่ได้กำหนด Exit Strategy ไว้ ผู้ใช้บริการอาจถูกยึดฐานข้อมูลไว้เป็นตัวประกันเมื่อต้องการย้ายระบบ

กรอบกฎหมายและ Claim Ledger Legal Framework

ระบบ WMS แบบ SaaS เป็นบริการซอฟต์แวร์ ผู้ให้บริการที่จัดให้เพียงระบบโดยมิได้รับสินค้าไว้ในความดูแลของตนจึงไม่ใช่นายคลังสินค้าตามประมวลกฎหมายแพ่งและพาณิชย์ มาตรา 770 ซึ่งหมายถึงบุคคลผู้รับทำการเก็บรักษาสินค้าเพื่อบำเหน็จเป็นทางค้าปกติของตน ความรับผิดของผู้ให้บริการ WMS จึงเป็นความรับผิดตามสัญญาที่อธิบายในหัวข้อนี้ แต่หากผู้ให้บริการรายเดียวกันรับเก็บรักษาสินค้าของผู้ใช้บริการด้วย ความรับผิดต่อสินค้าที่สูญหายหรือบุบสลาย ภาระพิสูจน์ และสิทธิยึดหน่วง เป็นไปตามบทบัญญัติว่าด้วยการเก็บของในคลังสินค้า ส่วนข้อจำกัดความรับผิดต่อสินค้าต้องผ่านการตรวจสามชั้น ทั้งสองเรื่องอธิบายไว้ในบทความหลักเรื่อง สัญญาบริการโลจิสติกส์และคลังสินค้า (3PL) ข้อความเรื่องข้อจำกัดความรับผิดในบทความนี้สอดคล้องกับบทความหลัก กล่าวคือ ความตกลงล่วงหน้าที่ยกเว้นความรับผิดเพื่อกลฉ้อฉลหรือความประมาทเลินเล่ออย่างร้ายแรงของลูกหนี้เองเป็นโมฆะตามมาตรา 373 แต่มาตรา 373 ไม่ใช้บังคับแก่ความผิดของบุคคลที่ลูกหนี้ใช้ในการชำระหนี้ตามมาตรา 220 และข้อจำกัดความรับผิดที่ไม่เป็นโมฆะมีผลบังคับได้เพียงเท่าที่เป็นธรรมและพอสมควรแก่กรณีตามพระราชบัญญัติว่าด้วยข้อสัญญาที่ไม่เป็นธรรม พ.ศ. 2540 มาตรา 8 วรรคสอง

การเรียกร้องความรับผิดในสัญญา Cloud WMS SaaS อ้างอิงประมวลกฎหมายแพ่งและพาณิชย์ (ป.พ.พ.), พระราชบัญญัติว่าด้วยข้อสัญญาที่ไม่เป็นธรรม พ.ศ. 2540, พระราชบัญญัติว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ พ.ศ. 2550, พระราชบัญญัติว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์ พ.ศ. 2544 และพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA)

Claim Ledger (C-SHIELD-35-01 ถึง 06)

วิเคราะห์ Fulfillment SLA: Picking Accuracy, Putaway Speed, และ Stock Reconciliation Frequency

ข้อตกลงระดับการให้บริการ (Service Level Agreement - SLA) ควรกำหนดเป็นตัวเลขเชิงปริมาณที่วัดผลได้อย่างชัดเจน ตัวเลขในหัวข้อนี้ถึงหัวข้อที่ 7 เป็นตัวอย่างตามแนวปฏิบัติของอุตสาหกรรมที่คู่สัญญาตกลงกันเอง มิใช่ข้อกำหนดตามกฎหมาย [ต้องยืนยันแหล่งที่มา] ดังนี้:

• Order Picking Accuracy (99.9%): อัตราความแม่นยำในการหยิบสินค้าตาม Picking List ที่ระบบสร้างขึ้น หากเกิดความผิดพลาดเกิน 0.1% ของรายการคำสั่งซื้อประจำเดือน ผู้ให้บริการต้องชดใช้ Service Credits หรือค่าส่งทดแทน
• Putaway Speed: ระยะเวลาในการอัปเดตสถานะสินค้าเข้าสต๊อกนับตั้งแต่สแกนรับเข้าคลัง (Receiving) ต้องพร้อมขายบนระบบภายในเวลาที่กำหนด (เช่น ไม่เกิน 30 นาที)
• Stock Reconciliation Frequency: กำหนดให้ระบบต้องทำการประมวลผลเปรียบเทียบสต๊อกทางบัญชีกับสต๊อกจริง (Cycle Count Reconciliation) แบบอัตโนมัติอย่างน้อยวันละ 1 ครั้ง และแจ้งเตือนข้อผิดพลาด (Discrepancy Alert) ทันที

การเชื่อมต่อ API ระหว่าง WMS กับระบบ ERP และ Marketplace: ความรับผิดต่อ Latency & Webhook Failure

จุดเปราะบางที่สุดของ WMS SaaS คือสถาปัตยกรรมอินเทอร์เฟซ (API Integration) ที่เชื่อมต่อกับระบบ ERP และ Marketplace ต่าง ๆ สัญญาจึงควรกำหนดมาตรฐานต่อไปนี้ไว้เป็นข้อสัญญา โดยตัวเลขเป็นตัวอย่างตามแนวปฏิบัติของอุตสาหกรรมที่คู่สัญญาตกลงกันเอง มิใช่ข้อกำหนดตามกฎหมาย [ต้องยืนยันแหล่งที่มา]:

• API Latency Standard: กำหนดให้ Response Time ของ API ในการอัปเดตจำนวนสต๊อก (Stock Sync) ต้องไม่เกิน 2,000 มิลลิวินาที (2 วินาที) ในช่วงภาวะปกติ และไม่เกิน 5,000 มิลลิวินาที ในช่วงเทศกาลแคมเปญ (High-Traffic Events)
• Webhook Failure & Retry Mechanism: หากระบบไม่สามารถส่งสัญญาณ Webhook ไปยัง Marketplace ได้ ระบบ WMS ต้องมีกลไก Retry Automatic Queue ไม่น้อยกว่า 5 ครั้งภายใน 60 วินาที
• Over-selling Liabilities: หาก API ล้มเหลวหรือเกิด Latency เกินมาตรฐาน จนเป็นเหตุให้เกิดการขายสินค้าเกินสต๊อกจริง (Over-selling) ผู้ให้บริการ WMS ต้องรับผิดชอบค่าปรับที่แพลตฟอร์มเรียกเก็บจากร้านค้า รวมถึงค่าเสียหายจากการถูกระงับสิทธิการขาย

มาตรการ Disaster Recovery: RPO, RTO, Database High-Availability และการทำ Penetration Testing

เพื่อประกันความต่อเนื่องในการบริหารจัดการคลังสินค้า สัญญาควรกำหนดมาตรฐานทางเทคนิคไว้เป็นข้อผูกพันตามสัญญา โดยตัวเลขต่อไปนี้เป็นตัวอย่างตามแนวปฏิบัติของอุตสาหกรรมที่คู่สัญญาตกลงกันเอง มิใช่ข้อกำหนดตามกฎหมาย [ต้องยืนยันแหล่งที่มา] ทั้งนี้ หากผู้ให้บริการประมวลผลข้อมูลส่วนบุคคลแทนผู้ใช้บริการ พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 40 (2) กำหนดให้ผู้ประมวลผลข้อมูลส่วนบุคคลจัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสมเพื่อป้องกันการสูญหาย เข้าถึง ใช้ เปลี่ยนแปลง แก้ไข หรือเปิดเผยข้อมูลส่วนบุคคลโดยปราศจากอำนาจหรือโดยมิชอบ แต่ไม่ได้กำหนดตัวเลขทางเทคนิคไว้:

• Recovery Point Objective (RPO) ไม่เกิน 15 นาที: ข้อมูลธุรกรรมการเข้า-ออกของสต๊อกและคำสั่งซื้อจะสูญหายได้ไม่เกิน 15 นาทีย้อนหลังเมื่อเกิดเหตุระบบล่ม
• Recovery Time Objective (RTO) ไม่เกิน 2 ชั่วโมง: ระบบต้องสามารถกู้คืนกลับมาพร้อมใช้งานตามปกติได้ภายในเวลาไม่เกิน 2 ชั่วโมงนับจากเกิดเหตุชะงักงัน
• Database High-Availability: กำหนดให้ผู้ให้บริการใช้สถาปัตยกรรมแบบ Multi-AZ (Availability Zone) มีการทำ Data Replication แบบ Real-time
• Penetration Testing: ผู้ให้บริการต้องจัดทำรายงานการทดสอบการเจาะระบบ (Penetration Test) โดยบุคคลภายนอกที่ได้รับมาตรฐานเป็นประจำอย่างน้อยปีละ 1 ครั้ง และแก้ไขข้อบกพร่องระดับ High/Critical ภายใน 30 วัน

LAS Practice Note: การออกแบบข้อสัญญา Marketplace Penalty Indemnity, Service Credits Matrix และ Data Transition Protocol

1 ข้อสัญญาชดใช้ค่าเสียหายจากบทลงโทษมาร์เก็ตเพลส (Marketplace Penalty Indemnity Clause)

สัญญาต้องระบุชัดเจนว่า ค่าปรับ ค่าธรรมเนียมการยกเลิกออเดอร์ หรือการสูญเสียรายได้จากการถูกลดเกรดร้านค้าบน Marketplace อันเนื่องมาจาก WMS Sync Latency ถือเป็นความเสียหายโดยตรงที่ผู้ให้บริการต้องชดใช้เต็มจำนวน โดยไม่นำข้อจำกัดความรับผิดเท่ากับค่าบริการมาใช้บังคับ

2 ตาราง Service Credits Matrix

กำหนดการหักลดค่าบริการรายเดือนอัตโนมัติเมื่อผู้ให้บริการไม่สามารถรักษา ระดับ SLA ได้:

• System Availability ต่ำกว่าร้อยละ 99.9 ถึงร้อยละ 99.0: หักคืน 10% ของค่าบริการรายเดือน
• System Availability ต่ำกว่าร้อยละ 99.0 ถึงร้อยละ 95.0: หักคืน 25% ของค่าบริการรายเดือน
• System Availability ต่ำกว่าร้อยละ 95.0: หักคืน 50% ของค่าบริการรายเดือน และผู้ใช้บริการมีสิทธิบอกเลิกสัญญาได้ทันที

Service Credits ที่กำหนดเป็นจำนวนแน่นอนเมื่อผิด SLA ทั้งในหัวข้อนี้และในหัวข้อที่ 4 อาจถือเป็นเบี้ยปรับตามประมวลกฎหมายแพ่งและพาณิชย์ มาตรา 379 ซึ่งศาลลดลงเป็นจำนวนพอสมควรได้หากสูงเกินส่วนตามมาตรา 383 การจะเป็นเบี้ยปรับหรือไม่ต้องพิจารณาจากถ้อยคำและความมุ่งหมายของข้อสัญญา

3 โปรโตคอลการโอนย้ายข้อมูลเมื่อเลิกสัญญา (Data Transition Protocol)

สัญญาควรกำหนดว่า เมื่อสัญญาเลิกกันไม่ว่าด้วยเหตุใด ผู้ให้บริการมีหน้าที่ตามข้อสัญญาดังต่อไปนี้ (กำหนดเวลา 14 วันเป็นตัวอย่างที่คู่สัญญาตกลงกันเอง มิใช่ข้อกำหนดตามกฎหมาย [ต้องยืนยันแหล่งที่มา]):

• ผู้ให้บริการต้องส่งมอบ Master SKU Data, บาร์โค้ด, ประวัติการทำรายการ (Transaction Logs), และโครงสร้างความสัมพันธ์ของข้อมูล ให้แก่ผู้ใช้บริการในรูปแบบ CSV หรือ JSON
• ดำเนินการให้แล้วเสร็จภายใน 14 วันนับแต่วันที่สัญญาสิ้นสุดลง
• ห้ามมิให้ผู้ให้บริการเรียกร้องค่าใช้จ่ายเพิ่มเติมเกินกว่าอัตราที่กำหนดไว้ล่วงหน้า และห้ามยึดหน่วงข้อมูลไว้ไม่ว่าด้วยเหตุผลใด ๆ ทั้งนี้ สิทธิยึดหน่วงตามประมวลกฎหมายแพ่งและพาณิชย์ มาตรา 241 เป็นสิทธิของผู้ครองทรัพย์สินของผู้อื่นซึ่งมีหนี้อันเป็นคุณประโยชน์แก่ตนเกี่ยวด้วยทรัพย์สินนั้น ส่วนข้อมูลจะเป็นทรัพย์สินที่อาจถูกยึดหน่วงได้หรือไม่ ยังไม่มีบทบัญญัติรับรองไว้โดยตรง [ต้องยืนยันมาตรา] สัญญาจึงควรกำหนดข้อห้ามนี้ไว้อย่างชัดแจ้ง

ข้อต่อสู้ของผู้ให้บริการ WMS กับธุรกิจจัดจำหน่าย/โลจิสติกส์ Devil's Advocate

ข้อแย้งฝั่งผู้ให้บริการ (WMS Provider Arguments)

1. API Rate Limit จาก Marketplace: ความล่าช้าเกิดจากฝั่ง Marketplace ปรับลด Rate Limit หรือ API Gateway ของแพลตฟอร์มปลายทางล่ม ไม่ใช่ความผิดของ WMS
2. Network/User Error: ปัญหาการนับสต๊อกผิดเกิดจากการสแกนบาร์โค้ดผิดพลาดของพนักงานคลังสินค้า หรือเครือข่ายอินเทอร์เน็ตภายในคลังสินค้าของผู้ใช้บริการขัดข้อง
3. Limitation of Liability: ผู้ให้บริการขายระบบในราคา SaaS รายเดือน ไม่สามารถรับความเสี่ยงเกินกว่ามูลค่าสัญญาได้

ข้อต่อสู้ทางกฎหมายของฝั่งผู้ใช้บริการ (Distributor/Merchant Counter-Arguments)

1. Log & Telemetry Proof: ข้อโต้แย้งเรื่อง API Rate Limit หรือ Network ขัดข้อง สามารถพิสูจน์ได้จาก System Telemetry Logs หาก Log แสดงว่า WMS ล้มเหลวในการส่ง Webhook ก่อนถึง Rate Limit ผู้ให้บริการต้องรับผิด
2. Standard Operating Procedure Audit: หากพนักงานคลังปฏิบัติตามขั้นตอน Scan-to-Confirm บน Handheld Scanner แล้ว แต่ฐานข้อมูลระบบกลับไม่ตัดสต๊อก ถือเป็นข้อบกพร่องของ Software Architecture
3. การบังคับใช้ ป.พ.พ. มาตรา 373: หากผู้ใช้บริการพิสูจน์ได้ว่าผู้ให้บริการเองประมาทเลินเล่ออย่างร้ายแรง เช่น เพิกเฉยต่อความเสี่ยงที่ได้รับแจ้งล่วงหน้าโดยไม่จัดให้มีระบบ Backup Server หรือ Failover เลย ข้อสัญญายกเว้นหรือจำกัดความรับผิดสำหรับความประมาทเลินเล่อดังกล่าวเป็นโมฆะตามมาตรา 373 การไม่มีระบบสำรองตามที่อ้างว่าเป็นมาตรฐานอุตสาหกรรม [ต้องยืนยันแหล่งที่มา] ไม่เป็นความประมาทเลินเล่ออย่างร้ายแรงโดยอัตโนมัติ แต่เป็นปัญหาข้อเท็จจริงที่ต้องพิสูจน์เป็นรายกรณี มาตรา 373 ใช้กับกลฉ้อฉลหรือความประมาทเลินเล่ออย่างร้ายแรงของลูกหนี้เอง ส่วนความผิดของตัวแทนหรือบุคคลที่ลูกหนี้ใช้ในการชำระหนี้ เช่น ลูกจ้าง ผู้รับช่วง หรือผู้ให้บริการคลาวด์ ลูกหนี้ต้องรับผิดตามมาตรา 220 แต่มาตรา 373 ไม่ใช้บังคับแก่กรณีดังกล่าว ผู้ใช้บริการจึงต้องพิสูจน์ว่ากลฉ้อฉลหรือความประมาทเลินเล่ออย่างร้ายแรงเป็นของผู้ให้บริการเอง หากพิสูจน์ไม่ได้ ข้อจำกัดความรับผิดที่ไม่เป็นโมฆะยังมีผลบังคับได้เพียงเท่าที่เป็นธรรมและพอสมควรแก่กรณีตามมาตรา 4 และมาตรา 8 วรรคสอง แห่งพระราชบัญญัติว่าด้วยข้อสัญญาที่ไม่เป็นธรรม พ.ศ. 2540

ตัวอย่างสถานการณ์จำลอง Worked Example

สถานการณ์

แบรนด์สินค้าแฟชั่นรายใหญ่เตรียมจัดแคมเปญ 12.12 บนแพลตฟอร์มอีคอมเมิร์ซ โดยคาดการณ์คำสั่งซื้อไว้ 80,000 ออเดอร์ ก่อนเริ่มแคมเปญ แบรนด์ได้แจ้งเตือนปริมาณ Traffic ให้ผู้ให้บริการ WMS ทราบล่วงหน้า 30 วัน

กระทั่งเวลา 00:00 น. ของวันแคมเปญ ระบบ WMS เกิดปัญหา Database Lock ทำให้การซิงก์ข้อมูลสต๊อกคงเหลือไปยัง Marketplace ล่าช้าไป 3 ชั่วโมง ผลทำให้ระบบมาร์เก็ตเพลสเปิดขายสินค้าที่หมดไปแล้ว เกิดการ Over-selling จำนวน 6,000 ชิ้น

ผลกระทบและความเสียหาย

1. แบรนด์ต้องยกเลิกคำสั่งซื้อ 6,000 ออเดอร์
2. ถูกแพลตฟอร์มปรับเงินเป็นจำนวน 1,200,000 บาท
3. ร้านค้าถูกลดคะแนนความประพฤติและระงับสิทธิการร่วมแคมเปญใหญ่เป็นเวลา 3 เดือน

การดำเนินมาตรการบังคับตามสัญญา

1. ตรวจสอบ System Logs: ทีมกฎหมายร่วมกับ IT Auditor ดึงข้อมูล Telemetry พบว่า API Queue ของ WMS เกิดการค้างเนื่องจาก Database Unindexed Query ไม่ใช่เกิดจาก Marketplace API
2. อ้างสิทธิ C-SHIELD-35-02 C-SHIELD-35-03 และ C-SHIELD-35-06: ผู้ใช้บริการต่อสู้ข้อสัญญาจำกัดความรับผิด (ที่ระบุรับผิดไม่เกินค่าบริการเดือนละ 50,000 บาท) ได้สองทาง ทางแรก ชี้ว่าผู้ให้บริการเองประมาทเลินเล่ออย่างร้ายแรงที่ไม่เตรียมความพร้อมของระบบทั้งที่ได้รับแจ้งปริมาณการใช้งานล่วงหน้า 30 วัน ข้อจำกัดความรับผิดสำหรับความประมาทเลินเล่อนั้นจึงเป็นโมฆะตามประมวลกฎหมายแพ่งและพาณิชย์ มาตรา 373 แต่หากความบกพร่องเป็นของลูกจ้าง ผู้รับช่วง หรือผู้ให้บริการคลาวด์ที่ผู้ให้บริการใช้ในการชำระหนี้ มาตรา 373 ไม่ใช้บังคับตามมาตรา 220 ทางที่สอง แม้ข้อจำกัดความรับผิดไม่เป็นโมฆะ ข้อจำกัดนั้นมีผลบังคับได้เพียงเท่าที่เป็นธรรมและพอสมควรแก่กรณีตามมาตรา 4 (หากเป็นสัญญาสำเร็จรูป) และมาตรา 8 วรรคสอง แห่งพระราชบัญญัติว่าด้วยข้อสัญญาที่ไม่เป็นธรรม พ.ศ. 2540 ส่วนค่าปรับของมาร์เก็ตเพลสเรียกได้ตามมาตรา 222 วรรคสอง เมื่อผู้ให้บริการได้คาดเห็นหรือควรจะได้คาดเห็นพฤติการณ์พิเศษนั้นล่วงหน้า
3. บังคับข้อสัญญา Marketplace Penalty Indemnity: ออกหนังสือบอกกล่าวเรียกร้องให้ผู้ให้บริการ WMS ชดใช้ค่าปรับ 1,200,000 บาท พร้อมคืน Service Credits สำหรับค่าบริการประจำเดือนนั้น

Checklist 10 จุดตรวจสัญญา Cloud WMS SaaS Agreement

• 1. Order Picking Accuracy SLA: มีการกำหนดความแม่นยำไม่ต่ำกว่า 99.9% หรือไม่?
• 2. API Sync Latency: กำหนดระยะเวลาตอบสนองของ API ไว้ไม่เกิน 2-5 วินาทีหรือไม่?
• 3. Marketplace Over-selling Indemnity: มีข้อสัญญาชดใช้ค่าปรับจากมาร์เก็ตเพลสกรณีระบบซิงก์ผิดพลาดหรือไม่?
• 4. Exemption of Liability Carve-out: มีข้อยกเว้นมิให้ข้อจำกัดความรับผิดใช้กับกลฉ้อฉลหรือความประมาทเลินเล่ออย่างร้ายแรงของผู้ให้บริการเอง (ป.พ.พ. มาตรา 373) และมีข้อสัญญาเฉพาะสำหรับความผิดของผู้ให้บริการคลาวด์หรือบุคคลอื่นที่ผู้ให้บริการใช้ในการชำระหนี้ ซึ่งมาตรา 373 ไม่ใช้บังคับตามมาตรา 220 หรือไม่?
• 5. Disaster Recovery RPO/RTO: กำหนด RPO ไม่เกิน 15 นาที และ RTO ไม่เกิน 2 ชั่วโมง หรือไม่?
• 6. High-Traffic Campaign Support: มีข้อผูกพันให้ผู้ให้บริการขยาย Capacity รองรับช่วงแคมเปญโดยไม่มีค่าใช้จ่ายแอบแฝงหรือไม่?
• 7. Penetration Test Compliance: ผู้ให้บริการส่งมอบรายงาน Pen Test ประจำปีหรือไม่?
• 8. Master SKU Data Rights: กำหนดสิทธิของผู้ใช้บริการในการใช้และเข้าถึงข้อมูล Master SKU และข้อมูลธุรกรรมทั้งหมดไว้ในสัญญาอย่างชัดเจนหรือไม่?
• 9. Data Transition Protocol: กำหนดให้ส่งมอบข้อมูลคืนในรูปแบบ CSV/JSON ภายใน 14 วันนับจากเลิกสัญญาหรือไม่?
• 10. Anti Vendor Lock-in: มีข้อห้ามผู้ให้บริการยึดหน่วงหรือล็อกการเข้าถึงฐานข้อมูลเมื่อเกิดข้อพิพาทหรือไม่?

คำถามที่พบบ่อย Frequently Asked Questions