ĐẶC TẢ SẢN PHẨM KHẢ DỤNG TỐI THIỂU (MVP) - AI BOOTH

Mã tài liệu:	EZD-MVP-SPEC	Phiên bản:	1.1
Ngày hiệu lực:	05/09/2025	Người soạn:	Stephen
Người phê duyệt:	Stephen	Trang:	1/X

Executive Summary

Tài liệu này mô tả kế hoạch xây dựng và triển khai Sản phẩm Khả dụng Tối thiểu (MVP) cho dự án EZD AI Booth, một hệ thống kiosk thông minh nhằm thay đổi trải nghiệm tại các không gian công cộng.

Vấn đề: Các đối tác doanh nghiệp (như TTTM) đang đối mặt với hai vấn đề lớn: thiếu dữ liệu sâu về hành vi và nhu cầu của khách hàng tại điểm bán, đồng thời mang lại một trải nghiệm khách hàng nhàm chán. Về phía người dùng cuối, họ thường cảm thấy khó khăn và mất thời gian khi tìm kiếm thông tin.
Giải pháp (MVP): Chúng ta sẽ triển khai một AI Booth tại một địa điểm duy nhất của đối tác tiên phong. Booth này sử dụng AI hội thoại (nền tảng Gemini) và Avatar 3D thân thiện để trả lời các câu hỏi của người dùng trong một phạm vi giới hạn. Đổi lại, hệ thống sẽ thu thập dữ liệu tương tác ẩn danh, cung cấp cho đối tác những insight ban đầu thông qua một dashboard đơn giản, qua đó "chào hàng" cho mô hình kinh doanh cốt lõi của chúng ta.
Mục tiêu Chính: Mục tiêu của MVP không phải là doanh thu, mà là để giảm thiểu rủi ro cho dự án bằng cách kiểm chứng 3 giả định lớn nhất: (1) Đối tác có thực sự thấy giá trị từ dữ liệu không? (2) Người dùng có sẵn lòng tương tác với booth không? và (3) Giải pháp kỹ thuật có khả thi không?. Thành công cuối cùng được đo lường bằng việc ký được Thư bày tỏ ý định (LOI) từ đối tác tiên phong.

1. Tổng quan

1.1. Mục tiêu của MVP

MVP này được xây dựng không phải để bán, mà để kiểm chứng các giả định rủi ro nhất của dự án với chi phí và thời gian tối thiểu. Các mục tiêu chính bao gồm: * Chứng minh Kỹ thuật: Xác thực khả năng xây dựng một hệ thống AI hội thoại và Avatar 3D hoạt động ổn định trong môi trường thực tế. * Chứng minh Giá trị cho Người dùng: Đo lường mức độ thu hút và sự hữu ích của booth đối với người dùng cuối. Họ có thực sự sử dụng nó không? * Chứng minh Giá trị cho Đối tác: Thu thập dữ liệu tương tác ban đầu và chứng minh tiềm năng insight cho đối tác, từ đó xác thực mô hình kinh doanh "dữ liệu đổi lấy chi phí thấp".

1.2. Phạm vi

MVP sẽ tập trung vào trải nghiệm cốt lõi, triển khai tại một địa điểm duy nhất với phạm vi kiến thức cực kỳ giới hạn. Tất cả các tính năng không phục vụ trực tiếp cho 3 mục tiêu trên sẽ được loại bỏ.

1.3. Giả định cần kiểm chứng (Hypotheses to Validate)

MVP này được thiết kế để kiểm tra 3 giả định cốt lõi. Mức độ thành công của dự án phụ thuộc trực tiếp vào việc các giả định này có đúng hay không. Chúng được xếp theo mức độ rủi ro từ cao đến thấp:

1.3.1. Giả định về Giá trị Kinh doanh (The Business Value Hypothesis) - RỦI RO CAO NHẤT

