Shipment tracking software gives a consignment a status that the people waiting for it can see: where it is in its journey, when it is expected, and what has happened if something has gone wrong. With Pentoggle, an operator can describe the events its operation already produces and generate the starting application around it.
This page is about consignment status for customers. Where the vehicle is, how long it has been stopped and whether it followed the expected route are operational questions covered by Vehicle Tracking Software. The two share some underlying events and answer different questions for different people.
Many operators already run Tally for accounting and a GPS or telematics provider for vehicle data. Those stay where they are. What is often still managed outside them is the customer-facing status, which in many operations is a person on a phone.
Key takeaways
- Tracking systems fail on update effort rather than on design. A status somebody has to type will be current for a few weeks and then will not be.
- The events needed for a usable status are mostly already being recorded somewhere for other reasons, and the work is connecting them rather than creating them.
- A status that is sometimes wrong is worse than no status, because customers act on it and then discover they should not have.
- Location is not status. Customers want to know when it will arrive and whether anything has gone wrong, which is a different question from where the vehicle currently is.
- A useful number is the age of the most recent status event on shipments currently in transit.
The phone is often not the problem
A customer service desk answering enquiries by calling branches is a working system, and where volumes are low and customers are few it is perfectly reasonable.
The trouble starts at identifiable points.
When the same question arrives repeatedly
Each enquiry costs a call chain and a call back. At a certain volume this becomes a role, and it is a role that produces no information the operation did not already have.
When the answer requires a chain of calls
Office to branch to driver and back. The answer is several minutes old by the time it reaches the customer, and the driver was interrupted to produce it.
When the customer's expectation is not managed
Without visibility, a customer assumes the committed date holds until it visibly does not. A delay known internally on Tuesday surfaces to them on Thursday.
When tracking exists but is not current
A status page showing a shipment as in transit when it was delivered yesterday is worse than no page, because the customer trusts it and acts on it.
What shipment tracking software holds
The shipment
Consignment reference, consignor, consignee, origin, destination and goods.
Status events
Booked, loaded, despatched, in transit, arrived at destination, out for delivery, delivered, with time on each.
Event source
Which operational action produced each event, so the status is a byproduct rather than an entry.
Expected arrival
The current expectation, updated as the shipment progresses rather than fixed at booking.
Exceptions
Delays, deviations, failed delivery attempts and holds, with what is being done.
Customer access
What a consignor or consignee can see, how they reach it, and what is deliberately not exposed.
Notifications
What is sent, to whom, on which events, and a record of what was sent.
History
The complete event trail for a shipment, retained and retrievable when a query arrives later.
The status has to be a byproduct
This is the design decision that most determines whether shipment tracking survives its first month, and it is the same update-friction problem that decides whether any field record works.
If keeping the status current requires somebody to open a screen and type what they already know, it will happen for a few weeks and then it will not. The status board becomes progressively wrong while continuing to look authoritative, and people keep acting on it.
The way around it is to derive status from actions the operation is already performing for its own reasons.
The consignment was booked and an LR was generated. That is the booked event, and it exists because the LR exists.
The consignment was loaded onto a trip and the trip despatched. That is the loaded and despatched event, and it exists because dispatch records which consignments went on which vehicle.
The driver captured the POD at the door. That is the delivered event, with a time on it, and it exists because the POD had to be captured anyway.
A failed attempt was recorded with a reason. That is an exception event, and it exists because the delivery operation records failures.
None of these required anybody to update a status. Each is a record the operation makes for a purpose of its own, and the customer-facing status is assembled from them.
Where a gap remains, the honest response is to show less rather than to add a manual step. A tracking view with four reliable states beats one with nine states where four are current and five are typed by somebody when they remember.
The upstream pages carry the detail on each of these: LR and Consignment Note Software, Dispatch Management Software, Proof of Delivery Software and Delivery Management Software.
Customers want arrival, not location
Operations that build tracking frequently build a map, because location data is available and a map is easy to show.
Customers rarely want a map. What they want to know is when the goods will arrive and whether anything has gone wrong, and a dot on a highway answers neither. A customer looking at a dot has to interpret it, and the interpretation is usually wrong in one direction or the other.
Three things answer what customers are actually asking.
A current expected arrival, updated as the shipment progresses rather than repeating the date given at booking. A commitment that has visibly not been revised despite an obvious delay damages more trust than the delay itself.
An explicit exception when something has gone wrong, saying what happened and what is being done. Silence during a problem is what generates the phone call the tracking was supposed to prevent.
A small number of states that mean something to the customer. Internal operational stages are frequently more granular than a customer needs, and exposing all of them creates questions rather than answering them.
There is a related decision about what to expose at all. Where your customer is a consignor and the recipient is their customer, what may be shown to the recipient is a matter for your arrangement with the consignor. Some will want the recipient to have direct visibility under their own branding; some will want all contact to route through them. Establish this before building rather than after, and hold it as a setting per customer rather than a single policy.
A wrong status is worse than none
Worth stating plainly because the failure is common and its cost is underestimated.
A customer with no tracking calls to find out. It is inefficient and it produces a correct answer.
A customer with tracking that says the shipment is out for delivery makes decisions on that basis: keeps someone at the site, holds a production line, arranges labour to unload. If the status is stale and the shipment is not coming today, the cost of the wrong information exceeds the cost of no information, and the trust does not come back quickly.
Three practices reduce this.
Show a timestamp on the status. "In transit, last updated at 9:40 this morning" allows the reader to judge how much to rely on it. A status with no time claims more certainty than it has.
Do not display states you cannot keep current. Fewer reliable states, more often.
Make exceptions visible rather than leaving a stale normal state in place. A shipment held at a check post should not continue displaying as in transit. Where you know something has gone wrong, saying so is better than a status that is technically true and practically misleading.
The same reasoning applies to notifications. A notification sent on an event that is reliably captured is useful. One sent on an event that is sometimes captured trains customers to distrust all of them.
Where shipment tracking looks different by business type
- Courier and Parcel Business Software, where recipients are individuals and tracking is expected as standard.
- Freight Forwarder and CHA Software, where milestones come from carriers, ports and agents rather than from your own operation.
- Transport Contractor and Fleet Owner Software, where the consignor is a business wanting visibility across many consignments at once.
- Container Transporter and CFS Software, where the status of interest includes gate movements and the empty return.
- E-commerce Logistics Software, where the marketplace or brand controls the customer relationship and expects data rather than a portal.
- Cold Chain Logistics Software, where condition during transit is part of what the customer wants to see.
Why operators choose Pentoggle for shipment tracking
Status derived from work already happening
Booking, dispatch, delivery and POD events assembled into a status, with nobody typing updates.
Arrival and exceptions, not a map
The current expected arrival and an explicit statement when something has gone wrong, which is what customers are asking.
Fewer states, kept current
A short set of reliable states with timestamps, rather than a detailed trail that is partly stale.
Visibility controlled per customer
What a consignor sees, what a consignee sees, and what routes through your customer instead, set per arrangement rather than as one policy.
Sits around your accounting and telematics
Tally and comparable systems continue handling accounting and GST. Your telematics provider continues supplying vehicle data. Pentoggle assembles the customer-facing status from the operational record.
A useful number for shipment tracking
The age of the most recent status event on shipments currently in transit.
This measures whether the tracking is actually current, which is the thing that determines whether it is worth having at all. A tracking system is only as good as its staleness, and staleness is measurable.
Read the distribution rather than an average. Most shipments will have recent events and a few will have nothing for days, and those few are exactly the ones a customer is about to call about. That list is a working list for the customer service desk.
Watch it by stage as well. If the gap is concentrated between despatch and arrival, that is expected on a long haul and the fix is a better expected-arrival estimate rather than more events. If the gap is concentrated after arrival at destination, something in the delivery process is not being recorded, and that is a capture problem worth fixing.
Where enquiry volume is measurable, track it alongside. A tracking system that is working should reduce the number of status enquiries reaching your team, and if it does not, the likely cause is that customers do not trust it or cannot find it.
Ready to build shipment tracking software?
Your operation already knows when a consignment was loaded, despatched and delivered.
The customer calling to ask is asking for something you have.
Describe the events your operation already records to Pentoggle in plain English and generate a working first version in hours, then refine it around your process.