Delivery Notification Template: Late and Missed Drop Texts With AI

Coding Liquids tutorial cover featuring Sagnik Bhattacharya for Delivery Notification Template: Late and Missed Drop Texts With AI.
Coding Liquids tutorial cover featuring Sagnik Bhattacharya for Delivery Notification Template: Late and Missed Drop Texts With AI.

A late or missed delivery text should say what has happened, what you are doing about it, and what the customer needs to do next, ideally within one 160-character text, with a time window rather than a promised time. AI can draft these from route data such as stop status, driver notes and delay minutes, if you fix the templates first.

These messages usually get written in a hurry, once, and then pasted for years. The result is either a vague "your delivery is delayed" that triggers a phone call, or a confident "arriving at 2:40pm" that is wrong by 3pm and triggers an angrier one. The fix is a small message set, organised by status, with rules for what the AI may fill in and what it must never invent.

Follow me on Instagram@sagnikteaches

Why the wording matters more than the apology

Customers contact you when a delivery is late for three reasons: they do not know whether it is still coming, they cannot plan their day, or they suspect nobody noticed. A good text answers all three before they dial. Count the calls and chat messages you receive on a bad day; most are variations of "where is it" and "when". Every one of those contacts costs a person a few minutes, and the same person is usually the dispatcher you need on the road plan. A text that resolves the question saves both.

Connect on LinkedInSagnik Bhattacharya

The AI does not make the message better by being clever. It makes it better by being consistent: the same structure, the same tone, the right data filled in, at 2pm when the dispatcher is busy. The planning therefore happens before any AI is involved, in the status list and the template rules.

Subscribe on YouTube@sagnikteaches

Start with a status list, not a template

List every state a stop can be in that a customer should hear about. For a small delivery firm this is usually shorter than expected. An illustrative list for a florist delivering orders in its own vans:

Status codeMeaningMessage sent?
BOOKEDOrder accepted, slot or window agreedYes, immediately
OUTOn the van, driver left depotYes, morning of delivery
NEARDriver is two to five stops awayOptional
DELAY_SMALLRunning under 30 minutes behind windowNo, unless the window will be missed
DELAY_LARGEWindow will be missed by 30 minutes or moreYes
DELAY_DAYWill not be delivered todayYes, as early as known
MISSED_NOONEDriver attended; nobody answeredYes
MISSED_ACCESSCould not reach the address (gate, road closed)Yes
MISSED_REFUSEDRecipient declinedYes, and notify the sender
DELIVEREDProof capturedYes

Notice the rule built into DELAY_SMALL: no message. Send an alert for every few minutes of slippage and customers learn to ignore them. A threshold is a business decision, and you set it. Typical choices are 30 minutes behind the window, or the moment the estimate would drift outside the stated window, whichever is sooner.

The Complete Excel Course with AI Integration thumbnail

The Complete Excel Course with AI Integration

From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.

By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner

Buy now

Message sets by status

Below are templates for the three statuses that cause most complaints. Each follows the same four-part skeleton: what happened, what we have done, what happens next, how to reach us. Square brackets are fields the AI or your software fills. Adapt the wording to your own voice.

Late: the window will be missed

Hi [first name], your [business name] delivery is running behind.
We now expect to reach you between [window start] and [window end].
No need to do anything. We'll text again if that changes.
Questions? Reply to this message.

Four lines, and about 190 characters once a short name, business name and times are filled in. That is more than the 160 characters of a single SMS segment, so it will go out, and be billed, as two; drop the last line if one segment matters to you. It names a window, it does not apologise three times, and it ends with the one action available to the customer. A variant for a small delay on a time-critical order, such as a cake or a wedding bouquet, might add one line: "Your order is in the van and has not been left anywhere." That reassures without inventing anything.

Missed: nobody answered

Hi [first name], we called today at [time] but couldn't hand over your
[item description]. We have [left a card / kept it safe on the van].
To rearrange, reply with a day that suits, or call [number].
We'll hold it until [date].

The sentence "we have kept it safe" must come from a driver action. If the driver left the parcel with a neighbour, the text must say which house or door, in the words the driver entered, not something the AI infers. Insist on this rule in the prompt.

Missed: could not reach the address

