Chương 7: Forecast bị sửa

Tôi nhìn dòng distribution history thêm vài giây nữa, cho đến khi chữ “pending approval” không còn giống một trạng thái hệ thống mà giống một ngón tay đang đặt sẵn trên nút gửi. Sau cuộc họp 14:00, mọi người vừa thống nhất không dùng package version 20 làm căn cứ đánh giá trách nhiệm. Nhưng ở một nhánh khác của cùng incident case, chính version đó đã sinh ra một bản nháp gửi khách, có owner là anh Khoa và approval owner là chị Mai. Tôi không mở draft ngay. Việc đầu tiên tôi làm vẫn là chụp màn hình, ghi lại thời điểm 15:08, case ID, package version 20, owner, approval owner và recipient group. Một người mệt rất dễ nhầm giữa phản xạ tự vệ và hành động đúng quy trình. Tôi không muốn vì vội mà biến một lỗi của họ thành một điểm yếu của mình.

Tôi gửi vào nhóm xử lý incident: “Em phát hiện customer follow-up draft generated lúc 22:52 từ package version 20, hiện pending approval. Vì package version 20 vừa được xác định cần audit lại nguồn, em đề nghị freeze outbound draft này và mở nội dung ở chế độ read-only trước khi có bất kỳ approval nào.” Tin nhắn vừa đi, anh Khoa trả lời gần như lập tức: “Draft chưa gửi. Khách đang chờ update, cứ hold hết thì ai chịu trách nhiệm delay?” Chị Mai thêm một câu mềm hơn nhưng không nhẹ hơn: “Chị là approval owner nên chị sẽ kiểm wording trước khi gửi. Không cần escalate thêm mọi thao tác.” Tôi đặt tay khỏi bàn phím, đếm thầm đến năm rồi mới nhìn sang chị Thảo. Trong nhóm, chị trả lời rất ngắn: “IT freeze outbound draft. Không gửi external communication từ case này cho đến khi bảng nguồn được gắn kèm.”

Anh Bình bên IT call vào sau đó ba phút. Giọng anh vẫn đều đều như đang đọc hướng dẫn sử dụng máy in: “Mình đã lock approval action, draft chuyển sang read-only. Ai cũng xem được nội dung, không ai approve hoặc edit được cho đến khi Thảo mở lại.” Tôi cảm ơn anh, rồi bấm vào bản draft. Tài liệu không dài, nhưng chỉ cần ba đoạn đầu đã đủ khiến gáy tôi lạnh đi. Nội dung viết rằng theo weekly forecast của khách Đại Phú cho tuyến MT Star, volume dự kiến đã được sales ghi nhận đầy đủ trước mốc xử lý, tuy nhiên support không secure đủ final space nên phát sinh rủi ro khi khách gate-in. Những chữ “weekly forecast” và “ghi nhận đầy đủ trước mốc xử lý” nằm cạnh nhau quá trơn tru, giống như một cái cầu được dựng vội qua đúng chỗ log vừa lộ ra cái hố.

Tôi kéo xuống phần source reference. Draft dẫn forecast ID F-DP-MTSTAR-W25, created time 09:05, submitted by Sales, expected volume 6x40HC, priority high, status customer committed. Nếu chỉ nhìn đúng năm dòng đó, ai cũng sẽ nghĩ support đã có đủ tín hiệu để giữ chỗ cho sáu container từ sáng. Nhưng tôi nhớ trong cuộc họp, chị Lan nói chứng từ hợp lệ chỉ hoàn chỉnh lúc 12:56, anh Phong OPS nói cảnh báo rủi ro đến 13:42 mới được chuyển qua. Forecast có thể là đầu vào, nhưng nó không thể tự biến thành slot confirmed. Tôi mở forecast card bằng chế độ read-only, chuyển thẳng sang version history.

Bảng version history hiện ra chậm hơn bình thường. Tôi không biết do mạng, do hệ thống, hay do chính tôi đang nhìn nó với quá nhiều đề phòng. Version 3 lúc 09:05: expected volume 2x40HC, status tentative, note: “customer estimates, docs pending, carrier space subject to confirmation.” Version 4 lúc 13:17: expected volume 3x40HC, status tentative, thêm ghi chú khách có thể tăng volume nếu chứng từ kịp. Version 5 lúc 21:58: expected volume 6x40HC, status customer committed, priority high. Version 6 lúc 22:50: source summary updated, “forecast provided before support follow-up.” Tôi đọc đi đọc lại mốc 21:58. Nó xảy ra sau khi incident đã nổ, sau khi khách đã kéo container ra bãi, sau khi mọi người bắt đầu gom timeline. Một forecast được sửa sau sự cố không thể quay ngược thời gian để chứng minh support biết trước.

Tôi không kết luận ngay. Tôi gửi vào nhóm một câu hỏi có thể kiểm tra được: “Nhờ anh Phong xác nhận forecast freeze time áp dụng cho tuyến MT Star tuần W25. Forecast ID F-DP-MTSTAR-W25 tại freeze time đang ở version nào?” Anh Phong trả lời sau chưa đầy hai phút: “Forecast freeze là 17:00 D-1 theo SOP phân bổ slot. Tại freeze, bản đang active là version 4: 3x40HC tentative, docs pending. Version 5 update 21:58 sau incident, không dùng làm căn cứ capacity commitment trước đó.” Câu trả lời ấy giống một cái chốt được gài vào đúng vị trí. Tôi không cần nói “forecast bị sửa”. Hệ thống đang tự nói điều đó bằng timestamp.

