Accept work
Validate the source, service rules, identifiers and required delivery window.
Keep every route, DSP and delivery result visible.
NaviBatch Enterprise organizes the operating handoff from accepted orders to routes, DSP assignments, driver execution, POD review and exception ownership.
The panel uses fictional records to explain the workflow. It is not live customer, recipient or driver data.
Today’s operationsSample data
Orders12,480
Assigned11,906
In delivery8,912
Exceptions84
G1North route174 of 186 stops reportedIn progress
G2Central route151 of 174 stops reportedIn progress
G8West route143 of 159 stops reportedReview 2
G10South route166 of 181 stops reportedIn progress
Operating control loop
One status chain from intake to upstream return.
Every handoff has an owner, a timestamp and a reason. Operators can see what is waiting, who has accepted it and what still needs review.
Build routes
Group stops by operating area, volume, deadline and available DSP capacity.
Dispatch DSP
Assign route responsibility to the DSP that will manage driver execution.
Follow progress
Track scanned, loaded, remaining, delivered and failed work by route.
Close the loop
Review POD and exceptions before approved events return upstream.
Role boundaries
Authority follows operational responsibility.
A DSP needs enough control to run its drivers, but not permission to change the last-mile company’s POD policy or final exception decision.
Delivery progress
A route is more than “assigned” or “done.”
High-tempo teams need event-level visibility so they can tell the difference between not loaded, out for delivery, delivered, failed and waiting for review.
Ready to load
DSP and driver assignment exists, but package scan and loading are not complete.
In delivery
Driver execution has started and route progress is updating from submitted events.
Result submitted
Delivered or failed result includes the required evidence and reason fields.
Reviewed
Company policy determines whether POD or exception work can close and sync upstream.
POD and exceptions
Execution can be distributed. Accountability cannot.
Drivers capture the result, DSPs manage execution, and the last-mile company keeps final review authority over customer-facing proof and operating exceptions.
Driver submissionDelivery result, timestamp, required photo or signature evidence, GPS context and failed-delivery reason.
DSP visibilitySee route and driver results, contact the driver and report operational context without changing company review policy.
Company reviewReview incomplete proof, duplicate or conflicting events, failed delivery, return-to-station and policy exceptions.
Upstream returnOnly approved status events should be mapped and returned to the authorized platform or merchant connection.
Operations FAQ
Simple roles prevent expensive confusion.
The operating model stays clear even when one last-mile company works with several DSPs and many drivers.
Can both the last-mile company and DSP assign routes?
Yes, at different levels. The last-mile company can assign an operating route to a DSP. The DSP then assigns accepted route work to its own driver.
Does a driver need the web Portal?
No. Driver work belongs in the mobile execution experience. The web Portal is for company and DSP operations.
Can route progress update in real time?
The architecture is designed for event-based updates. Production behavior still depends on authenticated driver events, network conditions, monitoring and acceptance testing.
See the operating model before committing to a pilot.
Review the sample demo, then share your current role, service area and operating experience with NaviBatch.