Hi [first name], we couldn't get to your address today because of
[reason from driver note, in plain words]. Your order is back at our depot.
We can try again [offered day] between [window]. Reply YES to confirm
or tell us a better day.

Here the AI's job is to turn a driver's shorthand ("gate locked no code, rang x2") into one plain reason ("the gate was locked and we couldn't get a code"). The next section covers how.

Draft the texts from route data with a controlled prompt

The AI needs three inputs per stop: the status, the facts from your route or driver app, and the template. It must be told what it may not do. Paste the following into ChatGPT, Claude or Gemini, or into the prompt field of your messaging automation, replacing the bracketed examples with your own text.

You write customer delivery texts for [business name].
Use ONLY the facts in the stop record below. Do not invent a time,
a reason, a driver name or a location.
Rules:
- 160 characters or fewer (one SMS segment), plain words, straight
  apostrophes, no emojis, no exclamation marks.
- Give a time WINDOW only if the record contains window_start and window_end.
  Otherwise say we will update them by [update time].
- If the record has no reason, do not give one.
- Never blame the customer.
- Choose the template for the status code and fill the fields.
- If anything needed is missing, return: NEEDS_PERSON and say what is missing.

STOP RECORD
status: DELAY_LARGE
first_name: [first name]
original_window: 12:00-14:00
new_window: 14:30-16:00
reason_from_driver: road closure on the main road, rerouted
item: flower arrangement

An illustrative reply:

Hi [first name], your flower arrangement is running late because
of a road closure. We now expect to reach you between 2:30pm and 4pm.
We'll text again if that changes.

With a three-letter first name that is 159 characters, so it fits one segment, and every fact is in the record. Fix anything it adds. A common flaw is the AI putting "our driver is very sorry for the inconvenience", which reads as filler and takes characters from the window. Add "no apology beyond one sentence" to the prompt if you see it. The NEEDS_PERSON escape hatch matters: when the data is incomplete, a draft that guesses is worse than no draft.

Time windows: how wide, and where the numbers come from

A window is only honest if it comes from data. Pull three figures from your own routes for the last month: the average gap between two stops, the 90th percentile of lateness against the planned arrival, and the number of stops left on the route. Ask the AI to compute them from an export, and check one by hand.

A simple rule an illustrative firm might adopt: new window start = planned arrival plus current delay; new window end = start plus the larger of 90 minutes or twice the average lateness on that route. If the driver is 40 minutes behind with an original time of 13:00, the new window is 13:40 to 15:10. Windows shorter than 60 minutes are tempting and nearly always missed on a long route. Your dispatch system or the guide to AI route planning for small fleets shows how to get the planned arrivals into one export.

If you cannot compute a window, do not guess. Use the fallback line: "We'll text you again by 3pm with a firmer time." It buys trust because you actually send that second text.

Avoid promising times you cannot keep

The word "by" is the dangerous one. "Delivery by 4pm" is a promise; "between 2:30pm and 4pm" is an estimate. Build a banned-phrase list into the prompt: "guaranteed", "definitely", "will arrive at", "within the hour", "very soon". And give the AI a replacement vocabulary: "we expect", "we now expect", "between", "we will text again".

Here is a before and after from an illustrative driving-school-supplies shop that delivers on its own van.

BeforeAfter
Your order will definitely arrive by 3pm today. Sorry for any inconvenience!Your order is running behind. We now expect to reach you between 3:00pm and 4:30pm. We'll text again if that changes.
Delivery attempted, no one home. Redelivery tomorrow.We called at 11:20am and couldn't hand over your order. It is back at the depot. Reply with a day that suits and we'll book a window.
Your parcel is delayed.Your parcel won't reach you today because the van was held at the depot. It's first on tomorrow's run. We'll text your window by 8am.

The first row is the classic trap: "definitely by 3pm" was true when written and false an hour later. The third row's "tomorrow's first run" must be true, so the text can only be sent once the dispatcher has actually placed the parcel on that run. Link your template to a dispatch action, not just a status flag.

Reply handling: where the customer's answer goes

