A shipment timeline for people who must act
Shipment tracking software for exceptions
Replace the single mutable status field with timestamped events, a current commitment, related proof and an exception record that names the next decision.
Live GPS, carrier networks and predictive ETA feeds require specialist services or integrations; this App keeps the operational record and exception response adaptable.
Event model
Keep facts, predictions and decisions separate
Mixing them is why a “tracking” page can look current while the operation is not. The user should be able to tell what physically happened, what the system expects, which promise still applies and who must act next without decoding an integration feed.
Fact
A timestamped event says what happened, where and with which result.
Prediction
An ETA states the current expectation and when it was calculated or received.
Commitment
The promised delivery window remains visible even after the ETA changes.
Decision
An exception record assigns containment, communication and recovery work.
Timeline
Use event history to answer the question behind the status
Each row should remain immutable enough to reconstruct the movement.
| Event | What it should retain | Question answered |
|---|---|---|
| Assigned | Resource and dispatch time | Who owns the move? |
| Departed origin | Time, origin and load context | Did execution start? |
| ETA changed | Previous/current expectation and source | Which commitment is at risk? |
| Delivery attempted | Time, location, outcome and evidence | Why did the stop fail? |
| Accepted | Recipient, proof and quantity note | What was actually received? |
| Returned | Return reason and pickup/receipt reference | Where did the goods go next? |
Integration design
Make every carrier update recoverable
A connector name is not a tracking design.
Define before launch
- Stable shipment and event identifiers
- Source timestamp and received timestamp
- Duplicate and out-of-order event behavior
- Retry queue, owner and reconciliation report
Keep visible to users
- Last confirmed event and its source
- Current commitment and risk
- Open exception and action owner
- Proof or return reference when the movement closes
Tracking experience
Show different answers to customers and operations
Both audiences need the same underlying truth, but not the same screen. Customer visibility should be clear and restrained; the internal record must expose source, uncertainty and recovery work.
Customer view
Show the current meaningful milestone, expected window and approved communication without exposing internal notes or irrelevant system events.
Operations view
Show event source, source time, received time, current commitment, confidence and any reconciliation or exception owner.
Exception alert
Trigger attention when a promise or decision changes—not for every routine scan that does not require action.
Closure evidence
Connect the accepted proof, delivered quantity, recipient outcome or return reference to the final movement state.
Rollout decision
Treat missing data as an operational state
A stale carrier feed is not the same as a physical delay. Show the last confirmed event, its source time, the current commitment and the person reconciling the gap. Test duplicates, out-of-order events, retries and manual correction so the timeline remains useful when an integration is least reliable.
Questions before rollout
Shipment tracking software FAQ
What is the difference between shipment tracking and delivery management?
Shipment tracking focuses on movement events, ETA and current state. Delivery management also coordinates requests, assignments, stop execution, proof, exceptions and returns.
Can Jodoo provide live GPS tracking?
Jodoo can receive and display data from connected services, but this example does not claim a native telematics network. Use a specialist tracking source when continuous location data is required.
How should duplicate events be handled?
Use a stable event identifier, preserve source and received timestamps, quarantine repeated updates and show the records that still need a person to reconcile them.
Which events matter most?
Choose events that change a customer promise, operational owner or decision: dispatched, departed, arrived, ETA changed, attempted, refused, accepted and returned.
How should shipment tracking handle a stale or missing event feed?
Keep the last confirmed event and its source visible, mark the feed as stale, name the person responsible for resolving the gap and avoid presenting an old ETA as a current fact. The operational record should distinguish missing data from a physical delay.
Inspect the working product
Open the populated App behind this page
Review connected records, operating views, a real exception workflow and representative normal, at-risk, failed and completed delivery states.