Customer Tracking Portal
A delivery business whose office phone rings continuously with customers asking where their delivery is, each enquiry requiring someone to call a driver.
The problem
The business is paying staff to relay information it already has, and customers judge reliability by how hard it is to get an answer.
In scope
- Tracking link per delivery
- Status display
- Automated notifications
- Proof-of-delivery access
- Corporate customer login with a view across all their deliveries
Out of scope
- Order placement
- Invoicing
- Dispatch
- Driver management
- This is a read surface over delivery data that must already exist — it depends on the Fleet Dispatch & Delivery Control Tower or the Driver Application and Proof of Delivery concept, or an existing system with a usable status feed.
What this would cover
Grouped by module — open the ones you want to read.
Tracking link
- Unique per delivery, no login, works on a shared link, expires after a configurable period post-delivery
Status display
- Plain-language progression with timestamps; no map of the driver's live position, deliberately
Delivery window
- Communicated as a window, never a time
Notifications
- Automated at collection, at out-for-delivery, at completion, and on failure; message channel rather than email, because that is where the recipient is
Proof access
- The recipient and the sending customer can view and download proof of delivery
Corporate view
- A business customer logs in and sees all their deliveries, filterable, with bulk proof download
Failure communication
- When a delivery fails, the reason reaches the customer automatically rather than being discovered by them
Data model
- Job (read)
- TrackingToken
- NotificationRule → NotificationEvent
- CustomerAccount
- ProofOfDelivery (read)
Invariants
- A tracking token grants access to one job and nothing else, and reveals no driver personal data — not name beyond a first name, not phone number, not live position.
- Tokens expire.
- Notification events are logged so a customer disputing that they were told can be answered.
Offline behavior
Not applicable.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
This system is only as good as the status data behind it, and publishing bad data to customers is worse than publishing none.
If drivers are inconsistent about marking collection, customers see deliveries stuck at "collected" for a day and lose more confidence than the phone calls were costing. This should not be sold to a business that has not first fixed capture — which usually means the Driver Application and Proof of Delivery concept comes first, even though this is the smaller and more attractive purchase.
Exposing a driver's live location to customers is a privacy decision affecting a third party who has not consented.
The design shows status and location at status events only, which answers the question customers actually ask.
End state
What would be true about their day once this is running.
- A customer with a link stops calling.
- Failures are communicated as they happen rather than discovered.
- A corporate client can pull their own proof of delivery for their own records, which is the feature that makes them stay.
This is a deliberate first step toward Fleet Dispatch & Delivery Control Tower — its data model is designed as a genuine subset, so growing into it later doesn't mean starting over.
Let's map how your operation actually runs.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Start the operations review