Bài viết
Quản lý yêu cầu khách hàng: từ nhóm chat sang một cổng tiếp nhận
Quản lý yêu cầu khách hàng cho đội làm và bảo trì phần mềm: vòng đời một yêu cầu, bốn thứ hệ thống tiếp nhận cần, quy trình trực mỗi ngày, kế hoạch 2 tuần rời nhóm chat.
Khoảng 7 phút đọc
Trả lời ngắn
Định nghĩaQuản lý yêu cầu khách hàng, với đội làm và bảo trì phần mềm, là đưa mọi báo lỗi, đề xuất và câu hỏi của khách vào một đường duy nhất, gắn cho mỗi yêu cầu một mã, một mức độ và một hạn phản hồi, rồi theo dõi nó cho tới khi khách xác nhận xong. Nguyên tắc gói trong ba chữ: một cửa, một mã, một đồng hồ. Nhóm Zalo không làm được cả ba.
Bài này dành cho đội đang nhận yêu cầu qua nhóm chat, điện thoại và hành lang, muốn chuyển sang một cổng tiếp nhận mà không làm khách khó chịu. Có vòng đời một yêu cầu, quy trình trực mỗi ngày, kế hoạch hai tuần để rời nhóm chat, và một ví dụ thật.
Nhóm chat là hộp thư không có đáy
Nhóm Zalo với khách rất tiện lúc đầu: gửi một dòng là có người trả lời. Nhưng sau ba tháng, năm triệu chứng này xuất hiện ở hầu hết đội, và không phải vì đội lười.
Năm triệu chứng
- Yêu cầu trôi. Tin nhắn báo lỗi lúc 16 giờ bị 40 tin nhắn khác đẩy lên trên; sáng hôm sau không ai nhớ.
- Hỏi tiến độ bằng nhắn riêng. Khách không biết yêu cầu đang ở đâu nên nhắn thẳng cho lập trình viên, người này dừng code để trả lời.
- Hai người cùng làm, hoặc không ai làm. Không có trường “người phụ trách”, chỉ có ai đọc trước thì làm.
- Không đếm được gì. Tháng này nhận bao nhiêu yêu cầu, trả lời trung bình sau bao lâu, lỗi tập trung ở phân hệ nào: không ai trả lời được.
- Khách thấy bị bỏ rơi. Không phải vì đội chậm, mà vì khách không thấy gì cho tới khi có người trả lời.
Cái giá thật của nhóm chat là thời gian người quản lý bỏ ra mỗi ngày để đọc lại, chép sang chỗ khác và trả lời “đã nhận”, cộng với sự tin cậy của khách bị bào mòn từng chút.
Vòng đời một yêu cầu
| Trạng thái | Nghĩa là | Ai làm | Khách thấy gì |
|---|---|---|---|
| Mới | Vừa vào hệ thống, chưa ai đọc. Đồng hồ hạn phản hồi bắt đầu chạy. | Người trực đọc trong ngày | Mã yêu cầu và hạn phản hồi |
| Đã tiếp nhận | Đã đọc, phân loại, giao người phụ trách, đã trả lời khách lần đầu. | Người trực | Ai phụ trách, hướng xử lý |
| Đang xử lý | Đã chuyển thành việc trên bảng của đội hoặc liên kết với việc có sẵn. | Người phụ trách và đội | Tiến độ của việc liên quan |
| Đã xử lý | Việc liên quan đã xong; chờ khách kiểm tra. | Tự động khi việc xong | Thông báo mời xác nhận |
| Đã đóng | Khách xác nhận, hoặc không phản hồi sau 7 ngày. | Khách, hoặc tự động | Yêu cầu vào lịch sử |
| Từ chối | Không làm, có lý do: ngoài phạm vi, trùng, không tái hiện được. | Người phụ trách | Lý do từ chối |
Khách mở lại được yêu cầu đã xử lý nếu vấn đề chưa hết; yêu cầu quay về Đang xử lý. Điểm quan trọng: chỉ khách mới khép được vòng, đội chỉ chuyển sang Đã xử lý. Điều này khác hẳn nhóm chat, nơi “xong” là khi đội nói xong.
Bốn thứ một hệ thống tiếp nhận phải có
| Thành phần | Vì sao cần | Kiểm tra |
|---|---|---|
| 1. Một đường vào duy nhất | Khách gửi ở đâu cũng đổ về một chỗ: cổng có tài khoản, biểu mẫu nhúng trong phần mềm, API từ hệ thống của khách, hay tin nhắn dán vào bot. | Có yêu cầu nào đang nằm ngoài hệ thống không? |
| 2. Phân loại | Loại (báo lỗi, đề xuất, hỗ trợ, câu hỏi) để đúng người xử lý; mức độ (thấp, trung bình, cao, nghiêm trọng) để đúng hạn. | Hai người khác nhau có xếp cùng mức độ cho cùng yêu cầu không? |
| 3. Cam kết thời gian | Hạn phản hồi lần đầu theo mức độ, đồng hồ chạy tự động, cảnh báo khi sắp trễ. | Người phụ trách có được báo trước khi trễ, hay chỉ biết khi khách phàn nàn? |
| 4. Nối với việc của đội | Yêu cầu chuyển thành việc trên bảng, việc xong thì yêu cầu tự cập nhật; không chép tay hai lần. | Đóng một việc trên bảng, khách có tự nhận được thông báo không? |
Thiếu thành phần nào cũng lộ ra sau vài tuần: thiếu 1 thì lại có nhóm chat song song, thiếu 2 thì mọi thứ đều “gấp”, thiếu 3 thì hạn chỉ là lời hứa, thiếu 4 thì người quản lý thành người chép sổ. Cách chia mức độ và hạn theo mức có ở SLA là gì?.
Quy trình trực mỗi ngày, năm bước
Người trực làm gì, theo thứ tự
- Đầu giờ sáng và đầu giờ chiều: mở hộp thư. Lọc trạng thái Mới. Không để yêu cầu Mới qua đêm; luân phiên người trực theo tuần.
- Đọc và phân loại. Đặt loại, mức độ theo định nghĩa đã thống nhất với khách, gán phân hệ, giao người phụ trách. Mức độ đo tác động, không đo khách to hay nhỏ.
- Trả lời lần đầu trong hạn, ba câu. Đã nhận và hiểu vấn đề; cần thêm gì hoặc hướng xử lý; khi nào có tin tiếp. Trả lời không có nghĩa là đã sửa.
- Quyết định. Chuyển thành việc mới, liên kết với việc có sẵn nếu trùng, hoặc từ chối kèm lý do. Lỗi nghiêm trọng vào thẳng sprint đang chạy và đổi việc khác ra.
- Khép vòng. Việc xong thì mời khách kiểm tra; khách xác nhận thì đóng; 7 ngày không phản hồi thì tự đóng, và vẫn mở lại được.
Mẫu trả lời lần đầu
Kế hoạch hai tuần rời nhóm chat
| Thời điểm | Việc | Lưu ý |
|---|---|---|
| Ngày 1–2 | Mở cổng, tạo tài khoản cho đầu mối của từng khách, thống nhất bốn mức độ và hạn phản hồi bằng một trang A4 gửi khách. | Mỗi khách một hoặc hai đầu mối, không mở cho mọi người dùng cuối ngay |
| Ngày 3 | Ghim trong nhóm chat: “Từ thứ Hai, báo lỗi và đề xuất qua địa chỉ này; em sẽ trả lời trong hạn ghi trên trang”. Gửi kèm hướng dẫn 3 bước có ảnh. | Nói rõ lợi ích cho khách: biết ai làm, đến đâu, không phải hỏi lại |
| Tuần 1 | Yêu cầu vẫn đến qua chat thì người trực tự tạo trên cổng rồi trả lời trong chat bằng mã và link. Không trách ai. | Khách quen dần nhờ thấy mã và tiến độ |
| Tuần 2 | Chỉ trả lời chi tiết trên cổng; trong chat chỉ gửi link. Gửi khách báo cáo tuần đầu: số yêu cầu, tỉ lệ đúng hạn. | Con số đầu tiên là thứ thuyết phục khách ở lại cổng |
| Sau hai tuần | Nhóm chat giữ để trò chuyện và hỏi nhanh; mọi thứ cần theo dõi đều có mã trên cổng. | Không cần giải tán nhóm, chỉ đổi vai của nó |
Ví dụ thật: phòng CNTT phục vụ nhiều phòng ban
Ví dụ
Đại học Công nghiệp Hà Nội dùng Pentara từ tháng 8/2026. Ở đây “khách hàng” là các phòng ban trong trường, mỗi phòng là một tổ chức khách hàng có đầu mối riêng gửi yêu cầu qua cổng; trước đó yêu cầu đến qua tin nhắn và gọi thẳng lập trình viên.
Số liệu từ bản đang chạy, tính đến 25/09/2026: 15 dự án đang chạy, 498 công việc đã hoàn thành, 21 yêu cầu khách hàng đã khép vòng, 6 tổ chức khách hàng.
Thay đổi lớn nhất không nằm ở số yêu cầu mà ở chỗ mỗi yêu cầu có người phụ trách và có mốc xác nhận của phòng gửi. Đầu mối phòng ban không còn nhắn riêng hỏi tiến độ, vì họ tự thấy trên cổng. Câu chuyện đầy đủ ở trang dành cho phòng CNTT; đội làm phần mềm cho khách bên ngoài xem trang dành cho công ty phần mềm.
Năm lỗi hay gặp
Đội mới mở cổng hay mắc
- Giữ hai đường song song “cho tiện”. Nhận qua chat rồi hứa “sẽ tạo sau”; sau một tháng cổng trống, chat vẫn đầy. Người trực tạo hộ ngay tại chỗ.
- Để khách tự đặt mức độ mà không có định nghĩa. Mọi yêu cầu thành Nghiêm trọng. Giữ định nghĩa bốn mức trên một trang, người trực chỉnh lại và giải thích.
- Xem phản hồi lần đầu là đã xong. Trả lời “đã nhận” rồi im ba tuần; đúng hạn phản hồi mà mất khách. Cam kết thêm hạn xử lý cho hai mức cao.
- Không ai trực. Ai rảnh thì đọc, nghĩa là không ai đọc. Luân phiên theo tuần, có người dự phòng khi nghỉ phép.
- Không gửi báo cáo cho khách. Khách đánh giá bằng lần trễ gần nhất họ nhớ. Báo cáo hằng tháng, kể cả tháng có yêu cầu trễ, kèm lý do.
Nếu đội chủ yếu xử lý yêu cầu và ít xây tính năng mới, nhịp Kanban với giới hạn việc đang làm hợp hơn sprint: xem Kanban là gì?. Đội mới quản lý dự án lần đầu đọc thêm Quản lý dự án phần mềm: hướng dẫn cho đội mới bắt đầu.
Quản lý yêu cầu khách hàng trên Pentara
Bốn đường vào đổ chung một hộp thư của dự án: cổng khách hàng, nơi đầu mối của mỗi tổ chức khách hàng đăng nhập để gửi yêu cầu, xem tiến độ, xác nhận hoặc mở lại, chỉ thấy dữ liệu của tổ chức mình; biểu mẫu nhúng, một thẻ script đặt vào phần mềm đã bàn giao để người dùng cuối bấm “Gửi phản hồi” ngay trong app; API và webhook để hệ thống của khách đẩy lỗi sang tự động; nhập tay khi khách gọi điện. Gói Chuyên nghiệp thêm bot Telegram và Zalo: dán tin nhắn của khách vào bot, Pentara tạo yêu cầu đúng dự án.
Mỗi yêu cầu có loại (Báo lỗi, Đề xuất tính năng, Hỗ trợ, Câu hỏi), mức độ và hạn phản hồi lần đầu 4 giờ, 24 giờ, 72 giờ hoặc 7 ngày theo mức độ; huy hiệu đổi màu khi còn 25% thời gian và khi quá hạn, kèm thông báo cho người phụ trách. Phản hồi gửi khách dừng đồng hồ, ghi chú nội bộ thì không. Nút Chuyển thành task điền sẵn thông tin lên Board; mọi task liên quan xong thì yêu cầu tự sang Đã xử lý và khách nhận thông báo xác nhận, 7 ngày không phản hồi thì tự đóng. Tab Báo cáo có tỉ lệ đúng SLA, thời gian phản hồi và xử lý trung bình theo nguồn, phân hệ, mức độ.
Cổng khách hàng, biểu mẫu nhúng và API có sẵn trong gói Miễn phí. Bắt đầu bằng đăng ký đơn vị, tạo một tổ chức khách hàng và một đầu mối, gửi thử một yêu cầu từ cổng; hướng dẫn chi tiết cách tiếp nhận ở chương Yêu cầu khách hàng, mức độ và SLA và Bắt đầu nhanh.
Hỏi đáp nhanh
- Khách không chịu dùng cổng, vẫn nhắn Zalo thì sao?
- Đừng cấm, đổi vai của nhóm chat. Trong hai tuần đầu, người trực tự tạo yêu cầu trên cổng hộ khách rồi trả lời trong chat bằng mã và đường dẫn; khách thấy có mã, có người phụ trách, có tiến độ sẽ tự chuyển. Sau đó chỉ trả lời chi tiết trên cổng, trong chat chỉ gửi link. Báo cáo tuần đầu với tỉ lệ đúng hạn là thứ thuyết phục nhất.
- Nên cho khách tự đặt mức độ không?
- Cho khách chọn, nhưng người trực có quyền chỉnh lại theo định nghĩa bốn mức đã gửi khách bằng văn bản, và giải thích khi chỉnh. Không có định nghĩa chung thì mọi yêu cầu sẽ thành Nghiêm trọng. Mức độ đo tác động lên người dùng, ưu tiên làm trước hay sau là quyết định riêng của đội.
- Phòng ban nội bộ có tính là khách hàng không?
- Có, và nên đối xử như khách: mỗi phòng ban là một tổ chức khách hàng với một hoặc hai đầu mối, gửi yêu cầu qua cổng, có hạn phản hồi. Phòng CNTT làm vậy tránh được việc mọi người trong trường nhắn thẳng cho lập trình viên và có số liệu để báo cáo lãnh đạo.
- Phản hồi lần đầu nên viết gì?
- Ba câu: đã nhận và hiểu vấn đề gì, kèm mã yêu cầu; ai phụ trách và hướng xử lý hoặc cần khách cung cấp thêm gì; khi nào có tin tiếp theo. Phản hồi lần đầu không phải là đã sửa xong, nhưng phải đúng hạn theo mức độ; ghi chú nội bộ giữa đội với nhau không tính là phản hồi.