Platform System Checklist

เช็กลิสต์ระบบ EasyTourAgent แบบกดอ่านรายละเอียดได้

หน้านี้สรุปแบบภาษาคนทำธุรกิจว่าเรามีระบบอะไรแล้ว อะไรพร้อมใช้ อะไรยังต้องทำต่อ และแต่ละหัวข้อทำงานยังไงในระบบจริง

สรุปสั้นที่สุด

ระบบหลักพร้อมเป็น MVP สำหรับ demo และเริ่มลูกค้ารายแรกได้ แต่ก่อนขายหลายเจ้าเต็มรูปแบบต้องทำ data quality, domain allowlist, Redis production และ onboarding automation ให้แน่นก่อน

ระบบหลักที่พร้อมใช้

มีโค้ด หน้าเว็บ API และฐานข้อมูลรองรับแล้ว

งานที่ต้องทำต่อ

เป็นงานเสริมความแข็งแรงก่อนเปิดขายหลายเจ้า

MVP+

ระดับพร้อมขาย

ใช้เป็นเดโมและเริ่มทำลูกค้ารายแรกแบบควบคุมใกล้ชิดได้

ดูสิ่งที่ยังค้างต้องทำต่อ เปิด API Docs

ฐานข้อมูลและคลังทัวร์กลาง

เก็บทัวร์โฮลเซลล์เป็นข้อมูลกลาง แล้วแยกค่าของแต่ละลูกค้าไว้คนละชั้น ไม่ให้ทับข้อมูลหลัก

Master tour data

มีตารางทัวร์กลางสำหรับเก็บแพ็กเกจทัวร์ ราคา รูป PDF และรอบเดินทาง

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

นี่คือคลังสินค้าหลักของระบบ เหมือนโกดังกลางที่ทุกเว็บลูกข่ายมาใช้ข้อมูลชุดเดียวกัน

ระบบทำงานยังไง

ระบบ sync ดึงข้อมูลจาก supplier/wholesale มาเก็บในฐานข้อมูล EasyTourAgent แล้วเว็บหน้าบ้านอ่านจากฐานนี้ ไม่ยิงหา supplier ทุกครั้ง

สถานะตอนนี้

มีโครงสร้างตารางและหน้า monitor แล้ว แต่คุณภาพข้อมูลบาง supplier ยังต้อง audit ให้ละเอียดกว่านี้

ต้องทำต่อ

ทำรายงานตรวจราคา รูป รอบเดินทาง และ PDF แยกตาม supplier ให้เห็นรายการผิดทันที

Bridge table รายลูกค้า

มี client_tour_settings สำหรับเปิด/ปิดทัวร์ ตั้งชื่อเฉพาะ ตั้งราคาเฉพาะ และบวกกำไรราย client

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

ลูกค้าแต่ละเว็บปรับสินค้าได้ โดยไม่ไปแก้ข้อมูลทัวร์ต้นฉบับ

ระบบทำงานยังไง

ข้อมูลหลักอยู่ที่ tours แต่ค่าของลูกค้าอยู่ใน client_tour_settings เช่น เว็บ A เปิดทัวร์นี้ เว็บ B ปิดทัวร์นี้ หรือบวกราคาไม่เท่ากัน

สถานะตอนนี้

ฐานข้อมูลและ API มีแล้ว

ต้องทำต่อ

ทำหน้า UI ให้ tenant admin กดเปิด/ปิดทัวร์และตั้ง markup ได้เองแบบไม่ต้องยิง API

Tenant markup layer

มี tour_markups และ pricing rule สำหรับบวกกำไรตาม tenant, supplier, ประเทศ, ทวีป หรือรายทัวร์

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

แต่ละเจ้ากำหนดกำไรเองได้ เช่น บวก 500 บาททุกทัวร์ญี่ปุ่น หรือบวก 3% เฉพาะ supplier หนึ่ง

ระบบทำงานยังไง

API จะอ่านราคาต้นทุนจากทัวร์กลาง แล้วคำนวณราคาขายจาก rule ของ client ก่อนส่งไปหน้าเว็บ

สถานะตอนนี้

โครงสร้างและ route รองรับแล้ว

