Biểu mẫu tư vấn và hộp thư CMS giúp tiếp nhận khách thế nào?

Một lời nhắn tự do thường thiếu thông tin để nhân viên chuẩn bị tư vấn. Biểu mẫu có cấu trúc giúp hỏi đúng nhu cầu, còn hộp thư trong CMS giúp tìm lại yêu cầu đã gửi thay vì phụ thuộc hoàn toàn vào email. Hai phần cần được thiết kế cùng quy trình tiếp nhận của doanh nghiệp.

Khi nào nên chia biểu mẫu theo nhu cầu?

Nếu website nhận nhiều loại yêu cầu, mỗi biểu mẫu nên có tập câu hỏi phù hợp. Chẳng hạn, người hỏi thiết kế website có thể cần mô tả ngành nghề và website tham khảo; người cần hỗ trợ sau bàn giao lại cần trang đang lỗi, tình huống gặp phải và ảnh. Đây là ví dụ giả định, không phải dữ liệu của khách hàng cụ thể.

Trong CMS Dybi, các trường được tập hợp bằng nhóm liên hệ. Một trường có thể thuộc nhiều nhóm để dùng lại ở những biểu mẫu khác nhau. Đổi nhãn hoặc lựa chọn của một trường dùng chung vì thế cần xem xét tất cả nhóm đang dùng, thay vì chỉ nhìn một trang.

Thông tin nào có thể thu thập?

Ngoài tên và số điện thoại, biểu mẫu hỗ trợ trường chữ, đoạn văn, số, ngày, màu, ảnh, có/không, chọn một hoặc chọn nhiều phương án. Nên hỏi những gì thực sự phục vụ bước tư vấn tiếp theo; không thêm một trường chỉ vì phần mềm có sẵn loại đó.

Ví dụ giả định, nhóm Yêu cầu hỗ trợ có thể dùng mô tả vấn đề và một ô ảnh. Luồng hiện tại nhận JPG/PNG, mỗi ảnh không quá 2 MB và 16 triệu điểm ảnh, tối đa ba ảnh trong mỗi ô đính kèm. Người gửi cần chọn lại ảnh sau lần gửi chưa thành công nếu biểu mẫu yêu cầu.

Các câu hỏi mở rộng hiện không có công tắc đặt từng trường thành bắt buộc trong màn hình khai báo. Đừng xây quy trình dựa trên giả định khách luôn điền đủ mọi trường. Tên và số điện thoại được kiểm tra riêng khi gửi.

Từ gửi biểu mẫu đến nhân viên tiếp nhận

1. Khách mở đúng biểu mẫu, đọc mục đích, nhập thông tin và gửi.
2. Hệ thống kiểm tra dữ liệu, mã xác nhận khi có và điều kiện chống gửi lặp, rồi lưu liên hệ.
3. Nếu đã cấu hình địa chỉ người nhận, hệ thống thử gửi email thông báo. Lỗi email không làm mất liên hệ đã lưu.
4. Nhân viên mở mục Liên hệ trong CMS, tìm theo tiêu đề, tên hoặc số điện thoại rồi đọc chi tiết.
5. Nhân viên xác minh nhu cầu và phản hồi bằng kênh làm việc của doanh nghiệp.

Điểm cần thống nhất là ai kiểm tra hộp thư CMS và kiểm tra vào lúc nào. Có dữ liệu tiếp nhận không đồng nghĩa đã có người liên hệ lại; một email đến hộp thư cũng không tự xác nhận công việc đã hoàn tất.

Đã đọc khác với đã giải quyết

Mở chi tiết một liên hệ chưa đọc sẽ tự đánh dấu đã đọc khi cập nhật thành công. Người quản lý cũng có thể chọn nhiều yêu cầu trên trang danh sách để đánh dấu cùng lúc. Đây là trạng thái xem thông tin, không phải kết quả tư vấn.

Màn hình hiện tại không có bộ trạng thái phân công, đang xử lý, hoàn tất, lịch nhắc lại hoặc hộp trả lời email. Nếu quy trình cần các bước đó, hãy nêu rõ khi khảo sát giải pháp hoặc theo dõi ở công cụ làm việc đã thống nhất; đừng dùng Xóa thay cho Hoàn tất.

Khi thay biểu mẫu đang có dữ liệu

Một nhóm đang được biểu mẫu hoặc lịch sử liên hệ sử dụng không được xóa. Trường đã có dữ liệu liên hệ cũng bị chặn xóa để giữ lịch sử. Muốn bỏ một câu hỏi khỏi một biểu mẫu, có thể gỡ nhóm áp dụng rồi lưu, thay vì xóa định nghĩa dùng chung.

Cần chú ý nguồn chưa phân nhóm: nó chỉ chứa các trường chưa gắn nhóm nào. Bỏ hết nhóm của một trường có thể khiến trường xuất hiện tại một biểu mẫu dùng nguồn chưa phân nhóm. Trước khi đổi, hãy đối chiếu các biểu mẫu đang hoạt động.

Biểu mẫu có sẵn chưa phải hệ thống đặt lịch tự động

Trường ngày hoặc câu hỏi thời gian mong muốn giúp tiếp nhận một đề nghị. Chúng không tự kiểm tra lịch trống, giữ phòng, chống trùng nhân viên hay xác nhận cuộc hẹn. Nếu dùng để nhận yêu cầu đặt lịch, nhân viên vẫn cần kiểm tra khả năng phục vụ rồi xác nhận lại với khách theo phạm vi đã triển khai.

Để bắt đầu, liệt kê từng loại yêu cầu, người tiếp nhận và những thông tin cần biết trước khi gọi lại. Sau đó đọc hướng dẫn cấu hình nhóm và thuộc tính liên hệ cùng hướng dẫn quản lý liên hệ trong CMS. Khi gặp vấn đề thư thông báo, dùng hướng dẫn kiểm tra email để tách lỗi lưu và lỗi gửi.