Loading ETA...
Loading ETA...
เช็กลิสต์ระบบ ETA
หน้านี้สรุปแบบภาษาคนทำธุรกิจว่าเรามีระบบอะไรแล้ว แพ็กเกจไหนติดตั้งได้จากหลังบ้าน และอะไรคือข้อมูลลูกค้าจริงที่ต้องเติมก่อนส่งมอบ
18
ระบบหลักที่พร้อมใช้
3
แพ็กเกจที่ติดตั้งได้
ETA ติดตั้งให้
ระดับพร้อมขาย
สรุปสั้นที่สุด
สรุปตอนนี้: ขายเป็นแพ็กเกจที่ทีม ETA ติดตั้งให้ได้แล้ว แต่ก่อนส่งมอบลูกค้าจริงต้องเติมค่าของลูกค้านั้น รัน readiness/smoke และเก็บ launch evidence ให้ครบ
ระบบหลักที่พร้อมใช้: มีโค้ด หน้าเว็บ API ฐานข้อมูล และหลังบ้านรองรับแล้ว
แพ็กเกจที่ติดตั้งได้: Starter, Pro, Enterprise เปิด/ปิดโมดูลจากหลังบ้าน ETA
ระดับพร้อมขาย: ขายเป็นแพ็กเกจที่ทีม ETA ตั้งค่า ทดสอบ และส่งมอบให้ลูกค้า
เก็บทัวร์โฮลเซลล์เป็นข้อมูลกลาง แล้วแยกค่าของแต่ละลูกค้าไว้คนละชั้น ไม่ให้ทับข้อมูลหลัก
มีตารางทัวร์กลางสำหรับเก็บแพ็กเกจทัวร์ ราคา รูป PDF และรอบเดินทาง
หมายความว่าอะไร
นี่คือคลังสินค้าหลักของระบบ เหมือนโกดังกลางที่ทุกเว็บลูกข่ายมาใช้ข้อมูลชุดเดียวกัน
ระบบทำงานยังไง
ระบบ sync ดึงข้อมูลจาก supplier/wholesale มาเก็บในฐานข้อมูล EasyTourAgent แล้วเว็บหน้าบ้านอ่านจากฐานนี้ ไม่ยิงหา supplier ทุกครั้ง
สถานะตอนนี้
มีโครงสร้างตารางและหน้า monitor แล้ว แต่คุณภาพข้อมูลบาง supplier ยังต้อง audit ให้ละเอียดกว่านี้
ต้องทำต่อ
ทำรายงานตรวจราคา รูป รอบเดินทาง และ PDF แยกตาม supplier ให้เห็นรายการผิดทันที
มี client_tour_settings สำหรับเปิด/ปิดทัวร์ ตั้งชื่อเฉพาะ ตั้งราคาเฉพาะ และบวกกำไรราย client
หมายความว่าอะไร
ลูกค้าแต่ละเว็บปรับสินค้าได้ โดยไม่ไปแก้ข้อมูลทัวร์ต้นฉบับ
ระบบทำงานยังไง
ข้อมูลหลักอยู่ที่ tours แต่ค่าของลูกค้าอยู่ใน client_tour_settings เช่น เว็บ A เปิดทัวร์นี้ เว็บ B ปิดทัวร์นี้ หรือบวกราคาไม่เท่ากัน
สถานะตอนนี้
ฐานข้อมูลและ API มีแล้ว
ต้องทำต่อ
ทำหน้า UI ให้ tenant admin กดเปิด/ปิดทัวร์และตั้ง markup ได้เองแบบไม่ต้องยิง API
มี tour_markups และ pricing rule สำหรับบวกกำไรตาม tenant, supplier, ประเทศ, ทวีป หรือรายทัวร์
หมายความว่าอะไร
แต่ละเจ้ากำหนดกำไรเองได้ เช่น บวก 500 บาททุกทัวร์ญี่ปุ่น หรือบวก 3% เฉพาะ supplier หนึ่ง
ระบบทำงานยังไง
API จะอ่านราคาต้นทุนจากทัวร์กลาง แล้วคำนวณราคาขายจาก rule ของ client ก่อนส่งไปหน้าเว็บ
สถานะตอนนี้
โครงสร้างและ route รองรับแล้ว
ต้องทำต่อ
เพิ่มหน้าตรวจราคาสุทธิ เพื่อให้แอดมินเห็นราคาก่อนและหลังบวกกำไรแบบชัดเจน
มีหน้า 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
เปิด 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 ถูกบล็อกจริงทุกตาราง
bookings มี policy อ่าน/เพิ่ม/แก้ไขเฉพาะ tenant ตัวเองแล้ว
หมายความว่าอะไร
ยอดจองของแต่ละเว็บแยกกันชัดเจน
ระบบทำงานยังไง
ทุก booking ผูก client_id/tenant_id และหลังบ้าน query ผ่านสิทธิ์ของ tenant นั้น
สถานะตอนนี้
โครงสร้างพร้อม
ต้องทำต่อ
เพิ่มหน้า export booking ราย tenant ให้ใช้ตอนลูกค้ายกเลิกบริการหรือขอย้ายข้อมูล
มีระบบออก API key, revoke, rotate และกำหนด scope แยกต่อ tenant
หมายความว่าอะไร
เว็บลูกค้าแต่ละเจ้าใช้กุญแจคนละดอก ถ้าคีย์รั่วก็ปิดเฉพาะเจ้านั้นได้
ระบบทำงานยังไง
API Gateway อ่าน key จาก request แล้วผูกกับ client_id, scope และ rate limit
สถานะตอนนี้
มี route ออกและจัดการ key แล้ว
ต้องทำต่อ
เพิ่มหน้าแสดงประวัติการใช้ key และแจ้งเตือน key ใช้ผิดปกติ
ยังต้องบังคับ origin/domain ต่อ API key ให้ชัด เพื่อกันเว็บอื่นเอา key ไปยิงผิดที่
หมายความว่าอะไร
คีย์ของลูกค้าควรใช้ได้เฉพาะ domain ที่อนุญาต เช่น customer.com เท่านั้น
ระบบทำงานยังไง
Gateway ตรวจ Origin/Referer เทียบกับ domain allowlist ของ client ก่อนตอบข้อมูล
สถานะตอนนี้
ยังเป็นงานค้างด้าน hardening
ต้องทำต่อ
เพิ่มตาราง client_allowed_domains และ middleware ตรวจ origin ก่อนเข้า API Gateway
ช่องทาง API สำหรับเว็บลูกข่ายยิงมาดูทัวร์ เช็กที่นั่ง และ hold ที่นั่ง โดยไม่ให้ฐานข้อมูลล้มพัง
มี GET /api/gateway/tours/{id}/availability รันแบบ Node.js runtime พร้อม cache header และ rate limit
หมายความว่าอะไร
เว็บลูกค้ากดเช็กที่นั่งได้เร็ว โดยไม่ต้อง query หนักทุกครั้ง
ระบบทำงานยังไง
API ตอบข้อมูลที่นั่งว่างจากฐานข้อมูลกลาง พร้อม cache ระยะสั้นเพื่อลดโหลด
สถานะตอนนี้
route พร้อมใช้งานแล้ว
ต้องทำต่อ
เพิ่ม distributed cache ด้วย Upstash Redis ใน production
มี POST /api/gateway/tours/{id}/hold เรียก RPC ล็อกแถวด้วย database transaction กัน overbooking
หมายความว่าอะไร
เมื่อหลายเว็บกดจองพร้อมกัน ระบบต้องกันไม่ให้ขายเกินจำนวนที่นั่ง
ระบบทำงานยังไง
Postgres RPC ใช้ row-level locking ตอนสร้าง hold seat แล้วปล่อยที่นั่งเมื่อหมดอายุ
สถานะตอนนี้
มี route และ RPC หลักแล้ว
ต้องทำต่อ
ทำ test concurrency จำลองเว็บ 50 เจ้ากดพร้อมกัน
มี pg_cron เคลียร์ hold หมดอายุทุก 1 นาที และย้ายข้อมูลเก่าเข้า log/archive
หมายความว่าอะไร
ถ้าลูกค้ากดจองค้างไว้แล้วไม่จ่าย ที่นั่งต้องคืนกลับมาอัตโนมัติ
ระบบทำงานยังไง
cron ตรวจ expired_at แล้วเปลี่ยนสถานะ/ย้าย log ไม่ให้ตารางหลักบวม
สถานะตอนนี้
migration รองรับแล้ว
ต้องทำต่อ
เพิ่มหน้า monitor จำนวน hold ค้าง, hold หมดอายุ และอัตราการจ่ายสำเร็จ
โค้ดรองรับ 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 สำหรับตั้งค่าโลโก้ ธีม payment notification API key และ markup
หมายความว่าอะไร
ลูกค้าเช่าระบบแล้วมีหลังบ้านของตัวเอง
ระบบทำงานยังไง
หลังบ้านอ่านค่าจาก tenant/client configuration ไม่ปนกับลูกค้ารายอื่น
สถานะตอนนี้
มีหน้าและ API หลักแล้ว
ต้องทำต่อ
ปรับ UX ให้เป็น onboarding wizard สำหรับเปิดเว็บใหม่ใน 1 รอบ
มี /api/tenant/client-tour-settings สำหรับเปิด/ปิดทัวร์และตั้ง markup รายทัวร์
หมายความว่าอะไร
เว็บลูกค้าเลือกได้ว่าจะขายทัวร์ไหน ไม่ขายทัวร์ไหน
ระบบทำงานยังไง
API บันทึกค่าเฉพาะ client แล้ว frontend/API pricing นำไปใช้ตอนแสดงผล
สถานะตอนนี้
API พร้อม
ต้องทำต่อ
ทำหน้าจอแบบตารางให้ค้นหา supplier/ประเทศ แล้ว bulk เปิดปิดหรือบวกราคาได้
มีหลังบ้านกลางสำหรับ tenants, suppliers, tours, bookings, settings และ supplier quality
หมายความว่าอะไร
ทีมเราเป็นเจ้าของ platform สามารถดูแลลูกค้าหลายเจ้าได้จากศูนย์กลาง
ระบบทำงานยังไง
admin กลางเห็นข้อมูลรวมและเข้าไปช่วยแก้ tenant แต่ละเจ้าได้ตามสิทธิ์
สถานะตอนนี้
มี route หลักแล้ว
ต้องทำต่อ
เพิ่ม audit log ว่าใครแก้ค่าอะไรของ tenant ไหน
มีหน้า /tenant-admin/tours ให้ค้นหาทัวร์ เลือกหลายรายการ เปิด/ปิด ปักหมุด และตั้ง markup ได้แล้ว
หมายความว่าอะไร
ตอนขายจริง แอดมินลูกค้าต้องจัดการสินค้าเองได้ ไม่ต้องให้เราแก้ฐานข้อมูลให้
ระบบทำงานยังไง
หน้า UI เรียก client_tour_settings API และบันทึกค่าของ tenant นั้น
สถานะตอนนี้
ทำหน้าใช้งานรอบแรกแล้ว มี search, supplier filter, bulk action, เปิด/ปิด, ปักหมุด และ preview ราคาขาย
ต้องทำต่อ
เพิ่ม inline edit รายแถว, export CSV และตัวกรองคุณภาพข้อมูล เช่น รูปหาย/รอบ 0/ราคาเพี้ยน
มีหน้าเว็บ demo และ sales page เพื่อโชว์ระบบให้ลูกค้าดู แต่ยังต้องจัดเนื้อหา/ภาพให้เป็นแบรนด์จริง
มีหน้า /white-label-tour-platform สำหรับขายระบบ พร้อมแพ็กเกจและภาพรวม product
หมายความว่าอะไร
เป็นหน้าแนะนำระบบให้ลูกค้าธุรกิจทัวร์เข้าใจว่าเราให้เช่า platform อะไร
ระบบทำงานยังไง
หน้าเล่าปัญหา โซลูชัน ฟีเจอร์ แพ็กเกจ และ call-to-action ให้ติดต่อหรือเริ่มใช้งาน
สถานะตอนนี้
มีหน้าใช้งานแล้ว
ต้องทำต่อ
เพิ่มเคสตัวอย่าง, FAQ ด้านสัญญา, และวิดีโอ demo สั้น
มีหน้า /tours และ /demo-tours ให้ดูตัวอย่างระบบค้นหาทัวร์
หมายความว่าอะไร
ลูกค้าจะเห็นภาพว่าถ้าเช่าระบบแล้วหน้าเว็บขายทัวร์จะหน้าตาและทำงานยังไง
ระบบทำงานยังไง
หน้า demo อ่านข้อมูลจากฐาน EasyTourAgent และใช้ธีมแบรนด์ใหม่ ไม่ใช่ EasyTourAgent
สถานะตอนนี้
มีหน้าแล้ว แต่ต้องตรวจข้อมูลทัวร์จริงให้ครบและถูกก่อนโชว์ลูกค้าเต็มรูปแบบ
ต้องทำต่อ
ล็อก dataset demo ที่สะอาด และซ่อน supplier ที่ข้อมูลยังเพี้ยนจากหน้า demo
มี /developers/api-docs และเอกสาร docs/eta-api-integration-guide.md
หมายความว่าอะไร
เว็บลูกข่ายหรือทีม dev ลูกค้าสามารถดูวิธีเชื่อมต่อ API ได้
ระบบทำงานยังไง
เอกสารอธิบาย endpoint, authentication, rate limit, hold seat และตัวอย่าง request/response
สถานะตอนนี้
มีเอกสารเริ่มต้นแล้ว
ต้องทำต่อ
เพิ่ม OpenAPI spec และตัวอย่าง SDK สำหรับ JavaScript
หน้านี้ใช้สรุปสถานะระบบให้ทีมงานและลูกค้าเข้าใจง่าย
หมายความว่าอะไร
เป็นหน้ารวมภาพจริงของระบบว่าอะไรพร้อม อะไรยังไม่พร้อม
ระบบทำงานยังไง
แยกหมวดงาน พร้อมสถานะ และกดเปิดอ่านรายละเอียดได้ในแต่ละหัวข้อ
สถานะตอนนี้
ปรับเป็นแบบกดอ่านรายละเอียดแล้ว
ต้องทำต่อ
อัปเดตทุกครั้งหลังทำ feature สำคัญหรือ deploy production
ลูกค้าเลือกแพ็กเกจ แล้วทีม ETA เปิด tenant ตั้งค่าโมดูล ตรวจความพร้อม และส่งมอบโดยไม่ต้องเขียนโค้ดใหม่ต่อราย
มี Starter, Pro และ Enterprise package manifest พร้อม service สำหรับ apply package เข้า tenant
หมายความว่าอะไร
ขายแพ็กเกจแล้วทีม ETA กดติดตั้งโมดูลที่ถูกต้องได้จากหลังบ้าน
ระบบทำงานยังไง
ระบบเขียน tenant plan, subscription limits, tenant modules, launch gates, health row และ audit log ผ่าน installer เดียวกัน
สถานะตอนนี้
มี package manifest, installer service, admin action, readiness, dry-run smoke และ launch evidence export แล้ว
ต้องทำต่อ
เพิ่ม browser E2E สำหรับกดเปลี่ยน Starter -> Pro -> Enterprise จากหน้าจริง
มีช่องสถานะ Bank, Stripe, Email, LINE, Domain, API, AI และ Supplier โดยไม่แสดง secret จริง
หมายความว่าอะไร
ทีมติดตั้งเห็นทันทีว่าแพ็กเกจนี้ยังขาดอะไร โดยไม่ต้องเปิดไฟล์ env หรือดู secret
ระบบทำงานยังไง
หน้า /admin/tenants แสดงสถานะตั้งค่าที่ต้องมีตามโมดูลและแพ็กเกจที่เลือก
สถานะตอนนี้
มี credential-status slots และ package-aware readiness แล้ว
ต้องทำต่อ
ทำ handover summary แบบ PDF/HTML ให้ฝ่ายขายส่งลูกค้าได้
ขั้นตอนติดตั้งจริงต้องเติมค่าของลูกค้าแต่ละราย เช่น domain, Supabase, payment, email, LINE และ supplier
หมายความว่าอะไร
ระบบไม่ควรใส่ค่าจริงไว้ในโค้ด ลูกค้าแต่ละรายต้องมีค่าของตัวเองตอนติดตั้ง
ระบบทำงานยังไง
ETA operator เติมค่าลง tenant settings/env ของลูกค้าจริง แล้ว readiness บอกว่าส่วนไหนผ่านหรือยังขาด
สถานะตอนนี้
มี runbook, env template, secret hygiene และ payment-channel readiness แล้ว
ต้องทำต่อ
ทำ onboarding wizard สำหรับ operator ให้กรอกข้อมูลลูกค้าทีละขั้นและบันทึก evidence
ยังควรทำสคริปต์/วิซาร์ดช่วยสร้างหรือตรวจ Vercel, Supabase, env, domain และ migration สำหรับลูกค้าใหม่
หมายความว่าอะไร
ถ้าลูกค้าต้องแยกฐานข้อมูล 100% เราต้องเปิดฐานใหม่ให้เร็วและไม่ผิดขั้นตอน
ระบบทำงานยังไง
operator ใส่ข้อมูลลูกค้า แล้วระบบตรวจหรือเรียก API เพื่อเตรียม project, env, domain, migration, seed tenant และ admin user
สถานะตอนนี้
ยังเป็น runbook + script บางส่วน ไม่ใช่ one-click เต็มรูปแบบ
ต้องทำต่อ
ทำ provision wizard พร้อม dry-run, rollback และ evidence log
งานด้านล่างไม่ใช่ blocker ของการขายแบบ ETA ติดตั้งให้ทั้งหมด แต่เป็นงานที่ทำให้การส่งมอบลูกค้าจริงและการขายหลายเจ้าซ้ำๆ แข็งแรงขึ้น
ต้องทำก่อนส่งมอบลูกค้าจริง
ตรวจราคา รูป PDF รอบเดินทาง ประเทศ และ supplier code ทุกเจ้า เพื่อไม่ให้ข้อมูลเพี้ยนขึ้นหน้าเว็บลูกค้า
งานที่ต้องลงมือ: ทำรายงาน error แบบแยก supplier และปุ่ม re-sync/repair
งาน scale สำหรับ API/widget
ใช้ทำ distributed cache และ rate limit สำหรับ API Gateway เมื่อมีเว็บลูกข่ายหลายเจ้ามายิงพร้อมกัน
งานที่ต้องลงมือ: เพิ่ม UPSTASH_REDIS_REST_URL และ UPSTASH_REDIS_REST_TOKEN ใน Vercel
งาน hardening
บังคับให้ API key ของลูกค้าใช้ได้เฉพาะ domain ที่อนุญาต ลดความเสี่ยง key รั่วหรือโดนเว็บอื่นนำไปใช้
งานที่ต้องลงมือ: เพิ่ม client_allowed_domains และตรวจ Origin ใน Gateway
งานพิสูจน์ install-ready
จำลอง operator กด Starter -> Pro -> Enterprise จาก /admin/tenants แล้วตรวจว่าโมดูลเปิด/ปิดและ route guard เปลี่ยนถูกจริง
งานที่ต้องลงมือ: เพิ่ม authenticated Playwright/Chrome test เมื่อมี staging admin user
งานลดเวลาทำซ้ำ
รวมขั้นตอน domain, SSL, env, Supabase, Vercel, email, payment และ Search Console ไว้หน้าเดียว
งานที่ต้องลงมือ: สร้าง /tenant-admin/onboarding และสถานะผ่าน/ไม่ผ่าน
งานพิสูจน์ระบบ
จำลอง 50 เว็บไซต์กด hold ที่นั่งพร้อมกัน เพื่อดูว่า row lock และ RPC กันขายเกินได้จริง
งานที่ต้องลงมือ: เพิ่ม script load-test gateway hold/availability
งานควบคุมสิทธิ์
เก็บว่าใครแก้ค่า tenant, API key, markup, payment หรือ sync setting เมื่อไร
งานที่ต้องลงมือ: เพิ่มตาราง audit_logs และ helper บันทึกเหตุการณ์สำคัญ
ถ้าจะนำไปคุยกับลูกค้า ให้บอกว่าระบบขายเป็นแพ็กเกจที่ทีม ETA ติดตั้ง ตั้งค่า ทดสอบ และส่งมอบให้ ไม่ใช่ให้ลูกค้าเอา API key ไปเชื่อมเอง
ใช้หน้านี้เป็นสารบัญ แล้วเปิดหน้าเดโม คู่มือเชื่อมต่อ และหน้าไวท์เลเบลเพื่อเช็กงานจริงต่อ