ต้องทำต่อ

เพิ่มหน้าตรวจราคาสุทธิ เพื่อให้แอดมินเห็นราคาก่อนและหลังบวกกำไรแบบชัดเจน

Supplier sync data quality

มีหน้า monitor และ supplier quality บางส่วนแล้ว แต่ยังต้องตรวจทุก supplier ให้ละเอียดกว่านี้

ทำแล้วบางส่วนกดอ่านรายละเอียด

หมายความว่าอะไร

ระบบต้องรู้ทันทีว่าข้อมูลที่ sync มาเพี้ยน เช่น ราคา 3 บาท รูปหาย หรือรอบเดินทางเป็น 0

ระบบทำงานยังไง

หลัง sync ต้องมี validator ตรวจราคา, รูป, PDF, ประเทศ, วันเดินทาง และจำนวนรอบ แล้วสร้างรายงาน error

สถานะตอนนี้

เริ่มมี monitor แล้ว แต่ยังไม่ครบระดับ production สำหรับขายหลายเว็บ

ต้องทำต่อ

ทำ supplier audit แบบละเอียดและปุ่ม re-sync/repair ราย supplier

ความปลอดภัยและการแยกลูกค้า

ออกแบบให้ลูกค้าแต่ละเว็บไซต์เห็นเฉพาะข้อมูลของตัวเอง ผ่าน client_id, tenant_id, RLS และ API key

Row-Level Security

เปิด RLS ในตารางสำคัญ เช่น bookings, chat_leads, ticket_reservations, tour_markups และ client_tour_settings

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

เป็นรั้วฐานข้อมูล ป้องกันลูกค้า A ไปอ่านหรือแก้ข้อมูลลูกค้า B

ระบบทำงานยังไง

Supabase policy ตรวจ tenant/client ของผู้ใช้ก่อนให้ query ข้อมูล

สถานะตอนนี้

มี migration และ policy หลักแล้ว

ต้องทำต่อ

เพิ่ม test policy เพื่อพิสูจน์ว่า cross-tenant read/write ถูกบล็อกจริงทุกตาราง

Booking isolation

bookings มี policy อ่าน/เพิ่ม/แก้ไขเฉพาะ tenant ตัวเองแล้ว

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

ยอดจองของแต่ละเว็บแยกกันชัดเจน

ระบบทำงานยังไง

ทุก booking ผูก client_id/tenant_id และหลังบ้าน query ผ่านสิทธิ์ของ tenant นั้น

สถานะตอนนี้

โครงสร้างพร้อม

ต้องทำต่อ

เพิ่มหน้า export booking ราย tenant ให้ใช้ตอนลูกค้ายกเลิกบริการหรือขอย้ายข้อมูล

API key แยกลูกค้า

มีระบบออก API key, revoke, rotate และกำหนด scope แยกต่อ tenant

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

เว็บลูกค้าแต่ละเจ้าใช้กุญแจคนละดอก ถ้าคีย์รั่วก็ปิดเฉพาะเจ้านั้นได้

ระบบทำงานยังไง

API Gateway อ่าน key จาก request แล้วผูกกับ client_id, scope และ rate limit

สถานะตอนนี้

มี route ออกและจัดการ key แล้ว

ต้องทำต่อ

เพิ่มหน้าแสดงประวัติการใช้ key และแจ้งเตือน key ใช้ผิดปกติ

CORS/domain allowlist

ยังต้องบังคับ origin/domain ต่อ API key ให้ชัด เพื่อกันเว็บอื่นเอา key ไปยิงผิดที่

ยังต้องทำกดอ่านรายละเอียด

หมายความว่าอะไร

คีย์ของลูกค้าควรใช้ได้เฉพาะ domain ที่อนุญาต เช่น customer.com เท่านั้น

ระบบทำงานยังไง

Gateway ตรวจ Origin/Referer เทียบกับ domain allowlist ของ client ก่อนตอบข้อมูล

สถานะตอนนี้

ยังเป็นงานค้างด้าน hardening

ต้องทำต่อ

เพิ่มตาราง client_allowed_domains และ middleware ตรวจ origin ก่อนเข้า API Gateway

Tour API Gateway

