การยอมรับการทดลอง Kiosk, Yield, Marketing และฮาร์ดแวร์

ใช้คู่มือนี้เมื่อสาขาพร้อมเปลี่ยนจากการทดสอบซอฟต์แวร์ไปเป็นการทดลองในสถานการณ์จริงแบบควบคุม Docker ที่ healthy หรือ build ที่สำเร็จไม่ได้พิสูจน์ว่า Kiosk จริง ข้อมูลสาขาจริง Email Provider หรืออุปกรณ์ที่ติดตั้งแล้วทำงานได้จริง

คำเตือน

ทดสอบทีละสาขา เวอร์ชัน และช่วงเวลาเท่านั้น หยุดทันทีเมื่อพบข้อมูลข้ามสาขา อีเมลที่ไม่มีความยินยอม การเปิดเผย credential สถานะการเงินผิด หรือข้อมูลลูกค้าที่ล้างไม่ได้ บันทึก BLOCKED และ NOT RUN ตามจริง ห้ามเปลี่ยนเป็น PASS

บันทึกก่อนเริ่ม

• Pilot ID, environment, Git SHA/image tag และเขตเวลาของสาขา
• Tenant, Store, ผู้ทดสอบ และผู้อนุมัติสุดท้ายที่แน่นอน
• ขอบเขตข้อมูล: ข้อมูลจำลอง ข้อมูลทดสอบของพนักงาน หรือข้อมูลสาขาที่ได้รับอนุมัติ
• รุ่น/OS ของอุปกรณ์ Email Provider และวิธีจัดการอุปกรณ์เมื่อเกี่ยวข้อง
• ผู้รับผิดชอบ rollback ตำแหน่งหลักฐาน และช่องทางเหตุการณ์

ห้ามใส่ข้อมูลติดต่อ/ข้อความสุขภาพของลูกค้า credential อุปกรณ์ หรือ Provider secret ในภาพหน้าจอและข้อความช่วยเหลือทั่วไป

Kiosk

1. ทดสอบบนอุปกรณ์ที่ติดตั้งจริงในโหมด supervised/fullscreen
2. ทำการจองวันเดียวกัน กรอก intent/body map และยืนยันชำระที่ร้าน
3. เพิ่ม Sale line สองรายการ ลบหนึ่งรายการ แล้วเทียบยอดกับ Sale ที่ POS รับไป
4. ตัดเครือข่ายแล้วลองใหม่ handoff ต้องรับได้ครั้งเดียว และต้องปฏิเสธการรับซ้ำ/หมดอายุ
5. หลังเสร็จและ reset ตรวจว่า back/forward, autofill และการเปิดเครื่องใหม่ไม่เผยข้อมูลลูกค้าคนก่อน
6. ตรวจ EN, 中文, ไทย เป้าสัมผัสจริง การเข้าถึงในท่านั่ง และ short status code ผลลัพธ์ต้องไม่แสดงนักบำบัด ลำดับคิว หรือสัญญาเวลารอ

ดู การขายและชำระเงิน สำหรับขั้นตอน Sale ที่เคาน์เตอร์

Yield Intelligence

1. ยืนยันว่าสาขามีข้อมูลนัดหมาย ความสามารถบริการ roster การลา station และ denied-demand ที่เป็นตัวแทนจริง
2. ที่ Admin → Roster → Coverage Planner รันช่วง 7 วันและ 14 วัน
3. เทียบ appointment demand, denied-demand, gap days และจำนวนคำแนะนำกับข้อมูลต้นทางของสาขานั้น
4. สลับสาขา/ช่วงเวลาและยืนยันว่าผลเก่าหรือ response ที่มาช้าไม่ทับผลปัจจุบัน
5. ผู้จัดการสาขาตรวจทุกคำแนะนำ การใช้หนึ่งคำแนะนำเป็นทางเลือกของมนุษย์และยังต้องมี roster.schedule.manage; planner ไม่แก้ roster อัตโนมัติ

