Dispatch and delivery tracking, from the plan to the evidence
A job is planned, assigned to a vehicle or a person, executed against a day that does not cooperate, and then has to be evidenced. This page describes that workflow as a delivery project: what the record must hold, where status and proof go missing, and which bounded piece is worth building first.
Submit a project See the related serviceReviewed by David (CEO) · Updated 24 Sep 2026
Who is in this workflow
- The planner turns tomorrow into assignments against capacity, windows and restrictions, and is judged on a plan that reality edits by nine in the morning.
- The dispatcher absorbs the difference all day by telephone, and is the only person who knows the current truth.
- The driver or field worker executes with one hand, in poor light, offline more often than the system's designers expect.
- The contact centre asks where it is, repeatedly, because nothing tells it.
- Finance needs to know what was performed before anything can be billed or disputed.
How the work runs today
The plan is built the evening before in a planning tool or a spreadsheet, then printed or messaged out. During the day it changes: an address is wrong, a customer is absent, a vehicle breaks down, a job is added. Those changes travel by phone call and never reach the plan.
Status is asked for more often than it is produced. The dispatcher calls the driver, the contact centre calls the dispatcher, the customer calls the contact centre. Proof of delivery is a signature on paper or a photograph on a driver's phone, uploaded that evening if at all. At week end the plan and the record are reconciled by more phone calls, and subcontracted work from whatever the carrier sent.
Where the workflow breaks
-
Status is pulled, not pushed
Because no event is recorded when it happens, everyone downstream asks a person, and answering is a full-time job nobody is assigned.
-
Proof of delivery lives on a phone
The evidence that the job was done is outside the system, so a dispute is settled by memory and the billing has nothing behind it.
-
The plan and the record are different documents
What was intended and what happened are never compared, so exception causes are anecdotes.
-
Exceptions have no vocabulary
Failed attempt, refusal, damage, wrong address and access problem are all recorded as a note, so nothing can be counted.
-
Subcontracted work is invisible
A carrier reports at its own pace in its own format, and the customer still expects one answer.
The target flow
-
One job record with one identifier
Plan, assignment, events, evidence and the billing line hang off the same object, and the customer can be told that reference.
-
Assignment as a recorded decision
Who was assigned, when, by whom and against which constraint, so a replan is an amendment rather than a new spreadsheet.
-
Events captured where they happen
Arrived, started, completed, failed, delayed: each stamped on the device at the moment, queued when offline, reconciled on reconnect.
-
Proof captured at the event
Signature, photograph, scan or code attached to the job before the worker leaves, with position and time recorded.
-
Exceptions from a fixed list
Every non-completion carries a coded reason, an owner and an age, so causes can be counted rather than recalled.
-
Plan against record, automatically
What was planned, what was performed and what each carrier reports are matched daily, and only the differences reach a person.
System boundary
A project of this shape owns the job record, the assignment, the event log, the mobile capture path, the evidence store, the exception taxonomy and the daily plan-against-record reconciliation.
It does not own the vehicles, the telematics hardware, the mapping provider or the carrier's systems. It does not own optimisation either, unless that is the explicit brief: routing engines are bought far more often than built. Where the same mechanics appear as procurement and inventory reconciliation, that is ERP and back-office operations; where the performed job becomes an invoice to be matched, that is order and payment operations. The sector view, with its pressures and regulatory ground, is the logistics and transport page; this page scopes the workflow as a project.
Data, devices and integrations
The objects to design are the job, the assignment, the event, the exception with its coded reason, the evidence file with its metadata, the resource and the reconciliation line. The event log is the product; everything else is a view of it, and a system that lets an event be edited in place will not survive a dispute.
Two constraints shape the architecture more than any feature. Offline-first is a data-model decision, not a caching trick: the device has to generate identifiers, queue events and resolve conflicts on reconnect. And position data identifies a named worker, so its use, retention and access are questions for people and their representatives before engineers.
The usual connections are the planning system, telematics, carrier interfaces, a mapping provider, an ERP or finance system and a customer portal. Netbase security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request.
What AI changes here
Little of this workflow is an AI problem, and pretending otherwise wastes a first milestone.
Netbase works with commercial and open-source AI models chosen per project, and implies no vendor partnership. What AI does not fix: an address with no access note, evidence never captured, and a carrier that sends nothing back.
-
Paperwork that arrives as images
Delivery notes and carrier statements can be read by document AI with a person confirming the fields, which is the argument in document and approval workflows.
-
Exception triage
Notes and inbound messages can be classified and routed with the job attached. That changes who reads them first, not who decides.
-
Estimated times
A model trained on your own event history beats a static window, and only once that history exists.
Delivery modules
- Job intake and one job model, with the customer-visible reference.
- Assignment and replan, with the decision recorded.
- Mobile capture: offline queue, conflict resolution, one-handed flows, low-bandwidth media.
- Evidence store with retention and controlled access.
- Exception taxonomy, queue, ownership and ageing.
- Carrier interfaces, with a fallback for the carrier that reports nothing.
- Plan-against-record reconciliation and the billing export.
- Status views built from events rather than phone calls.
These are built as custom product engineering milestones with written acceptance criteria; other engagement shapes are under services.
Rollout
Capture the event before optimising the plan. One depot, lane or crew, with event capture and proof of delivery only, running beside the phone calls, produces the first honest picture within weeks. Optimisation has nothing to be judged against until that exists.
Then add the exception taxonomy, the reconciliation and the status view. Widen depot by depot, and treat subcontracted capacity as a separate step with its own fallback.
Netbase follows one delivery lifecycle: discovery and strategic alignment; team assembly and architecture planning; agile execution with outcome-based milestones; modular components; training and rollout; ongoing support. Delivery is remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review. Milestone acceptance is on the project delivery page.
Risks
- The operation cannot pause. There is no quiet weekend to cut over. Plan a parallel run and a rollback that works per depot.
- The mobile application meets reality. Gloves, rain, cracked screens, no signal and the oldest handset in the fleet. Test there, not on a desk.
- A capture flow that adds a minute per stop will be worked around, and the record will then describe a workflow nobody follows.
- Subcontractors cannot be made to adopt. Every step that depends on a third party entering data needs a fallback.
- Master data is worse than reported. Addresses, access notes and service points decide whether a plan is executable.
How success is measured
Baseline first, then track: jobs with a complete event trail; proof of delivery attached at the event rather than that evening; status questions reaching a person per hundred jobs; exceptions by coded reason; the difference between planned and performed each day; and disputes resolved from the record alone.
Netbase publishes no measured business result from another client's operation, so nothing here is a benchmark. Your own baseline is the only comparison that means anything; how evidence is labelled is on the methodology page.
Where this workflow holds
It holds wherever a plan, a physical act and a record have to agree: parcel and freight delivery, field service and installation, waste and utility rounds, home healthcare visits, equipment rental and inspection routes. The plan differs; the event log, the evidence and the reconciliation do not. The neighbouring workflows are under solutions.
It does not hold where the fleet is small enough that one person knows where everything is, or where the real constraint is capacity rather than visibility.
Proof from delivery
OutsourcingVN publishes no delivered project record for a dispatch, tracking or logistics client. No approved claim in the register describes one, and this page claims none.
The relevant overlap is mechanical. Since 2020 Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP platform for a client that is not named. Its first phase, from 2020 to 2023, covers customer records, real-time messaging, HR, a knowledge base, custom fields and configurable workflows, work and project management, and API integrations, on React and Next.js, Laravel and Strapi, with PostgreSQL, MySQL, MariaDB and MongoDB on AWS. A later retail phase was planned work when that profile was written and is not presented as delivered.
Work and project management with real-time messaging is the same machinery as assignment, event capture and status: a record many parties write to, a history that has to survive a dispute, and a periodic match between agreed and actual. That is a capability argument rather than a track record, and it is the accurate one. The full record with its evidence limits is the multi-tenant cloud ERP platform page.
This record covers phase-one scope for agency SMEs; the client and product are not named, and no usage or business result is claimed.
Keep ReadingCommon questions
Usually not. Event capture and proof of delivery come first, because optimisation is judged against recorded reality and most operations have none.
Yes, and that is the common shape. It keeps the plan; the project owns execution, evidence and reconciliation.
For custom development the client owns the intellectual property created for it. Netbase productized modules and products are licensed rather than transferred, and any used are named in the proposal.
Services behind this solution
Custom product engineering for a bounded release outcome
Custom Product Engineering is for a buyer who can name the users, the release decision and the outcome a product increment should deliver. The engagement produces an accepted, working release, the evidence that it works, and a handover your team can operate. It is not a way to rent developers by the month.
Learn More
Scope this workflow
Bring a week of real jobs, the exceptions as your team describes them, the subcontracted share, and the devices your people carry. Name the depot or lane you would prove it on, then submit a project brief. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.