ช่องทาง API สำหรับเว็บลูกข่ายยิงมาดูทัวร์ เช็กที่นั่ง และ hold ที่นั่ง โดยไม่ให้ฐานข้อมูลล้มพัง

Availability API

มี GET /api/gateway/tours/{id}/availability รันแบบ Edge พร้อม cache header และ rate limit

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

เว็บลูกค้ากดเช็กที่นั่งได้เร็ว โดยไม่ต้อง query หนักทุกครั้ง

ระบบทำงานยังไง

API ตอบข้อมูลที่นั่งว่างจากฐานข้อมูลกลาง พร้อม cache ระยะสั้นเพื่อลดโหลด

สถานะตอนนี้

route พร้อมใช้งานแล้ว

ต้องทำต่อ

เพิ่ม distributed cache ด้วย Upstash Redis ใน production

Hold seats API

มี POST /api/gateway/tours/{id}/hold เรียก RPC ล็อกแถวด้วย database transaction กัน overbooking

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

เมื่อหลายเว็บกดจองพร้อมกัน ระบบต้องกันไม่ให้ขายเกินจำนวนที่นั่ง

ระบบทำงานยังไง

Postgres RPC ใช้ row-level locking ตอนสร้าง hold seat แล้วปล่อยที่นั่งเมื่อหมดอายุ

สถานะตอนนี้

มี route และ RPC หลักแล้ว

ต้องทำต่อ

ทำ test concurrency จำลองเว็บ 50 เจ้ากดพร้อมกัน

Expired hold cleanup

มี pg_cron เคลียร์ hold หมดอายุทุก 1 นาที และย้ายข้อมูลเก่าเข้า log/archive

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

ถ้าลูกค้ากดจองค้างไว้แล้วไม่จ่าย ที่นั่งต้องคืนกลับมาอัตโนมัติ

ระบบทำงานยังไง

cron ตรวจ expired_at แล้วเปลี่ยนสถานะ/ย้าย log ไม่ให้ตารางหลักบวม

สถานะตอนนี้

migration รองรับแล้ว

ต้องทำต่อ

เพิ่มหน้า monitor จำนวน hold ค้าง, hold หมดอายุ และอัตราการจ่ายสำเร็จ

Upstash Redis

โค้ดรองรับ distributed cache/rate limit แล้ว แต่ production ยังต้องใส่ UPSTASH_REDIS_REST_URL และ TOKEN

ทำแล้วบางส่วนกดอ่านรายละเอียด

หมายความว่าอะไร

Redis เป็นกันชนก่อนถึงฐานข้อมูล ช่วยไม่ให้ฐานพังเวลาเว็บลูกค้าหลายเจ้าถล่มพร้อมกัน

ระบบทำงานยังไง

Gateway เช็ก cache และ rate limit ใน Redis ก่อน query Supabase

สถานะตอนนี้

โค้ดพร้อม fallback แต่ยังต้องใส่ env จริง

ต้องทำต่อ

สร้าง Upstash Redis และตั้ง env บน Vercel production/development

หลังบ้านลูกค้าและทีมงาน

มีหน้าหลังบ้าน tenant สำหรับตั้งค่าเว็บ จัดการ API key และกำไร โดยไม่ต้องแชร์ฐานข้อมูลเอง

Tenant admin

มีหน้า /tenant-admin สำหรับตั้งค่าโลโก้ ธีม payment notification API key และ markup

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

ลูกค้าเช่าระบบแล้วมีหลังบ้านของตัวเอง

ระบบทำงานยังไง

หลังบ้านอ่านค่าจาก tenant/client configuration ไม่ปนกับลูกค้ารายอื่น

สถานะตอนนี้

มีหน้าและ API หลักแล้ว

ต้องทำต่อ

ปรับ UX ให้เป็น onboarding wizard สำหรับเปิดเว็บใหม่ใน 1 รอบ

Client tour settings API

มี /api/tenant/client-tour-settings สำหรับเปิด/ปิดทัวร์และตั้ง markup รายทัวร์

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

เว็บลูกค้าเลือกได้ว่าจะขายทัวร์ไหน ไม่ขายทัวร์ไหน

