PRD: Yêu cầu kinh doanh
| Module | Khách hàng | PRD ID | PRD-INQ-001 |
| Trạng thái | Sẵn sàng dev | FEAT | INQ |
| Epic | — | Plane | BANA-1534 |
| Ngày | 2026-04-06 | Phiên bản | v1.0 |
| Gói | @nx/outreach | URD | INQ |
| Surface | Client · Chủ/QL | ||
| Phụ trách | Phát Nguyễn | ||
TL;DR
Khách tiềm năng gửi yêu cầu kinh doanh từ trang công khai; đội sales back-office nhận tín hiệu real-time ngay khi lead xuất hiện và xử lý nó theo vòng đời rõ ràng NEW → gán → trả lời → chuyển đổi/thất bại - không lead nào bị bỏ sót, mọi lần theo dõi đều được ghi nhận.
1. Bối cảnh & Vấn đề
Trang Overture công khai là nơi khách tiềm năng liên hệ, nhưng lead chỉ có giá trị khi đội sales nhìn thấy và xử lý. Thiếu một quy trình thu thập-và-thông-báo bài bản, yêu cầu hoặc nằm im trong hộp thư hoặc buộc đội phải tự dò danh sách - lead nguội đi, không rõ ai phụ trách, không ai ghi lại ai đã trả lời hay yêu cầu được giải quyết thế nào. Khi BANA nhắm tới các doanh nghiệp HKD/SME qua đăng ký tự phục vụ, phễu lead đầu vào phải đáng tin cậy và rõ trách nhiệm.
Tính năng này lưu yêu cầu thành một bản ghi hạng nhất, đẩy tín hiệu real-time tới admin ngay khi gửi, và đưa mỗi lead qua một vòng đời được kiểm soát để sales gán, trả lời và giải quyết.
2. Mục tiêu & Loại trừ
Mục tiêu
- Thu thập một yêu cầu từ trang công khai - thông tin liên hệ, thông tin doanh nghiệp và lời nhắn - chỉ trong một lần gửi.
- Thông báo cho admin real-time ngay khi có yêu cầu mới - không cần dò danh sách.
- Theo dõi việc gán, trả lời, chuyển đổi và lý do thất bại của mỗi lead qua vòng đời NEW → gán → trả lời → chuyển đổi/thất bại.
Loại trừ
- Engine chiến dịch Email / SMS (Dự kiến - xem URD §7).
- Phân khúc và nhắm mục tiêu khách hàng.
- Phân tích giá trị trọn đời của lead.
3. Thước đo thành công
| Thước đo | Mục tiêu / tín hiệu |
|---|---|
| Độ trễ thông báo | Yêu cầu mới hiện ra cho admin real-time (đẩy dưới một giây), không phải do dò danh sách |
| Độ đầy đủ khi thu thập | 100% lần gửi công khai được lưu kèm thông tin liên hệ + doanh nghiệp + lời nhắn |
| Trách nhiệm với lead | Mỗi yêu cầu đều có người phụ trách, tác giả/thời điểm trả lời và kết quả cuối |
| Thời gian phản hồi đầu tiên | Thời gian trung vị NEW → trả lời theo mỗi merchant có xu hướng giảm |
4. Persona & Tình huống
| Persona | Mục tiêu trong tính năng này |
|---|---|
| Khách truy cập (Lead) | Gửi một yêu cầu từ trang công khai mà không cần tài khoản |
| Sales | Thấy lead mới ngay lập tức, nhận về, trả lời và kết là chuyển đổi hoặc thất bại |
| Chủ / Admin | Theo dõi lượng lead đầu vào và đảm bảo không yêu cầu nào bị bỏ sót |
Tình huống cốt lõi: khách truy cập gửi yêu cầu → yêu cầu được lưu ở trạng thái NEW và admin được thông báo real-time → một sales rep nhận về cho mình → trả lời (ghi nhận tác giả + thời điểm) → đánh dấu chuyển đổi hoặc thất bại kèm lý do.
5. Câu chuyện người dùng
- Là khách truy cập, tôi muốn gửi yêu cầu kèm thông tin liên hệ, thông tin doanh nghiệp và lời nhắn, để doanh nghiệp liên hệ lại với tôi.
- Là một sales rep, tôi muốn được thông báo real-time khi có yêu cầu mới, để phản hồi nhanh mà không phải tự dò danh sách.
- Là một sales rep, tôi muốn nhận một yêu cầu về cho mình, để rõ ai phụ trách.
- Là một sales rep, tôi muốn trả lời một yêu cầu và lưu lại nội dung cùng thời điểm trả lời, để việc theo dõi kiểm tra được.
- Là một sales rep, tôi muốn đánh dấu yêu cầu là chuyển đổi hoặc thất bại (kèm lý do), để ghi lại kết quả của lead.
6. Yêu cầu chức năng
| # | Yêu cầu | URD ref |
|---|---|---|
| FR-1 | Thu thập yêu cầu từ lần gửi công khai kèm thông tin liên hệ, thông tin doanh nghiệp và lời nhắn; yêu cầu mới khởi tạo ở trạng thái NEW | URD-INQ-001 |
| FR-2 | Khi gửi, phát thông báo real-time tới admin kèm mã yêu cầu, loại, họ và tên, email, tên doanh nghiệp, tiêu đề và thời điểm tạo | URD-INQ-002 |
| FR-3 | Thông báo lan tới một kênh chung cho mọi yêu cầu và một kênh riêng theo từng yêu cầu, để nhắm tới một yêu cầu cụ thể | URD-INQ-002 |
| FR-4 | Theo dõi việc gán, trả lời (tác giả + thời điểm), chuyển đổi và lý do thất bại của một yêu cầu | URD-INQ-003 |
| FR-5 | Theo dõi tiến trình của lead - gán, trả lời (tác giả + thời điểm), chuyển đổi và lý do thất bại - bằng các trường chuyên dụng thay vì gói trong giá trị trạng thái; trạng thái nền dùng các trạng thái vòng đời tổng quát (NEW → PROCESSING → COMPLETED/CLOSED/CANCELLED), không phải các giá trị assigned/replied/converted/lost riêng | URD-INQ-004 |
| FR-6 | Quản lý yêu cầu (liệt kê, xem, đếm, tạo, cập nhật, xóa), mỗi thao tác đều cần quyền tương ứng | URD-INQ-003..004 |
Toàn bộ nội dung yêu cầu và tiêu chí chấp nhận nằm trong URD Khách hàng. PRD này tham chiếu, không lặp lại.
7. Yêu cầu phi chức năng
| Khía cạnh | Yêu cầu |
|---|---|
| Phân phối real-time | Kênh real-time chạy trên một backbone dùng chung ở chế độ single hoặc cluster; thông báo lan qua nhiều instance |
| Suy giảm nhẹ nhàng | Nếu dịch vụ real-time chưa sẵn sàng, lần gửi vẫn lưu yêu cầu và thông báo thành no-op kèm cảnh báo - khâu thu thập không bao giờ chết vì đường thông báo |
| Phạm vi & phân quyền | Việc quản lý yêu cầu giới hạn trong merchant của người dùng và cần quyền tương ứng; lần gửi công khai không cần xác thực |
| Toàn vẹn dữ liệu | Mọi bản ghi yêu cầu đều soft-delete được, giữ lại lịch sử lead |
| i18n | Nhãn/trạng thái hướng tới người dùng là song ngữ (tiếng Anh / tiếng Việt) |
8. UX & Luồng
Các màn hình chính: form yêu cầu công khai nằm trên trang Overture; danh sách yêu cầu, màn chi tiết và các nút điều khiển vòng đời (kèm badge/toast báo lead mới real-time) nằm trên bề mặt nhân viên back-office.
9. Dữ liệu & Miền nghiệp vụ
| Khái niệm | Vai trò |
|---|---|
| Yêu cầu | Bản ghi lead - thông tin liên hệ, thông tin doanh nghiệp, lời nhắn, loại, trạng thái, người phụ trách, lần trả lời và kết quả (lý do chuyển đổi/thất bại) |
| Thông báo real-time | Sự kiện "yêu cầu đã gửi", lan tới một kênh chung cho mọi yêu cầu và một kênh riêng theo từng yêu cầu để phân phối có nhắm mục tiêu |
Chỉ ở mức khái niệm - mô hình dữ liệu đầy đủ và các bất biến nằm trong Outreach domain model.
10. Phụ thuộc & Giả định
Phụ thuộc vào
- Năng lực outreach - sở hữu bản ghi yêu cầu, vòng đời CRUD và thành phần real-time.
- Dữ liệu lõi dùng chung - model yêu cầu dùng chung và các primitive thông báo real-time nền tảng.
- Backbone real-time - lan thông báo qua nhiều instance.
Giả định
- Trang Overture công khai render form yêu cầu và post lần gửi.
- Một subscriber phía client (badge sidebar / toast real-time) trên bề mặt nhân viên nhận thông báo.
- Việc gửi email nằm ngoài phạm vi module này; theo dõi lead diễn ra qua vòng đời, không qua tính năng này.
11. Rủi ro & Câu hỏi mở
| Rủi ro / câu hỏi | Giảm thiểu / trạng thái |
|---|---|
| Dịch vụ real-time ngừng → admin bỏ lỡ thông báo | Lần gửi vẫn lưu; thông báo thành no-op kèm cảnh báo, nên yêu cầu không bao giờ mất - admin vẫn thấy nó trong danh sách |
| Lan thông báo qua nhiều instance | Backbone real-time dùng chung ở chế độ cluster lo phần phân phối đa-instance |
| Spam / lạm dụng trên endpoint công khai | Mở: cân nhắc rate-limiting / captcha cho lần gửi công khai |
| Không có kênh theo dõi qua email | Ngoài phạm vi; engine chiến dịch là Dự kiến trong URD |
12. Kế hoạch phát hành & Tiêu chí ra mắt
| Khía cạnh | Kế hoạch |
|---|---|
| Phase | P2 - xem danh mục tính năng URD (INQ) |
| Rollout | Tất cả merchant; không feature flag |
| Migration | Không (các trường yêu cầu được thêm vào dữ liệu lõi dùng chung) |
| Tiêu chí ra mắt | Lần gửi công khai lưu được một yêu cầu NEW; admin nhận thông báo real-time đầu-cuối; vòng đời gán → trả lời → chuyển đổi/thất bại được kiểm chứng |
| Giám sát | Lượng yêu cầu theo merchant, tỷ lệ gửi thông báo thành công/thất bại, thời gian NEW → trả lời |
13. FAQ
Admin có phải refresh để thấy yêu cầu mới không? Không - thông báo real-time được đẩy ngay khi gửi, nên lead mới hiện ra tức thì.
Nếu dịch vụ real-time ngừng đúng lúc có yêu cầu gửi tới thì sao? Yêu cầu vẫn được lưu; thông báo bị bỏ qua kèm cảnh báo. Admin vẫn thấy nó trong danh sách - khâu thu thập không bao giờ phụ thuộc vào đường thông báo.
Khách truy cập gửi yêu cầu mà không có tài khoản được không? Được - lần gửi công khai không cần xác thực. Việc quản lý yêu cầu (tìm/gán/trả lời/giải quyết) cần xác thực và phải có quyền.
Gửi một yêu cầu có gửi email cho lead không? Không - module này không có kênh email/SMS. Việc theo dõi được ghi nhận qua vòng đời của yêu cầu.
Yêu cầu có những trạng thái nào? Trạng thái nền dùng các trạng thái vòng đời tổng quát (NEW → PROCESSING → COMPLETED/CLOSED/CANCELLED). Tiến trình lead mà admin quan tâm - gán → trả lời → chuyển đổi/thất bại, kèm lý do thất bại khi có - nằm trong các trường chuyên dụng, không gói trong giá trị trạng thái.
Tham chiếu
- URD: Khách hàng - Yêu cầu kinh doanh (vùng INQ)
- Module: Khách hàng - URD
- Developer: @nx/outreach · Outreach domain model