Anh Khoa lại nhắn: “Forecast là living data. Khách lớn thay đổi volume liên tục, không ai vận hành bằng ảnh chụp chết.” Tôi nhìn câu “ảnh chụp chết” và nhớ đến Hương, đến những người mới bị dạy rằng dữ liệu cũ chỉ có giá trị khi nó phục vụ người có quyền nói lớn hơn. Tôi gõ: “Dạ, forecast có thể rolling. Nhưng bản rolling sau 21:58 không thể được dùng để viết rằng support đã nhận đủ forecast trước mốc 10:29. Nếu dùng forecast version 5 trong draft gửi khách, draft cần ghi rõ đó là bản cập nhật sau incident.” Lần này anh Hải là người phản hồi trước chị Thảo: “Open version compare cho forecast. Tôi muốn xem field nào thay đổi.”

Anh Bình share màn hình. Version compare của forecast không có câu văn dài như package, nhưng nó còn lạnh hơn vì từng ô thay đổi hiện màu rõ ràng. Expected volume từ 3 thành 6. Forecast status từ tentative thành customer committed. Support action từ monitor thành secure final space. Source note từ “customer estimates, docs pending” thành “customer forecast committed via CRM.” Created time vẫn là 09:05, còn last modified nằm ở cột bên phải: 21:58 và 22:50. Tôi nhìn vào hai cột ấy và hiểu vì sao draft gửi khách chỉ trích created time. Nếu người đọc chỉ thấy 09:05, họ sẽ tin forecast này có mặt trước toàn bộ chuỗi xử lý. Nếu họ thấy 21:58, câu chuyện đổ lỗi lập tức mất chân.

Chị Mai nói trong call: “Chị nghĩ đây là cách tổng hợp forecast mới nhất, không phải sửa sai lệch. Khi gửi khách thì phải dùng dữ liệu cập nhật nhất.” Giọng chị vẫn bình tĩnh, nhưng chữ “cập nhật nhất” lần này không còn che được mùi khét của một bản ghi bị dùng sai thời điểm. Tôi đáp: “Dữ liệu cập nhật nhất dùng để xử lý hiện tại, không dùng để mô tả quá khứ nếu không ghi mốc update. Draft đang viết như thể forecast 6x40HC, customer committed đã tồn tại trước khi support follow. Nhưng version history cho thấy lúc đó forecast chưa như vậy.” Chị Nhung HR không nói nhiều, chỉ hỏi anh Bình: “Version history forecast này có export được read-only không?” Anh Bình đáp có.

Hương ngồi ở bàn bên cạnh tôi, mặt tái hơn lúc sáng. Con bé đẩy điện thoại sang cho tôi xem nhưng không đưa hẳn vào tay. Chị Mai vừa nhắn riêng cho Hương: “Em có nhớ forecast khách ban đầu là mấy cont không? Trả lời chị nhanh để chị tổng hợp.” Tôi lắc đầu rất nhẹ. Hương hít một hơi rồi tự gõ vào nhóm chung: “Em không xác nhận qua chat riêng. Theo attachment index em giữ, forecast snapshot lúc em nhận follow vẫn là tentative, docs pending. Em sẽ attach index read-only theo yêu cầu audit.” Tôi thấy vai con bé run lên một chút sau khi bấm gửi. Có những câu rất bình thường trong công ty khác, nhưng ở đây lại giống như tự bước ra khỏi hàng.

Chị Thảo chốt lại trước khi call kết thúc: “Forecast F-DP-MTSTAR-W25 bị freeze để audit. Customer follow-up draft 22:52 tiếp tục hold. Draft mới, nếu cần, phải tách rõ forecast tại freeze time, forecast sau incident và trạng thái chứng từ. Không dùng created time thay cho last modified time.” Anh Hải yêu cầu team sale cung cấp toàn bộ trao đổi với khách trước 12:56, bao gồm mail, call note và CRM comment liên quan volume forecast. Anh Khoa im khoảng mười giây rồi nói: “Vậy tức là mọi câu trong draft đều phải có nguồn à?” Tôi nhìn màn hình, nhìn những dòng xanh đỏ của version compare vẫn chưa tắt, rồi trả lời: “Dạ, những câu có thể làm sai trách nhiệm của một bộ phận thì phải có nguồn.”

Call kết thúc lúc 15:49. Văn phòng không ồn, nhưng tiếng máy lạnh trên đầu tôi đột nhiên nghe rất rõ. Tôi mở timeline, thêm một nhánh mới bên dưới package version 20: forecast version 5 updated 21:58; version 6 source summary updated 22:50; customer draft generated 22:52; draft dùng created time 09:05 nhưng không ghi last modified. Tôi ghi chậm, cố để chữ không run. Một ngày làm việc bình thường đáng lẽ phải kết thúc bằng việc chốt booking, cập nhật khách, đóng case. Còn ngày hôm nay, tôi đang học cách phân biệt từng loại “đúng”: đúng dữ liệu, đúng thời điểm, đúng bối cảnh, và đúng người được phép dùng nó.

Tôi vừa lưu note thì điện thoại bàn đổ chuông. Màn hình hiện số đại diện khách Đại Phú, escalation contact mà tôi đã thấy trong recipient group của draft. Tôi nhìn sang Hương; con bé cũng nhận ra cái tên ấy nên lập tức ngồi thẳng dậy. Tôi nhấc máy, chưa kịp chào hết câu thì đầu dây bên kia đã nói rất nhanh: “Chị Linh phải không? Bên tôi vừa được báo rằng forecast ban đầu là sáu container nhưng support bên chị không giữ đủ slot. Tôi cần chị xác nhận chuyện đó ngay bây giờ.”