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 Huy Nguyen (David), CEO · Updated 1 Nov 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
, carrying plan, assignment, events and billing.
-
Assignment as a recorded decision
, so a replan is an amendment, not a new spreadsheet.
-
Events captured where they happen
, stamped on the device, queued offline, reconciled on reconnect.
-
Proof captured at the event
signature, photo, scan or code, with position and time.
-
Exceptions from a fixed list
, each with a coded reason, owner and age.
-
Plan against record, automatically
, with only the differences reaching a person.
| Step | What it gives you | Best for |
|---|---|---|
| One job record with one identifier | Plan, assignment, events and billing on a single object | Giving the customer one reference that always resolves |
| Assignment as a recorded decision | A logged who, when and constraint behind every assignment | Turning a replan into an amendment, not a new spreadsheet |
| Events captured where they happen | Device-stamped status, queued offline and reconciled on reconnect | Fieldwork with patchy connectivity |
| Proof captured at the event | A signature, photo, scan or code attached before the worker leaves | Disputes over whether a job was actually completed |
| Exceptions from a fixed list | A coded reason, owner and age on every non-completion | Counting causes instead of relying on memory |
| Plan against record, automatically | A daily match between plan, performance and carrier reports | Surfacing only the differences that need a person's attention |
System boundary
A project of this shape owns the job record, assignment, event log, mobile capture path, evidence store, exception taxonomy and the daily plan-against-record reconciliation.
It does not own the vehicles, telematics hardware, mapping provider or carrier's systems, nor optimisation unless that is the explicit brief: routing engines are bought far more often than built. The same mechanics as procurement and inventory reconciliation are ERP and back-office operations; the performed job becoming an invoice to match is order and payment operations. The sector view 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.
What AI changes here
Little of this workflow is an AI problem, and pretending otherwise wastes a first milestone.
Whether a step needs rules or a model is worked through in the business workflow transformation guide; an AI Workflow Blueprint settles it for one workflow before a build. Netbase works with commercial and open-source AI models chosen per project. 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.
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. In dispatch work the first depot is the rollout step; acceptance per milestone follows the project delivery page.
Risks
- The operation cannot pause. No quiet weekend to cut over; plan a parallel run and a per-depot rollback.
- The mobile app meets reality. Gloves, rain, cracked screens, no signal, the oldest handset. Test there.
- A slow capture flow gets worked around, and the record then describes a workflow nobody follows.
- Subcontractors cannot be made to adopt. Any step depending on a third party needs a fallback.
- Master data is worse than reported. Addresses and access notes decide whether a plan is executable.
How is success 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. 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. Where independent sellers ship their own orders it meets marketplace and classifieds operations, and the flood of "where is it" messages is customer support automation. The other 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
Dispatch and tracking run on machinery Netbase builds across its platform work: shared records, event capture, assignment and status. Two published records show related parts of that machinery.
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. The cloud ERP record sets out its scope. 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; a later retail phase was planned work when that profile was written. Work management with real-time messaging is the same machinery as assignment, event capture and status: a record many parties write to, with a history that has to survive a dispute.
For RB Marketplace, Netbase built vendor order fulfilment with tracking updates on the web platform, and order tracking in the customer app for Android, with iOS in the extended scope. The RB Marketplace record lists the rest of that scope.
This record covers phase-one scope for agency SMEs; the client and product are not named.
Keep Reading
This record sets out what was delivered on each side and what deliberately stayed in the web panel.
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.
You do. The code created in custom development is the client's intellectual property, and the event log is your operational record; any Netbase productized module is licensed and named in the proposal.
Yes. Every service on this site is delivered remotely from Hanoi, and Netbase has worked with clients in 80 countries. Delivery communication is in English, with weekly reviews and a named project manager.
Netbase takes on projects in any industry where the work can be delivered remotely and accepted by milestones. The industry pages describe the approach sector by sector, and the Work records show delivered projects.
Payment is by bank transfer to the company account of Netbase JSC or through PayPal Business. The payee is always Netbase JSC, the company that operates OutsourcingVN.
Talk to Huy Nguyen (David), Founder and CEO of Netbase JSC: message him on WhatsApp at +84 937 869 689 or email project@netbasejsc.com. You can also send your brief through the project request form. Say which workflow or system the project concerns and what has to stay unchanged; the first step is a discovery conversation, and scope and milestones are agreed after it.
Services behind this solution
Custom product engineering for a bounded release outcome
One defined release of your product, built to named outcomes and handed over with acceptance evidence.
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.