ระบบทำงานยังไง

API บันทึกค่าเฉพาะ client แล้ว frontend/API pricing นำไปใช้ตอนแสดงผล

สถานะตอนนี้

API พร้อม

ต้องทำต่อ

ทำหน้าจอแบบตารางให้ค้นหา supplier/ประเทศ แล้ว bulk เปิดปิดหรือบวกราคาได้

Platform admin

มีหลังบ้านกลางสำหรับ tenants, suppliers, tours, bookings, settings และ supplier quality

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

ทีมเราเป็นเจ้าของ platform สามารถดูแลลูกค้าหลายเจ้าได้จากศูนย์กลาง

ระบบทำงานยังไง

admin กลางเห็นข้อมูลรวมและเข้าไปช่วยแก้ tenant แต่ละเจ้าได้ตามสิทธิ์

สถานะตอนนี้

มี route หลักแล้ว

ต้องทำต่อ

เพิ่ม audit log ว่าใครแก้ค่าอะไรของ tenant ไหน

UI จัดการทัวร์ราย client

มีหน้า /tenant-admin/tours ให้ค้นหาทัวร์ เลือกหลายรายการ เปิด/ปิด ปักหมุด และตั้ง markup ได้แล้ว

ทำแล้วบางส่วนกดอ่านรายละเอียด

หมายความว่าอะไร

ตอนขายจริง แอดมินลูกค้าต้องจัดการสินค้าเองได้ ไม่ต้องให้เราแก้ฐานข้อมูลให้

ระบบทำงานยังไง

หน้า UI เรียก client_tour_settings API และบันทึกค่าของ tenant นั้น

สถานะตอนนี้

ทำหน้าใช้งานรอบแรกแล้ว มี search, supplier filter, bulk action, เปิด/ปิด, ปักหมุด และ preview ราคาขาย

ต้องทำต่อ

เพิ่ม inline edit รายแถว, export CSV และตัวกรองคุณภาพข้อมูล เช่น รูปหาย/รอบ 0/ราคาเพี้ยน

เว็บหน้าบ้านและการขาย

มีหน้าเว็บ demo และ sales page เพื่อโชว์ระบบให้ลูกค้าดู แต่ยังต้องจัดเนื้อหา/ภาพให้เป็นแบรนด์จริง

Sales page

มีหน้า /white-label-tour-platform สำหรับขายระบบ พร้อมแพ็กเกจและภาพรวม product

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

เป็นหน้าแนะนำระบบให้ลูกค้าธุรกิจทัวร์เข้าใจว่าเราให้เช่า platform อะไร

ระบบทำงานยังไง

หน้าเล่าปัญหา โซลูชัน ฟีเจอร์ แพ็กเกจ และ call-to-action ให้ติดต่อหรือเริ่มใช้งาน

สถานะตอนนี้

มีหน้าใช้งานแล้ว

ต้องทำต่อ

เพิ่มเคสตัวอย่าง, FAQ ด้านสัญญา, และวิดีโอ demo สั้น

Tour demo

มีหน้า /tours และ /demo-tours ให้ดูตัวอย่างระบบค้นหาทัวร์

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

ลูกค้าจะเห็นภาพว่าถ้าเช่าระบบแล้วหน้าเว็บขายทัวร์จะหน้าตาและทำงานยังไง

ระบบทำงานยังไง

หน้า demo อ่านข้อมูลจากฐาน EasyTourAgent และใช้ธีมแบรนด์ใหม่ ไม่ใช่ Jongtour

สถานะตอนนี้

มีหน้าแล้ว แต่ต้องตรวจข้อมูลทัวร์จริงให้ครบและถูกก่อนโชว์ลูกค้าเต็มรูปแบบ

ต้องทำต่อ

ล็อก dataset demo ที่สะอาด และซ่อน supplier ที่ข้อมูลยังเพี้ยนจากหน้า demo

API docs

มี /developers/api-docs และเอกสาร docs/eta-api-integration-guide.md

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

เว็บลูกข่ายหรือทีม dev ลูกค้าสามารถดูวิธีเชื่อมต่อ API ได้

ระบบทำงานยังไง