Giả định: "Chúng tôi tin rằng các đối tác (Tenants) sẵn sàng cho phép chúng ta triển khai booth và thu thập dữ liệu tương tác của khách hàng, vì những insight thu được từ dữ liệu đó sẽ mang lại giá trị kinh doanh lớn hơn chi phí họ bỏ ra (nếu có) và những lo ngại về bảo mật."
Tại sao rủi ro: Đây là nền tảng của toàn bộ mô hình kinh doanh. Nếu đối tác không thấy giá trị từ dữ liệu hoặc quá lo ngại về việc chia sẻ dữ liệu, mô hình của chúng ta sẽ sụp đổ.
Cách MVP kiểm chứng: Thông qua phản hồi trực tiếp của "Đối tác Tiên phong" sau khi họ xem dashboard dữ liệu, và quan trọng nhất là việc họ có đồng ý ký Thư bày tỏ ý định (LOI) hay không.

1.3.2. Giả định về Giá trị cho Người dùng (The User Value Hypothesis) - RỦI RO TRUNG BÌNH

Giả định: "Chúng tôi tin rằng người dùng cuối sẽ chủ động tương tác với AI Booth vì nó cung cấp một phương thức tìm kiếm thông tin nhanh chóng, tiện lợi và thú vị hơn so với các phương pháp truyền thống (hỏi nhân viên, tự tìm trên điện thoại)."
Tại sao rủi ro: Có khả năng người dùng sẽ cảm thấy ngại ngùng khi nói chuyện với máy ở nơi công cộng, hoặc họ thấy booth chỉ là một thứ "trang trí" và lờ đi.
Cách MVP kiểm chứng: Thông qua chỉ số "Số lượt tương tác trung bình mỗi ngày". Nếu con số này đạt hoặc vượt mục tiêu (>50 lượt/ngày), giả định này được xác thực.

1.3.3. Giả định về Tính khả thi Kỹ thuật (The Technical Feasibility Hypothesis) - RỦI RO THẤP

Giả định: "Chúng tôi tin rằng chúng ta có thể xây dựng một hệ thống tích hợp giữa phần cứng, phần mềm, AI (Gemini) và Avatar 3D để tạo ra một trải nghiệm hội thoại mượt mà (<3 giây độ trễ) và ổn định (>95% uptime) trong môi trường thực tế của một TTTM."
Tại sao rủi ro thấp: Các công nghệ thành phần đều đã tồn tại. Thách thức nằm ở việc tích hợp chúng một cách trơn tru, nhưng đây là vấn đề có thể giải quyết được bằng kỹ thuật.
Cách MVP kiểm chứng: Thông qua các chỉ số về hiệu năng và uptime được theo dõi liên tục trong suốt quá trình thử nghiệm.

2. Đối tác & Môi trường Triển khai

Đối tác: Cần một "Đối tác Tiên phong" (Pioneer Partner) - ví dụ: một Trung tâm Thương mại (TTTM) - sẵn sàng cho phép thử nghiệm trong 1-2 tháng.
Yêu cầu tại địa điểm:
- Không gian đặt booth khoảng 2m².
- Nguồn điện ổn định.
- Kết nối Internet (Wi-Fi hoặc có dây) với băng thông tối thiểu.

2.1. Bảng Phạm vi MVP (Scope In / Scope Out)

Để đảm bảo sự tập trung và tốc độ, ranh giới của MVP được định nghĩa rõ ràng như sau. Mọi tính năng, yêu cầu đều phải được đối chiếu với bảng này trước khi đưa vào thiết kế hoặc phát triển.

