Use Cases

Bản đồ use case theo trạng thái

✅ 1. Boutique Hotel (khách sạn boutique) — ĐÃ CHỨNG MINH

Bối cảnh: khách sạn 20–40 phòng, phong cách riêng, đang phụ thuộc Agoda, muốn thương hiệu và kênh trực tiếp.

Portal dùng: Guest OTA (khách đặt) · Partner (quản phòng/giá/đơn) · Web App /app (lễ tân vận hành).

Giá trị:

• Kênh đặt phòng đẹp mang đúng chất boutique (theme "minimal").
• Giữ hoa hồng + dữ liệu khách để chăm sóc khách quen.
• Booking engine chống trùng, xác nhận có mã đơn.

Kịch bản: Khách thấy khách sạn trên Instagram → vào web thương hiệu → đặt trực tiếp → lễ tân xác nhận qua /app → check-in. Không qua Agoda, không mất 20%.

✅ 2. Luxury Resort — ĐÃ CHỨNG MINH

Bối cảnh: resort cao cấp, đơn giá trị lớn (5–20 triệu/đêm), trọng trải nghiệm và đẳng cấp thương hiệu.

Portal dùng: Guest OTA (theme "luxury"/"beach") · Partner · Web App /app.

Giá trị:

• Mỗi đơn tiết kiệm hoa hồng tuyệt đối lớn (20% của 10 triệu = 2 triệu/đêm).
• Trải nghiệm đặt phòng sang, không "hoà lẫn" trên OTA.
• Dữ liệu khách VIP cho chăm sóc riêng.

Kịch bản: khách quay lại đặt trực tiếp qua kênh resort, nhận ưu đãi thành viên → giữ chân + biên lợi nhuận cao.

✅ 3. Homestay Chain (chuỗi homestay) — ĐÃ CHỨNG MINH

Bối cảnh: 3–15 homestay rải rác, muốn thương hiệu chung + quản lý tập trung.

Portal dùng: Platform Admin (chủ chuỗi giám sát) · Partner (mỗi cơ sở tự quản) · Guest OTA (theme "family").

Giá trị:

• Multi-tenant: mỗi homestay một không gian, chung một thương hiệu.
• Chủ chuỗi thấy GMV toàn chuỗi; mỗi chủ cơ sở tự chủ giá/lịch.
• Thay thế mớ Excel + Facebook + Zalo rời rạc.

Kịch bản: khách đặt trên brand chung → đơn về đúng cơ sở → chủ chuỗi theo dõi toàn bộ.

✅ 4. Travel Company / OTA nội địa — ĐÃ CHỨNG MINH (marketplace + API)

Bối cảnh: DN du lịch muốn vận hành marketplace lưu trú riêng, hoặc nối booking vào app/web sẵn có.

Portal dùng: Platform Admin (điều hành sàn) · Partner (đối tác lên sàn) · Booking API (nối hệ thống).

Giá trị:

• Hạ tầng marketplace có sẵn → go-to-market nhanh, không xây 1–2 năm.
• Bộ tích hợp API (OpenAPI/Postman/ví dụ) để đối tác kỹ thuật tự nối.
• Cách ly dữ liệu giữa các cơ sở trên sàn.

Kịch bản: DN duyệt nhiều khách sạn lên sàn của mình, thu phí/hoa hồng nội bộ, giám sát GMV toàn sàn.

✅ 5. Destination Management (DMC) — phần lưu trú ĐÃ CHỨNG MINH

Bối cảnh: đơn vị quản lý điểm đến gom nhiều cơ sở lưu trú tại một vùng.

Portal dùng: Platform Admin · Partner · Guest OTA.

Giá trị: làm "OTA của vùng" — tập hợp lưu trú địa phương dưới một thương hiệu điểm đến.

Lưu ý trung thực: phần lưu trú đã LIVE; nếu DMC cần tour/vé/hoạt động, đó là 🟡 In Implementation (Founder duyệt, đang triển khai — có thể pre-sell / design partner).

🟡 6. Restaurant Booking (đặt bàn) — IN IMPLEMENTATION

Bối cảnh: nhà hàng nhận đặt bàn theo khung giờ, muốn giảm trùng + giữ khách quen.

Ánh xạ mô hình: nhà hàng = Listing · bàn/suất = Đơn vị/slot · đặt bàn = Reservation.

Giá trị (tiềm năng): cùng engine chống trùng + vòng đời đơn + audit.