บันทึกคำแนะนำที่ใช้ได้ ถูกปฏิเสธ false positive และ false negative ห้ามตีความเป็นคำแนะนำด้าน payroll, Award, qualification, revenue หรือการจัดพนักงานอัตโนมัติ ดู นัดหมายและ roster

Email Marketing

มีเพียง Email ที่ใช้งานจริง ห้ามเริ่มหากยังไม่มี sender, Provider, consent wording และกลุ่มทดสอบที่ยินยอมอย่างชัดเจน

1. ที่ Admin → การตลาดตามวงจรลูกค้า ตรวจสาขาและ Channel readiness ให้ถูกต้อง
2. สร้าง fixed lifecycle candidate หนึ่งรายการ ตรวจ audience แบบ aggregate แก้เนื้อหา และให้คนอื่นอนุมัติก่อน schedule
3. ถอน consent ของผู้รับทดสอบหนึ่งรายก่อนส่ง และพิสูจน์ว่ารายนั้นไม่ถูกส่ง ขณะที่ผู้รับที่อนุมัติยังดำเนินต่อ
4. เก็บเฉพาะ MMOS delivery ID และ Provider outcome ที่ปกปิดข้อมูล ห้ามเก็บ API key หรือรายชื่อผู้รับทั้งหมด
5. ทดสอบ signed unsubscribe และการเปลี่ยน Email ภายหลัง ทั้ง delivered address เดิมและ current address ต้องถูก suppress
6. ปิด Email แล้วพิสูจน์ว่าการ prepare ใหม่และ delivery ที่เตรียมไว้หยุดก่อน Provider egress; WhatsApp, WeCom และ SMS ต้องยังใช้ไม่ได้

ดู Marketing automation

Marketplace, ฮาร์ดแวร์ และอุปกรณ์

1. ส่ง quote/order จริงแบบควบคุมและตรวจ frozen items, notes และ status history สถานะต้องไม่สื่อว่าจ่ายเงินหรือจัดส่งแล้ว
2. Super Admin ตรวจ/เสนอราคาเอง และ Tenant ยืนยันอย่างชัดเจน
3. ลงทะเบียนและมอบหมายสินทรัพย์จริงให้ Tenant/Store ที่แน่นอน
4. สำหรับ Kiosk ให้เก็บ one-time credential ลง approved device secret store โดยตรง และพิสูจน์ว่าอ่านกลับไม่ได้หลังปิด
5. enroll อุปกรณ์ ส่ง heartbeat และเทียบ expected software/config; ทดสอบเฉพาะ update, restart หรือ maintenance ที่อนุมัติบนอุปกรณ์ควบคุม ห้าม remote shell, camera, microphone และ Customer monitoring
6. เตรียม Hardware Support handoff แล้วให้ผู้ใช้กดส่งและดำเนิน ticket เอง handoff ต้องไม่ส่งอัตโนมัติ
7. แนบหลักฐานการติดตั้ง เครือข่าย supervised mode ข้อกำหนดเชิงพาณิชย์ การจัดส่ง และ EMM/MDM หรือทำเครื่องหมาย BLOCKED/NOT RUN

ดู Platform marketplace และ hardware support

การลงนาม

บันทึกทุกขั้นตอนเป็น PASS, FAIL, BLOCKED, NOT RUN หรือ NOT APPLICABLE พร้อมหลักฐาน เจ้าของงาน และวันทดสอบซ้ำ ผู้จัดการสาขาและเจ้าของด้านเทคนิคต้องลงนามสำหรับสาขา/เวอร์ชัน/ช่วงเวลานั้น Marketing/Privacy และ Platform Owner ต้องลงนามในส่วนที่รับผิดชอบ การอนุมัติแบบมีเงื่อนไขต้องมีวันหมดอายุและห้ามนำไปใช้กับสาขา เวอร์ชัน Provider หรือรุ่นอุปกรณ์อื่น