Hạng mục	✅ Trong Phạm vi (In-Scope)	❌ Ngoài Phạm vi (Out-of-Scope)
Chức năng Cốt lõi	Hỗ trợ hỏi-đáp bằng giọng nói về vị trí và khuyến mãi trong một phạm vi kiến thức hẹp.	Mọi hình thức giao dịch (đặt hàng, thanh toán), đặt lịch hẹn, gọi điện thoại, hay các tác vụ phức tạp khác.
AI & Học máy	Sử dụng Gemini API cho NLU. Câu trả lời dựa trên cơ sở kiến thức cố định (static knowledge base).	Khả năng tự học theo thời gian thực (real-time machine learning), tự động cập nhật kiến thức từ Internet.
Avatar & Tương tác	Avatar 3D với 4 biểu cảm cơ bản và các cử chỉ đơn giản. Tương tác chủ động khi người dùng đến gần.	Lip-sync (đồng bộ môi) hoàn hảo, nhận diện cảm xúc người dùng, các cử chỉ và biểu cảm phức tạp.
Giao diện (UI)	Giao diện phụ trợ cho giọng nói, hiển thị thông tin đơn giản (bản đồ 2D, text). Có nút phản hồi 👍/👎.	Các giao diện tương tác phức tạp (bàn phím ảo, bộ lọc, form nhập liệu), cá nhân hóa giao diện người dùng.
Admin Webapp	Một Admin Webapp MVP bao gồm: 1. Dashboard: Hiển thị log dữ liệu thô, bộ đếm tương tác, và 2 biểu đồ cơ bản (tương tác theo ngày, top câu hỏi). 2. CMS Tối thiểu: Cho phép quản lý nội dung động (Khuyến mãi, FAQ, Branding, Avatar). 3. RBAC Động: Hỗ trợ một hệ thống phân quyền động, với 2 vai trò ban đầu là `SUPER_ADMIN` và `TENANT_ADMIN`.	Các báo cáo phân tích sâu và phức tạp (ví dụ: biểu đồ có khả năng drill-down, bộ lọc tùy chỉnh, so sánh theo khoảng thời gian). Giao diện cho phép Tenant tự tạo ra các vai trò và quyền hạn mới.
Phần cứng	Một kiosk prototype ưu tiên chức năng, sử dụng các linh kiện thương mại có sẵn.	Mọi thiết kế công nghiệp hoàn thiện, vật liệu cao cấp, hay các cảm biến ngoại vi phức tạp (máy in, NFC...).
Vận hành	Giám sát tình trạng (uptime) và cập nhật phần mềm từ xa (OTA).	Hệ thống quản lý đội ngũ kỹ thuật hiện trường, quản lý kho linh kiện, hay các quy trình bảo trì phức tạp.

3. Đặc tả Chi tiết Sản phẩm (v0.1)

3.1. Phần cứng (The Booth)

Mục tiêu: Ưu tiên chức năng, không phải hình thức.
Bao gồm:
- Một kiosk prototype dạng đứng, đơn giản.
- Màn hình TV thương mại, đặt dọc.
- Máy tính mini (PC Mini) đủ mạnh để render 3D và chạy AI.
- Webcam chất lượng cao để nhận diện có người tiến lại gần.
- Microphone định hướng (array microphone) để thu âm tốt trong môi trường ồn ào.
Loại bỏ:
- Thiết kế công nghiệp hoàn thiện, vật liệu đắt tiền.
- Hệ thống đèn LED, cảm biến phức tạp khác.

3.2. AI Core (The Brain)

Mục tiêu: Đạt độ chính xác >90% trong phạm vi kiến thức hẹp.
Phạm vi kiến thức: Giới hạn nghiêm ngặt tại địa điểm triển khai.
- Ví dụ: Nếu đặt tại TTTM A, kiến thức chỉ bao gồm:
  - Vị trí các cửa hàng tại Tầng 1.
  - Các chương trình khuyến mãi đang diễn ra tại Tầng 1.
  - Vị trí nhà vệ sinh, thang máy tại Tầng 1.
Khả năng xử lý:
- Nhận diện câu hỏi và trả lời chính xác trong phạm vi đã định.
- Xử lý các câu hỏi ngoài phạm vi một cách lịch sự (xem mục 4.2).

Nền tảng: Áp dụng mô hình Hybrid, sử dụng Gemini API cho NLU và Knowledge Base nội bộ để trả lời.

3.3. 3D Avatar (The Face)

Mục tiêu: Tạo ra một giao diện thân thiện, mượt mà.
Bao gồm:
- Một mô hình nhân vật 3D dạng stylized (hoạt hình), không cần tả thực.
- 04 biểu cảm cơ bản: Chào/Trạng thái chờ, Lắng nghe, Đang nói, Cảm ơn.
- Các cử chỉ đơn giản: Gật đầu, vẫy tay chào.
Loại bỏ:
- Cử chỉ phức tạp, lip-sync hoàn hảo, biểu cảm đa dạng.

3.4. Tenant Dashboard

