Delivery management software holds the operational picture of deliveries in progress: what is out for delivery, who has it, what has been completed, what has failed and why, what is running late, and what the customer has been told. With Pentoggle, an operator can describe how deliveries actually run and generate the starting application around it.
This is the general page, written for any delivery operation including business-to-business deliveries to plants, warehouses, dealers and retail outlets. If your operation is specifically the final leg to end recipients at volume, with riders, attempts and cash collection, start with Last-Mile Delivery Software.
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 delivery position: what is out, what is at risk, and what somebody needs to do about it.
Key takeaways
- The useful view is exceptions, not everything. A screen listing every delivery in progress requires somebody to scan it; a screen listing the ones at risk does not.
- A failed delivery costs roughly what a successful one costs and returns nothing, so the reason for failure matters more than the count.
- Delivery failures sort into recipient-side, booking-side and operation-side causes, and each needs a different response from a different person.
- Telling the customer before they ask converts a complaint into a notification, and it depends on the operation knowing first.
- A useful number is the share of deliveries completing without an exception, read with the reason breakdown behind the rest.
The spreadsheet is often not the problem
A despatch list marked up through the day, with the branch phoning drivers for updates, is a working system and at modest volume it is an efficient one.
The trouble starts at identifiable points.
When knowing the position requires phone calls
The customer asks about a delivery. Answering means calling a branch, which calls a driver, which calls back. Twenty minutes for a question that recurs many times a day.
When failures have no reasons attached
Six of forty deliveries did not happen. The list shows six blanks. Whether those were closed premises, refused goods, or a vehicle that ran out of time is not recorded, so nothing improves.
When problems surface after the customer notices
The delivery was going to be late by mid-morning. The customer found out at four o'clock by calling. The information existed inside the operation hours earlier.
When the same customers are affected repeatedly
Deliveries that fail tend to be the last few on a route, which means the same recipients every time. Without the record, that pattern is invisible and the relationship erodes.
What delivery management software holds
Deliveries in progress
What is out, with consignment, recipient, address and expected timing.
Assignment
Vehicle, driver or delivery staff, and the route or run it belongs to.
Delivery requirements
Windows, appointment requirements, site access, documents needed and anything the recipient specifically requires.
Status as it happens
Out for delivery, arrived, completed, or not completed, recorded at the point rather than at day end.
Exceptions and reasons
What did not go to plan, from a defined list, captured where it happened.
At-risk view
Deliveries unlikely to be completed as committed, surfaced early enough to act.
Customer communication
What the recipient or consignor has been told, when, and by whom.
Reattempts
Deliveries to be attempted again, with the reason from last time and any change needed.
Show the exceptions, not the list
A common way delivery software fails is that it shows everything.
A screen listing every delivery in progress is complete, and it requires a person to read it, interpret it and notice the two entries that matter. That person has other work, so it gets read carefully for the first week and skimmed thereafter.
An operation of any size needs the opposite: a short list of deliveries that need attention, and silence about the rest. Most deliveries proceed without incident and require nothing from anybody.
Defining what qualifies as needing attention is the design work, and it is worth doing carefully because the credibility of the whole system depends on it. Deliveries not started when they should have been. Deliveries where the vehicle is unlikely to arrive within the committed window. Deliveries attempted and failed. Deliveries where the recipient has raised something. Deliveries where a required document or a required collection is missing.
Two things determine whether such a list stays useful.
Thresholds set per customer and per route rather than globally. A delay of thirty minutes is nothing for a warehouse delivery with a day-long window and significant for an appointment slot. Global thresholds generate items nobody needs to see, and a list with noise in it stops being read.
Every item having an owner and a next action. An exception nobody is responsible for is a notification. The list should be short enough that each item can be somebody's task.
The test of a well-designed exception view is that it is frequently empty or nearly so. Operators sometimes read an empty screen as a system doing nothing, when it is a system telling you the day is going to plan.
Failure reasons sort into three owners
A failed delivery consumes the travel, the time and the handling of a successful one and produces nothing, and in many cases it has to be repeated, consuming those costs twice for one delivery.
Counting failures tells you the size of the loss. Recording why sorts it into problems different people can fix.
Recipient-side. Premises closed, nobody available to receive, goods refused, payment not ready, no space to unload. These are addressed with better information before arrival, a call ahead, appointment confirmation, or a change in the terms agreed with that customer.
Booking-side. Address incomplete, wrong contact, requirements not communicated, wrong goods or quantity against the order. These originate before the vehicle left, frequently with the information captured at booking, and they are fixed upstream rather than at the door.
Operation-side. Ran out of time, vehicle unsuitable for the site, driver could not locate the premises, document or collection missing. These are planning, routing and preparation problems.
The value of the split is that the three have completely different remedies and completely different owners, and a single failure count gives no clue which conversation to have. An operation discovering that most of its failures are booking-side has learned that its delivery problem is really a data-capture problem at the point of order, which no amount of delivery-side effort will fix.
Capture the reason at the point of failure, from a short defined list, by the person who is there. A free-text field filled in later produces descriptions rather than categories, and categories are what allow the pattern to be seen.
Telling the customer first
Most delivery complaints are not about the delay. They are about finding out from an absence.
A recipient expecting goods in the morning, hearing nothing, and calling at two o'clock has had a worse experience than one told at ten that the vehicle is running behind and will arrive by three. The physical outcome is identical. The relationship outcome is not.
This is only possible if the operation knows before the customer does, which is what the at-risk view is for. It is the same information, used proactively rather than reactively.
Three practical points.
Communicate when it becomes apparent, not when it becomes certain. Waiting for certainty usually means waiting until the customer already knows.
Say what will happen, not only what has happened. A revised expectation is useful; an apology without one is not.
Record what was said. When a dispute arises about whether a customer was informed, the record settles it, and when the same customer is told the same thing three weeks running, the record makes the pattern visible.
What can be shared, and with whom, depends on your arrangements with your customers, particularly where the recipient is your customer's customer rather than yours. Establish that before building notifications rather than after. The same question is covered from the status side in Shipment Tracking Software.
Where delivery management looks different by business type
- City Distribution Software, where a day is thirty drops on a repeating route to known outlets.
- Courier and Parcel Business Software, where volume is high and the branch network handles delivery.
- Transport Contractor and Fleet Owner Software, where deliveries are to plants and warehouses with appointment and gate constraints.
- Packers and Movers Software, where a delivery is a crew working at a destination for hours.
- Bulk and Tanker Transport Software, where delivery involves measured discharge and a quantity to agree.
- Container Transporter and CFS Software, where the delivery is one leg and the empty return follows it.
Why operators choose Pentoggle for delivery management
Exceptions, not everything
A short list of deliveries needing attention, with thresholds set per customer and route, and silence about the rest.
Failure reasons captured at the door
From a defined list, by the person present, so blanks become categories with owners.
At-risk before it is late
Deliveries unlikely to meet their window surfaced while there is still time to tell somebody.
A record of what the customer was told
When, by whom and what was promised, which settles disputes and reveals patterns.
Sits around your accounting
Tally and comparable systems continue handling accounting, invoicing and GST. Pentoggle adds the operational layer around deliveries in progress and the ones that need intervention.
A useful number for delivery management
The share of deliveries completing without an exception, read alongside the reason breakdown for the rest.
The headline figure is a health measure. The breakdown is the actionable part, and reporting one without the other is what makes delivery metrics feel like scorekeeping rather than management.
Segment by customer and by route rather than reading a single figure. Concentrations are common and informative: one customer whose sites are routinely unable to receive, one route where the last stops repeatedly fail, one origin whose address data is poor.
Read it with the delivery-attempt view where your operation reattempts failed deliveries, since a completion rate that looks acceptable can conceal a high number of second and third attempts. That cost is covered on Last-Mile Delivery Software.
Ready to build delivery management software?
Your team can tell you what went out this morning.
What is going to be a problem this afternoon is usually discovered when the phone rings.
Describe how your deliveries run and what tends to go wrong to Pentoggle in plain English and generate a working first version in hours, then refine it around your process.