Recovering a failed delivery before the parcel goes back

A failed delivery attempt is a parcel the courier could not hand over — nobody home, wrong address, no cash ready, or a customer who declined at the door. Most couriers try two or three times before returning it to you, and those attempts are a window in which the order is still saveable.

Almost nobody uses it. Logistics platforms own the failure data, messaging platforms own the customer conversation, and the two rarely meet — which is why this flow is thin on every competitor site we reviewed and worth building.

The economics of the second attempt

By the time a delivery fails, you have already spent the outbound shipping. What remains to be decided is whether you also spend the return leg and lose the sale entirely.

Outcome	What you have spent	What you earn
Second attempt succeeds	Outbound shipping + one wasted attempt	The full order
Parcel returns to origin	Outbound + return + handling	Nothing

That asymmetry is the whole argument. A message that converts even a modest share of failed attempts into successful redeliveries pays for itself immediately, because the alternative outcome is the most expensive one available.

Getting the failure into a flow

Here is the honest constraint: Shopify does not send a failed-delivery event. The seven store events available are order placed, payment success, payment failed, order shipped, order delivered, order cancelled and abandoned cart. Failed delivery is not among them, and no amount of configuration adds it.

Your courier or aggregator knows, though. Three routes:

1. Your courier aggregator posts an event. If you ship through a platform with a non-delivery-report panel and it can call a web address, it can start the flow. This is the clean version and it needs a developer for about an hour — see starting a flow from your own system.
2. A Google Sheet your ops team updates. Paste the day's failed attempts in, and a flow reads them. Less elegant, works today, no developer — using a Google Sheet as your automation's database.
3. Manually, from the inbox. For low volumes, a person messaging the affected customers is entirely reasonable and needs no automation at all.

What the message should do

Not apologise, primarily. The customer usually knows the delivery failed, and often knows why. What they need is a way to fix it in one tap.

The third option looks like a loss and is not. A customer who has decided against the order will decline again at the door, so learning now saves you the attempt you were about to pay for.

Send it the same day

Timing is most of the value. A message the evening of the failed attempt reaches a customer who remembers missing the courier and can plan tomorrow. The same message two days later arrives after the second attempt has already failed.

If your courier data arrives in a daily batch, send in the evening. If it arrives in real time, send within the hour.

What it costs

The first message is a utility template, charged because it lands on a chat the customer may not have written to recently. Everything after their tap is free text inside the 24-hour window that the tap opens, per Meta's pricing documentation — so collecting a corrected address or arranging a new day costs nothing.

One template against a saved order is not a close call.

Keep it utility

This message is about an order that exists, so it qualifies as a utility template — free inside an open window, deliverable everywhere including the United States, and not subject to per-user marketing limits.

Adding "and here's 10% off your next order" to soften the apology would reclassify it as marketing and undo all three of those. If you want to apologise with a discount, do it in the free reply after they tap. The line is in utility versus marketing templates.

Close the loop with your courier

The flow collects an answer; something has to act on it. Whether that is a person updating the courier's panel or an automated call back into their system, decide it before you launch — a reschedule the customer requested and nobody actioned is worse than not asking.

Tag the order distinctly so the ops task is a filter rather than a memory: "reattempt requested", "address changed", "customer cancelled".

Where it sits

Fourth, after confirmation, address verification and the delivery-day notice. Each of those reduces how many parcels reach this stage at all, and they are cheaper because they act earlier. The sequence is in reducing RTO with WhatsApp.

But build it eventually, because the parcels that reach a failed attempt are the most expensive ones you have — and unlike most RTO interventions, this one is recovering money you have already spent rather than preventing a future cost.

Why customers miss deliveries

Worth listing, because the message should address the real reasons rather than apologise generically.

Reason	What fixes it
Nobody home	A delivery-day notice, and a choice of day
No cash ready	Telling them the amount in advance
Rider could not find the address	A landmark or floor number
Phone unanswered	Confirming the number is the one they use on WhatsApp
Changed their mind	Learning it now instead of after a second attempt
Ordered to a work address at the weekend	An alternative address

Only the last two are genuinely about the customer changing something. The rest are information problems, which is why a single well-timed message recovers as many as it does.

Prevent what you can, the day before

The cheapest failed delivery is the one that does not happen. A short message on the morning of delivery — naming the amount due for a cash-on-delivery order — removes the two commonest causes at once, because the customer now knows to be there and to have the money.

That message is a utility template, and if the customer replies it opens a 24-hour window in which rescheduling costs nothing. Meta's sending messages documentation covers the mechanic.

Keep the template count down

One template covers every failed delivery if the order number, the reason and the options are variables. That matters because Meta caps templates at 250 per WhatsApp Business Account for an unverified business portfolio, rising to 6,000 once verified, per its template documentation.

Building one template per courier or per failure reason is how a store with a dozen useful flows finds itself at the ceiling.

What to do with the answers

1. Reattempt requested — tag the order and tell the courier. If your aggregator has a non-delivery-report panel, this is where the loop closes.
2. Address changed — collect it, note it, assign to a person. A flow cannot rewrite the shipping address on the order.
3. Cancelled — stop the reattempt immediately. This is the one that saves you money right now.
4. No reply — let the courier's normal process run, and do not chase. A second message to someone who ignored the first converts almost nothing and costs a template.

Measuring it

Two numbers, both of which you can get from your courier's report:

• Reattempt success rate before and after launching the flow.
• Parcels returned to origin as a share of failed first attempts.

The second is the one that shows up in your accounts. If it does not move within a couple of months, check whether anyone is actually actioning the answers — an unactioned reschedule is the usual reason this flow underperforms, and it is an operations problem rather than a messaging one.

Start manually before you automate

This is the one RTO flow worth doing by hand first. Take a week of failed attempts, message those customers from the inbox, and record what they say.

Two things come out of it. You learn your real recovery rate, which tells you whether automating is worth the integration work. And you learn which reasons dominate in your market, which tells you what the automated message should offer — the three options in a generic flow are a guess until your own data replaces them.

Why this is a cross-category gap

Worth naming, because it explains why you will struggle to find good material on it. Logistics platforms own failed-delivery data and write about non-delivery reports; messaging platforms own the customer conversation and write about campaigns. The flow that joins them sits between two categories, so neither publishes it.

The practical consequence is that you are unlikely to find a packaged solution, and the integration will be yours to specify. The upside is that most of your competitors have not built it either.

What it costs against what it saves

One utility template per failed attempt, charged because it lands on a cold chat. Everything after the customer taps is free text inside the 24-hour window, which Meta's pricing documentation confirms costs nothing — so collecting a corrected address or agreeing a new delivery day adds no further charge.

Against that: a recovered order earns its full value, and a cancelled one saves you a second attempt you were about to pay for. Both outcomes are better than the parcel quietly going back.