Mục tiêu: Cung cấp bằng chứng về dữ liệu thu thập được cho đối tác.
Bao gồm:
- Một trang web đơn giản, yêu cầu đăng nhập.
- Hiển thị log dữ liệu thô: danh sách các câu hỏi đã được hỏi, thời gian, và feedback (nếu có).
- Một bộ đếm tổng số lượt tương tác trong ngày.
Loại bỏ:
- Các biểu đồ phân tích, báo cáo trực quan hóa phức tạp.

3.4.1. Mockup Giao diện Tenant Dashboard

Dưới đây là một bản mockup đơn giản (wireframe) để minh họa giao diện mà đối tác ("Anh Phong") sẽ sử dụng. Mục tiêu của giao diện này là sự đơn giản, tập trung vào việc cung cấp dữ liệu thô một cách minh bạch nhất có thể.

Mockup Giao diện Tenant Dashboard

Bản mockup này minh họa giao diện đơn giản mà đối tác sẽ sử dụng, tập trung vào việc cung cấp dữ liệu thô một cách minh bạch nhất có thể.

EZD AI Booth Dashboard	💡 Kiosk: Sảnh chính, Saigon Centre	Chào, Anh Phong
Thời gian	Chi tiết Tương tác
14:32	User: `em ơi uniqlo ở đâu?` AI: `Dạ, cửa hàng Uniqlo ở ngay tầng 1 ạ.`	👍
14:30	User: `khuyến mãi hôm nay có gì hot?` AI: `Dạ, Adidas đang giảm giá 30% cho các dòng sản phẩm...`	👍
14:28	User: `nhà vệ sinh ở đâu em?` AI: `Nhà vệ sinh gần nhất ở cuối hành lang, bên tay trái ạ.`	👎
14:25	User: `bán đồ ăn cho chó ở đâu?` AI: `Xin lỗi, thông tin này em chưa được cập nhật ạ.`
---	---
Tổng kết hôm nay (05/09/2025)	Tổng lượt tương tác: 152 • Tỷ lệ hài lòng (👍): 85%

Những cải tiến trong phiên bản này:

Hiển thị dạng hội thoại: Mỗi tương tác được nhóm lại thành một khối hội thoại giữa User và AI, giúp dễ theo dõi hơn.
Phản hồi rõ ràng: Biểu tượng 👍/👎 được đặt ngay cuối câu trả lời của AI, làm rõ phản hồi đó dành cho câu trả lời nào.
Gọn gàng: Toàn bộ thông tin được gói gọn trong 2 cột chính, giúp giao diện thoáng và tập trung vào nội dung.
Thống nhất: Phần tổng kết được giữ ở cuối cùng như một dòng tóm tắt, duy trì tính thống nhất của toàn bảng.

3.5. Sơ đồ Kiến trúc Kỹ thuật (Technical Architecture Diagram)

Sơ đồ dưới đây mô tả kiến trúc hệ thống cho MVP ở mức độ cao, thể hiện rõ các thành phần chính và luồng dữ liệu theo triết lý Module hóa và API-First.

graph TD
    subgraph Người dùng
        A[Người dùng Cuối]
        B[Đối tác - Tenant]
    end

    subgraph Thiết bị tại Hiện trường
        C[Booth App @ Kiosk]
    end

    subgraph EZD Cloud Platform
        D{API Gateway}
        E[AI Core Service]
        F[Backend Service]
        G[(Knowledge Base)]
    end

    subgraph Dịch vụ Bên thứ ba
        H[Google Gemini API]
    end

    subgraph Giao diện Web
        I[Tenant Dashboard]
    end

    A -- 1. Tương tác giọng nói --> C
    C -- 2. Gửi yêu cầu (API) --> D
    D -- 3. Điều hướng --> E
    E -- 4. Gửi câu hỏi NLU --> H
    H -- 5. Trả về cấu trúc JSON --> E
    E -- 6. Truy vấn kiến thức --> G
    G -- 7. Trả về câu trả lời --> E
    E -- 8. Gửi phản hồi --> D
    D -- 9. Trả kết quả --> C
    C -- 10. Phản hồi người dùng --> A

    B -- 11. Truy cập --> I
    I -- 12. Yêu cầu dữ liệu (API) --> D
    D -- 13. Điều hướng --> F
    F -- 14. Truy vấn log --> G
    G -- 15. Trả về log --> F
    F -- 16. Gửi dữ liệu --> D
    D -- 17. Trả kết quả --> I

