One delivery, four views of status

Start with the order, not four screens

The supplied brief describes operational information spread across radio/WhatsApp, manual tracking, and paper records. That suggested a question: what must remain true when four roles look at the same delivery at different moments? This is framing from the brief, not validated field research.

I made the order the shared object from Request → Match → Capacity → Execute → Proof. Customer needs a clear expectation, Operations needs assignment and exception signals, Fleet Manager needs vehicle and driver readiness, and Driver needs the next field milestone. One event can trigger four different decisions.

A useful status assigns a next action

“No driver available” should not be a waiting badge. Customer needs an expectation, Operations a resolution or retry path, Fleet Manager a view of capacity, and Driver should not receive an unassigned trip. Status matters when paired with ownership.

On the Customer App, booking progresses through route, cargo, vehicle, schedule, and confirmation. “No driver available” and “Retry searching” acknowledge that matching may fail. They are part of the product flow, not decoration added after the UI is done.

Put exceptions where decisions happen

Operations coordinates system-wide dispatch; Fleet Manager owns readiness within a fleet. Expiring inspection and unapproved driver records are capacity problems. Driver follows pickup, transit, delivery, and Proof of Delivery (POD), with delay and issue reporting.

The common system is not four identical dashboards. Shared status meaning travels across two web portals and two mobile apps, while information priority, permissions, and actions change by role.

• Request: Customer specifies the job.
• Match: Operations handles unavailable drivers.
• Capacity: Fleet Manager checks ready vehicles and drivers.
• Execute and Proof: Driver records milestones and POD.

What remains unproven

The four UI sets and design system exist, but there is no documented field test, baseline, or post-launch data. I cannot claim this status model reduced dispatch time.

Proposed measures include time to assign a driver, time to detect and resolve an exception, status-update errors, POD completion, and customer support requests. These are validation lenses, not results.