Failed Deliveries: Sort Driver Notes Into Fixable Causes With AI

Export a month of failed deliveries with the driver's free-text note, give ChatGPT or Claude a fixed list of cause codes, and have it tag each note, with UNCLEAR when the note gives no cause. Then count by cause, by address and by time window. The causes you can fix are usually address quality, access instructions and the delivery window.

Two cautions decide whether this works. The cause list must be short and agreed before you start, and the AI must be allowed to say it does not know. Left alone, a model will give a confident cause to a note that says only "no" or "CU", and your counts will look neat and be wrong.

Follow me on Instagram@sagnikteaches

What you need in the export before you start

Most dispatch systems, courier portals and route apps can export deliveries as a CSV. Ask for every delivery attempt, not only the failures, because you need the successes to calculate rates. Useful columns are:

Connect on LinkedInSagnik Bhattacharya

• Order or consignment number (your key; keep it).
• Delivery address, with the unit or flat number in its own field if you can.
• Planned time window and the actual attempt time.
• Status (delivered, failed, returned) and attempt number.
• The driver's note, in whatever words they typed.
• Delivery type: home, workplace, shop, locker.
• Whether the customer was told a window and by what channel.

Strip names, phone numbers and emails before upload. Nothing in this analysis needs them. If your export lacks attempt times or windows, the cause coding still works, and the time analysis waits until you can add them. If there are three or more spellings of the same status, tidy them first; cleaning messy data with AI shows how.

Subscribe on YouTube@sagnikteaches

Agreeing a cause list that can be fixed

The categories decide what you can learn. "Customer issue" is useless, since it hides every fixable thing in one pile. Use causes that point to an action, and keep them mutually exclusive. An illustrative set for a small online retailer:

Nine codes is about the limit. More than that and every code holds three cases and no trend appears. A tenth called OTHER is the reflex; avoid it, since OTHER becomes the biggest category in a month. UNCLEAR does the honest job instead, and it measures the quality of your notes.

The worked example: an online clothing store with 1,240 drops

An illustration. An online clothing store delivers 1,240 parcels in a month, using its own two drivers for the local area and a courier export for the rest. Of the 1,240 first attempts, 77 fail, a rate of 6.2 percent. The owner exports those 77 with notes and attempt times, removes names and phones, and uploads the file to Claude.

Below are 77 failed delivery attempts. Each has an order number, the
driver's note, planned window and attempt time. For every row, assign
exactly ONE code from this list:
NOBODY, ACCESS, ADDR-INCOMPLETE, ADDR-WRONG, CLOSED, REFUSED,
RAN-OUT-OF-TIME, VEHICLE-SITE, UNCLEAR.

Rules:
- Use only what the note says. If the note does not state a cause,
  use UNCLEAR. Never infer from the time or the address.
- Add a column "evidence" quoting the words from the note that
  support the code.
- Add a column "confidence" (high, medium, low).
- Return a table with order number, code, evidence, confidence.
- Finish with counts per code.

Illustrative counts that come back: NOBODY 29, ACCESS 14, ADDR-INCOMPLETE 12, CLOSED 7, RAN-OUT-OF-TIME 5, UNCLEAR 4, REFUSED 3, VEHICLE-SITE 2, ADDR-WRONG 1. The "evidence" column is the safeguard: you can scan it and see that row 31's code NOBODY rests on the words "no reply, card left". A model that has to quote the note finds it much harder to invent a cause.

Now put a cost on it. Suppose each failure costs the shop about $9.50 on average: $6.50 for the second attempt or the return leg, and roughly ten minutes of customer-service time at $18 an hour, which is $3. Seventy-seven failures is about $731 a month, or $8,780 a year, before the lost goodwill. That number tells you how much effort a fix is worth.

Checking the AI's coding before you trust the counts

Do not accept the totals blind. Take a random 20 rows and read the note against the code yourself. If you disagree on more than two, tighten the rules or the code list and run it again. A quick method: sort by "confidence", read every low-confidence row, and sample ten of the high ones.

The common disagreements are predictable. A note such as "gate locked, rang twice" can be NOBODY or ACCESS. Decide the rule once ("a locked gate with no code is ACCESS") and add it to the prompt. Notes in a driver's shorthand, "N/A at add" or "CU not in", are fine for a model when you add a glossary of the abbreviations your drivers use; ask a driver to write you five lines of it. Keep the glossary with your prompt so next month's run behaves the same way.

Reading the messy notes: before and after

The point of the exercise is to turn text no one reads into counts that show a pattern. A small illustrative sample shows the scale of the clean-up:

Notice row three. The AI chose ADDR-WRONG, but one could argue ADDR-INCOMPLETE, since the unit letter may be a suffix the customer left out. That is the sort of edge case to settle in your rules. Notice row five too: "ordered twice" is a duplicate order, which is a data-entry or checkout problem, not a delivery problem. If you see it repeat, add a code for it.