เอกสารอธิบาย endpoint, authentication, rate limit, hold seat และตัวอย่าง request/response

สถานะตอนนี้

มีเอกสารเริ่มต้นแล้ว

ต้องทำต่อ

เพิ่ม OpenAPI spec และตัวอย่าง SDK สำหรับ JavaScript

หน้า checklist ระบบ

หน้านี้ใช้สรุปสถานะระบบให้ทีมงานและลูกค้าเข้าใจง่าย

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

เป็นหน้ารวมภาพจริงของระบบว่าอะไรพร้อม อะไรยังไม่พร้อม

ระบบทำงานยังไง

แยกหมวดงาน พร้อมสถานะ และกดเปิดอ่านรายละเอียดได้ในแต่ละหัวข้อ

สถานะตอนนี้

ปรับเป็นแบบกดอ่านรายละเอียดแล้ว

ต้องทำต่อ

อัปเดตทุกครั้งหลังทำ feature สำคัญหรือ deploy production

การเปิดเว็บใหม่ให้ลูกค้า

เริ่มเป็น template clone ได้แล้ว แต่ automation สำหรับสร้างโปรเจกต์ใหม่ทั้งชุดยังต้องทำเพิ่ม

Template repo

EasyTourAgent ใช้เป็นตัวอย่าง template สำหรับ clone เว็บลูกค้าได้

ทำแล้วกดอ่านรายละเอียด

หมายความว่าอะไร

ถ้ามีลูกค้าใหม่ เราสามารถใช้ระบบนี้เป็นฐานเริ่มต้นได้

ระบบทำงานยังไง

clone repo, ตั้ง env, ผูก domain, ตั้ง Supabase/Vercel แล้วปรับธีมและข้อมูลลูกค้า

สถานะตอนนี้

ใช้ทำ demo ได้แล้ว

ต้องทำต่อ

ทำ checklist เปิดเว็บใหม่ให้ทีมเซล/แอดมินกรอกตามขั้นตอน

Domain / SSL / env checklist

มีความรู้และขั้นตอนแล้ว แต่ควรทำเป็น onboarding wizard ให้กรอกในหน้าเว็บ

ทำแล้วบางส่วนกดอ่านรายละเอียด

หมายความว่าอะไร

เวลาเปิดเว็บใหม่ต้องไม่พลาดเรื่อง domain, SSL, email, payment, LINE และ Search Console

ระบบทำงานยังไง

wizard ถามข้อมูลทีละขั้น แล้วบอกว่าสิ่งไหนยังไม่ได้ตั้ง

สถานะตอนนี้

ยังเป็นเอกสารและขั้นตอน manual

ต้องทำต่อ

สร้างหน้า /tenant-admin/onboarding สำหรับกรอกและตรวจสถานะ

Vercel project automation

ยังต้องทำสคริปต์สร้าง project, ใส่ env, ผูก domain และ deploy อัตโนมัติผ่าน Vercel API

ยังต้องทำกดอ่านรายละเอียด

หมายความว่าอะไร

ลดงานซ้ำเวลาเปิดเว็บใหม่ ไม่ต้องตั้งค่าด้วยมือทุกครั้ง

ระบบทำงานยังไง

admin กรอกชื่อแบรนด์และ domain แล้วระบบเรียก Vercel API สร้าง project/ตั้งค่าให้

สถานะตอนนี้

ยังไม่ได้ทำ automation เต็มรูปแบบ

ต้องทำต่อ

ทำ script create-tenant-project และ dry-run mode ก่อนใช้งานจริง

Supabase project automation

ยังไม่ได้ทำระบบสร้าง Supabase ใหม่/รัน migration/seed admin ให้ลูกค้าแบบกดครั้งเดียว

ยังต้องทำกดอ่านรายละเอียด

หมายความว่าอะไร

ถ้าลูกค้าต้องแยกฐานข้อมูล 100% เราต้องเปิดฐานใหม่ให้เร็วและไม่ผิดขั้นตอน

ระบบทำงานยังไง

script รับ Supabase URL/key แล้วรัน migration, seed tenant, seed admin, policy และ storage bucket

สถานะตอนนี้

ยังเป็นงาน manual

ต้องทำต่อ

