The scan says “delivery attempted”. The buyer says nobody came. Now what?
A false attempt scan is one of the most frustrating events in marketplace selling: your parcel turns around, the freight lands on you, and the only witness is a tracking system that disagrees with your buyer. This guide covers what the pattern looks like, why sellers keep reporting it, what it costs, and how to fight it with evidence instead of anger.
- A false 'delivery attempted' or 'customer refused' scan burns one of the parcel's limited attempts without a doorstep visit. When attempts run out, the order flips to RTO automatically — freight both ways, buyer lost, and often nobody at fault on your side of the label.
- Seller reports consistently tie the pattern to route overload: too many parcels per agent, with remote addresses, COD collections, and heavy parcels the likeliest to be scanned away. Treat that as context, not an accusation you can prove for any single scan.
- You fight it with a timeline: tracking screenshots, the buyer's written statement, call recordings where lawful, scan-time versus the buyer's day — filed through a panel ticket citing the AWB event trail, and tracked as a pattern by courier and pin code.
A scan is a claim, not a fact
Every tracking event on an AWB is a human with a handheld device pressing a button. Almost always, the button matches reality. But last-mile delivery in India runs on brutal per-day parcel targets, and when a route is overloaded — festival weeks, sale events, a short-staffed hub — the parcels that don't fit the day have to go somewhere. Sellers and buyers have long reported the same release valve: “attempted, customer not available” on doors nobody knocked, and “customer refused” from buyers who were waiting with cash ready.
For the agent, the scan resets the day. For your parcel, it burns one of a small, finite number of delivery attempts — and when they are gone, the system does exactly what it was built to do: flips the order to return-to-origin, no human decision required. That is why a fake attempt is not a tracking cosmetic. It is the first domino in a forced RTO, and the freight for both directions usually settles on the seller. You cannot see inside any single scan, and this guide won't pretend you can. What you can do is document, dispute, and measure — because patterns are provable even when single incidents are not.
Seven moves when the scan and the buyer disagree
Speed matters more than outrage. The attempt counter is still running while you decide what to do — so the first moves happen the same day.
- 01
Contact the buyer the moment attempt one fails
Don't wait for attempt two. Message or call through the marketplace's channel and ask one question: did anyone come? If the answer is no, you now have a live incident to document instead of a cold RTO to appeal — and the buyer knows to stay reachable for the next attempt.
- 02
Get the buyer's account in writing
A chat message — 'no one visited today, I was home till 8pm' — is timestamped by the platform and beats any verbal claim. Screenshot it alongside the tracking page showing the attempt scan and its time. Those two images, side by side, are the spine of your dispute.
- 03
Record calls only where lawful, and say so
A short recorded call in which the buyer confirms nobody came is strong support — but recording laws and marketplace communication rules both apply. Disclose the recording, keep it factual, and skip this step entirely if you're not certain it's permitted where you and the buyer are.
- 04
Line the scan time up against the buyer's day
An 'attempted 2:47pm' scan against a buyer's statement that they were home from noon to evening is a contradiction a support agent can act on. Some scans betray themselves further — attempts logged at implausible hours or minutes apart across distant addresses. Note anything the timeline exposes.
- 05
Dispute through a panel ticket, citing the AWB trail
File on the marketplace panel against the specific order: AWB number, each attempt event with its timestamp, the buyer's written statement, and the remedy you want — re-attempt before RTO triggers, or freight waived if it already has. Factual, complete tickets travel up the queue; angry ones get templates.
- 06
Ask for re-attempt before the RTO triggers
While attempts remain, the parcel can still be saved — and a delivered order beats a won dispute every time. Make 'please instruct the courier to re-attempt, buyer confirms availability' the first ask in every ticket, with the refund of charges as the fallback, not the goal.
- 07
Track the pattern by courier and pin code
Log every disputed attempt with courier, pin code, date, and outcome. One incident is noise; twelve failed attempts on one lane in three weeks is a case. Patterns are what get lanes reassigned and batches of charges reversed — and they're the only version of this fight you can win at scale.
A forced RTO bills like a real one
The settlement system does not know the attempt was false. Once the parcel turns around, the machinery treats it like any refusal: forward freight spent, reverse freight typically charged, roughly two weeks of stock and cash riding couriers instead of selling, and a buyer who wanted the product now refunded and gone — possibly to a competitor's listing. Illustratively, a ₹500 order caught in one false-attempt RTO can leave ₹120–₹170 in freight and handling on your ledger with nothing earned against it. Exact charges differ by marketplace, courier, and weight slab — check the current policy on your panel.
There is a quieter cost too: depending on the marketplace, undelivered and cancelled orders can feed the metrics that shape your visibility. A courier lane quietly generating false attempts doesn't just tax individual parcels — it can lean on your whole account. That is why the lane-level view matters more than any single dispute.
You can't watch every AWB. Robnu can.
The whole playbook above depends on catching the first failed attempt on the day it happens — and no seller doing 15 orders a day is refreshing tracking pages hourly. Robnu tracks every parcel it dispatches for AJIO and Meesho and turns an attempt-failed event into a same-day alert, while the buyer is still reachable and the parcel can still be saved.
Because Robnu keeps each order's full event trail, the dispute file — scan times, order history, settlement impact — is already assembled when you need it. Its ledger breaks attempt failures and RTO rates down by courier and pin code, so a lane that spikes shows up as a number you can put in a ticket. And when a false attempt ends in charges that should come back, Robnu prepares and files the claim — the rare one still asks you for a single approval click.
Fake delivery attempts, answered
It is a tracking event that says 'delivery attempted — customer not available' or 'customer refused' when, according to the buyer, no delivery agent ever came to the door. The scan is real; the visit behind it may not be. Sellers usually discover the mismatch when a buyer messages asking where the parcel is while tracking shows two failed attempts. After the courier's attempt limit, the parcel flips to return-to-origin automatically — which is why a false scan is not a cosmetic error but a forced RTO with freight attached.
Sellers and industry reporting point to workload mechanics rather than anything personal: agents carry more parcels than a route can absorb, and marking the overflow as 'attempted' or 'refused' resets the clock without a penalty on the agent's numbers. Remote addresses, COD parcels that need cash collected, and heavy or awkward packages are reported as the likeliest to be skipped. None of this can be proven for any single scan from the outside — which is exactly why your response should be built on documented patterns, not accusations.
The scan itself costs nothing; what it triggers does. Attempts exhaust, the parcel turns around, and you typically absorb forward freight, often reverse freight, and the two-plus weeks of stock and cash stuck in the loop — on an order the buyer still wanted. Depending on the marketplace, a cancelled or undelivered order can also brush against your account metrics. Illustratively, a ₹500 order that bounces this way can cost ₹120–₹170 in freight and handling while earning nothing. Exact charges vary by marketplace and courier; check the current policy on your panel.
You assemble a timeline the scan cannot survive. Screenshot the tracking events with timestamps. Get the buyer's statement in writing — chat or marketplace messaging is ideal because it is timestamped by a third party. If the buyer says they were home all day, note it. Where recording is lawful in your state and disclosed, a short call recording of the buyer confirming no visit is strong support. Then put the scan time against the buyer's account of that hour. One incident rarely wins; a documented AWB event trail plus a buyer statement, filed promptly, often does.
Complain about the pattern, through the panel, with the file attached. On most Indian marketplaces you don't choose the courier, so the useful ask is not 'punish this agent' but 'reassign this lane and waive this RTO's charges.' A ticket citing the AWB, the exact scan events, and the buyer's written statement — repeated across several affected orders — gives the marketplace something its courier team can act on. Stay factual in every ticket: describe events, attach evidence, request the specific remedy. Measured, documented complaints get escalated; angry ones get templated replies.
Robnu watches every AWB it dispatches for AJIO and Meesho, so an 'attempt failed' event becomes an alert the same day — while the buyer can still be reached and the parcel can still be saved. Because it keeps the full event trail per order, the evidence for a dispute is already assembled when you need it, and its ledger shows attempt-failure and RTO rates by courier and pin code, so a lane that suddenly spikes stands out in numbers, not vibes. Where a bounce leads to a recoverable charge, Robnu prepares and files the claim — the rare one asks you for a single approval click.
Where this comes from
- Recurring seller and buyer reports of false “attempted” and “refused” scans in public communities (Reddit r/IndiaBusiness and consumer forums, seller Facebook and Telegram groups), 2023–2026.
- Marketplace panel documentation on delivery attempts, RTO triggers, and dispute tickets (Meesho supplier hub, AJIO seller portal) — check the current policy on your panel, as attempt limits and fee treatment change.
- Industry reporting on last-mile workload pressure in Indian e-commerce logistics. Rupee figures and the trend chart in this guide are illustrative.
Related guides & pages
The COD RTO problem
Why cash orders bounce at multiples of prepaid, and the maths of one bounce.
RTO in Meesho
How return-to-origin works on Meesho and what it does to your payout.
What is RTO?
Return-to-origin from first principles — the full lifecycle of a bounce.
Revenue protection
How Robnu recovers the money marketplaces owe you.