Repeat addresses: the cheapest fix in the file

Once every row has a code, ask for patterns by place. Build a key from the street line plus unit (or the cleaned first line of the address) and count failures per key. Many small businesses find that a handful of addresses produce a disproportionate share.

Using the coded table and the address key, list every address key
with 2 or more failed attempts in the period. For each, show the
codes, the dates, and whether a later attempt succeeded. Then
group them: (a) same address fails the same way, (b) same address
fails for different reasons, (c) fixed after a second attempt.

In the example, nine addresses account for 18 of the 77 failures, two each. Six of them are blocks of flats with an ACCESS problem each time, two are offices that are shut on the day, and one is a rural address where the van cannot park. These are fixed by one-off actions, not by general policy: save an access note on the customer record, flag office addresses so the order asks for opening hours, and mark the rural address with a drop point. The next order from any of those nine now arrives with the instruction attached.

Time windows: when failures happen

Join the attempt times and the planned windows, and ask for failure rate by window. A quick table in the example:

The late window fails three times as often as the morning. The AI can tell you that; it cannot tell you why. Looking at the codes inside the 15:00 to 19:00 rows, RAN-OUT-OF-TIME and CLOSED are over-represented, so the likely story is overloaded final routes and offices closing at five. Both have operational answers: fewer stops on the last run, and a morning-only window for workplace addresses. A route tool can help with the first; see route planning for small fleets, and driver scheduling for peak weeks if the late window overloads in busy seasons.

Matching each cause to a fix and an owner

A finding with no owner changes nothing. Write the fix list as a short table with a person, a change and a date, then review it in a month. In the example the owner chose four changes.

• Address fields (12 failures). Make flat or unit a prompted field at checkout and add an address lookup. The shop's web person does it in an afternoon. Expected: ADDR-INCOMPLETE falls from 12 to about 3.
• Access (14 failures). Add an optional "gate code or entry instructions" box and mention it in the order confirmation. Expected: halve ACCESS, so about 7.
• Nobody in (29 failures). Send a text the evening before with a two-hour window and a reply option to leave instructions or choose a neighbour or a pick-up point. Expected: 29 down to about 19.
• Late window (RAN-OUT-OF-TIME, CLOSED). Cap the final route at 30 stops and offer workplace addresses mornings only.

If those expectations hold, the first three fixes remove about 9, 7 and 10 failures, which is 26 a month. At $9.50 each that is about $247 a month, or $2,960 a year. These are guesses from an illustrative month, which is exactly why you re-run the same prompts next month and compare.

Customer messages that reduce the second failure

Every failed delivery needs a message, and the first one decides whether the second attempt succeeds. Draft one template per cause, and keep each to the one thing the customer must do. Prompt the AI with the cause and the facts you have, and ask for short, plain text with no blame.

Write a text message of under 300 characters for a customer whose
delivery failed because nobody answered. Include: today's date as
[date], the order number [order], the two options (leave a safe
place, or choose a new day), and a reply keyword for each.
Neutral tone, no apology paragraph, no exclamation marks.

An illustrative result: "Hello [first name], we tried to deliver order [order] today and no one answered. Reply SAFE with a safe place, or DAY with a day that suits you, and we will rebook. If you do nothing we will try again tomorrow." Check it against what your system can really do before you send it. A message that promises "tomorrow" when the next slot is Thursday creates a new complaint. The ACCESS message asks for the entry code and says who sees it. The ADDR-INCOMPLETE message asks for the missing flat number and shows what was on file so the customer can spot the gap. Keep a version of each in a shared document so a human can send it by hand until you trust a workflow. For the same idea at larger scale, AI delivery updates for a courier shows how to cut tracking calls.

A coding run that went wrong and how it showed

An illustrative slip of the kind to watch for. In one run the model coded the three blank notes as NOBODY, which pushed that cause to 32 of 77 and left UNCLEAR with a single row. The owner spotted it because the "evidence" column was empty for those rows and the confidence was marked "low". The rule "if the note does not state a cause, use UNCLEAR" was in the prompt, but the first draft had put it in a paragraph at the end and the model weighted the codes more heavily. Moving the rule to the top, repeating it once and adding "blank notes are always UNCLEAR" fixed it.

The lesson is to look at the empty cells. Any column the AI must fill should have a visible "none" value when there is no evidence; blank is where invention hides. A second guard is to ask the model to count blank notes up front, so you know the number before any coding starts.

Other sectors, same method

A specialist food importer delivering to cafés and delis has a different cause list: temperature refusals, no goods-in person, wrong delivery hours, no purchase order on the day. The method is unchanged; only the codes differ. A furniture maker delivering large items cares about narrow stairs, lift size and two-person availability, so a code such as ACCESS-SIZE is worth its own line. Always build the list from a read of fifty real notes, not from a template.

