Khi khách leo thang lên lãnh đạo: FDE làm gì trong 24 giờ đầu

Thử hình dung: chín giờ tối thứ Năm, CTO của khách gửi email thẳng cho CEO công ty bạn, cc thêm ba người. Agent trích xuất hóa đơn mà bạn deploy ba tuần trước đang đọc sai trường tổng tiền, và người ta không còn muốn nói chuyện với đội support nữa.

Từ lúc đó, mọi việc bạn làm đều diễn ra trước mặt lãnh đạo của cả hai bên. Ở một số vị trí, đây là phần việc được ghi thẳng vào mô tả công việc.

Tin tuyển dụng FDE mảng phòng chống churn của Tungsten Automation ghi rõ: FDE là đầu mối chính nhận những ca kỹ thuật khó, nhiều rủi ro mà quy trình hỗ trợ thông thường không xử lý được.

Vậy 24 giờ đầu nên dùng thế nào? Đừng lao ngay vào log. Hãy chạy song song hai luồng việc, sửa lỗi và báo tin, và chia thời gian thành ba chặng, chặng nào cũng phải ra được một sản phẩm cụ thể.

Vì sao tin báo phải đi trước bản vá?

Không ai biết chắc vì sao từng khách chọn vượt mặt kênh hỗ trợ. Nhưng thứ tự ưu tiên trong các playbook xử lý sự cố là một gợi ý đáng chú ý: việc đầu tiên được yêu cầu không phải bản vá, mà là một tin xác nhận gửi rất sớm, kèm lời hẹn sẽ cập nhật tiếp.

Lý do khá dễ suy ra. Một bản sửa lỗi hoàn hảo đến lúc 3 giờ sáng không bù được sáu tiếng khách ngồi chờ mà không biết ai đang xử lý, và xử lý đến đâu.

Google SRE Workbook mô tả ứng phó sự cố qua ba mục tiêu gọi là 3C, trong đó có việc giao tiếp giữa những người xử lý, trong nội bộ tổ chức và ra bên ngoài. Sách cũng gợi ý cách chia vai.

Người tuyên bố sự cố thường nhận vai Incident Commander (IC) để điều phối và giao việc. Communications Lead (CL) là bộ mặt của đội ứng phó với bên ngoài, tách khỏi người đang gỡ lỗi.

Dù vậy, việc tách vai vẫn có ích. Nếu có account manager hay đồng nghiệp, nhờ họ làm CL. Nếu không, hãy chia thời gian rõ ràng: hết giờ gỡ lỗi mới đến giờ viết cập nhật, đừng vừa debug vừa trả lời tin nhắn.

Chặng một, phút 0 đến 60: tuyên bố sự cố và gửi tin xác nhận

Quay lại email lúc chín giờ tối. Việc đầu tiên là tuyên bố sự cố trong kênh nội bộ và nhận vai IC. Việc thứ hai là gửi tin xác nhận cho khách. Playbook xử lý escalation B2B của Supportbench khuyên gửi tin này trong vòng một giờ.

Atlassian nêu ba việc tin đầu tiên phải làm: xác nhận có sự cố, tóm tắt ngắn tác động đã biết, và hứa sẽ cập nhật tiếp. Một mẫu bạn có thể soạn sẵn:

Chào anh/chị [tên],

Đội [tên công ty] đã nhận được phản ánh và đang xử lý sự cố này ngay lúc này.

Tác động đã biết: từ khoảng [giờ], một phần hóa đơn bị trích xuất
sai trường tổng tiền. Hóa đơn xử lý trước [giờ] không bị ảnh hưởng.
Biện pháp tạm thời: đội kỹ thuật đã [dừng tự động duyệt / chuyển sang
duyệt tay] để không có thêm số liệu sai đi vào hệ thống của anh/chị.

Cập nhật tiếp theo: lúc [giờ], kể cả khi chưa có tin mới.
Liên hệ trực tiếp: [tên, số điện thoại].

Tin này không đổ lỗi cho ai. Kể cả khi nguyên nhân hóa ra nằm ở một dịch vụ OCR bên thứ ba, Atlassian vẫn khuyên bạn nhận trách nhiệm về vấn đề và tỏ ra hiểu khách đang cảm thấy thế nào. Với khách, hệ thống là của bạn, còn nhà cung cấp phía sau là chuyện nội bộ của bạn.

Chặng hai, giờ 1 đến 6: tài liệu chung và nhịp cập nhật

Khi đã có từ ba người trở lên cùng xử lý, Google SRE Workbook khuyên mở một tài liệu chung ghi các giả thuyết đang xét và những nguyên nhân đã loại trừ. Trong ví dụ hóa đơn, tài liệu đó có thể có hai dòng như sau:

- Model đổi phiên bản? Đã loại trừ: không có deploy từ thứ Hai.
- Định dạng hóa đơn của một nhà cung cấp mới? Đang kiểm tra.

