Khách viết: “Tôi đã hỏi hai lần rồi, sao vẫn chưa giải quyết?” Một câu trả lời dài về quy trình lúc này có thể khiến cuộc trao đổi căng thêm. Xử lý khiếu nại khách hàng bắt đầu từ việc gọi đúng vấn đề, xác định điều có thể kiểm tra và đưa ra một bước tiếp theo mà người phụ trách thực hiện được. Bạn không cần nói thật nhiều; bạn cần làm cho khách hiểu ai đang xử lý việc gì và khi nào họ nhận được thông tin mới.
Trong công việc hỗ trợ, chăm sóc khách hàng hoặc vận hành nội dung, một khiếu nại thường mang theo cả sự bất tiện lẫn khoảng trống thông tin. Bài viết này dùng tình huống bản sửa chưa tới tay khách để luyện cách phản hồi, chuyển việc và theo dõi đến cuối. Bạn có thể đổi sản phẩm trong ví dụ thành dịch vụ mình đang phụ trách, nhưng cần giữ nguyên nguyên tắc: chỉ xác nhận những gì đã biết, không hứa vượt quyền.
Mục lục
Đọc điều khách cần trước khi tìm câu trả lời mẫu
Một tin nhắn có thể chứa nhiều lớp: khách nói chưa nhận được tệp, đã mất thời gian hỏi lại và lo rằng lịch của họ bị ảnh hưởng. Nếu chỉ đáp “bên em đã tiếp nhận”, bạn chưa cho thấy mình hiểu phần nào đang gây bất tiện. Hãy đọc lịch sử trao đổi trước, ghi lại yêu cầu ban đầu, mốc đã hẹn và phản hồi mới nhất. Khi lịch sử chưa đầy đủ, nói rõ phần cần xác nhận thay vì suy đoán người trước đã xử lý sai.
Hướng dẫn của Zendesk về phản hồi tiêu cực nhấn mạnh việc ghi nhận vấn đề cụ thể trước khi đi vào giải pháp. Áp dụng vào ví dụ, câu mở đầu có thể là: “Em hiểu anh/chị đang chờ bản sửa và đã phải liên hệ lại. Em sẽ kiểm tra đúng yêu cầu này để cập nhật bước tiếp theo.” Câu này nhận diện sự bất tiện, nhưng chưa khẳng định nguyên nhân khi bạn chưa kiểm tra.
Tránh nhắc lại toàn bộ câu phàn nàn theo kiểu máy móc. Nếu khách đã gửi mã yêu cầu ở tin nhắn trên, hãy sử dụng mã đó. Hỏi lại một thông tin vừa được cung cấp làm khách phải làm thêm việc và khiến lời nói “em đã kiểm tra” thiếu thuyết phục. Cũng đừng mở đầu bằng một đoạn giới thiệu công ty; lúc này khách đang cần một câu trả lời gắn với việc của họ.
Tách sự kiện, mong muốn và điều còn chưa rõ
Thử ghi ba dòng trong ghi chú nội bộ. Sự kiện: khách nói chưa thấy bản sửa trong hộp thư. Mong muốn: nhận được tệp để kịp xem. Điều chưa rõ: tệp đã gửi chưa, gửi phiên bản nào và qua địa chỉ nào. Ba dòng này giúp bạn không nhầm “khách chưa nhận được” với “bộ phận xử lý chưa làm”. Hai khả năng dẫn đến cách kiểm tra khác nhau.
Chỉ hỏi những câu làm thay đổi hướng xử lý. Chẳng hạn, nếu có hai địa chỉ nhận tệp trong lịch sử, bạn cần xác nhận địa chỉ đang dùng qua kênh riêng phù hợp. Nếu đã có tệp đính kèm, hãy kiểm tra quyền truy cập trước khi yêu cầu khách gửi ảnh màn hình. Không yêu cầu mật khẩu, mã xác thực hay dữ liệu tài khoản không cần thiết để tìm một bản thảo.
Khách có thể yêu cầu “gửi ngay”, trong khi bạn cần một người khác xác nhận phiên bản. Khi đó, diễn đạt giới hạn bằng việc cụ thể: “Em cần đối chiếu bản đã duyệt trước khi gửi để tránh gửi nhầm. Em sẽ cập nhật tình trạng vào mốc đã thống nhất.” Đây là lời giải thích có mục đích, dễ hiểu hơn việc viện dẫn một tên quy trình nội bộ mà khách không biết.
Đưa ra lời hẹn nằm trong khả năng thực hiện
“Em xử lý ngay” nghe nhanh nhưng không cho khách biết kết quả nào sẽ đến. Một lời hẹn tốt nói rõ bạn sẽ kiểm tra, gửi bản đã xác nhận hay cập nhật tình trạng. Nếu chưa kiểm soát được thời điểm có kết quả cuối cùng, đừng hứa thời điểm hoàn tất. Bạn vẫn có thể cam kết một mốc cập nhật mà mình chủ động thực hiện.
Ví dụ luyện tập: “Em đang kiểm tra lịch sử gửi và quyền mở tệp. Em sẽ cập nhật lại trước 15:00 theo giờ Colombo hôm nay. Nếu bản sửa chưa được xác nhận, em sẽ báo rõ phần đang chờ và mốc tiếp theo.” Trước khi gửi, thay thời gian bằng mốc thực sự phù hợp với ca làm và quy định của nhóm. Nếu khách ở nơi khác, ghi cả múi giờ hoặc dùng một mốc được hai bên thống nhất.
Đừng biến lời hẹn thành một lời trấn an không có người theo dõi. Tạo nhắc việc hoặc ghi vào hệ thống mà nhóm đang sử dụng. Người đang nhận yêu cầu cần biết lúc nào phải kiểm tra lại, kể cả khi chưa có kết quả mới. Một cập nhật ngắn đúng hẹn thường hữu ích hơn sự im lặng kéo dài rồi giải thích rằng bạn vẫn đang chờ người khác.
Chuyển việc mà không bắt khách kể lại từ đầu
Có những việc vượt quyền người tiếp nhận: thay điều khoản, hoàn tiền hoặc xác nhận một thay đổi kỹ thuật. Hãy chuyển đến đúng người theo quy định thực tế của nhóm, kèm tóm tắt có thể dùng ngay. Không tự hứa một phương án tài chính hay ngoại lệ chỉ để làm cuộc trao đổi dịu xuống. Nếu cần phê duyệt, nói rõ đây là bước đang chờ xác nhận.
Một bản bàn giao ngắn có thể gồm mã yêu cầu, điều khách phản ánh, những gì đã kiểm tra, phần cần quyết định và mốc đã hẹn với khách. Trong ví dụ bản sửa, hãy ghi tên phiên bản đã tìm thấy và quyền truy cập đã thử. Câu “khách đang bực, nhờ xử lý” truyền cảm xúc nhưng thiếu dữ kiện để người nhận làm việc.
Tài liệu Zendesk về giải quyết ticket cho thấy vai trò của lịch sử trao đổi và việc phân công trong quá trình hỗ trợ. Bạn không cần dùng cùng phần mềm để áp dụng cách bàn giao rõ. Điều cốt lõi là giữ thông tin tại nơi người có trách nhiệm tìm được, thay vì chia thành nhiều đoạn chat riêng không ai thấy toàn cảnh.
Khi đồng nghiệp khác múi giờ tiếp nhận, hãy xem thêm cách viết tin nhắn bàn giao để công việc đi tiếp. Một yêu cầu có đủ bối cảnh và quyết định cần đưa ra giúp hạn chế vòng hỏi lại, đặc biệt khi hai người không cùng trực tuyến.
Khi khách tiếp tục căng thẳng hoặc yêu cầu điều chưa thể đáp ứng
Không tranh luận từng câu trong lúc khách đang muốn biết kết quả. Hãy quay về sự kiện và lựa chọn thực tế: bạn có thể kiểm tra phần nào, phương án nào được phép và ai có quyền xác nhận phần còn lại. Nếu khách đưa thêm thông tin, cập nhật hướng xử lý thay vì bảo vệ câu trả lời cũ chỉ vì đã gửi nó trước đó.
Bạn cũng cần giữ ranh giới trao đổi chuyên nghiệp. Khi có lời đe dọa hoặc hành vi vi phạm quy định hỗ trợ, làm theo hướng dẫn của tổ chức và báo người phụ trách. Không tự đặt ra quy tắc ngừng hỗ trợ, cũng không đáp lại bằng lời công kích. Ghi nhận sự việc bằng nội dung cụ thể, tránh nhận xét về tính cách hay suy diễn ý định của khách.
Nếu cần trao đổi dữ liệu đơn hàng hoặc thông tin cá nhân, đưa cuộc trao đổi sang kênh riêng đã được tổ chức cho phép. Đừng yêu cầu khách đăng dữ liệu đó dưới bình luận công khai. Với bài học nghề nghiệp, bạn có thể ghi lại cách mình xử lý để chuẩn bị một câu chuyện phỏng vấn theo STAR, nhưng cần loại bỏ thông tin nhận diện khách.
Khép lại bằng kết quả và việc còn cần theo dõi
Gửi được tệp chưa chắc có nghĩa khách đã mở được. Sau khi thực hiện phương án, nói rõ mình đã làm gì và khách có cần kiểm tra điều gì không. Ví dụ: “Em đã gửi bản v2 qua kênh đã xác nhận và kiểm tra quyền xem. Anh/chị thử mở giúp em; nếu còn lỗi truy cập, báo lại trong yêu cầu này để em tiếp tục theo dõi.” Điều chỉnh câu chữ theo kênh và quy trình đang dùng.
Cuối ca, xem lại những yêu cầu còn mở và lời hẹn chưa đến hạn. Một khiếu nại được xử lý tốt để lại dấu vết rõ: khách đã nhận thông tin gì, ai chịu trách nhiệm tiếp theo và điều gì cần phòng tránh lần sau. Chọn một thay đổi nhỏ có thể làm ngay, như ghi phiên bản tệp rõ hơn hoặc xác nhận địa chỉ trước khi gửi. Chất lượng hỗ trợ nằm ở việc khách có thể tiếp tục công việc của họ, chứ không chỉ ở một câu trả lời lịch sự.
