MUZE·LABS

MUZE LAB-05 · TCEB MICE INTELLIGENCE & INNOVATION SUMMIT 2026

จาก One-Size-Fits-All
สู่ MICE-Made
From One-Size-Fits-All
to MICE-Made

ยกระดับ Productivity และ Interactive Experience ด้วย AIAI-Powered Productivity & Interactive Experience

Peeranat (B) Thoonsaengngam
CEO & Founder, Muze

29 กันยายน 2026 · Gaysorn29 September 2026 · Gaysorn

ติดต่อทีมงาน MuzeContact the Muze team
Prompt แบบเต็มFull prompt

  
▤ APP REQUIREMENTS
ข้อกำหนดตัวอย่างจากบทสนทนาSAMPLE REQUIREMENTS FROM THE CONVERSATION

Exhibitor Portal

40 บูธ · ผู้แสดงสินค้าและผู้จัด · ข้อกำหนดสำหรับสร้าง Web App40 booths · Exhibitors and organizers · Web app specification

01

ภาพรวม

สร้าง Web App Portal จัดการความพร้อมผู้แสดงสินค้า 40 บูธ ใช้ข้อมูลสมมติสำหรับเดโม

02

บทบาทและสิทธิ์

บทบาท: ผู้แสดงสินค้าเข้าถึงเฉพาะบูธตนเอง ผู้จัดเห็นภาพรวมและตรวจงาน ทีมที่ได้รับสิทธิ์ยืนยันไฟฟ้าและอินเทอร์เน็ต บังคับสิทธิ์ฝั่งเซิร์ฟเวอร์ ไม่ใช่แค่ซ่อนปุ่ม

03

ข้อมูลที่ต้องเก็บ

ข้อมูลแต่ละบูธ: บริษัท โลโก้ แบบบูธและเวอร์ชัน ความต้องการไฟฟ้าและอินเทอร์เน็ต ผู้รับผิดชอบ สถานะรายรายการ และประวัติการเปลี่ยนแปลง

04

Workflow และการขอแก้

Workflow: ผู้แสดงสินค้าส่งแบบ v1 → ผู้จัดตรวจ → ถ้าขอแก้ต้องระบุเหตุผล → ผู้แสดงสินค้าส่ง v2 โดยเก็บ v1 → ผู้จัดอนุมัติ ห้ามผู้ส่งอนุมัติตัวเอง

05

เงื่อนไขพร้อมติดตั้ง

บูธพร้อมติดตั้งเมื่อข้อมูลที่จำเป็นครบ แบบอนุมัติ และไฟฟ้า/อินเทอร์เน็ตยืนยันครบ หากไม่ใช้บริการใดให้ทีมผู้จัดยืนยันว่าไม่ต้องใช้ การอนุมัติแบบต้องไม่กลบงานบริการที่ยังค้าง

06

หน้าจอของแอป

หน้าจอ: portal ผู้แสดงสินค้า หน้าตรวจแบบพร้อมประวัติและความคิดเห็น dashboard ผู้จัดพร้อมกรองงานค้างและดูรายบูธ

07

เกณฑ์ตรวจรับ

เกณฑ์ตรวจรับ: เดินเส้นทางส่ง v1 ขอแก้ ส่ง v2 และอนุมัติได้ ข้อมูลเวอร์ชันไม่หาย ผู้แสดงสินค้าไม่เห็นข้อมูลข้ามบูธ และยังเห็นบริการที่ค้างหลังอนุมัติแบบ

08

การเก็บข้อมูลและขอบเขตเดโม

ระบุการบันทึกข้อมูล การอัปโหลดและตรวจไฟล์ การจัดการข้อผิดพลาด และข้อจำกัดของเดโมให้ชัด ไม่ส่งอีเมลจริง หากยังมีเรื่องไม่ตกลงให้ถามก่อนพัฒนา

01

Overview

Build a web portal for 40 exhibitors using fictional demo data.

02

Roles and permissions

Roles: exhibitors access only their own booths; organizers review work and see the overview; authorized teams confirm power and internet. Enforce authorization on the server, not merely by hiding buttons.

03

Data model

Booth data: company details, logo, versioned drawings, power/internet needs, owners, per-item statuses and change history.

04

Workflow and revisions

Workflow: submit drawing v1; organizer reviews; revision requests require a reason; exhibitor submits v2 retaining v1; organizer approves. No self-approval.

05

Readiness rules

Readiness requires complete mandatory data, approved drawings, and confirmed power/internet. Organizers confirm any service that is not needed. Drawing approval must not hide pending services.

06

App screens

Screens: exhibitor portal, drawing review with history/comments, organizer dashboard with pending-task filters and per-booth details.

07

Acceptance criteria

Acceptance: submit v1, request changes, submit v2 and approve without losing history; no cross-booth access; pending services remain visible after drawing approval.

08

Persistence and demo scope

Specify persistence, file upload/validation, error handling and demo limitations. Do not send real email. Ask about unresolved requirements before development.

Requirement → AI ช่วยเขียนโค้ด → สร้างและทดสอบ Web AppRequirements → AI-assisted coding → Build and test the web app