Bạn bớt phải giải thích lại cho từng người mới vào, và CL có ngay nguồn để viết cập nhật.

Về nhịp cập nhật, không có một con số chuẩn. Atlassian gợi ý 30 phút một lần, hoặc nhịp nào hợp với tình huống. Supportbench gắn nhịp với mức độ nghiêm trọng: Sev-1 mỗi giờ, Sev-2 mỗi ngày.

Con số cụ thể ít quan trọng hơn việc giữ lời. Đã hẹn mười giờ thì mười giờ phải có tin, dù nội dung chỉ là “vẫn đang kiểm tra giả thuyết B, đã loại A”.

Chặng ba, giờ 6 đến 24: kể nguyên nhân bằng ngôn ngữ của khách

Khi đã tìm ra nguyên nhân, Supportbench yêu cầu bản tóm tắt nguyên nhân gốc phải viết bằng ngôn ngữ của khách, không dán stack trace. Hãy xem cùng một sự thật được kể theo hai cách:

Bản bên phải trả lời đúng ba câu lãnh đạo bên khách quan tâm: chuyện gì đã xảy ra, dữ liệu của họ giờ ra sao, và lần sau có lặp lại không.

Trang tóm tắt cho người bảo trợ phải có trước khi ai đó hỏi

Song song với bản gửi khách, bạn cần một trang cho người bảo trợ cấp lãnh đạo phía mình. Ở Tungsten Automation, việc đưa cho những người bảo trợ này phân tích kỹ thuật chuyên sâu, hướng đi về kiến trúc và số liệu telemetry được ghi thẳng vào nhiệm vụ của FDE.

Thời điểm cần trang này không do bạn chọn. Ở Gainsight, người bảo trợ được gọi vào bất cứ khi nào CSM, trưởng nhóm hoặc VP nhờ, nên hãy viết nó từ chặng hai và sửa sau mỗi lần cập nhật khách.

Nó còn là hồ sơ của tài khoản: Supportbench khuyên gán một người bảo trợ có tên cho tài khoản nào leo thang hai lần trong một quý. Với ví dụ hóa đơn, trang đó có thể như sau:

Gửi: [người bảo trợ phía mình]
Khách: [tên] · Mức độ: Sev-1 · Trạng thái: đã khắc phục, đang theo dõi
Chuyện gì xảy ra: hóa đơn của một nhà cung cấp mới bị đọc nhầm
  tổng tiền sang dòng thuế, từ [giờ] đến [giờ].
Telemetry: [số hóa đơn bị ảnh hưởng] / [tổng hóa đơn trong khoảng đó];
  tỷ lệ chuyển duyệt tay từ [x] lên [y].
Kiến trúc: thêm bước kiểm tra mẫu lạ trước khi tự động duyệt, dự kiến [ngày].
Lịch sử: lần leo thang thứ [n] của tài khoản trong quý này.
Việc cần anh/chị: [ví dụ: gọi cho CTO bên khách trước 17h].

Dòng cuối là dòng quan trọng nhất. Người bảo trợ đọc xong phải biết ngay mình cần làm gì, chứ không phải gọi lại cho bạn để hỏi.

Những lỗi khiến một sự cố nhỏ thành khủng hoảng

Lỗi dễ mắc nhất là im lặng để sửa cho xong rồi mới báo. Cám dỗ này dễ hiểu, vì ai cũng muốn mang tin tốt đến. Nhưng mỗi giờ không có tin là thêm một giờ khách tự đoán, và câu chuyện họ tự đoán hiếm khi dễ nghe hơn sự thật.

Kế đến là hứa giờ sửa xong khi chưa biết nguyên nhân. Hãy hứa giờ cập nhật, đừng hứa giờ khắc phục. Cũng đừng đổ lỗi cho nhà cung cấp phía sau ngay trong tin gửi khách. Và đừng dán log vào email gửi lãnh đạo: người đọc không hiểu, và chỉ thấy bạn chưa nắm được vấn đề.

Biến kỹ năng này thành lợi thế khi đi xin việc

Khi đọc mô tả công việc FDE, hãy để ý các cụm như “escalation point”, “executive sponsor” hay “churn prevention”. Chúng cho biết vị trí đó sẽ đánh giá bạn qua chính những đêm như thế này. Khi phỏng vấn, hãy kể một sự cố theo ba chặng ở trên thay vì chỉ kể bạn đã sửa bug nào.

Trong CV, một dòng như “Làm đầu mối xử lý sự cố Sev-1 cho khách doanh nghiệp: gửi xác nhận trong một giờ, cập nhật theo giờ, viết báo cáo nguyên nhân cho lãnh đạo hai bên” cho nhà tuyển dụng thấy kỹ năng mà một dòng “fix production bugs” không thể hiện được.

Chặng cuối của 24 giờ không phải là bản vá. Đó là lúc CTO bên khách chuyển tiếp bản tóm tắt của bạn cho đội mình mà không cần sửa chữ nào.