Luồng Xử lý một Yêu cầu của Người dùng cuối (1-10):

Tương tác: Người dùng cuối ("Chị An") nói chuyện với AI Booth.
Gửi yêu cầu: Booth App trên kiosk ghi nhận âm thanh, chuyển thành văn bản và gửi một yêu cầu API đến API Gateway trên nền tảng đám mây của chúng ta.
Điều hướng: API Gateway xác thực và chuyển tiếp yêu cầu đến AI Core Service.
Phân tích NLU: AI Core Service gửi văn bản câu hỏi đến Google Gemini API để phân tích và rút trích intent (ý định) và entity (thực thể).
Nhận kết quả NLU: Gemini API trả về một cấu trúc dữ liệu JSON.
Truy vấn kiến thức: AI Core Service sử dụng cấu trúc JSON này để truy vấn vào Knowledge Base (cơ sở dữ liệu nội bộ chứa thông tin về TTTM).
Lấy câu trả lời: Knowledge Base trả về câu trả lời chính xác đã được định sẵn.
Soạn phản hồi: AI Core Service soạn thảo câu trả lời cuối cùng và gửi ngược lại qua API Gateway.
Nhận kết quả: Booth App nhận được câu trả lời.
Phản hồi: Avatar 3D sẽ đọc câu trả lời và hiển thị thông tin hỗ trợ trên màn hình cho người dùng.

Luồng Truy cập của Đối tác (11-17):

Truy cập: Đối tác ("Anh Phong") đăng nhập vào Tenant Dashboard từ trình duyệt web.
Yêu cầu dữ liệu: Dashboard gửi yêu cầu lấy dữ liệu log tương tác đến API Gateway.
Điều hướng: API Gateway chuyển yêu cầu đến Backend Service.
Truy vấn log: Backend Service truy vấn dữ liệu log (đã được ẩn danh) từ Knowledge Base hoặc một cơ sở dữ liệu log riêng.
Lấy log: Cơ sở dữ liệu trả về thông tin log.
Gửi dữ liệu: Backend Service xử lý và gửi dữ liệu ngược lại qua API Gateway.
Hiển thị: Tenant Dashboard nhận dữ liệu và hiển thị cho đối tác.

Sơ đồ này khẳng định kiến trúc của chúng ta hoàn toàn tách biệt: Front-end (Booth App, Dashboard) và Back-end (Các services trên cloud) giao tiếp hoàn toàn qua API, giúp việc phát triển và nâng cấp độc lập trở nên dễ dàng.

4. Trải nghiệm Người dùng (UX)

4.1. Luồng Tương tác Chính

Thu hút: Người dùng tiến lại gần, avatar chuyển từ trạng thái chờ sang vẫy tay chào.
Bắt đầu: Người dùng bắt đầu hỏi bằng giọng nói.
Lắng nghe: Avatar thể hiện trạng thái đang lắng nghe.
Xử lý & Trả lời: Avatar trả lời câu hỏi bằng giọng nói, đồng thời có thể hiển thị thông tin hỗ trợ trên màn hình (ví dụ: bản đồ chỉ đường đơn giản).
Thu thập Feedback: Sau khi trả lời, trên màn hình hiển thị 2 nút 👍/👎.
Kết thúc: Avatar cảm ơn và quay về trạng thái chờ.

4.2. Kịch bản Thất bại

Khi AI không hiểu hoặc không có câu trả lời, avatar sẽ nói: "Xin lỗi, tôi chưa được cập nhật thông tin này. Bạn có thể hỏi tôi về vị trí các cửa hàng hoặc khuyến mãi tại Tầng 1 nhé."

4.3. Cơ chế Thu thập Feedback

Nút 👍/👎 trên màn hình cảm ứng. Dữ liệu này được ghi lại cùng với câu hỏi tương ứng.

4.4. Luồng Onboarding

Khi cảm biến nhận diện có người đứng trước booth trong >3 giây, avatar sẽ chủ động vẫy tay và nói: "Xin chào, tôi có thể giúp bạn tìm đường hoặc các thông tin khuyến mãi tại đây. Bạn cần tìm gì ạ?"

