AI automation in logistics: the last mile and proof of delivery

The long legs of a journey are comparatively well behaved. A container crosses an ocean and the information about it is imperfect but the process is stable. The final leg is where the cost concentrates, where most failures happen, and where a customer forms their opinion of the whole thing.

It is also where the information problem is most tractable, because unlike a supplier's factory the last mile is yours or your carrier's, and the data exists. The work is using it before a delivery fails rather than explaining afterwards.

What we'll cover

• Why the last leg dominates
• Density, windows and what a stop costs
• Failed deliveries and what causes them
• Building it with CodeWords
• Exceptions in transit
• Proof of delivery and disputes
• What the tracking page should say
• Carrier performance and selection
• The return leg as a network problem
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Why the last leg dominates

Cost per unit of distance is highest at the end, where consolidation stops and individual stops begin.

Failure is expensive and repeated. A failed delivery is a second attempt, a second cost, and frequently a third.

The customer experience is entirely here. Nobody judges you on the ocean leg.

Density determines economics, so a route with scattered stops costs disproportionately more.

Most exceptions surface here, even when their cause was upstream.

Small improvements compound, because the volume of individual stops is where any percentage applies to a large base.

Density, windows and what a stop costs

Cost per stop falls with density, which is why two deliveries on one street cost far less than two across a city.

A narrow promised window destroys density, because the route has to serve it rather than the geography.

Wide windows are cheaper and worse for the customer, and where that trade sits is a commercial decision rather than an operational one.

Offer a window the customer chooses where you can, since a chosen slot is attended far more reliably than an assigned one.

Cluster by area and by day, which for a regular delivery business is the single largest cost lever available.

Measure cost per successful stop, not per parcel, because the failed attempts and the second visits are where the real number differs from the quoted one.

Failed deliveries and what causes them

Nobody in is the largest category and is largely predictable from the delivery window.

Access problems — gates, buildings, codes — which are knowable in advance and rarely recorded.

Address wrong or incomplete, which is the upstream problem above.

Refused or unexpected, which usually means the customer was not told it was coming.

Damaged in transit, which is a packaging or handling question rather than a delivery one.

Categorise every failure and report the distribution, because each category has a different and specific fix and the aggregate rate tells you nothing about which.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which shipments to watch, what constitutes an exception, who is told, and what the customer receives.
3. Authorize the connections — the carrier tracking sources, the order system, and the customer communication channel.
4. Describe the exceptions: a shipment with no movement, a failed attempt, an address change request, a high-value or time-critical delivery.
5. Run it over last month's shipments and check which exceptions it would have caught and when.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Exceptions in transit

Absence of movement is the strongest signal, and it is the least reported one — a parcel that has not scanned in three days is a problem before any status says so.

A status that repeats is different from progress, and tracking pages present both identically.

Customs and clearance holds have their own patterns and usually need somebody to supply a document.

Weather and network disruption affect many shipments at once and should be grouped rather than raised individually.

Weight by consequence, not by lateness — a time-critical delivery and a routine one need different responses to the same delay.

Act before the customer notices, which is the entire value of watching this.

Proof of delivery and disputes

"It never arrived" is the most common dispute and the one that is answerable with evidence.

Capture the evidence properly: timestamp, location, signature or photograph, and who received it.

Photographs need care. A doorstep photograph can capture more than intended, and retention should be deliberate.

Link it to the order so support can answer without an investigation.

Automate the retrieval, since the delay in answering is usually finding the record rather than the record existing.

Track dispute rates by carrier and route, which is a measure of delivery quality that nothing else surfaces.

What the tracking page should say

A status is not an answer. "In transit" tells somebody nothing they can plan around.

Give an arrival estimate with an honest confidence, since a precise wrong time is worse than a wider right one.

Explain what a status means in plain words, because carrier vocabulary is internal language that customers read as significant.

Show what happens next and when, rather than only what has happened.

Make it work without a login and on a phone, which is where nearly all of these are opened.

Put the action there — redirect, reschedule, leave with a neighbour — since a tracking page that only informs generates the contact it could have prevented.

Carrier performance and selection

Measure against the promise, not against the revised estimate, which is the distinction most carrier reporting blurs.

Break it down by route and service, since a carrier good in one region may be poor in another.