Cách bán trung thực: "Kiến trúc đặt-chỗ-theo-suất của tụi em hợp với đặt bàn. Lưu trú đã chạy thật; vertical F&B đã được Founder duyệt và đang triển khai — anh/chị có thể pre-sell hoặc đồng hành làm design partner."

Trạng thái: 🟡 In Implementation — Founder duyệt, đang triển khai (giai đoạn discovery/design); chưa hoàn thành, chưa có inventory F&B.

🟡 7. Coffee Booking (đặt chỗ quán) — IN IMPLEMENTATION

Bối cảnh: chuỗi cà phê muốn nhận đặt chỗ giờ cao điểm + chương trình thành viên.

Ánh xạ: giống nhà hàng.

Lưu ý kinh tế: đơn giá trị thấp → giá trị phụ thuộc quy mô + CRM. Cân nhắc kỹ trước khi theo đuổi.

Trạng thái: 🟡 In Implementation — Founder duyệt, đang triển khai; chưa hoàn thành.

🟡 8. Spa / Beauty & Wellness Booking — IN IMPLEMENTATION

Bối cảnh: spa đặt lịch dịch vụ theo khung giờ + kỹ thuật viên.

Ánh xạ: spa = Listing · slot dịch vụ/kỹ thuật viên = Đơn vị/slot · đặt lịch = Reservation.

Giá trị (tiềm năng): quản lịch tránh trùng, dữ liệu khách, nhắc lịch (khi có notification production).

Cách bán trung thực: như mục 6. Nhấn: đặt-lịch-theo-suất là dạng bài toán engine đã làm với lưu trú.

Trạng thái: 🟡 In Implementation — Founder duyệt, đang triển khai; chưa hoàn thành. Lưu ý nhắc-lịch cần notification.

🟡 9. Golf / Sports Booking (đặt sân/tee time) — IN IMPLEMENTATION

Bối cảnh: sân golf bán tee-time theo khung giờ, số lượng giới hạn.

Ánh xạ: sân = Listing · tee-time = Đơn vị/slot theo ngày/giờ.

Giá trị (tiềm năng): chống bán quá slot, vòng đời đơn, check-in.

Cách bán trung thực: "suất theo khung giờ" rất hợp mô hình; vertical này đã được Founder duyệt và đang triển khai.

Trạng thái: 🟡 In Implementation — Founder duyệt, đang triển khai; chưa hoàn thành.

🟡 10. Corporate Travel (du lịch doanh nghiệp) — IN IMPLEMENTATION

Bối cảnh: DN đặt phòng cho nhân viên/khách công tác, muốn kênh nội bộ + kiểm soát chi.

Portal dùng: Guest OTA (đặt) · Partner/Admin (quản lý) · (báo cáo chi tiêu = roadmap).

Giá trị (tiềm năng): kênh đặt lưu trú nội bộ dưới thương hiệu DN.

Lưu ý trung thực: phần lưu trú đã LIVE và dùng được ngay; các nhu cầu corporate đặc thù (chính sách chi, phê duyệt, hoá đơn tự động) đã được Founder duyệt và đang triển khai — chưa hoàn thành.

Trạng thái: 🟡 In Implementation — lưu trú đã LIVE; tính năng corporate chuyên biệt đang triển khai, chưa có.

🟡 11. Clinic / Healthcare (đặt lịch khám / du lịch y tế) — IN IMPLEMENTATION

Bối cảnh: phòng khám/bệnh viện đặt lịch khám, hoặc du lịch y tế xuyên biên giới.

Vị trí trong lộ trình: Medical Tourism là vertical mũi nhọn của nền tảng OTA đa dịch vụ — tái sử dụng Booking (đặt lịch), Payment, Notification; có định hướng AI trust/triage. Vertical này đã được Founder duyệt và đang triển khai.

Cách bán trung thực: "Vertical y tế đã được Founder duyệt và đang trong quá trình triển khai — chưa phải sản phẩm hoàn thiện hôm nay. Nếu anh/chị trong ngành y tế, đây là cơ hội đồng hành làm design partner, không phải cam kết giao hàng ngay."

Trạng thái: 🟡 In Implementation — Founder duyệt, đang triển khai; chưa hoàn thành. Tuyệt đối không bán như tính năng sẵn có/đã xong.

Bảng tổng use case

Tiếp theo: 10 — Pricing Strategy.