4.5. Kịch bản Hội thoại Mẫu (Sample Conversation Script)

Bảng dưới đây mô tả một kịch bản hội thoại lý tưởng, thể hiện cá tính thân thiện, hữu ích và chuyên nghiệp của AI Booth. Giọng điệu (Tone of Voice) cần nhất quán theo mẫu này.

Giai đoạn	Hành động của Avatar	Lời thoại của AI	Ghi chú
Thu hút (Onboarding)	Đứng ở trạng thái chờ, khi người dùng đến gần (>3s) thì chủ động vẫy tay chào.	"Xin chào, em là trợ lý ảo của Saigon Centre. Em có thể giúp anh/chị tìm đường hoặc các thông tin khuyến mãi tại đây ạ."	Chủ động, lịch sự và giới thiệu rõ vai trò. Sử dụng xưng hô "em - anh/chị".
Hỏi & Lắng nghe	Chuyển sang trạng thái lắng nghe (hơi nghiêng đầu, có hiệu ứng sóng âm nhẹ).	(Im lặng, lắng nghe)	Thể hiện sự tập trung, không ngắt lời người dùng.
Xác nhận & Xử lý	Gật đầu nhẹ. Chuyển sang trạng thái suy nghĩ.	"Dạ, để em kiểm tra thông tin về cửa hàng Uniqlo ngay ạ."	Xác nhận lại yêu cầu để người dùng biết AI đã hiểu đúng.
Trả lời & Hỗ trợ	Chuyển sang trạng thái nói, đồng thời hiển thị bản đồ 2D trên màn hình.	"Cửa hàng Uniqlo ở ngay tầng 1, anh/chị đi thẳng về phía trước khoảng 50 mét là tới ạ. Uniqlo đang có chương trình giảm giá 20% cho các sản phẩm áo thun đến hết tuần này đó ạ."	Trả lời thẳng vào vấn đề (vị trí), sau đó chủ động cung cấp thêm thông tin giá trị gia tăng (khuyến mãi).
Thu thập Feedback	Quay về trạng thái chờ, trên màn hình hiện 2 nút 👍/👎.	"Thông tin của em có hữu ích không ạ?"	Lời thoại tự nhiên để khuyến khích người dùng cho phản hồi.
Kết thúc (Happy Path)	Mỉm cười, gật đầu cảm ơn.	"Em cảm ơn ạ. Chúc anh/chị có một buổi mua sắm vui vẻ!"	Kết thúc một cách lịch sự, thân thiện.
Xử lý Thất bại	Biểu cảm hơi bối rối, xua tay nhẹ.	"Ôi, xin lỗi anh/chị, thông tin về 'cửa hàng bán đồ cho chó' em chưa được cập nhật rồi. Hiện tại em chỉ có thông tin chi tiết về các cửa hàng tại Tầng 1 thôi ạ."	Thừa nhận hạn chế một cách trung thực, sau đó định hướng lại cho người dùng về khả năng của mình.

5. Yêu cầu Kỹ thuật & Vận hành

Hệ thống Logging & Monitoring: Hệ thống phải tự động gửi tín hiệu "heartbeat" về server mỗi 5 phút. Gửi cảnh báo qua email/chat cho Tech Lead nếu booth offline quá 15 phút.
Quy trình Cập nhật Phần mềm: Phải hỗ trợ cập nhật từ xa (OTA - Over-the-Air) cho cả phần mềm và cơ sở kiến thức của AI.
Hiệu năng:
- Uptime: > 95%.
- Thời gian phản hồi: < 3 giây từ khi người dùng hỏi xong đến khi AI bắt đầu trả lời.

6. Pháp lý & Quản trị Dữ liệu

6.1. Chính sách Quyền riêng tư

Một thông báo rõ ràng, dễ đọc phải được hiển thị ở góc màn hình: "Để cải thiện dịch vụ, các nội dung trao đổi sẽ được ghi lại dưới dạng văn bản ẩn danh. Chúng tôi không thu thập video hay giọng nói của bạn. Bằng việc tương tác, bạn đồng ý với chính sách của chúng tôi."

6.2. Dữ liệu Thu thập

