Một đơn giao hàng, bốn cách nhìn về trạng thái

Bắt đầu từ đơn hàng, không từ bốn màn hình

Brief mô tả thông tin vận hành rải ở radio/WhatsApp, theo dõi thủ công và chứng từ giấy. Từ tài liệu đó, tôi đặt câu hỏi: nếu bốn vai trò đang nhìn cùng một chuyến hàng nhưng ở những thời điểm khác nhau, thông tin nào phải thống nhất, thông tin nào chỉ từng người cần thấy? Đây là product framing từ brief, không phải phát hiện đã kiểm chứng qua field research.

Tôi dùng đơn hàng làm đối tượng chung xuyên suốt Request → Match → Capacity → Execute → Proof. Customer cần biết chuyến đã được xác nhận và đang ở đâu; Operations cần biết điều gì chặn phân công; Fleet Manager cần biết xe, tài xế và hồ sơ có sẵn sàng; Driver cần biết mốc hiện trường nào phải xác nhận. Cùng một sự kiện, nhưng bốn quyết định khác nhau.

Một status tốt là lời giao việc

Ví dụ, “chưa có tài xế” không thể chỉ là badge chờ. Customer cần một kỳ vọng rõ ràng; Operations cần lối xử lý hoặc tìm lại; Fleet Manager cần hiểu liệu thiếu năng lực xe hay hồ sơ tài xế chưa đủ điều kiện; Driver chưa nên nhìn thấy một chuyến chưa được phân công. Status có ý nghĩa khi gắn với vai trò chịu trách nhiệm và bước tiếp theo.

Vì vậy tôi không cố ép một dashboard “tổng quát” cho tất cả. Trên Customer App, booking đi qua lộ trình, hàng hóa, chọn xe, thời gian và xác nhận; “No driver available” cùng “Retry searching” là failure path được thiết kế, không phải trạng thái tô thêm màu sau khi hoàn thành màn đẹp.

Ngoại lệ cần xuất hiện ở đúng điểm quyết định

Operations điều phối trên toàn hệ thống; Fleet Manager quản lý năng lực đội xe của mình. Một chiếc xe sắp hết hạn kiểm định hoặc một hồ sơ chưa được duyệt là vấn đề năng lực, không chỉ là một đơn hàng “đang chờ”. Driver lại cần chuỗi mốc pickup, transit, delivery và Proof of Delivery (POD), kèm đường báo chậm hay sự cố.

Điểm chung không nằm ở việc cả bốn UI có cùng một badge. Nó nằm ở cùng ý nghĩa sự kiện và cùng vòng đời giao hàng, nhưng action, quyền sửa và thông tin ưu tiên thay đổi theo người thực hiện. Đó là lý do design system phải giữ được pattern và ngôn ngữ trạng thái giữa hai portal web và hai app mobile.

• Tạo yêu cầu: Customer cung cấp thông tin đặt chuyến.
• Phân công: Operations nhìn thấy trường hợp không ghép được tài xế.
• Năng lực: Fleet Manager quản lý xe/tài xế sẵn sàng.
• Thực thi và bằng chứng: Driver cập nhật mốc, POD khép vòng phản hồi.

Điều tôi chưa thể khẳng định

Bốn bộ UI và design system đã có, nhưng tài liệu hiện không có field test, baseline hay dữ liệu sau launch. Tôi chưa thể nói hệ trạng thái này làm giảm thời gian điều phối. Để kiểm chứng, tôi sẽ theo dõi time to assign driver, time to detect/resolve exception, lỗi cập nhật status, POD completion và số lần khách phải hỏi lại trạng thái. Đây là metric đề xuất, không phải kết quả.

Một vòng đời giao hàng được mô hình hóa tốt là điểm khởi đầu. Sự thật vận hành chỉ xuất hiện khi đặt luồng đó trước người dùng thực và những tình huống không đúng như bản thiết kế.