Bài 7 — Phục hồi sau sự cố

Nghịch lý phục hồi dịch vụ

Một khách gặp sự cố và được xử lý xuất sắc đôi khi trung thành hơn khách chưa từng gặp sự cố nào. Lý do: phần lớn thời gian bạn chỉ nói rằng mình đáng tin. Sự cố là dịp hiếm hoi để chứng minh điều đó.

Điều này không có nghĩa là nên tạo ra sự cố. Nó có nghĩa là năng lực phục hồi đáng được đầu tư ngang với năng lực phòng ngừa.

Bốn bước phục hồi

• Thừa nhận nhanh. Tốc độ quan trọng hơn sự đầy đủ. Một tin nhắn trong 15 phút nói "chúng tôi đang xử lý, sẽ cập nhật sau 30 phút" tốt hơn một thông báo hoàn hảo sau ba tiếng.
• Nhận trách nhiệm, không đổ lỗi. Đổ cho nhà cung cấp hạ tầng nghe như né tránh. Khách mua dịch vụ từ bạn, không từ nhà cung cấp của bạn.
• Sửa, và nói rõ đã sửa gì. Không chỉ "đã khắc phục" mà "nguyên nhân là X, chúng tôi đã làm Y, và để nó không lặp lại chúng tôi đang làm Z".
• Theo dõi lại sau. Một tin nhắn vài ngày sau hỏi mọi thứ đã ổn chưa có tác động lớn hơn nhiều so với chi phí của nó.

Bước 4 bị bỏ gần như luôn, và nó là bước tạo khác biệt lớn nhất giữa "họ đã sửa" và "họ quan tâm".

Viết thông báo sự cố

Cấu trúc bốn phần, theo thứ tự này: cái gì đang hỏng (bằng ngôn ngữ khách hiểu, không phải thuật ngữ nội bộ), ảnh hưởng tới ai và ra sao, chúng tôi đang làm gì, khi nào cập nhật tiếp.

Phần cuối quan trọng nhất và hay bị bỏ. Không có nó, khách phải tự đi kiểm tra liên tục, và mỗi lần kiểm tra là một lần họ lại bực.

Bồi thường: khi nào và bao nhiêu

Bồi thường quá tay tạo ra kỳ vọng sai và đôi khi khuyến khích phàn nàn. Bồi thường quá ít thì như xúc phạm.

Nguyên tắc: bồi thường nên tương xứng với thiệt hại thật, và lời xin lỗi chân thành cùng việc sửa dứt điểm thường quan trọng hơn tiền. Với khách doanh nghiệp, thứ họ cần nhất thường không phải giảm giá mà là bằng chứng rằng điều đó sẽ không lặp lại — vì họ còn phải giải trình với sếp của họ.

Học từ sự cố

Mỗi sự cố nên để lại ba thứ: nguyên nhân gốc đã được sửa, một dấu hiệu cảnh báo sớm được thêm vào, và một cập nhật cho kịch bản phản hồi lần sau. Nếu sự cố chỉ để lại một bản tường trình, tổ chức chưa học được gì.

Sai lầm thường gặp

• Chờ có đầy đủ thông tin mới thông báo.
• Đổ lỗi cho nhà cung cấp.
• Không nói khi nào cập nhật tiếp.
• Bỏ bước theo dõi lại sau vài ngày.
• Coi bồi thường là cách thay thế cho việc sửa dứt điểm.

Checklist kết bài

• [ ] Tôi thừa nhận nhanh, trước khi có đầy đủ thông tin.
• [ ] Thông báo của tôi luôn nói khi nào cập nhật tiếp.
• [ ] Tôi theo dõi lại với khách sau vài ngày.
• [ ] Mỗi sự cố để lại nguyên nhân gốc đã sửa và một cảnh báo sớm mới.

<!--les-append-->

Mẫu thông báo sự cố

Bốn bước trong bài chỉ hữu ích nếu có sẵn mẫu để dùng lúc đang hoảng. Chuẩn bị trước:

Tin đầu tiên (trong 15 phút): > Chúng tôi đang gặp sự cố ảnh hưởng tới [chức năng]. Đội đang xử lý. Cập nhật tiếp theo trong 30 phút.

Ngắn, không đổ lỗi, có cam kết thời điểm cập nhật. Cam kết thời điểm quan trọng hơn nội dung — nó cho khách biết khi nào cần quay lại, thay vì phải tự kiểm tra liên tục.

Tin cập nhật (đúng hẹn, kể cả khi chưa có gì mới): > Vẫn đang xử lý. Nguyên nhân đã xác định là [nếu biết]. Dự kiến khôi phục [thời gian]. Cập nhật tiếp lúc [giờ].

Gửi đúng hẹn kể cả khi không có tiến triển. Im lặng là thứ phá niềm tin, không phải tin xấu.

Tin kết thúc: > Đã khôi phục lúc [giờ]. Nguyên nhân: [ngắn gọn, không kỹ thuật]. Ảnh hưởng: [cụ thể]. Chúng tôi sẽ [hành động cụ thể] để việc này không lặp lại.

Ba lỗi khi thông báo

Bồi thường: khi nào và bao nhiêu

Nguyên tắc: bồi thường nên đến trước khi khách hỏi. Một khoản nhỏ được đề nghị chủ động có giá trị lớn hơn nhiều một khoản lớn phải đòi.

Và bồi thường không thay được lời giải thích. Khách muốn biết chuyện gì xảy ra nhiều hơn là muốn được giảm giá — nhất là khách doanh nghiệp, vì họ phải giải thích lại cho sếp của họ.

Làm ngay

Viết sẵn ba mẫu tin ở trên cho sản phẩm của bạn, hôm nay, lúc không có sự cố. Lưu ở chỗ đội trực tìm được trong 30 giây. Viết mẫu lúc đang hoảng là lúc viết tệ nhất. <!--/les-append-->