Chương 9: Bản giải trình thứ hai

Chương 9: Bản giải trình thứ hai

Cảnh báo trên CRM đứng yên giữa màn hình như một chiếc kim đồng hồ bị kẹt đúng chỗ đau nhất: trước 17:00. Tôi nhìn dòng yêu cầu của chị Vân thêm một lần nữa, tự nhắc mình không được để chữ “đính chính” kéo cả phòng support vào một cái bẫy khác. Đính chính không phải xin lỗi thay, cũng không phải viết lại câu chuyện cho êm tai hơn. Nó chỉ nên là việc đặt thông tin sai về đúng vị trí của nó, với đủ mốc thời gian và đủ người chịu trách nhiệm.

Nhóm incident vốn đã im vài giây sau email 15:31, lúc này bỗng sáng lên liên tục. Anh Hải tạo một cuộc họp khẩn ngay trên Teams, tiêu đề ngắn đến lạnh: “Dai Phu correction before 17:00.” Tôi vừa bấm tham gia vừa mở song song CRM version history, call note lúc 16:03 và file .eml vừa lưu. Hương không nói gì, chỉ kéo ghế ngồi lệch sau lưng tôi một chút.

Giọng anh Hải vang lên trước, khô và thấp: “Hiện tại khách yêu cầu văn bản đính chính. Trước khi soạn bất cứ câu nào, tôi cần Mai giải thích cơ sở email 15:31.” Chị Mai mất gần mười giây mới trả lời: “Em gửi để trấn an khách. Lúc đó sales có thông tin forecast mới nhất là sáu container. Em dùng wording hơi nhanh, không có ý kết luận support sai.” Anh Hải hỏi ngay: “Nguồn nào xác nhận forecast đã được ghi nhận từ sáng là 6x40HC?” Chị Mai đáp nhỏ hơn: “Theo trao đổi với Khoa.” Anh Hải chuyển sang anh Khoa: “Call note cuộc gọi sau 15:00 đâu?” Anh Khoa thở ra nghe rõ qua micro. “Em đang ghi lại. Lúc đó khách gọi gấp, em không kịp note ngay. Em chỉ nói forecast mới nhất Đại Phú muốn giữ sáu cont, team đang kiểm tra space. Không có chuyện em cố tình đổ lỗi cho support.”

Tôi đặt tay lên bàn phím nhưng chưa gõ. Câu “không cố tình” luôn là một cái áo rất rộng. Nó có thể trùm lên một email sai, một câu nói thiếu mốc, một cuộc gọi không có note, thậm chí cả một chữ ký bị đẩy sang bàn người khác. Chị Thảo lên tiếng trước tôi: “Không ai đang hỏi ý định. Mọi người đang hỏi dữ kiện. Nếu không có nguồn xác nhận từ sáng là 6x40HC, văn bản đính chính phải nói rõ email 15:31 dùng wording chưa chính xác về timeline.” Chị Mai vội nói: “Nếu viết vậy khách sẽ hiểu nội bộ mình sai hoàn toàn.” Chị Nhung, im lặng từ đầu, bỗng chen vào: “External communication sai timeline thì nội bộ phải ghi nhận là sai timeline. Cách diễn đạt có thể kiểm soát, nhưng không thể biến nó thành đúng.”

Một file Word được chị Mai thả vào nhóm họp: “Draft correction v1.” Tôi mở ở chế độ preview. Đoạn đầu đọc rất trơn: “Due to ongoing internal checking, our support team requires more time to verify why final space was not secured as expected.” Tôi nhìn câu ấy, máu trong người như chậm lại. Không có chữ “support failed”, nhưng toàn bộ trọng lượng vẫn rơi xuống support. Bản đính chính này không sửa email 15:31; nó chỉ đánh bóng cái gai cho dễ nuốt hơn.

Tôi bật micro. “Em xin phép góp ý trên dữ kiện. Câu này vẫn giữ giả định support có trách nhiệm secure final space cho forecast 6x40HC từ sáng, trong khi hiện tại chưa có nguồn xác nhận forecast 6x40HC là active/customer committed tại freeze time. Nếu gửi vậy, văn bản đính chính sẽ tiếp tục tạo một timeline sai.” Chị Mai đáp, giọng đã có cạnh: “Linh, khách không đọc kỹ technical như mình đâu. Khách chỉ cần thấy công ty đang xử lý.” Tôi nhìn vào dòng version history, từng mốc thời gian nằm thẳng hàng, lạnh hơn mọi câu dỗ dành. “Vì khách không đọc kỹ technical nên mình càng không nên đưa một câu có thể bị hiểu thành support nhận lỗi.”

