PRD: Thu thập lead & người đăng ký
| Module | Marketing | PRD ID | PRD-CAP-001 |
| Trạng thái | Sẵn sàng dev | FEAT | CAP |
| Epic | — | Plane | BANA-1510 |
| Ngày | 2026-04-03 | Phiên bản | v1.1 |
| Gói | @nx/outreach | URD | CAP |
| Surface | BO · Vận hành | ||
| Phụ trách | Phát Nguyễn | ||
TL;DR
Cho phép trang marketing công khai thu thập lead - yêu cầu tư vấn/liên hệ/bán hàng/demo/đối tác (inquiry) và người đăng ký bản tin (subscriber). Subscribe idempotent theo email, unsubscribe được tôn trọng qua token một-chạm, và mỗi inquiry mới báo thời gian thực tới đội vận hành (NEXPANDO & VNPAY) - một danh sách đối tượng sạch, tôn trọng opt-out, sẵn sàng cho các chiến dịch ở Giai đoạn 2. Bản đọc back-office (danh sách + thống kê người đăng ký) đặc tả tại PRD-SUB-001.
1. Bối cảnh & Vấn đề
Nhà bán muốn xây tập đối tượng từ trang công khai của mình - khách truy cập yêu cầu demo, liên hệ bán hàng, hoặc đăng ký bản tin. Không có bề mặt thu thập, các tín hiệu này bị mất hoặc rải rác: không có danh sách không trùng lặp, không cưỡng chế unsubscribe, không có cách đánh giá tập đối tượng đang tăng ra sao. Khoảng trống đó chặn mọi công việc chiến dịch gửi đi sau này, vốn phụ thuộc vào một tập sạch và tôn trọng opt-out.
Tính năng này đặt nền thu thập: ghi nhận inquiry và đăng ký bản tin từ trang công khai, giữ danh sách người đăng ký idempotent và an toàn opt-out, và báo ngay cho đội vận hành khi có lead mới.
2. Goals & Non-Goals
Goals
- Thu thập inquiry từ trang công khai với 5 loại (tư vấn, liên hệ, bán hàng, demo, đối tác), kèm thông báo thời gian thực tới đội vận hành.
- Làm cho việc subscribe bản tin idempotent theo email - subscribe lại sẽ tái kích hoạt bản ghi đã unsubscribe trước đó thay vì tạo trùng.
- Tôn trọng unsubscribe dựa trên token trước mọi lần tái kích hoạt hoặc gửi.
Non-Goals
- Danh sách và thống kê người đăng ký ở back-office - đặc tả tại PRD-SUB-001 (nguồn duy nhất).
- Xử lý inquiry ở back-office (gán, trả lời, convert) - đặc tả tại PRD-CAP-002.
- Chiến dịch, tự động hóa drip, và A/B testing - thuộc về Chiến dịch & Tự động hóa (
CMP, P2). - Hạ tầng gửi email/SMS - do nhà cung cấp bên ngoài đảm nhiệm.
- Logic giá khuyến mãi - thuộc về module Chiến dịch.
3. Success Metrics
| Metric | Mục tiêu / tín hiệu |
|---|---|
| Khử trùng lặp | Không có người đăng ký active trùng lặp trên mỗi email |
| Toàn vẹn opt-out | Mọi token unsubscribe phân giải về một bản ghi đã hủy; không gửi tới người đăng ký đã hủy |
| Độ trễ thu thập | Inquiry gửi → đội vận hành được thông báo gần thời gian thực |
4. Personas & Use Cases
| Persona | Mục tiêu trong tính năng |
|---|---|
| Khách truy cập | Gửi inquiry hoặc đăng ký bản tin từ trang công khai |
| Người đăng ký | Hủy đăng ký bất cứ lúc nào qua liên kết token một-chạm |
| Đội vận hành (NEXPANDO & VNPAY) | Được báo ngay khi có inquiry mới để phản hồi nhanh |
Kịch bản chính: một khách truy cập gửi inquiry (đội vận hành được thông báo thời gian thực) hoặc đăng ký bản tin (idempotent theo email) → một người đăng ký sau đó nhấp liên kết unsubscribe (phân giải qua token, bị hủy kích hoạt) → một địa chỉ từng hủy đăng ký lại và được tái kích hoạt, không tạo trùng.
5. User Stories
- Là một khách truy cập, tôi muốn gửi inquiry tư vấn/liên hệ/bán hàng/demo/đối tác từ trang công khai, để doanh nghiệp có thể theo dõi tiếp.
- Là một khách truy cập, tôi muốn đăng ký bản tin bằng email của mình, để nhận cập nhật - và đăng ký hai lần không bao giờ tạo bản trùng.
- Là một người đăng ký, tôi muốn hủy đăng ký qua liên kết token, để dừng nhận tin.
- Là một khách truy cập từng hủy đăng ký, tôi muốn việc đăng ký lại tái kích hoạt bản ghi của mình, để tham gia lại mà không có mục trùng.
- Là đội vận hành, tôi muốn có thông báo thời gian thực khi inquiry đến, để phản hồi nhanh.
6. Functional Requirements
| # | Yêu cầu | Trạng thái | URD ref |
|---|---|---|---|
| FR-1 | Thu thập một inquiry từ trang công khai - form đầy đủ field và validation (chi tiết bên dưới) | ✅ đã dựng | URD-CAP-001 |
| FR-2 | Subscribe bản tin idempotent theo email; email đang active trả về bản ghi hiện có, không tạo trùng | ✅ đã dựng | URD-CAP-002 |
| FR-3 | Đăng ký lại một email đã unsubscribe sẽ tái kích hoạt nó (đặt lại mốc thời gian subscribe, xóa mốc thời gian unsubscribe, đặt status về active) | ✅ đã dựng | URD-CAP-002 |
| FR-4 | Unsubscribe dựa trên token phân giải người đăng ký theo token của họ và hủy kích hoạt; token không hợp lệ bị từ chối | ✅ đã dựng | URD-CAP-003 |
| FR-5 | Bản đọc back-office về danh sách và thống kê người đăng ký - đặc tả và trạng thái dựng tại PRD-SUB-001 (nguồn duy nhất; PRD này không lặp lại) | - | URD-CAP-004 |
| FR-6 | Một lần gửi inquiry mới phát ra thông báo thời gian thực tới đội vận hành | ✅ đã dựng | URD-CAP-001 |
FR-1 - Thu thập inquiry (form công khai)
| Field | Bắt buộc | Quy tắc |
|---|---|---|
| Loại inquiry | ✔ | Chọn 1 trong 5: Tư vấn · Liên hệ · Bán hàng · Demo · Đối tác |
| Tên | ✔ | Không được để trống |
| Họ | - | |
| ✔ | Đúng định dạng email | |
| Số điện thoại | ✔ | Đúng định dạng số điện thoại |
| Tên doanh nghiệp | - | |
| Loại hình doanh nghiệp | - | |
| Số điểm bán | - | Nhập tự do |
| Doanh thu ước tính | - | Nhập tự do |
| Tiêu đề | - | |
| Nội dung | - | Nhiều dòng |
- Form mở cho khách truy cập ẩn danh - không cần đăng nhập.
- Inquiry mới vào hệ thống với trạng thái Mới và xuất hiện ngay trong bàn làm việc của đội vận hành (PRD-CAP-002).
FR-2 / FR-3 - Subscribe bản tin (idempotent)
Form đăng ký bản tin công khai thu: email (bắt buộc, đúng định dạng), chủ đề quan tâm (tùy chọn), ngôn ngữ ưu tiên (tùy chọn - Tiếng Việt / English).
Quy tắc idempotent theo email:
- Email chưa tồn tại → tạo người đăng ký mới (status active) kèm một token unsubscribe duy nhất.
- Email đang active → trả về bản ghi hiện có; không tạo bản trùng, không báo lỗi.
- Email đã unsubscribe → tái kích hoạt: đặt lại mốc thời gian subscribe về hiện tại, xóa mốc thời gian unsubscribe, đặt status về active.
FR-4 - Unsubscribe qua token
- Liên kết unsubscribe mang một token duy nhất, khó đoán, cấp lúc đăng ký; nhấp một lần là hủy kích hoạt - không cần đăng nhập.
- Token không hợp lệ → từ chối là không-tìm-thấy; không lộ thông tin người đăng ký nào.
- Bản ghi đã hủy được tôn trọng trước mọi lần gửi về sau (ràng buộc C-01).
FR-6 - Thông báo thời gian thực
- Khi một inquiry mới được gửi từ trang công khai, đội vận hành đang mở Back Office thấy ngay: badge trên menu tăng (đếm inquiry Mới + Đang xem xét) và một thông báo nổi hiện ra - không cần tải lại trang.
Tiêu chí nghiệm thu
- Gửi form inquiry thiếu Tên, Email, Số điện thoại, hoặc Loại → báo lỗi tại field, không ghi nhận.
- Email hoặc số điện thoại sai định dạng trên form inquiry → báo lỗi tại field.
- Gửi inquiry hợp lệ → inquiry xuất hiện trong danh sách Back Office với trạng thái Mới; badge và thông báo nổi hiện ra cho người vận hành đang online.
- Đăng ký bản tin cùng một email hai lần liên tiếp → chỉ một bản ghi active tồn tại.
- Đăng ký lại một email đã unsubscribe → bản ghi được tái kích hoạt (status active, mốc subscribe mới, mốc unsubscribe đã xóa) - không sinh bản ghi thứ hai.
- Nhấp liên kết unsubscribe hợp lệ → bản ghi chuyển sang đã hủy ngay lần nhấp đầu.
- Mở liên kết unsubscribe với token không hợp lệ → nhận phản hồi không-tìm-thấy.
7. Non-Functional Requirements
| Lĩnh vực | Yêu cầu |
|---|---|
| Toàn vẹn dữ liệu | Subscribe idempotent theo email - một bản ghi active trên mỗi email |
| Toàn vẹn opt-out | Unsubscribe được tôn trọng trước mọi lần tái kích hoạt hoặc gửi; hủy kích hoạt chỉ qua token |
| Tenancy | Dữ liệu thu thập là toàn cục (không giới hạn theo một merchant) theo ràng buộc module C-02 |
| Authz | Điểm thu thập công khai mở cho khách ẩn danh; bản đọc back-office gác theo quyền (xem PRD-SUB-001) |
| i18n | Ngôn ngữ ưu tiên của người đăng ký được thu để các lần gửi sau có thể bản địa hóa; nhãn hiển thị song ngữ (EN/VI) |
8. UX & Flows
Màn hình chính: các form thu thập trên trang công khai (inquiry + bản tin). Bản đọc back-office (danh sách người đăng ký, thống kê) thuộc PRD-SUB-001; bàn làm việc inquiry thuộc PRD-CAP-002.
9. Data & Domain
| Khái niệm | Vai trò |
|---|---|
| Inquiry | Một yêu cầu tư vấn/liên hệ/bán hàng/demo/đối tác thu từ trang công khai - liên hệ (tên, họ, email, điện thoại), doanh nghiệp (tên, loại hình, số điểm bán, doanh thu ước tính), nội dung (tiêu đề, nội dung) |
| Subscriber | Một đăng ký bản tin - email, ngôn ngữ ưu tiên, chủ đề, status (active/deactivated), mốc thời gian subscribe, mốc thời gian unsubscribe, token unsubscribe |
Chỉ ở mức khái niệm - schema đầy đủ và bất biến nằm trong tài liệu lập trình viên outreach.
10. Dependencies & Assumptions
Phụ thuộc vào
- Khả năng thu thập - nơi đặt logic thu thập và tra cứu cho inquiry và subscriber.
- Kênh thông báo thời gian thực - đẩy sự kiện inquiry-mới tới đội vận hành.
Giả định
- Dữ liệu thu thập là toàn cục (ràng buộc C-02); không giới hạn theo merchant trên subscriber/inquiry.
- Mỗi người đăng ký giữ một token unsubscribe duy nhất cấp tại thời điểm thu thập cho unsubscribe một-chạm.
- Nhà cung cấp bên ngoài (ngoài phạm vi) xử lý việc gửi email/SMS cuối cùng.
11. Risks & Open Questions
| Rủi ro / câu hỏi | Giảm thiểu / trạng thái |
|---|---|
| Người đăng ký trùng lặp khi gửi đúp nhanh | Subscribe idempotent theo email - trả về bản ghi active hiện có, không tạo mới |
| Gửi tới một địa chỉ đã unsubscribe | Unsubscribe hủy kích hoạt bản ghi; ràng buộc C-01 yêu cầu opt-out phải được tôn trọng trước mọi lần gửi |
| Dữ liệu toàn cục (không giới hạn) xuyên các merchant | Chấp nhận theo ràng buộc C-02 |
| Spam qua form công khai | Chưa có chống spam chuyên biệt; theo dõi lượng inquiry, bổ sung nếu bị lạm dụng |
12. Release Plan & Launch Criteria
| Khía cạnh | Kế hoạch |
|---|---|
| Phase | P1 (nền tảng) - marketing/CAP trong danh mục tính năng URD |
| Rollout | Tất cả các trang; không feature flag |
| Migration | Không (entity mới; dữ liệu toàn cục) |
| Tiêu chí ra mắt | Toàn bộ Tiêu chí nghiệm thu ở §6 đạt |
| Giám sát | Lượng subscribe/unsubscribe, tỷ lệ người đăng ký trùng (kỳ vọng 0), độ tin cậy thông báo inquiry |
13. FAQ
Điều gì xảy ra nếu cùng một email đăng ký hai lần? Không có gì bị trùng - một email đang active trả về bản ghi hiện có; một email từng unsubscribe sẽ được tái kích hoạt.
Unsubscribe hoạt động ra sao? Qua một liên kết token: token unsubscribe phân giải về người đăng ký, sau đó người đó bị hủy kích hoạt. Opt-out luôn được tôn trọng trước mọi lần gửi.
Người đăng ký có được giới hạn theo merchant không? Không - dữ liệu thu thập là toàn cục theo ràng buộc C-02.
Muốn xem danh sách hoặc thống kê người đăng ký thì ở đâu? Ở bản đọc back-office - đặc tả tại PRD-SUB-001.
Tính năng này có gửi chiến dịch nào không? Không - việc gửi nằm ngoài phạm vi ở đây và thuộc về Chiến dịch & Tự động hóa (CMP, P2). Tính năng này chỉ thu thập đối tượng.
References
- URD: Marketing - Thu thập lead & người đăng ký
- PRD liên quan: PRD-CAP-002 - Quản lý Inquiry (Back Office) · PRD-SUB-001 - Người đăng ký bản tin · Chiến dịch & Tự động hóa (kế hoạch)
- Module: Marketing - URD
- Developer: @nx/outreach