Failed delivery reasons: how to find them, measure them and cut them down

Failure, reschedule and refusal: why they can't share a bucket

The first mistake in record-keeping is counting everything that didn't end with goods changing hands the same day as one thing. That broad wording hides events that are fundamentally different, and each of them is cured a different way.

• A reschedule requested by the customer. The recipient is reachable, they still want the order, only the date or the time slot has changed. Economically this is an extra visit, not a loss.
• A failure that is our fault. The courier ran out of time, the address was mixed up, the goods were wrong or damaged. Here you lose both money and goodwill.
• An unreachable recipient. No answer, nobody home, a broken door intercom, a gated site. Technically nobody's fault, but the repeat visit is on your budget.
• A refusal at the door. The customer changed their mind, didn't like the look of the goods, has no cash to pay. That is about the product, the price and how the terms were explained — not about logistics.
• A same-day return. The order was handed over and cancelled on the spot — a separate scenario that often hides inside your successful drop-offs.

While all of this sits in one pile, analytics are meaningless: a drop in the overall percentage could mean the dispatch desk is doing better, or simply that the share of prepaid orders fell with the season. Splitting failures into groups isn't bureaucracy — it is the condition under which the number becomes something you can manage.

A working list of reasons: what actually derails deliveries

In practice the overwhelming majority of failures fit into a short list. Below is one worth taking as a starting point and adapting to your own order flow.

Recipient-related:

• Unreachable by phone: switched off, no answer, or the number is simply wrong.
• Not at the address during the agreed time slot.
• A reschedule at the customer's request, including a late one — announced as the courier pulls up.
• A refusal at handover: changed their mind, the goods weren't right, no money to pay.
• Someone else tries to accept the order when the terms require a specific recipient.

Address and access:

• An incomplete address: no building, entrance, floor or office number.
• A dead intercom, a missing code, a site pass required to get in.
• A closed office building, warehouse or shop that isn't open at the stated hours.
• A geocoding error: the pin on the map doesn't match the actual entrance.

Execution-related:

• Running late because of an overloaded route or traffic.
• Goods not released by the warehouse, picked incompletely, or swapped during loading.
• Damage or a mismatch discovered on the spot.
• Technical trouble: a vehicle breaks down, a phone dies, the connection drops.
• The courier is off sick or doesn't show up and there was no time to reassign the jobs.

One case deserves its own line: goods handed over at the wrong address. It is rare and expensive, and unlike the rest it almost always points to a systemic problem — identical street names, an address copied by hand, or no verification step before handover.

Reason codes: how to stop reading free text

The most common recording problem is the free-form comment. "Customer won't pick up", "no answer", "called ×3", "not there, phoned" — four entries describing one event, and no query will ever add them up.

The fix is simple: a closed list of ten to fifteen options the courier picks with a single tap, plus an optional field for details. The rules for building it:

• Wording describes a fact, not a judgement. "Recipient did not answer calls" instead of "customer's fault".
• Every reason maps to its own action. If two options lead to exactly the same next step, merge them.
• Evidence is mandatory. A photo of the closed door or entrance, a record of the call, a comment — otherwise the review turns into one person's word against another's.
• The time and place of the entry are captured. Without that you can't tell a real visit from a job closed after the fact.
• An "other" option exists, but is watched. If its share is growing, the list needs updating.

From there you track four numbers: the share of incomplete orders out of the total, the breakdown of reasons within that share, the success rate of repeat attempts and the cost of a repeat visit. The first three take about a week to collect; the fourth needs at least a rough estimate of an hour of a courier's time and a kilometre of driving. It pays to compare not only period against period, but couriers, cities and order types against each other — that is exactly how you find where the problem is concentrated.

What to do with each group of reasons

Once you know the structure, the work stops being a vague push for better quality and turns into a set of specific steps.

• Unreachable recipients. A call or a message 30–60 minutes before arrival closes most of these cases. A status link helps too: the recipient can see the courier is on the way and doesn't ignore a call from an unknown number.
• Nobody there during the slot. The problem is almost always the width of the window — the wider the slot, the less likely anyone will sit and wait. Narrowing it only works together with planning that actually respects those windows.
• Bad addresses. Normalisation at order intake, mandatory fields for building and entrance, a separate "how to get in" field for the intercom code and site pass. Access notes collected once save visits for years.
• Running late. An overloaded route is the by-product of manual planning: a spreadsheet can't weigh time windows, travel time and constraints all at once.
• Picking and goods. A checklist when goods leave the warehouse and a completeness check before departure remove the most galling failures of all — the courier arrived on time with nothing to hand over.
• Courier discipline. Review specific jobs with photos and timestamps, not an aggregate percentage.

Technically all of this comes down to one question: do the facts from the route reach the system at the moment they happen? In itlogist the field employee records the outcome in a mobile web interface with photo reports and checklists, the dispatcher sees live routes on a map and can reassign a job before the day falls apart, and the client follows the status in their own portal — the whole setup is laid out on the Courier management page.

The repeat attempt: where the order is lost for good

A failed visit rarely becomes a loss on its own. The order is lost on the second attempt — when it slips to an unspecified date, gets scheduled without asking anyone, or simply drops out of the queue.

What is worth writing into your process:

• A response deadline. Contact the recipient the same day, next day at the latest: the longer the pause, the higher the chance of a refusal.
• Automatic return to the plan. An unclosed job shouldn't wait until someone remembers it — it goes back into the dispatch queue with a clear status.
• A limit on attempts. Two or three, after which you renegotiate the terms or process a return. Endless visits cost more than the order itself.
• An agreed window for the retry. A second visit scheduled for "whenever we can" produces exactly the same outcome as the first.
• Cost accounting. Every attempt goes into the cost of the order, otherwise repeat visits stay invisible in the reporting.

It is worth watching the share of orders closed on the second attempt separately. If it is high, the original information about the recipient was poor, and what needs fixing is order intake, not the couriers' work.

A four-week plan

Failures are best tackled in short cycles: measure first, then change one thing, then compare.

• Week one — set the baseline. Introduce the closed list of reasons, collect the current share of incomplete orders and its breakdown. This is the reference point you will keep coming back to.
• Week two — customer data. Mandatory address and access fields, a phone check at order intake, a heads-up about the arrival time.
• Week three — planning. Realistic time slots and a workload per courier that accounts for windows and constraints; the optimisation engine built on OR-Tools works out the visiting order more accurately than manual sorting in a spreadsheet.
• Week four — feedback. Go through specific failures with couriers and dispatchers, update the reason codes, drop the duplicate paper reporting.

Orders should reach the team from the sources you already use: itlogist exchanges data with 1C, AmoCRM, Bitrix24 and Excel, so nobody has to copy addresses by hand — and manual retyping is precisely what generates a share of the address errors. Launch takes 7 days, there are no long-term contracts, and the platform is built for teams of 5 to 100 field employees, so you can test the idea on live orders and compare it against week one.

The real result of a cycle like this isn't a one-off drop in a percentage — it is the habit of seeing failures as a structure. Once it is obvious that half of the incomplete orders come from unanswered calls and a third from incomplete addresses, the next step needs no meeting to decide.