For businesses that handle other people's goods inwards, the same skill works in reverse: reading inbound delivery notes turns paperwork into stock. And if your drivers still key notes by hand in an app, a better note field often pays more than any analysis. Offer a pick-list of the nine codes in the driver app, with a free-text box beside it, and the coding step disappears for new failures.

How long each stage takes

For a month of 77 failures the whole first run takes about two hours, and later runs take well under one. Allow 20 minutes to export and strip the file, 30 minutes to agree the cause list with a driver or dispatcher, 15 minutes for the coding run, 30 minutes to check a sample of rows, and 25 minutes to read the patterns and write the fix list. The checking step is not optional and not where to save time. A dispatcher who has driven the routes will spot a wrong code in seconds that you would take a minute each to doubt.

If you have several hundred failures, split the file into batches of about 100 rows, because long outputs drift and a model can lose its rules over a very long table. Keep the same prompt for each batch, and add the batch totals in a spreadsheet yourself rather than asking the AI to add up four tables.

When notes arrive in voice or in other languages

Some driver apps let drivers dictate notes, and some drivers write in a mix of languages. Both work with the same method, with two changes. First, ask the AI to give the cause code and also an English version of the note in a separate column, so a dispatcher can read it. Second, add a rule that a note it cannot read confidently is UNCLEAR. Dictated notes often carry odd spellings of street names; that does not matter for the code, but it matters for the address key, so never use the dictated text as the key. Use the address field.

A short check: pull ten dictated notes and read them against the audio if your app keeps it. If the transcription is poor, no analysis can fix it, and the better step is a drop-down of the nine codes the driver taps in the app. That costs a driver three seconds and gives you clean data for ever after.

Keeping the monthly loop running

One analysis is a snapshot; the value lies in repeating it. Keep the cause list, the glossary of driver shorthand and the three prompts in a project or saved document, and run them on the second working day each month. Track four figures in a single sheet: failure rate, cost per failure, share of UNCLEAR notes, and the top cause. If UNCLEAR is over 15 percent, the driver app needs work before anything else. If one cause rises for two months running, check whether a change upstream, such as a new courier, a new product line or a checkout update, preceded it.

Add each month's fixes to the same sheet with the date they started. After a quarter you can show which changes moved which numbers, and which did nothing and can be dropped. If you want a second pair of eyes on the first run, that is a task a 1:1 call can cover.

Questions about coding delivery notes with AI

How many notes do I need before the pattern is useful?

A month of failures is usually enough, often 50 to 300 notes. Fewer than 30 gives you anecdotes, not patterns. If you have too few, widen the date range rather than inventing categories, and keep the cause list short so each code still holds several cases.

Can I upload customer names and phone numbers to ChatGPT or Claude?

You do not need to. Remove names, phone numbers and email addresses before upload, keep an order number as the key, and join the results back in your spreadsheet afterwards. If you must include addresses, use a business plan and check what your customer terms say about sharing.

What if the driver notes are blank or just say a single word?

Code them as UNCLEAR and report how many there are. A high share of blanks is itself a finding: it means the app or the habit gives you nothing to analyse. Do not let the AI guess a cause from an empty field, because it will happily invent one.

Should the AI contact customers directly after a failed delivery?

Draft the messages with AI, but start by sending them from your own system or by hand, so a person reads the first fifty. Automatic sending is reasonable once the wording has been tested and you have a way for customers to reply to a real person.

Further reads

• Route Planner for Delivery Drivers: Four Apps Compared on Cost and AI — Compare route apps that capture proof of delivery and notes.
• AI Courier Quotes: Reply to Delivery Enquiries From Your Rate Card — Reply to delivery enquiries from your rate card.
• Cost per Drop: Work Out Delivery Cost From Route and Fuel Data — Work out what each drop really costs from route and fuel data.
• Automation in Clothing Manufacturing: What a Small Workshop Can Automate — See what else a small clothing business can automate.
• Outgrowing Spreadsheets: When to Replace Manual Excel With AI — Know when the delivery sheet needs a proper system.
• AI in Delivery and Courier Services: Handling Damage Claims and Disputes — Sort damaged-parcel and missed-delivery claims from photos and delivery records, then draft careful replies that a named person approves.
• AI Dispatch Automation for Small Delivery Firms: Where to Begin — A small delivery firm's first dispatch pilot: capture jobs, suggest assignments, handle exceptions and measure results.
• Delivery Notification Template: Late and Missed Drop Texts With AI — Ready-to-adapt late and missed delivery texts, plus the AI prompt that drafts them from route data without promising times you cannot keep.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: general delivery-operations practice and the upload guidance on the ChatGPT and Claude help pages; every count, rate and cost in the examples is illustrative.