Every message that invites a reply needs a place for that reply to land and a rule for what happens. Without one you will send "reply YES" and then discover forty replies sitting in a phone nobody checks.

  1. Choose the channel. A two-way texting number tied to your helpdesk or shared inbox is better than a driver's mobile. See AI email triage for shared inboxes for sorting the replies once they arrive.
  2. Write the accepted replies. "YES", "NO", a day name, a time, or a free-text question. Anything else goes to a person.
  3. Define an auto-response for each. YES books the redelivery and sends the new window; a day name checks capacity and proposes a window; free text goes to the dispatcher with an AI summary.
  4. Set a response time. A reply sent at 5pm gets read the next morning at 8am; say so in the text if you are not staffed in the evening: "We read replies from 8am."

An AI classifier can label each reply: CONFIRM, RESCHEDULE, COMPLAINT, SAFE_PLACE, ADDRESS_CHANGE, OTHER. Give it ten real replies from past weeks and the label you would give each, so it learns your usage. Run it in shadow for two weeks before it triggers any action; piloting AI in shadow mode explains the method.

Handling the angry reply

Some replies to a missed-delivery text are not a request for a new slot. They are "I took the day off for this". A classifier labelled COMPLAINT should skip every automation and alert a person. The AI may draft a first line for the person to edit ("I'm sorry, you arranged your day around this delivery"), but a person sends it. If the missed delivery was your fault, say so plainly and say what you will do: refund of delivery fee, priority slot, a call from the manager.

Check the facts against the driver's evidence

A missed-drop text that says "nobody answered" when the driver never reached the door is the single most damaging message you can send, because the customer knows it is false. Before MISSED_NOONE goes out, require at least two items from the stop record: a timestamp and one of a photo, a GPS point within a set distance of the address, or a call log. The AI should not decide this; your software should check the fields and only then call the AI to word the message. The same evidence supports any later dispute, which is the subject of sorting failed-delivery driver notes into fixable causes.

An illustrative case. A mobile dog groomer delivers pre-ordered shampoo and treats alongside appointments. The driver's note reads "no ans x2 left card". The record has a timestamp 11:20 and a GPS point 14 metres from the address. The template fires with "we have left a card". The same record without a card flag would produce NEEDS_PERSON, and the groomer's office checks before anything is sent.

Tone and length for different customers

A business customer receiving pallets wants dock times and a reference; a person receiving a gift wants a plain, warm sentence. Keep one template per audience, not one blended text. Business version:

Delivery [order ref] to [site] is delayed. Revised window: [start] to [end].
Dock contact needed? Reply with name and number. Next update by [time].

Consumer version, same status:

Hi [first name], your order is running late. We now expect to reach you
between [start] and [end]. We'll text again if that changes.

Both are short. Both carry the reference or the item. Neither has a signature block, which saves characters. A standard text holds 160 characters; anything longer is split into segments of 153, and Twilio, for one, bills each segment. One emoji, or a curly apostrophe pasted from a word processor, switches the whole message to Unicode, where a single segment holds only 70 characters (67 per segment once split). Tell the AI to use straight apostrophes, and check how your own sending tool counts.

One bad afternoon, message by message

An illustrative walk-through shows how the pieces fit. A florist's van carries 62 stops on the afternoon before a gifting date. At 13:10 a road closure adds 55 minutes to the northern loop of 18 stops. The dispatcher marks the loop DELAY_LARGE with the reason "road closure, rerouted". Each of the 18 records gets a new window: original arrival plus 55 minutes, then a window of 90 minutes from that start. A stop planned for 14:00 therefore reads 14:55 to 16:25.

Eighteen texts are drafted in under a minute. The dispatcher scans them (about two minutes), spots one where the order is a wedding bouquet due at 15:00 and sets it aside to phone the customer instead. That is the right call: a text cannot rescue a time-critical order, and a good rule is that any stop with a hard deadline is handled by a person, not a template. The remaining 17 go out. By 16:30 two customers have replied "fine, thanks", one has asked for a neighbour drop, and none have phoned. Without the texts, the same afternoon would plausibly produce a queue of calls to the one person who is also routing the van.

The same afternoon shows the cost of a wrong text. If the closure had cleared at 13:40 and the window text said 14:55, the driver would arrive early, and early is usually forgiven. If the closure had lasted longer and the window said 16:25, a second text becomes necessary. That is why the template ends "we'll text again if that changes" and why you must actually do so: set a rule that a stop whose live estimate leaves its window triggers a fresh draft automatically, rather than waiting for the dispatcher to remember.