Anh Hải hỏi: “Linh, đề xuất wording.” Tôi không nhận ngay. Tôi biết khoảnh khắc này rất dễ bị biến thành “Linh soạn văn bản cho khách”, rồi sau này nếu có vấn đề, người ta chỉ cần kéo file properties hoặc lịch sử chỉnh sửa để nói support là bên đưa câu chữ cuối. Tôi đáp: “Em có thể cung cấp timeline và wording dữ kiện, nhưng văn bản gửi khách cần do incident owner hoặc cấp quản lý ký. Phần của em chỉ là nguồn chứng cứ.” Chị Thảo nói ngay: “Đúng. Linh gửi timeline dạng bullet vào nhóm. Hải chốt văn bản. Không để support ký thay external correction.”

Tôi bắt đầu gõ, từng dòng một, không thêm tính từ nào. 15:08: CRM customer follow-up draft liên quan Đại Phú bị đặt hold, approval action bị khóa. 15:31: email external từ Mai Nguyen, cc Khoa Tran, không có CRM approval ID, nội dung ghi forecast recorded since morning as 6x40HC và support checking why final space was not secured in time. 15:49: forecast bị freeze để audit version history. 16:03: support call note ghi nhận khách thông tin đã nhận email/call từ Sales; support không xác nhận kết luận trách nhiệm. 16:07: khách yêu cầu văn bản đính chính trước 17:00 nếu email 15:31 không đúng. Tôi đọc lại một lần, xóa chữ “sai” ở dòng 15:31, thay bằng “chưa có căn cứ trên CRM tại thời điểm kiểm tra.” Chứng cứ không cần nóng giận. Chứng cứ càng lạnh càng khó bị bẻ.

Anh Bình nhắn riêng vào nhóm incident, không phải nhóm họp: “Mail 15:31 gửi trực tiếp từ Outlook, không qua CRM mail sync. Không thấy approval token. Em đang export server log.” Tôi chuyển dòng đó vào timeline với trạng thái “IT pending confirmation”, không viết như kết luận. Hương ghé sát màn hình, thì thầm: “Chị để chữ pending là đúng. Đừng để họ nói mình kết luận thay IT.” Tôi khẽ gật đầu. Con bé học rất nhanh, hoặc đúng hơn, phòng này đã ép người ta học rất nhanh cách tự bảo vệ mình.

Bản nháp thứ hai xuất hiện lúc 16:32, lần này từ anh Hải. Câu chữ đã khác: “We would like to clarify that the email sent at 15:31 contained an incomplete description of the forecast timeline. Based on records currently under audit, we have not identified an approved record showing 6x40HC as the active/customer-committed forecast at the relevant freeze time. We are separating operational mitigation for the current shipment from responsibility review and will provide follow-up through the official incident thread.” Tôi đọc chậm từng câu. Nó không hoàn hảo, vì trong một công ty đang cháy, không có văn bản nào hoàn hảo. Nhưng ít nhất nó không bắt support quỳ xuống trong khi người khác đứng sau cầm bút.

Chị Mai nói: “Câu ‘email sent at 15:31 contained incomplete description’ có cần ghi rõ vậy không? Khách sẽ biết mail đó là từ em.” Cuối cùng anh Hải nói: “Khách đang cầm mail đó. Việc khách biết không phải do câu này.” Anh Khoa chen vào: “Em vừa upload call note. Mọi người xem giúp.” Một file mới hiện lên trong nhóm: “Khoa_callnote_DaiPhu_1500_v2.docx.” Chữ “v2” làm tôi nhìn lâu hơn cần thiết. Trong một ngày mà tất cả đều phải giữ nguyên bản gốc, một bản giải trình mang tên v2 luôn có mùi của thứ đã được chỉnh để vừa một câu chuyện nào đó.

