Courier software in South Africa: plan dispatch to proof of delivery

Define the order record before the map

Start with a real delivery and follow it through your operation. Record the customer reference, collection and delivery contacts, addresses, parcel details, promised service and instructions. Decide which details the dispatcher must validate before assignment. Keep a history of corrections rather than silently changing the record after a driver has started.

Separate an order from a delivery attempt. A refused parcel, inaccessible premises or incorrect address may create another attempt, with its own reason, time and evidence. If the software treats every exception as a completed job, the dashboard can look healthy while customers still wait. Agree status definitions with dispatch and customer service together.

Design for the driver’s actual phone and connection

Test the journey on the devices drivers will use. Decide whether a mobile-friendly web app is sufficient or whether offline capture is needed. A disconnected device should clearly distinguish a locally saved update from one received by the office. Show pending uploads and failed synchronisation so a driver knows what still needs attention.

Scope the evidence needed for proof of delivery: recipient name, timestamp, approved photograph or signature where appropriate. Limit access to customer contact details by role and active assignment. Define how a wrong attachment is corrected, how long evidence is retained and how authorised staff retrieve it. These are operational and privacy decisions, not default settings to leave until launch.

Make tracking and messages reflect approved events

A customer tracking page should show the approved public status and a useful exception message. It does not need to reveal internal staff notes, driver personal details or another customer’s address. Use a reference and suitable access controls; check that changing an identifier cannot expose another delivery.

For the website, answer collection cut-offs, delivery areas, parcel restrictions and what happens after a failed attempt. Use terms the buyer recognises, such as courier booking, delivery tracking and proof of delivery. Publish your actual service rules. A tracking integration depends on the provider’s API, commercial plan and permitted use, so check access before quoting it.

Pilot one route and reconcile every job

Choose a manageable dispatch group and run a pilot with representative exceptions, not just successful deliveries. Import a small set of orders, assign them, capture evidence and confirm that customer updates follow the agreed rules. Compare the software’s completed jobs with the office’s delivery records before expanding.

Ask a supplier to separate discovery, driver access, dispatch, tracking, imports and ongoing hosting or messaging costs. Pricing depends on users, devices, data migration and integrations. The first release can focus on dispatch and evidence; it does not need route optimisation, fleet telemetry and invoicing in one launch.

What to measure

Start with your own baseline. These are definitions for your team to track, rather than promised improvements or industry benchmarks.

Unresolved exceptions

Open exception records grouped by reason, owner and age.

Evidence completeness

Completed deliveries with the required proof attached and synchronised.

Update lag

Time between an operational event and receipt of its approved system update.

Useful questions