ทำ provision script และเอกสาร rollback ถ้ารันไม่สำเร็จ

สิ่งที่ยังค้างและควรทำต่อ

ลำดับงานต่อไปเพื่อให้ระบบขายจริงได้แน่นขึ้น

งานด้านล่างไม่ใช่ของตกแต่ง แต่เป็นชั้นกันพังสำหรับระบบ white-label ที่มีหลายเว็บเข้ามาใช้ข้อมูลและ API พร้อมกัน

ไปหน้า Supplier Quality

1. ทำ Supplier Audit ให้แข็งแรง

ต้องทำก่อนขายจริง

อ่าน

ตรวจราคา รูป PDF รอบเดินทาง ประเทศ และ supplier code ทุกเจ้า เพื่อไม่ให้ข้อมูลเพี้ยนขึ้นหน้าเว็บลูกค้า

งานที่ต้องลงมือ: ทำรายงาน error แบบแยก supplier และปุ่ม re-sync/repair

2. ใส่ Upstash Redis production

รอค่า env จริง

อ่าน

ใช้ทำ distributed cache และ rate limit สำหรับ API Gateway เมื่อมีเว็บลูกข่ายหลายเจ้ามายิงพร้อมกัน

งานที่ต้องลงมือ: เพิ่ม UPSTASH_REDIS_REST_URL และ UPSTASH_REDIS_REST_TOKEN ใน Vercel

3. ทำ CORS/domain allowlist

งาน hardening

อ่าน

บังคับให้ API key ของลูกค้าใช้ได้เฉพาะ domain ที่อนุญาต ลดความเสี่ยง key รั่วหรือโดนเว็บอื่นนำไปใช้

งานที่ต้องลงมือ: เพิ่ม client_allowed_domains และตรวจ Origin ใน Gateway

4. ทำหน้า tenant-admin/tours

ทำรอบแรกแล้ว

อ่าน

ลูกค้ากดเปิด/ปิดทัวร์ บวกราคา ปักหมุด และ preview ราคาขายเองได้จาก /tenant-admin/tours

งานที่ต้องลงมือ: ต่อยอดด้วย inline edit รายแถว, export CSV และ filter คุณภาพข้อมูล

5. ทำ onboarding wizard เปิดเว็บใหม่

งานลดเวลาทำซ้ำ

อ่าน

รวมขั้นตอน domain, SSL, env, Supabase, Vercel, email, payment และ Search Console ไว้หน้าเดียว

งานที่ต้องลงมือ: สร้าง /tenant-admin/onboarding และสถานะผ่าน/ไม่ผ่าน

6. ทำ test กัน overbooking

งานพิสูจน์ระบบ

อ่าน

จำลอง 50 เว็บไซต์กด hold ที่นั่งพร้อมกัน เพื่อดูว่า row lock และ RPC กันขายเกินได้จริง

งานที่ต้องลงมือ: เพิ่ม script load-test gateway hold/availability

7. ทำ audit log

งานควบคุมสิทธิ์

อ่าน

เก็บว่าใครแก้ค่า tenant, API key, markup, payment หรือ sync setting เมื่อไร

งานที่ต้องลงมือ: เพิ่มตาราง audit_logs และ helper บันทึกเหตุการณ์สำคัญ

วิธีอ่านสถานะ

เขียวคือใช้ได้แล้ว เหลืองคือใช้ได้แต่ต้องตั้งค่าเพิ่ม แดงคืองานที่ยังต้องทำ

ถ้าจะนำไปคุยกับลูกค้า ให้บอกว่าระบบพร้อมทำ demo และเริ่ม project แรกได้ แต่การเปิดหลายเว็บไซต์พร้อมกันต้องปิดงาน hardening ด้านข้อมูล API และ onboarding ให้ครบก่อน

ทำแล้ว

ทำแล้วบางส่วน

ยังต้องทำ

หน้าที่ควรเปิดคู่กันเวลาตรวจระบบ

ใช้หน้านี้เป็นสารบัญ แล้วเปิดหน้า monitor, API docs และ sales page เพื่อเช็กงานจริงต่อ

Monitor API Docs Sales Page Tenant Admin