Third-party carriers and your own vans

If part of your volume goes through a carrier, you will not control their texts, and customers will receive theirs and yours. Decide which of you speaks for which statuses. A workable split: the carrier owns tracking and delivery alerts; you own the pre-dispatch message ("your order has been handed to the carrier"), the missed-delivery follow-up once the carrier reports the failure, and anything about refunds. Pull the carrier's failure code into your status list (for example CARRIER_FAILED_ATTEMPT) and write a template for it that says what you will do, since the customer cannot contact the carrier's driver and will contact you.

Testing the set before customers see it

Run ten stop records through the prompt, including three awkward ones: no reason supplied, a customer name with an apostrophe, and a record where the new window starts earlier than the original (a data error). Read each output aloud. Questions to ask:

  • Does every fact appear in the record?
  • Could this message make a customer call us? If so, what is missing?
  • Would we be comfortable if this text were read out in a complaint?
  • Is the length under the limit with the longest likely name and item?

Fix the template or the prompt, not the output, and rerun the same ten records so you see the effect. Keep that set of ten as a regression test; run it whenever you change a template. If you are using a delivery system with its own notification feature, run the same ten cases through it too, since built-in messages often default to a time promise.

Measuring whether the new texts work

Pick three numbers and record them for two weeks before and four weeks after. First, calls and chats about "where is my order" per hundred deliveries. Second, the share of missed-drop texts answered within two hours. Third, redelivery success: of the stops that were missed and rebooked, how many delivered on the second attempt. An illustrative result: where-is-my-order contacts fall from 11 per hundred to 6, redelivery success rises from 70 to 82 per cent. If the first number does not fall, the text probably does not answer the customer's real question; if the third does not rise, you are booking windows you cannot hold.

The cost side matters too. A failed drop, once the van trip is wasted and the redelivery is booked, costs real money; use cost per drop from route and fuel data to put a figure on it so you can judge whether another message is worth sending.

A week-one rollout plan

  1. Monday: write the status list and set the thresholds. Decide the windows rule.
  2. Tuesday: write the nine or ten templates in a document. Have two drivers read them and mark anything that is not how you would say it to a customer.
  3. Wednesday: build the prompt and run the ten test records.
  4. Thursday: run live in shadow. The AI drafts every message for real stops; a person compares it with what was actually sent.
  5. Friday: review edits. Anything edited more than once becomes a template change.

After two weeks, let the unedited templates send themselves and keep a person on the missed and complaint ones. The result is a small, plain set of messages that answer the question customers actually have, with the AI doing the typing and your rules deciding what it may say.

Questions about late and missed delivery messages

Should a late delivery text give a new time?

Give a window, not a time, and only if your route data supports it. 'Between 2pm and 4pm' survives a traffic jam; '2:40pm' becomes a second apology. If the driver cannot say, tell the customer when you will next update them instead.

How many texts is too many for one delivery?

For a normal drop, three at most: booked, on the way, delivered. Add one more only when something changes. A late and a missed message are exceptions, so each must tell the customer something new and what to do next.

Can AI send the messages automatically?

The AI drafts the wording and picks the template from the status. Sending is done by your delivery or messaging software. Start with a person approving each late and missed message for two weeks, then automate only the templates that were never edited.

What should a missed-drop text never say?

Never blame the customer ('you were not in') before checking the driver's evidence, and never promise a redelivery slot you have not booked. State what happened, what you did (card left, parcel kept safe, returned to depot) and the next step.

Do customers need to agree to receive these texts?

Rules on marketing and service messages differ by market and by channel. Delivery updates tied to an order are usually treated differently from promotions, but check with a qualified adviser, include a way to stop messages where required, and keep promotions out of delivery texts.

Further reads

Sources: Twilio's glossary page on the SMS character limit (segment sizes, Unicode encoding and per-segment billing), read November 2026; otherwise the author's own delivery-communication method.

Want customer delivery updates that cut the phone calls?

On a 1:1 call we can go through your statuses, your messaging tool and the replies you get today, then decide which texts AI can draft and which a person should approve.

Book a 1:1 call with me