THU THẬP: Nội dung câu hỏi (dạng text), thời gian, câu trả lời của AI, feedback 👍/👎.
KHÔNG THU THẬP: Video từ camera, file ghi âm giọng nói gốc của người dùng.

7. Đội ngũ & Quy trình

Vai trò	Người phụ trách	Nhiệm vụ chính
Product Owner	Stephen Le	Chịu trách nhiệm cuối cùng về sản phẩm, làm việc với đối tác, phân tích dữ liệu.
Tech Lead	Stephen Le	Chịu trách nhiệm về kiến trúc kỹ thuật, phát triển và vận hành hệ thống.
Partner Relations	Thảo Tô	Đầu mối liên lạc, hỗ trợ và thu thập phản hồi từ đối tác tiên phong.

Quy trình làm việc chính: Design Thinking cho giai đoạn thiết kế, Agile/Scrum cho giai đoạn phát triển.

8. Chỉ số Thành công & Kế hoạch Tiếp theo

8.1. Chỉ số Thành công (Success Metrics)

MVP được coi là thành công khi đạt được đồng thời các chỉ số về Kỹ thuật, Tương tác Người dùng và Kinh doanh được mô tả chi tiết dưới đây.

8.1.1. Chỉ số Kỹ thuật

Chỉ số: Độ ổn định và Hiệu năng hệ thống.
Mục tiêu:
- Uptime (Thời gian hoạt động): > 95%.
- Thời gian phản hồi trung bình: < 3 giây.
Cách đo lường:
- Uptime: Được tính toán tự động bởi hệ thống monitoring, dựa trên tỷ lệ thành công của tín hiệu "heartbeat" mà mỗi booth gửi về server mỗi 5 phút. Ví dụ: (Số heartbeat thành công / Tổng số heartbeat kỳ vọng) * 100.
- Thời gian phản hồi: Backend service sẽ ghi lại (log) thời gian xử lý của mỗi yêu cầu API, từ lúc nhận được yêu cầu từ Booth App đến lúc gửi trả kết quả. Chúng ta sẽ tính toán thời gian trung bình từ các log này.

8.1.2. Chỉ số Tương tác Người dùng

Chỉ số: Mức độ thu hút của AI Booth.
Mục tiêu: Đạt trung bình > 50 lượt tương tác/ngày.
Cách đo lường:
- Mỗi khi một phiên hội thoại mới được bắt đầu (người dùng hỏi câu đầu tiên), backend sẽ ghi nhận một "interaction event" vào cơ sở dữ liệu.
- Con số này sẽ được tính bằng cách lấy Tổng số interaction event chia cho Tổng số ngày trong giai đoạn thử nghiệm. Dữ liệu này cũng chính là nguồn cho "Bộ đếm tương tác" trên Tenant Dashboard.

8.1.3. Chỉ số Kinh doanh

Chỉ số: Mức độ xác thực giá trị cho đối tác.
Mục tiêu: Đối tác tiên phong đồng ý ký Thư bày tỏ ý định (Letter of Intent - LOI) cho việc triển khai chính thức.
Cách đo lường:
- Đây là một chỉ số định tính, được đo lường bằng kết quả của cuộc họp tổng kết với đối tác vào cuối giai đoạn thử nghiệm.
- Trong cuộc họp, chúng ta sẽ trình bày toàn bộ dữ liệu thu được từ các chỉ số Kỹ thuật và Tương tác.
- Kết quả "Đạt" được xác nhận khi chúng ta nhận được văn bản LOI đã ký từ đối tác.

8.2. Kế hoạch "Sau MVP"

Nếu thành công: Dùng dữ liệu và LOI để hoàn thiện hồ sơ gọi vốn vòng tiếp theo, đồng thời bắt đầu phát triển phiên bản v0.2 với phạm vi kiến thức mở rộng.
Nếu thất bại: Phân tích dữ liệu để tìm ra nguyên nhân (vấn đề kỹ thuật, trải nghiệm người dùng kém, hay mô hình không hấp dẫn?), từ đó quyết định điều chỉnh (pivot) hoặc dừng lại.

9. Sản phẩm Đầu ra của Giai đoạn Thiết kế