Tôi mở file. Ba dòng đầu khá chung: khách hỏi tình trạng slot, sales cập nhật forecast mới nhất, sales cam kết nội bộ đang kiểm tra. Đến dòng thứ tư, mắt tôi dừng lại. “Đã trao đổi với support phụ trách case, support nắm tình trạng forecast 6x40HC và đang kiểm tra nguyên nhân chưa secure đủ space.” Không có tên tôi. Nhưng trong case này, support phụ trách là tôi. Câu ấy không đổ lỗi thẳng, nhưng nó dựng một cây cầu rất tiện: từ email 15:31 của chị Mai, qua call note v2 của anh Khoa, đến bàn làm việc của tôi.

Tôi nghe tiếng Hương hít vào. Lần này, tôi không chờ ai hỏi. Tôi gõ vào nhóm họp và đọc bằng giọng đều nhất có thể: “Em cần ghi nhận ngay: từ sau 15:00 đến thời điểm hiện tại, em không có cuộc trao đổi riêng nào với anh Khoa xác nhận support nắm forecast 6x40HC là active/customer committed hoặc xác nhận đang kiểm nguyên nhân chưa secure đủ space. Tất cả position của support đã được ghi trong incident group và call note 16:03. Đề nghị nếu call note dùng cụm ‘support phụ trách case’, cần nêu rõ người, thời điểm, kênh trao đổi và nội dung nguyên văn.” Tôi bấm gửi trước khi tay kịp run.

Anh Khoa đáp gần như lập tức: “Linh, em đừng căng. Support phụ trách case là cách nói chung, không phải nói riêng em.” Tôi nhìn câu ấy, tự nhiên thấy cổ họng khô đến đau. Cách nói chung luôn chỉ chung cho đến khi cần một người cụ thể chịu trách nhiệm. Chị Thảo nói thay tôi: “Khoa sửa call note. Không dùng cụm mơ hồ. Nếu có trao đổi với ai, ghi tên, kênh, giờ. Nếu không có, bỏ.” Chị Nhung thêm một câu ngắn: “Bản v2 cần lưu cùng bản đầu hoặc ghi rõ đây là bản ghi lại sau sự việc, không được thể hiện như note lập tại thời điểm 15:00.”

Không khí trong cuộc họp đặc lại. Tôi biết đây chưa phải chiến thắng. Không ai bị kỷ luật ngay, không ai xin lỗi support, và khách ngoài kia vẫn đang chờ văn bản trước 17:00. Nhưng một câu mơ hồ vừa bị kéo ra ánh sáng trước khi nó kịp đóng dấu lên tên tôi. Đôi khi trong văn phòng, thắng lợi chỉ là một dòng chữ không còn được phép đứng một mình trong bóng tối.

16:51, anh Hải chốt bản gửi khách. 16:55, văn bản đính chính được gửi từ incident owner, cc chị Thảo, chị Nhung, anh Bình và nhóm phụ trách Đại Phú. Tôi không nằm ở dòng người ký. Tôi chỉ được tag trong phần internal source log, đúng vị trí của một người cung cấp dữ kiện. Chị Vân phản hồi sau hai phút: “Đã nhận. Đại Phú ghi nhận công ty đính chính timeline. Vui lòng gửi phương án giảm phí phát sinh và kết luận trách nhiệm nội bộ sau.” Không có lời cảm ơn, nhưng cũng không còn câu “support không giữ đủ slot” đứng nguyên như một bản án.

Tôi vừa thở ra thì hệ thống HR case management bật thông báo mới. Người tạo: Nhung Pham. Tiêu đề: “Yêu cầu bổ sung bản giải trình thứ hai – Incident Đại Phú/MT Star.” Tôi nhìn tên mình trong ô người cần phản hồi, cảm giác nhẹ vừa có lập tức chìm xuống. Nội dung chỉ có ba dòng: “Do xuất hiện khác biệt giữa email external 15:31, call note Sales bản v2 và timeline support cung cấp, đề nghị Nguyễn Gia Linh nộp bản giải trình thứ hai trước 18:00. Nội dung cần làm rõ: support có/không xác nhận forecast 6x40HC với Sales trước khi email 15:31 được gửi.” Bên dưới thông báo là file đính kèm từ anh Khoa, bản vừa được sửa tên thành “Khoa_callnote_DaiPhu_1500_final.docx.”

Tôi nhìn chữ “final” ở cuối tên file, rồi nhìn đồng hồ chuyển sang 17:01. Có những văn bản được gửi đi để sửa một câu sai, cũng có những văn bản được sinh ra để tìm một người ký dưới câu sai còn lại. Và lần này, bản giải trình thứ hai đang gọi đúng tên tôi.