Ba tin tuyển FDE logistics cùng xoay quanh TMS của khách, còn việc thật bắt đầu từ hộp thư

Tin tuyển Forward Deployed Engineer của Loadsmart đặt một yêu cầu lên trước mọi dòng code: làm discovery có cấu trúc để tìm ra những pain point đáng giải, rồi xếp thứ tự ưu tiên cho chúng.

Người được tuyển làm việc trực tiếp với đội vận hành của khách và có thể đi công tác tới 50% thời gian. Chỉ sau đó mới đến phần build và tích hợp với hệ thống thật của khách: TMS, WMS, ERP.

Thứ tự ấy cho thấy giá trị trong logistics không nằm sẵn trong một database sạch. Nó nằm trong hộp thư, trong cuộc gọi, trong chứng từ. Trang giới thiệu sản phẩm ShipperGuide của chính Loadsmart viết rằng mỗi ngày, một điều phối viên trung bình mất hàng giờ đọc email của nhà xe rồi gõ tay số liệu vào TMS.

Nếu bạn là kỹ sư đang tìm đường vào nghề FDE, logistics là mảng nên cân nhắc. Hãy đọc tin tuyển của Loadsmart, Vooma và Augment cùng với tài liệu của các nhà cung cấp phần mềm vận tải.

Bạn sẽ thấy ngành này cần đúng bộ kỹ năng của một người triển khai: hiểu quy trình lộn xộn, xử lý dữ liệu phi cấu trúc và đưa được kết quả vào hệ thống cũ.

Vì sao phải đến tận nơi trước khi viết code?

Vooma mô tả phần discovery còn cụ thể hơn. FDE của họ chạy các buổi làm việc với nhà môi giới vận tải, nhà xe và đội IT của các công ty 3PL để chốt pain point, nguồn dữ liệu và success metrics. Họ cũng phải sẵn sàng dành tới 25% thời gian ở chỗ khách, để giảm rủi ro cho deployment và xây quan hệ.

Hai con số 50% và 25% khác nhau, nhưng thông điệp giống nhau: customer discovery ở đây diễn ra ngay trong văn phòng của khách. Thử hình dung một nhà môi giới dùng một TMS nào đó làm system of record. Nhiều việc vẫn diễn ra bên ngoài nó: dispatcher đọc email, gọi điện cho nhà xe, rồi gõ lại số liệu vào màn hình.

Nếu chỉ đọc tài liệu API, bạn dễ tự động hóa nhầm chỗ. Hãy ngồi xem một người làm check call (gọi hỏi tài xế xem hàng đang ở đâu) trong một buổi sáng. Bạn sẽ thấy họ hỏi gì, ghi vào đâu và chỗ nào họ phải đoán.

Việc Vooma đòi chốt success metrics ngay từ discovery cũng đáng học: hãy đo xem một việc đang tốn bao nhiêu thời gian trước khi hứa sẽ rút ngắn nó.

Giá trị nằm trong hộp thư, không nằm trong TMS

Vooma viết rằng các agent của họ hoạt động qua giọng nói, email và tin nhắn để tự động hóa các luồng việc quan trọng trong suốt vòng đời một lô hàng. Cả ba kênh ấy đều nằm ngoài system of record. Đó là chỗ con người đang phải làm thay phần mềm.

Một bài hướng dẫn năm 2026 trên blog ngành của GetTransport cũng đi đến kết luận tương tự. Bài này gọi việc phân loại email nhà xe gửi tới là use case mở đường cho agent AI trong môi giới vận tải, và xếp tự động hóa báo giá ngay phía sau.

Hướng đi này không mới. Năm 2023, Tai TMS quảng bá trợ lý email của mình bằng tuyên bố rằng tỷ lệ thắng tăng 30% khi nhà môi giới trả lời yêu cầu báo giá ngay lập tức.

Đây là con số do nhà cung cấp tự công bố. Chỉ nên đọc nó như một gợi ý vì sao tốc độ trả lời email lại được coi trọng đến vậy.

Một email báo giá đi qua những bước nào?

Thử hình dung một ví dụ. Một chủ hàng gửi email: cần một xe thùng khô, lấy hàng ở kho A sáng thứ Năm, giao ở B, hàng nặng khoảng mười tấn, “giá tốt thì chốt luôn”. Người đọc chỉ mất mười giây. Còn hệ thống thì phải tách được năm trường: điểm đi, điểm đến, ngày lấy, loại xe, trọng lượng.

Phần khó bắt đầu ngay sau đó. “Sáng thứ Năm” là thứ Năm nào? “Kho A” ứng với mã địa điểm nào trong TMS của khách? Nếu email thiếu trọng lượng, agent nên hỏi lại hay chuyển cho người duyệt? Tài liệu kỹ thuật không trả lời những câu hỏi này. Bạn chỉ trả lời được sau khi đã ngồi cạnh người làm việc đó.

