Fleet Dispatch & Delivery Control Tower
A delivery and haulage business running a fleet of vans and motorcycles, plus contracted riders. Dispatch happens in a group chat. Proof of delivery is a photograph in a chat or a signed paper waybill that reaches the office days later. Invoicing waits for the paperwork.
The reality
A delivery and haulage business runs a fleet of vans and motorcycles, plus contracted riders. Dispatch happens in a group chat. Proof of delivery is a photograph in a chat or a signed paper waybill that reaches the office days later. Invoicing waits for the paperwork.
Where it breaks
- Dispatch happens in a group chat, so who was assigned what is a memory, not a record.
- Proof of delivery is a photo in a chat or a paper waybill that reaches the office days after the delivery actually happened.
- Invoicing waits for paperwork to physically return, so cash flow lags the work by days.
- A failed delivery gets discovered when the customer calls, not surfaced as something to act on.
- Nobody can say what a trip actually costs against what it earned.
The Afivox approach
Afivox doesn't start with a tracking map. It starts by replacing the chat scroll with a record — every assignment, every status change, every proof of delivery — because the map is only useful once there's something underneath it that can't be scrolled past or forgotten.
The system
Users
Office dispatchers, drivers and riders, customers, management
Application
Order intake, dispatch, driver application
Services
Tracking and communication, exceptions, costing and invoicing
Data
Order → Job → StatusEvent, Trip → Stop, Vehicle → FuelRecord → MaintenanceRecord
Integrations
Customer tracking link, status notifications
Security
Append-only status events, CoD liability tracking
What it looks like
Concept mockups — illustrative interfaces, not a built system.
Operations control tower
91%
On-time rate
12
Active drivers
34
In transit
4
Exceptions today
₦184,000
CoD outstanding
2
Failed attempts
Live map
Dispatch board
Driver app
Today — 2 jobs
Job #4471
14 Allen Ave, Ikeja
Job #4472
9 Admiralty Way, Lekki
Exception queue
| Job | Reason | Driver | Status |
|---|---|---|---|
| Job #4450 | Recipient absent | Chinedu | |
| Job #4441 | Address wrong | Bassey |
Proof of delivery
Fleet analytics
₦4,200
Margin per trip
₦612,000
Fuel cost (30d)
2
Vehicles due service
How it flows
Secure by design
- Status events are append-only — a delivery's history is a sequence, never a mutable current-state field that can be quietly overwritten.
- Proof of delivery captures device time and location at the moment of capture, not at the moment of sync, so it can't be backdated.
- A job cannot be marked delivered without a proof-of-delivery record attached to it.
- Cash on delivery collected is tracked as a liability against the driver until remitted, independent of the order's delivery status.
- The customer tracking link shows status without exposing the driver's live location or phone number.
Designed to improve
- Coordination — dispatch is a board, not a chat scroll, and who was assigned what is a record.
- Customer self-service — a customer asking where their delivery is gets an answer from a link, without anyone calling a driver.
- Cash flow — invoices are raised from delivery data the same day, not after paperwork returns.
- Profitability — cost per vehicle and per trip is calculated, so margin is known rather than felt.
Before
- Dispatch happens in a group chat, and reconstructing who was assigned what means scrolling.
- Proof of delivery arrives as a photo in a chat, sometimes days after the delivery happened.
- An invoice waits for a paper waybill to physically make it back to the office.
- A failed delivery is discovered when the customer calls to ask where it is.
After
- Dispatch is a board. Every assignment and reassignment is a timestamped record.
- Proof of delivery exists at the moment of handover, attached to the order.
- Invoices are raised from delivery data the same day.
- Failed deliveries surface as a worklist, with a structured reason, before the customer has to ask.
Your operation probably has a workflow like this.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Tell us where yours breaks