Mục tiêu cuối cùng của Giai đoạn Thiết kế là tạo ra một "Bộ Đặc tả Kỹ thuật Toàn diện", sẵn sàng để chuyển giao cho đối tác phát triển và sản xuất mà không còn sự mơ hồ. Bộ tài liệu này định nghĩa "Hoàn thành" (Done) cho giai đoạn này.

Nó bao gồm 5 nhóm sản phẩm chính:

9.1. Tài liệu Khung (Framework Documents)

Bộ chân dung người dùng chi tiết (Detailed Personas): Hoàn thiện hồ sơ cho "Chị An" (Người dùng cuối) và "Anh Phong" (Khách hàng Doanh nghiệp), bao gồm mục tiêu, nhu cầu và các điểm khó khăn của họ.
Bản đồ hành trình người dùng (User Journey Maps): Mô tả trực quan các bước, điểm chạm, suy nghĩ và cảm xúc của người dùng khi tương tác với AI Booth, từ lúc bị thu hút cho đến khi hoàn thành mục tiêu.
Luồng người dùng chi tiết (Detailed User Flows): Sơ đồ logic (dạng biểu đồ) mô tả tất cả các nhánh rẽ có thể xảy ra cho các tác vụ chính (ví dụ: luồng tìm đường, luồng hỏi khuyến mãi, luồng xử lý khi AI không hiểu).

9.2. Thiết kế Trải nghiệm & Giao diện (UX/UI Design)

Hệ thống Thiết kế v1.0 (Design System v1.0): Một thư viện trên Figma bao gồm:
- Nguyên tắc Thiết kế: 4 nguyên tắc đã thống nhất.
- Hệ thống Màu sắc & Chữ viết (Color & Typography): Quy định rõ mã màu, font chữ, kích thước, và cách sử dụng.
- Bộ Components: Thiết kế chi tiết cho tất cả các thành phần giao diện (nút, thẻ, icon...) với đầy đủ các trạng thái (default, hover, clicked).
Thiết kế Giao diện Chi tiết (High-Fidelity UI Screens): Toàn bộ các màn hình cho Booth App và Tenant Dashboard, được thiết kế dựa trên Design System.
Thiết kế Cá tính AI (AI Personality Guide): Một tài liệu định nghĩa rõ chân dung, tính cách và giọng điệu (Tone of Voice) của AI, kèm theo các ví dụ mẫu câu trả lời.

9.3. Đặc tả Kỹ thuật Phần mềm (Software Specifications)

Sơ đồ Kiến trúc Hệ thống: Sơ đồ mô tả cách các module (Booth App, AI Core, Cloud Platform, Database...) kết nối và trao đổi dữ liệu.
Đặc tả API v1.0: Tài liệu định nghĩa tất cả các API endpoints theo chuẩn OpenAPI (Swagger), làm "hợp đồng" giữa Front-end và Back-end.
Sơ đồ Lược đồ Cơ sở Dữ liệu (Database Schema): Thiết kế chi tiết các bảng và mối quan hệ trong cơ sở dữ liệu.
Bộ User Stories Chi tiết: Danh sách đầy đủ các User Story cho từng tính năng, mỗi story phải kèm theo "Tiêu chí Chấp nhận" (Acceptance Criteria) rõ ràng.

9.4. Thiết kế Phần cứng (Hardware Design)

Bản vẽ CAD 3D: Các file thiết kế 3D chi tiết của vỏ kiosk và các bộ phận cơ khí, sẵn sàng cho việc sản xuất.
Danh sách Vật liệu chi tiết (BOM): Liệt kê chính xác mã sản phẩm, nhà cung cấp cho từng linh kiện phần cứng (màn hình, máy tính, micro,...).
Đặc tả CMF (Color, Material, Finish): Quy định chi tiết về màu sắc, vật liệu và chất lượng hoàn thiện bề mặt của sản phẩm.

9.5. Sản phẩm Xác thực (Validation Artifact)

"Golden Prototype": Một mẫu thử nội bộ, có độ trung thực cao, hoạt động đầy đủ các chức năng trong phạm vi MVP trên phần cứng tương đương. Đây là bằng chứng cuối cùng về tính khả thi của thiết kế và là tham chiếu không thể chối cãi cho vendor.