Case study · Logistics & supply chain
One plan in the office, one app in the cab, one status customers believe
A regional freight operator was running dispatch on a whiteboard and tracking on the phone. We built a platform where the plan, the driver's day and the customer's status all come from the same place.
Engagement · Build & rollout
Two products on one job record: a dispatch console and a driver app.
- Industry
- Logistics & supply chain
- Solution
- Dispatch & delivery platform
- Engagement model
- Product team
- Market stage
- Operational rollout
- Client
- A regional freight operator, NL
- Scope
- Custom software development
- Platform
- Web console · Android app
- Environment
- Vehicles, warehouses, poor signal
Outcomes
What changed once the whiteboard came down
Every figure here replaces a phone call that somebody used to have to make.
-
80%
Fewer status calls to the office
Customers read the job status from the same record dispatch sees. This was the single largest category of inbound call the operator handled.
Measured against inbound call volume before rollout
-
35%
More deliveries per driver per day
No phone calls to confirm changes, no paperwork at the end of a round, and a route that reflects the actual plan.
Measured per driver after the first depot went live
-
90%
Faster proof of delivery
Signature and photographs are captured at the door and attached to the job immediately, instead of being written on paper and typed up that evening.
From delivery completed to proof available in the office
Context
The situation before the platform
How a freight operation runs on a whiteboard, and where that breaks.
The business
A regional freight operator running scheduled and ad-hoc deliveries with its own drivers and vehicles across a mixed urban and rural area.
The starting point
Dispatch planned the day on a whiteboard, drivers adjusted it by phone, and customers were told the status only when they rang to ask.
The trigger
Freight goes wrong in the gaps between those three. Every relayed message is work that software should be doing, and every relay is a chance to be wrong.
What they wanted
The plan, the execution and the customer-facing status as the same data, so a change made in a cab shows up in the office and on the customer's tracking without a phone call.
Constraints
Signal disappears in warehouses, tunnels and rural routes · drivers are wearing gloves, in a hurry, often in the rain · plans change all day with breakdowns and failed deliveries · proof of delivery is a commercial document, not a nice-to-have.
System
What it runs at today
The platform as it runs across the operation.
-
3
Audiences served
Dispatch, drivers and customers, from one record
-
1
Source of truth per job
No second list, no whiteboard, no parallel spreadsheet
-
0
Connection required to work
The driver app holds the day locally and syncs when signal returns
-
3
Proof types captured
Signature, photographs and notes, timestamped and located
The engineering problem
Four problems the road imposes
Logistics software fails in a vehicle, not in a meeting room. These four decided the design.
-
The driver app is used in the worst conditions in the system
A dispatcher sits at a desk with two screens. A driver is standing at a tailgate in the rain, wearing gloves, with a customer waiting. Software designed for the first will not survive the second.
What we did
We designed the driver app first and constrained everything else to fit it: the day as a short ordered list, large targets, few taps, readable in daylight.
-
No signal is the normal case, not the exception
Warehouses are steel boxes, rural routes have gaps, and tunnels are tunnels. An app that assumes connectivity stops working exactly where the work happens.
What we did
The app holds the whole day locally and works offline by default. Updates queue and replay on reconnection, and the driver is always told which state they are in.
-
Dispatch and driver will change the same job at once
A dispatcher reassigns a delivery at the same moment the driver marks it complete. Both actions are legitimate, and naive syncing will silently discard one of them.
What we did
Conflicts resolved explicitly rather than by last-write-wins, with the rule that a driver's record of what physically happened takes precedence over a plan made in the office.
-
Proof of delivery is a commercial document
A signature is not a nice feature — it is what settles a dispute about whether goods arrived. Captured badly, or captured late, it is worth nothing when it is needed.
What we did
Proof captured at the door as part of completing the job, timestamped and located, attached to the record immediately and available to the office and the customer.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Driver app
- Android
- Local database
- Queued sync
- Camera & signature
An offline-first app holding the day locally, with everything the driver does queued and replayed rather than depending on a live connection.
-
Dispatch console
- Web console
- Live board
- Drag-and-drop assignment
The whiteboard rebuilt as software, keeping what worked about it: everything visible at once, change by moving things.
-
Services
- Job service
- Location tracking
- Conflict resolution
- Notifications
One job service both products read and write, with explicit conflict rules rather than whichever update arrived last.
-
Customer & integration
- Status page
- Notifications
- Export to accounts
Customer-facing status from the same job record, and job data exported to the operator's accounts system rather than re-keyed.
The app is offline-first rather than offline-tolerant. It works from local data as the normal case and treats the network as an optimisation, which is the only design that survives a rural round.
Solutions
Dispatch, the cab, and the customer
Three audiences, one job record. The driver app is deliberately the simplest thing in the system, because it is used in the worst conditions.
-
Dispatch console
The day's jobs, vehicles and drivers on one board, with assignment, reordering and reassignment done by dragging rather than by phone call.
-
Driver app
The driver's day as a short ordered list: next stop, what to do, what to capture. Large targets, few taps, readable in daylight.
-
Live tracking
Position and progress against the plan, so dispatch can see a run slipping before the customer notices it.
-
Proof of delivery
Signature, photographs and notes captured at the door, timestamped and located, attached to the job and available immediately.
-
Offline first
The app holds the day locally and works without signal. Updates queue and sync when the connection returns, and the driver is told which state they are in.
-
Customer status
A status view and notifications for the customer, drawn from the same job record, so the office is not the messenger.
Key capabilities
What it does day to day
Six capabilities across the operation.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Dispatch board | Dispatcher | Real time | The day's jobs, vehicles and drivers on one board, reassigned by dragging |
| Driver day | Driver | On sync | The round as a short ordered list: next stop, what to do, what to capture |
| Live tracking | Automatic | Continuous | Position and progress against the plan, so a slipping run is visible before the customer notices |
| Proof of delivery | Driver | Per delivery | Signature, photographs and notes, timestamped and located, attached to the job |
| Offline working | Automatic | On reconnect | The day held locally, updates queued and replayed, state always shown |
| Customer status | Automatic | On change | Status and notifications drawn from the same job record |
Integrations
How the moving parts plug in
Everything about a job — planned, executed or reported — resolves against one record.
In the field and the office
- Driver appExecution and proof capture
- Dispatch consolePlanning and reassignment
- Vehicle locationProgress against the plan
Job service
- Job statePlanned, assigned, in progress, complete
- Conflict rulesWhat actually happened wins
- Sync queueOffline updates replayed in order
Outputs
- Customer status
- Proof archive
- Accounts export
- Operational reporting
Because the customer status and the accounts export both come from the job record, what the customer was told and what the customer is invoiced for cannot disagree.
Security & data
What protects the operation's data
The system holds customer addresses, delivery evidence and driver locations — commercially sensitive and personal in equal measure.
-
Role-scoped access
Drivers see their own round, dispatchers their depot, customers only their own jobs.
-
Device data
The day held on a driver's device is scoped to that driver and cleared when the round closes, so a lost phone is not a customer list.
-
Location boundaries
Driver location is tracked during a round for operational purposes and not retained beyond what the delivery record requires.
-
Tamper-evident proof
Delivery evidence is timestamped and located at capture, so it stands up when a delivery is disputed.
The brief
The office says one thing, the driver knows another, the customer is told a third
Freight goes wrong in the gaps. Dispatch plans the day on a board, the driver adjusts it by phone, and nobody updates the customer until they ring to ask. Every one of those conversations is a person doing work that software should be doing.
The operator wanted the plan, the execution and the customer-facing status to be the same data, so that a change made in a cab shows up in the office and on the customer's tracking page without anyone relaying it.
- Dispatch plans and reassigns without ringing the driver
- Drivers see their day and update it from the cab
- Proof of delivery captured at the door, not typed up later
- Customers see status without calling the office
What the road does to software
- 01Signal disappears in warehouses, tunnels and rural routes
- 02Drivers are wearing gloves, in a hurry, often in the rain
- 03Plans change all day: breakdowns, failed deliveries, late loads
- 04Proof of delivery is a commercial document, not a nice-to-have
Process
We rode along before we designed anything
The dispatch board was easy to understand from a meeting room. The driver's day was not, so we went and watched it.
-
Observing the operation
Time in the office and in the cab, recording every phone call and every piece of paper, because each one marks something the software would have to replace.
-
Designing the driver app first
The constrained end drives the design. We settled what a driver can realistically do at a delivery, then built dispatch to fit it.
-
Dispatch console
The board rebuilt as software, keeping the things that worked about a whiteboard: everything visible at once, change by moving things.
-
Offline and sync
The bulk of the engineering: local storage, queued updates, conflict handling when dispatch and driver change the same job.
-
Rollout by depot
Introduced one depot at a time with the old process running alongside, until the drivers stopped using the phone.
Technology
Built for vehicles, warehouses and no signal
An offline-capable mobile app and a real-time console over a single job service.
Driver app
- Android app
- Local database
- Queued sync
- Camera and signature capture
Dispatch
- Web console
- Live board
- Drag-and-drop assignment
Core services
- Job service
- Location tracking
- Notification service
Integration
- Customer status page
- Export to accounts
- Reporting
Business impact
What changed for the operator
Three things the office noticed within the first depot rollout.
-
The phone stopped ringing
Customers read status themselves, which removes the calls that used to interrupt dispatch all day.
-
Disputes end quickly
Timestamped, located proof attached to the job settles a delivery argument in minutes rather than days.
-
Evening paperwork gone
Proof captured at the door means nothing has to be typed up after the round.
The result
The whiteboard, the phone calls and the paperwork all became the same record
Dispatch plans and changes the day on screen, drivers work from an app that keeps functioning without signal, and proof of delivery is captured at the door instead of typed up that evening.
Customers get status from the same record the office sees, which removes an entire category of phone call.
- Dispatch board and driver app on one job record
- Offline-capable app with queued sync
- Proof of delivery captured, timestamped and located
- Customer status without a call to the office
What we would repeat in logistics
- 01Design the driver's screen before the dispatcher's
- 02Assume no signal and make the app say which state it is in
- 03Replace each phone call with something explicit
- 04Roll out depot by depot, never all at once
Verified reviews
What clients say about our custom software work
Verified reviews from clients of ours on similar work, published on Clutch. They are not from this project.
-
Custom Software Development
Web-Based Coupon App Development
The work produced by the team was of exceptional quality.
Jon Thies
CTO, Model Rocket Feb 2022 – Mar 2023
-
Custom Software Development
Mobile & Web Platform Development & Design
Silver Scintilla was responsive, respectful, and enjoyable to work with, quickly addressing any questions or requests.
DeShawn Brown
CEO & Founder, Lithios Jun 2021 – Nov 2022
-
Custom Software Development
Web-Based HRM System Development
Silver Scintilla provided the best solution with scalable functionality, personalized features, and robust security.
Suheb Khan
Director, Collaborative Insight Technologies Jul 2020 – Jun 2022
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate