PRD: Cơ sở tri thức, khảo sát & phản hồi
| Module | Hỗ trợ khách hàng (CORE-13) | PRD ID | PRD-KB-001 |
| Status | In-progress | Owner | Nhóm Hỗ trợ khách hàng |
| Date | 2026-06-02 | Version | v0.1 |
| Packages | @nx/helpdesk · @nx/core | URD | KB · SRV · FR · CMP |
TL;DR
Cung cấp cho đội hỗ trợ của merchant một lớp tự phục vụ và phản hồi trên nền lõi ticket: một cơ sở tri thức đa ngôn ngữ để giảm tải ticket, khảo sát CSAT/NPS/CES tự gửi sau khi giải quyết để đo chất lượng, một kênh yêu cầu tính năng với mỗi khách hàng vote một lần, và một đường bù đắp do agent phát hành để bù lại khi vi phạm. Kết quả: khách hàng tự giải quyết vấn đề mà không cần agent, chất lượng hỗ trợ trở nên đo được, còn nhu cầu sản phẩm lẫn thiện chí đều được ghi nhận gắn với ticket đã khơi ra chúng.
1. Bối cảnh & Vấn đề
Lõi ticket cho phép agent xử lý ticket qua một vòng đời với việc thực thi SLA, nhưng nó dừng lại ở thời điểm giải quyết. Không có cách nào để khách hàng tự phục vụ trước khi tạo ticket, không có tín hiệu về việc hỗ trợ đã cho có thực sự làm họ hài lòng hay không, không có kênh để ghi nhận nhu cầu sản phẩm nổi lên trong các cuộc hội thoại hỗ trợ, và không có cách có kiểm soát để agent bù đắp cho khách hàng sau một vi phạm. Thiếu những điều này, lượng ticket vẫn cao, chất lượng hỗ trợ vô hình, nhu cầu khách hàng bị mất, và các động thái thiện chí mang tính tạm thời và không được theo dõi.
Lớp này xây trên lõi ticket → message → SLA → agent sẵn có để khép kín vòng lặp: giảm tải bằng cơ sở tri thức, đo lường bằng khảo sát, ghi nhận nhu cầu bằng yêu cầu tính năng, và khôi phục lòng tin bằng bù đắp.
2. Mục tiêu & Không phải mục tiêu
Mục tiêu
- Một cơ sở tri thức đa ngôn ngữ: bài viết (tiêu đề, nội dung, trích đoạn) với vòng đời
draft → published → archived, danh mục phân cấp, slug độc nhất toàn cục, tác giả/locale/tag, và theo dõi lượt xem + hữu ích + không hữu ích. - Khảo sát & phản hồi: khảo sát CSAT / NPS / CES với câu hỏi có thứ tự, kích hoạt sau-giải-quyết / sau-đóng / định kỳ, một worker tự gửi sau khi giải quyết, ghi nhận câu trả lời, và đẩy vào điểm hài lòng của mỗi agent.
- Yêu cầu tính năng: khách hàng gửi yêu cầu qua một vòng đời theo dõi sản phẩm, mỗi khách hàng vote một lần (kèm bỏ vote), và liên kết tùy chọn ngược về ticket nguồn.
- Bù đắp: thiện chí do agent phát hành (store credit, voucher, hoàn tiền, chiết khấu, miễn phí ship) khi vi phạm hoặc theo quyết định, với vòng đời riêng
pending → processing → completed, gắn với một ticket và tùy chọn một escalation.
Không phải mục tiêu
- Gợi ý trả lời bằng AI và dự đoán vi phạm SLA (URD tương lai).
- Tiếp nhận đa kênh (email, Zalo OA, Messenger) và cổng ticket tự phục vụ hướng khách hàng.
- Dashboard báo cáo SLA - thuộc module Báo cáo.
3. Success Metrics
| Metric | Mục tiêu / tín hiệu |
|---|---|
| Giảm tải ticket | Bài viết đã publish tích lũy lượt xem và đánh giá hữu ích; lượt đọc bài tương quan với việc giảm tạo ticket |
| Độ phủ khảo sát | Ticket đã giải quyết có kích hoạt và ghi nhận được câu trả lời khảo sát |
| Tín hiệu hài lòng | Câu trả lời khảo sát đẩy vào điểm hài lòng theo từng agent, không có câu trả lời mồ côi |
| Ghi nhận nhu cầu | Yêu cầu tính năng được gửi và vote, mỗi khách hàng vote tối đa một lần |
| Truy vết thiện chí | 100% bù đắp gắn với một ticket; không cái nào kẹt ngoài vòng đời pending → completed |
4. Personas & Use Cases
| Persona | Mục tiêu trong tính năng này |
|---|---|
| Khách hàng | Đọc bài trợ giúp để tự phục vụ, đánh giá chúng, trả lời khảo sát sau-giải-quyết, gửi và vote yêu cầu tính năng |
| Agent hỗ trợ | Phát hành bù đắp thiện chí trên một ticket khó hoặc bị vi phạm |
| Quản lý hỗ trợ | Soạn và publish bài cơ sở tri thức, cấu hình khảo sát, phân loại yêu cầu tính năng |
Kịch bản cốt lõi: một khách hàng đọc bài đã publish và đánh giá hữu ích → sau khi một ticket được giải quyết, worker khảo sát tự gửi một khảo sát CSAT/NPS/CES mà câu trả lời đẩy vào điểm hài lòng của agent → một khách hàng gửi yêu cầu tính năng và những người khác vote → một agent phát hành bù đắp trên ticket bị vi phạm và nó đi qua vòng đời của mình.
5. User Stories
- Là một quản lý hỗ trợ, tôi muốn viết bài đa ngôn ngữ trong danh mục phân cấp với vòng đời draft → published → archived, để khách hàng có thể tự phục vụ bằng ngôn ngữ của họ.
- Là một khách hàng, tôi muốn đọc một bài đã publish và đánh dấu hữu ích hoặc không, để merchant biết nội dung nào hiệu quả.
- Là một quản lý hỗ trợ, tôi muốn một khảo sát được tự gửi sau khi ticket giải quyết, để đo chất lượng hỗ trợ mà không cần thao tác tay.
- Là một khách hàng, tôi muốn trả lời một khảo sát CSAT/NPS/CES, để phản hồi của tôi đến được đội đã giúp mình.
- Là một khách hàng, tôi muốn gửi một yêu cầu tính năng và vote các yêu cầu khác (một lần), để đội sản phẩm thấy được nhu cầu thực.
- Là một agent hỗ trợ, tôi muốn phát hành bù đắp thiện chí trên một ticket bị vi phạm, để khôi phục lòng tin của khách hàng bằng một động thái được theo dõi.
6. Functional Requirements
| # | Yêu cầu | URD ref |
|---|---|---|
| FR-1 | Tạo và quản lý bài viết đa ngôn ngữ (tiêu đề, nội dung, trích đoạn) với vòng đời draft → published → archived | URD-KB-001..002 |
| FR-2 | Bài viết mang danh mục, tác giả, locale, một slug độc nhất toàn cục, và tag; danh mục theo phân cấp | URD-KB-003 · URD-KB-005 |
| FR-3 | Theo dõi số lượt xem, hữu ích, và không hữu ích theo từng bài; khách hàng gửi phản hồi hữu ích/không hữu ích; lượt xem được ghi riêng từng cái | URD-KB-004 · URD-KB-006..007 |
| FR-4 | Tạo khảo sát loại CSAT, NPS, hoặc CES với câu hỏi có thứ tự, sắp xếp lại được | URD-SRV-001 · URD-SRV-003 |
| FR-5 | Chế độ kích hoạt - sau-giải-quyết, sau-đóng, định kỳ; một worker tự gửi khảo sát sau khi một ticket giải quyết | URD-SRV-002 · URD-SRV-004 |
| FR-6 | Ghi nhận và lưu câu trả lời khảo sát; câu trả lời đẩy vào điểm hài lòng của agent | URD-SRV-005..006 |
| FR-7 | Khách hàng gửi yêu cầu tính năng (tiêu đề, mô tả, danh mục, tag) qua một vòng đời theo dõi sản phẩm | URD-FR-001..002 |
| FR-8 | Mỗi khách hàng vote một lần cho mỗi yêu cầu, kèm bỏ vote; một yêu cầu có thể liên kết tới ticket nguồn; ghi chú nội bộ/giải quyết | URD-FR-003..005 |
| FR-9 | Phát hành bù đắp khi vi phạm SLA hoặc theo quyết định; loại: store credit, voucher, hoàn tiền, chiết khấu, miễn phí ship | URD-CMP-001..002 |
| FR-10 | Bù đắp đi theo pending → processing → completed / failed / cancelled / expired, gắn với một ticket và tùy chọn một escalation | URD-CMP-003..004 |
Toàn văn yêu cầu và tiêu chí chấp nhận nằm trong URD Hỗ trợ khách hàng. PRD này tham chiếu chúng thay vì lặp lại.
7. Non-Functional Requirements
| Khía cạnh | Yêu cầu |
|---|---|
| Toàn vẹn dữ liệu | Slug bài viết độc nhất toàn cục; ràng buộc mỗi khách hàng vote một lần cho mỗi yêu cầu; câu trả lời khảo sát không bao giờ mồ côi khỏi điểm agent |
| Tenancy & authz | Mọi thao tác scope theo merchant (x-merchant-id); kiểm soát bởi permission helpdesk (kiểm tra permission ở mức route) |
| Soft-delete | Mọi bản ghi dùng soft-delete; chỉnh sửa không bao giờ xóa cứng lịch sử |
| Độ tin cậy | Việc gửi khảo sát sau-giải-quyết chạy trong một worker (survey-trigger), tách rời khỏi request giải quyết |
| i18n | Nội dung bài viết và nhãn hướng người dùng song ngữ ({ en, vi }) |
8. UX & Flows
Màn hình chính (trong workspace hỗ trợ): quản lý bài viết + danh mục, trình tạo khảo sát, bảng yêu cầu tính năng kèm vote, và luồng phát hành bù đắp trên một ticket.
9. Data & Domain
| Entity | Vai trò |
|---|---|
Article · ArticleCategory | Nội dung cơ sở tri thức và danh mục phân cấp của nó |
ArticleView · ArticleFeedback | Theo dõi từng lượt xem và phản hồi hữu ích/không hữu ích |
Survey · SurveyQuestion · SurveyResponse | Định nghĩa khảo sát, câu hỏi có thứ tự, và câu trả lời ghi nhận được |
FeatureRequest · FeatureVote | Yêu cầu của khách hàng và bản ghi mỗi-khách-hàng-một-vote |
Compensation | Thiện chí do agent phát hành với vòng đời riêng, gắn với một ticket/escalation |
Chỉ mang tính khái niệm - toàn bộ schema và bất biến nằm trong mô hình miền helpdesk. Các schema nằm trong bộ tập trung
core/models/schemas/helpdesk.
10. Dependencies & Assumptions
Phụ thuộc vào
- Lõi ticket (URD-TKT · URD-SLA) - việc giải quyết kích hoạt khảo sát; vi phạm kích hoạt bù đắp.
- Agent (URD-AGT) - câu trả lời khảo sát đẩy vào điểm hài lòng của mỗi agent.
- Quản lý người dùng (
@nx/core) - danh tính khách hàng và agent đứng sau phản hồi, vote, và quyền tác giả.
Giả định
- Có một sự kiện giải quyết được phát ra mà worker
survey-triggercó thể tiêu thụ. - Khách hàng định danh được để có thể thực thi quy tắc mỗi-khách-hàng-một-vote và phản hồi theo từng khách hàng.
- Tồn tại một khảo sát với kích hoạt sau-giải-quyết để đường tự-gửi kích hoạt.
11. Risks & Open Questions
| Rủi ro / câu hỏi | Giảm thiểu / trạng thái |
|---|---|
| Package hiện không compile được (tham chiếu chết) | Theo dõi ở mức module; chặn verified-shipped, không phải scope |
| Vote trùng lặp hoặc lạm dụng làm thổi phồng nhu cầu | Ràng buộc mỗi-khách-hàng-một-vote cho mỗi yêu cầu ở tầng dữ liệu (C-06), kèm bỏ vote |
| Việc gửi khảo sát lỗi âm thầm sau giải quyết | Chạy trong một worker riêng, tách rời và retry được, không inline với request giải quyết |
| Bù đắp đã phát hành nhưng không bao giờ hoàn tất | Vòng đời gồm failed / cancelled / expired; mỗi bù đắp liên kết với một ticket |
| Xung đột slug bài viết giữa các merchant | Slug độc nhất toàn cục (C-04) |
12. Release Plan & Launch Criteria
| Khía cạnh | Kế hoạch |
|---|---|
| Phase | P2 (KB, SRV, FR) · P1 (CMP) - xem catalog tính năng URD |
| Rollout | Tất cả merchant khi build package được sửa; không feature flag |
| Migration | Không - entity mới trong core/models/schemas/helpdesk; cấu hình khảo sát soạn theo từng merchant |
| Launch criteria | Publish bài → đọc → đánh giá đã kiểm chứng; tự-gửi khảo sát → câu trả lời → điểm agent đã kiểm chứng; mỗi-khách-hàng-một-vote được thực thi; vòng đời bù đắp kiểm chứng đầu-cuối |
| Monitoring | Tỷ lệ lượt xem/hữu ích bài viết, tỷ lệ gửi + trả lời khảo sát, vote yêu cầu tính năng, tỷ lệ hoàn tất bù đắp |
13. FAQ
Có thể tái dùng cùng một slug bài viết giữa các merchant không? Không - slug độc nhất toàn cục. Mỗi bài viết cần một slug riêng biệt.
Khi nào khảo sát được gửi? Khi một ticket được giải quyết (hoặc đóng, hoặc theo lịch định kỳ, tùy chế độ kích hoạt). Một worker survey-trigger tự gửi nó; nó không được gửi inline với hành động giải quyết của agent.
Khách hàng có thể vote một yêu cầu tính năng nhiều lần không? Không - mỗi khách hàng vote một lần cho mỗi yêu cầu. Bỏ vote được hỗ trợ, nên khách hàng có thể rút lại vote của mình.
Phát hành bù đắp có trả cho khách hàng ngay không? Không hẳn - bù đắp đi qua pending → processing → completed, và cũng có thể kết thúc ở failed / cancelled / expired. Việc phát hành ghi nhận ý định và theo dõi việc hoàn tất.
Phản hồi và câu trả lời khảo sát đi về đâu? Phản hồi hữu ích/không hữu ích được theo dõi theo từng bài; câu trả lời khảo sát được lưu và đẩy vào điểm hài lòng của agent phụ trách.
References
- URD: Hỗ trợ khách hàng - Cơ sở tri thức · Khảo sát & Phản hồi · Yêu cầu tính năng · Bù đắp
- Xây trên: Quản lý Ticket · Quản lý SLA · Quản lý Agent
- Module: Hỗ trợ khách hàng - tổng quan + truy vết
- Developer: @nx/helpdesk · mô hình miền