Last-mile delivery software runs the final leg at volume: allocating shipments to riders and delivery staff, giving each of them a workable run, recording every attempt and its outcome, capturing collection at the door, handling reattempts and returns, and reporting what a completed delivery actually cost. With Pentoggle, an operator can describe how the last leg actually works and generate the starting application around it.
This page assumes volume and individual recipients. If your deliveries are to businesses, plants, warehouses or retail outlets, with appointments and gate constraints, start with Delivery Management Software. If your question is about running a branch and franchise network rather than the run itself, start with Courier and Parcel Business 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 run: what each rider has, what happened at each door, and what is coming back.
Key takeaways
- The unit of cost is the attempt while the unit of revenue is the shipment, so the number of attempts per completed delivery is the main lever on last-mile economics.
- Reattempts and returns are a second and third journey with no additional revenue, and their cost is frequently absorbed rather than measured.
- The rider needs the run on a phone with everything required at each door, including any collection due, because a question asked from the doorstep costs more than the delivery is worth.
- Collection at the door is money passing through many hands briefly, which makes reconciliation to the shipment a control question rather than an accounting one.
- A useful number is cost per successful delivery, with attempts per completed delivery beside it.
The spreadsheet is often not the problem
A printed manifest per rider, marked up and reconciled at the end of the day, is a working system and at modest volume it is a reasonable one.
The trouble starts at identifiable points.
When attempts are not counted
The sheet records deliveries. It does not record that the rider went to eleven addresses twice, so the cost of the day looks like the cost of the completions.
When collection reconciles at the branch, not the shipment
Cash comes back as a total that matches or nearly matches. Individual discrepancies pass through unnoticed because nothing is reconciled shipment by shipment.
When the rider has to call for information
A wrong pin code, a missing flat number, a recipient not answering. The rider calls the branch, the branch checks, the rider waits. Repeated across a run, this is a large part of why runs overrun.
When returns disappear from view
Shipments that could not be delivered come back to the hub and re-enter the pile. Which ones, for how long, and what is to be done with them is a list that frequently does not exist.
What last-mile software holds
Shipments for the day
What is to be delivered, with recipient, address, contact, and any collection due.
Rider allocation
Shipments assigned to riders or delivery staff, by area, capacity and shift.
The run on a phone
Sequence, addresses, contact numbers, delivery notes and what is required at each door.
Attempts
Every attempt with time, outcome and reason for failure from a defined list.
Collection
Cash, digital payment or other collection captured at the door against the shipment it settles.
Acknowledgement
Signature, photograph or other proof captured at the point of delivery.
Reattempts and returns
Undelivered shipments held with their reason, next action, and how long they have been pending.
Cost per delivery
Rider cost and run cost allocated over completed deliveries rather than over shipments assigned.
Attempts, not deliveries
This is the central measurement point in last-mile work and it is worth stating carefully.
An attempt has a cost whether or not it succeeds. The rider travelled to the address, carried the shipment, and spent the time. A delivery completed at the first attempt consumes one unit of that cost. One completed at the third consumes three, plus the handling between attempts, plus any contact with the recipient in between.
Reporting that counts deliveries and treats failures as an operational annoyance makes the economics invisible. A run that completed ninety deliveries from a hundred and thirty attempts cost a third more per delivery than the completion count suggests, and no report built on completions will show it.
The reasons matter as much as the count, and they sort into the same three owners described on Delivery Management Software: recipient-side, booking-side and operation-side. In last-mile specifically, recipient availability is frequently a large share of failures, and it has a set of remedies worth naming because they are cheap.
Contacting the recipient before arrival, where the operation has a number and permission to use it. Offering a delivery window rather than a day. Allowing delivery to an alternative person or a neighbour where the consignor permits it. Allowing the recipient to reschedule rather than discovering the failure at the door. Each of these reduces attempts, and each has a cost of its own, which is why the pair of numbers matters rather than either alone.
Address quality is the booking-side half and it is worth attacking upstream. Incomplete addresses, wrong pin codes and missing landmarks are created at the point of order, frequently by a consignor whose data is poor, and they produce failures that the delivery operation cannot fix at the door. Reporting failure reasons back to the consignor is the only real remedy, and it needs the reason data to be credible.
Returns are a whole second journey
Every undelivered shipment goes somewhere, and the reverse flow is the part of last-mile economics most commonly left out.
A shipment that fails all its attempts returns to the hub, is held, and eventually goes back to the consignor. That journey consumes handling, space, and in many cases a return leg with its own transport cost, and it earns nothing. Where the original delivery was on a rate that assumed completion, the shipment has now cost several times what it earned.
Three things make this manageable.
A pending list with age. Undelivered shipments held at the hub, with how long each has been there and what the next action is. Without this, shipments sit because nobody owns them.
A decision point rather than an indefinite hold. After a defined number of attempts or days, a shipment needs a decision: reattempt, return to consignor, or hold pending instruction. Which of those applies depends on your arrangement with the consignor, and the arrangement is worth having explicitly rather than deciding case by case.
Return cost attributed to the consignor and the reason. A consignor whose shipments return at a high rate is more expensive to serve than the rate assumed, and that is a commercial conversation supported by evidence. Frequently the cause is address quality or a product category with a high refusal rate, and both are things the consignor can act on.
For operations serving e-commerce, returns include customer-initiated returns as well as failed deliveries, which is a different flow with its own handling and is covered on E-commerce Logistics Software.
Collection at the door is a control problem
Where deliveries involve collecting money, the operation is handling amounts belonging to somebody else, briefly, across a large number of people. That is a control question regardless of how much anyone is trusted, and it is worth designing rather than assuming.
Four things should be visible.
Collection recorded against the shipment, in the same entry as the delivery, so no separate reconciliation step is created. Splitting them produces a matching task that would not otherwise exist.
What is held and by whom, right now. Not the day's total collected, but the amount currently with riders and at hubs that has not moved onward.
Ageing by rider and by hub. A hub passing amounts onward daily and one doing so weekly may report the same monthly total while representing different exposures.
Reconciliation at shipment level rather than in bulk. A total that matches can contain offsetting individual errors, and only shipment-level matching finds them.
The onward obligation is the other half. Amounts collected belong to the consignor and are payable to them on agreed terms. Holding them longer than agreed is a working-capital and control matter that should be a deliberate position rather than something arrived at by drift. What the terms are, and how such amounts should be treated, depends on your arrangements, so confirm that with your CA and configure the application accordingly.
Digital collection reduces the exposure and does not remove the reconciliation, because a digital payment still has to be matched to the shipment it settles.
Where last-mile looks different by business type
- Courier and Parcel Business Software, where the run sits inside a branch and franchise network with its own settlement.
- E-commerce Logistics Software, where marketplace requirements and customer-initiated returns shape the whole operation.
- City Distribution Software, where recipients are businesses on a repeating route rather than individuals.
- Pharmaceutical Logistics Software, where the recipient is a chemist or distributor and documentation travels with the delivery.
- Cold Chain Logistics Software, where the shipment has a condition to maintain until the moment it is handed over.
- Tempo and Small Commercial Vehicle Software, where the operator is delivering with their own vehicle.
Why operators choose Pentoggle for last-mile delivery
Attempts counted, not just completions
Every attempt with its outcome and reason, so cost per completed delivery reflects what the day actually cost.
The run on the rider's phone
Sequence, addresses, contacts, notes and any collection due, so questions are not asked from the doorstep.
Collection tied to the shipment
Captured in the same entry as the delivery, reconciled shipment by shipment, with ageing by rider and hub.
Returns as a tracked list
Pending shipments with age and a next action, and return cost attributed to consignor and reason.
Sits around your accounting
Tally and comparable systems continue handling accounting, invoicing and GST. Pentoggle adds the operational layer around runs, attempts, collection and returns.
A useful number for last-mile delivery
Cost per successful delivery, with attempts per completed delivery beside it.
Cost per shipment assigned understates the real figure, because it spreads the day's cost over work that did not complete. Cost per successful delivery is what the business actually pays to finish a job.
Attempts per completed delivery is the driver behind it, and having both means an improvement can be understood rather than just observed. A fall in cost per delivery achieved by reducing attempts is a genuine gain. The same fall achieved by loading more shipments per rider may be borrowing against completion rates and will show up next month.
Segment by consignor and by area. Consignors differ substantially in address quality and recipient availability, and a consignor that looks profitable at contracted rates can be loss-making once attempts and returns are counted. That is a rate conversation with evidence behind it.
Where you also track first-attempt delivery rate at network level, as a courier business would, treat that as the network quality measure and this as the unit economics measure. See Courier and Parcel Business Software.
Ready to build last-mile delivery software?
Your report says the riders completed ninety deliveries.
How many doorsteps they visited to do it is the number that decides whether the day paid.
Describe how your runs are allocated and what happens at the door to Pentoggle in plain English and generate a working first version in hours, then refine it around your process.