Trích xong vẫn chưa xong. Bài của GetTransport chỉ ra rằng phần khó của integration là ghi dữ liệu ngược vào TMS theo cả hai chiều. Khi đã làm được, mỗi email được cấu trúc hóa sẽ trở thành một dòng dữ liệu đếm được: bao nhiêu yêu cầu tới, trả lời sau bao lâu, thắng bao nhiêu lô.

Rate confirmation, chặng cuối chưa được tự động hóa

Nếu email báo giá là cửa vào, thì quyết toán là chặng cuối mà ngành vẫn chưa làm xong. GetTransport coi chứng từ quyết toán là phần cuối cùng mà tự động hóa còn chưa chạm tới. Ví dụ là rate confirmation, văn bản xác nhận giá giữa nhà môi giới và nhà xe.

Aljex, một nhà cung cấp TMS, giải thích lý do: những trao đổi mất thời gian này tốn tiền vì cần con người can thiệp. Hãng này cũng mô tả cách tự động tải bản rate confirmation đã ký lên TMS.

Sai một con số ở chặng này có thể làm lệch tiền giữa hai công ty. Vì thế FDE làm chặng này nên thiết kế cả bước kiểm tra lại, chứ không chỉ phần trích xuất.

Bảng dưới đây ghép ba tin tuyển với tài liệu của các nhà cung cấp và bài hướng dẫn ngành thành một bản đồ công việc theo vòng đời lô hàng. Không nguồn nào một mình vẽ đủ bức tranh này.

Chặng	Việc của FDE	Điểm khó	Ai đang nói tới
Nhận yêu cầu, báo giá	Phân loại email, trích trường, đẩy sang công cụ tính giá	Email mơ hồ, thiếu trường, cần trả lời nhanh	GetTransport, Tai TMS, ShipperGuide của Loadsmart
Theo dõi lô hàng	Tự động hóa check call và shipment tracking	Thông tin đến qua cuộc gọi và tin nhắn	Loadsmart
Quyết toán	Đọc rate confirmation, đưa bản đã ký vào TMS	Sai số liệu là lệch tiền	GetTransport, Aljex
Xuyên suốt	Thiết kế integration chịu được hệ thống cũ	Ghi ngược dữ liệu vào TMS/ERP	Loadsmart, Vooma, Augment, GetTransport

TMS đời cũ mới là bài kiểm tra thật

Dòng cuối của bảng là phần việc quyết định một deployment thành hay bại. Vooma mô tả công việc là thiết kế kiến trúc integration “sống sót” khi va chạm với hệ thống TMS/ERP đời cũ. Loadsmart thì yêu cầu build và tích hợp giải pháp với hệ thống thật của khách.

Cách diễn đạt của Vooma đáng đọc kỹ. Họ không viết “tích hợp với TMS”. Họ dùng chữ “sống sót”, tức là biết trước sẽ có chuyện. Có thể hình dung những tình huống quen thuộc: trường dữ liệu đặt tên khác nhau, không có API nên phải import qua tệp, hay một tùy biến cũ mà không ai còn nhớ lý do.

Ở điểm này, việc của FDE khác hẳn việc của kỹ sư sản phẩm. Kỹ sư sản phẩm có thể giả định một giao diện chuẩn. FDE nên giả định điều ngược lại. Khi phía khách thay đổi gì đó, luồng dữ liệu phải báo lỗi rõ ràng thay vì lặng lẽ ghi sai.

Muốn vào mảng này, nên chuẩn bị gì?

Augment ghi thẳng vào phần yêu cầu: có kinh nghiệm trong logistics, chuỗi cung ứng hoặc vận tải, cụ thể là các hệ thống TMS, WMS, ERP. Với kỹ sư chưa từng làm ngành này, đó không phải bức tường. Đó là danh sách những thứ cần học.

Cách bắt đầu hợp lý nhất là nắm từ vựng của ngành. Bạn cần biết TMS, WMS và ERP mỗi hệ thống giữ dữ liệu gì, check call là gì, rate confirmation dùng để làm gì.

Sau đó, hãy làm một dự án nhỏ đi đúng con đường trong bảng trên. Đầu vào là email hoặc chứng từ, qua bước trích xuất, rồi ghi ra một định dạng import giống TMS, có xử lý trường thiếu và trường mơ hồ.

Khi viết CV, đừng ghi chung chung “xây pipeline xử lý tài liệu”. Hãy ghi rõ đầu vào là gì, đầu ra đi vào hệ thống nào, và bạn xử lý những trường hợp xấu ra sao.

Khi đọc tin tuyển, hãy để ý những cụm như “structured discovery”, “legacy TMS/ERP”, “check calls” hay một tỷ lệ thời gian ở chỗ khách cụ thể. Đó là dấu hiệu công ty hiểu việc triển khai thật, chứ không chỉ cần người demo.

Cả ba tin tuyển đều cần người làm việc được với TMS, WMS hay ERP của khách. Còn email, cuộc gọi và chứng từ là nơi dữ liệu bắt đầu. FDE nào nối được hai đầu ấy sẽ nắm đúng phần việc mà GetTransport gọi là phần khó: ghi dữ liệu ngược vào hệ thống cũ.