Include failed attempts and disputes, not only late deliveries, because those are the costs that do not appear in a transit-time report.

Cost per successful delivery is the number that matters, not cost per label.

Share the data with the carrier, which changes behaviour more than an internal report does.

Keep an alternative warm. A single-carrier dependency is a risk that becomes visible at the worst possible time of year.

The return leg as a network problem

A return is a collection, which is a different and more expensive operation than a delivery.

Consolidation is the lever. Individual collections cost far more than drop-off points or aggregated pickups, which is why carriers price them differently.

Give the customer options, since a drop-off within walking distance is frequently preferred and is cheaper for everybody.

Track the return in transit, because the gap between a customer sending something and it being received is where the complaints concentrate.

Know where the goods actually are, since returns disappearing between the customer and the warehouse is common and invisible without tracking.

Measure the return leg's cost separately, as it is routinely absorbed into a general shipping line and therefore never examined.

Making it survive

Handle tracking data that is missing or contradictory, which is normal rather than exceptional.

Make exception detection idempotent, so a repeated status does not raise a repeated alert.

Normalise carrier status codes to your own vocabulary, since every carrier means something different by similar words.

Retain proof of delivery for as long as disputes can be raised, and no longer.

Report the outcome: shipments tracked, exceptions raised by type, failed attempts by cause, and disputes resolved.

Limits worth knowing about

Carrier data quality varies enormously, and some provide only sparse scans.

Status meanings differ between carriers and are not standardised in practice.

Physical constraints are real — vehicle capacity, driver hours, route density — and software does not change them.

Peak periods break every assumption, including carrier capacity and transit estimates.

You cannot automate a driver's judgement about whether a parcel is safe to leave, and pretending otherwise produces theft and disputes.

What to build first

Absence-of-movement detection: any shipment with no scan for a defined period, weighted by consequence and surfaced with the customer and order attached. It is the strongest available signal, almost nobody reports on it, and it converts a problem discovered by the customer into one you raised first.

Two habits make the difference. Validate addresses at the point of entry and never silently correct them, since most failed deliveries are address problems and nearly all of those are fixable while the customer is still present. And categorise every delivery failure by cause, because the aggregate failure rate tells you nothing and each category has a specific and different fix.

Frequently asked questions

Why does the last mile dominate logistics cost?

Because consolidation stops and individual stops begin, failures are expensive and repeated, and route density determines the economics. It is also where the entire customer experience is formed.

What causes most failed deliveries?

Address problems, nearly all of which are fixable before dispatch. After that, nobody being in, access problems that were knowable in advance, and customers who were not told a delivery was coming.

Why does a narrow delivery window cost more?

Because it forces the route to serve the promise rather than the geography, which destroys density — and density is what determines cost per stop. Where that trade sits is a commercial decision rather than an operational one.

What is the most useful transit signal?

Absence of movement. A parcel that has not scanned in days is a problem before any status field says so, and it is the least reported signal in shipping.

What should proof of delivery capture?

Timestamp, location, signature or photograph, and who received it — linked to the order so support can answer without an investigation. Photographs can capture more than intended, so retention should be deliberate.

What should a tracking page show?

An arrival estimate with honest confidence rather than a status, an explanation of what that status means in plain words, what happens next — and the actions that prevent a failed delivery: redirect, reschedule, leave with a neighbour.

How should carrier performance be measured?

Against the original promise rather than a revised estimate, broken down by route and service, including failed attempts and disputes, and reported as cost per successful delivery rather than cost per label.

What can automation not do here?

Change physical constraints — vehicle capacity, driver hours, route density — or replace a driver's judgement about whether a parcel is safe to leave. Pretending otherwise produces theft and disputes.

Why is a return more expensive than a delivery?

Because it is a collection, which carriers price differently for good reason. Consolidation through drop-off points or aggregated pickups is the lever, and a drop-off within walking distance is frequently what the customer prefers anyway.

Where do returns go missing?

Between the customer and the warehouse, and it is invisible without tracking the return leg. The cost of that leg is also routinely absorbed into a general shipping line and therefore never examined.

Related reading

• Automating order fulfilment
• Workflow automation for supply chain
• Automating Shopify orders to Google Sheets