Amazon Flex
You Got the Amazon Flex “Unattempted Deliveries” Email: What It Means and What to Do
TL;DR
The unattempted deliveries email says every delivery countsand often adds that your standing isn't at risk — which is why almost everyone archives it. But it exists because a record is now attached to your account for packages that came back without evidence of an attempt, usually for reasons you don't control: locked gates, controlled-access buildings, traffic, stations that dispatched late. One email deactivates nobody; the risk is the pattern. The answer isn't to reply — it's to start documentingtime, GPS and photo on every delivery you can't complete, so next time your version is on the record too.
The email arrives in a friendly tone. It talks about how much every delivery matters, thanks you for your work, and somewhere in there includes the line that makes almost everyone close it reassured: your standing is not at risk.
For most drivers, that's where it ends. The problem is what the email means on the other side: a note now sits on your account for packages that weren't delivered, and in the overwhelming majority of cases the reason was something outside your control.
What it says, and what it actually means
The unattempted deliveries email goes out when one or more packages from your route returned to the station without a record of a valid attempt. The text is informational and usually repeats the idea that every delivery counts.
The part worth reading slowly is the reassuring one. Your standing not being at risk todaydoesn't mean the event wasn't saved. It means it hasn't crossed a threshold yet. Those are very different things, and the difference only becomes visible once there are three or four similar emails.
The real causes (and why the system can't see them)
A returned package is almost never a driver who decided not to deliver. It's one of these:
- A locked gate with no code, or a code that doesn't work.
- A controlled-access building with nobody answering the intercom.
- An incorrect or incomplete address in the system.
- Traffic that ate the delivery window.
- A station that dispatched late, compressing the entire route.
The uncomfortable detail is that the system records the outcome, not the reason. A package that came back because the gate was locked looks, in the data, exactly like one that came back because the driver never went. The only thing separating those two cases is documentation — and by default, the driver has none.
That's the whole imbalance: Amazon generates its record automatically on every route, and you generate nothing.
What to do if you already got one
- Don't reply in the heat of the moment. If the email is informational and asks for nothing, replying rarely changes anything — and a generic written apology can read later as an admission. Reply only if an explanation is requested, and do it with dates, times and facts.
- Reconstruct that route while you remember it. Date, station, dispatch time, and what happened to the packages that came back. Write it today: in two weeks you won't be able to tell that day apart from the others.
- Change the habit starting with your next route. The email that already arrived doesn't disappear. What you do control is that the next event has your version recorded at the same time as Amazon's.
What evidence actually holds up
Not all documentation carries the same weight. Text written days later proves nothing; what holds up a case is the record captured in the moment, with metadata:
- The exact time you were at the address.
- Your GPS coordinates right there — that proves you went.
- A photoof what prevented the delivery: the gate, the blocked access, the address that doesn't match.
With those three, “I couldn't deliver because of a locked gate” stops being your word against an automatic record and becomes a fact with a time, a place and an image.
It has to take seconds, or with a route running you simply won't do it. FlexDash saves it in one tap — timestamp, GPS and photo in a single record — and exports it as a PDF report organized by date and platform, ready to send to support if a warning arrives or you have to appeal.
Related situations worth knowing
The same principle applies when the problem happens at the station rather than at the customer's door. If you get stuck waiting at the warehouse, there's a 30-minute paid-wait rule and a delay report that protects both your pay and your standing. And if you arrive to find no routes available, Amazon pays the full block — but that's worth screenshotting the same day too.
If the email you received is already a formal warning or a deactivation, the appeal process uses exactly this kind of evidence — it's laid out step by step in the Amazon Flex appeal guide.
Frequently asked questions
What does the Amazon Flex unattempted deliveries email mean?+
It means Amazon recorded one or more packages from your route as returned without a documented valid delivery attempt. The email usually takes a soft tone — every delivery counts — and often clarifies that your standing isn't at risk right now. That last part is why most drivers archive it without acting. But the email exists because a note is now attached to your account, and notes accumulate.
Can I be deactivated over the unattempted deliveries email?+
A single email deactivates nobody. The risk isn't the email, it's the pattern: several similar notices within a few weeks build a history that can trigger an account review. So the right response isn't to panic at the first one — it's to immediately change how you document deliveries you can't complete, so the next ones don't arrive without your side of the story.
What counts as an unattempted delivery on Amazon Flex?+
Any package that returns to the station without evidence of a real delivery attempt. The typical cases aren't driver negligence: a locked gate with no code, a controlled-access building, an incorrect address, a resident who doesn't answer, traffic that consumed the delivery window, or a station that dispatched late and compressed the whole route. All of those produce returned packages, and without documentation they look identical to never going.
Why does the email say my standing isn't at risk?+
Because at that moment it's probably true — the notice is informational, not disciplinary. The important detail is that informational doesn't mean unrecorded. Amazon is logging an event tied to your account, and if there's a review later, that history is part of the file. Treating it as 'nothing happened' is exactly what leaves a driver walking into a review with nothing from their own side.
What should I do if I got the unattempted deliveries email?+
Three things. First, don't reply in the heat of the moment or admit fault in writing. Second, reconstruct what you can of that route while you still remember it: date, station, dispatch time, and what happened to the packages that came back. Third, and most important going forward, start documenting every problem delivery at the moment it happens — time, location and photo. The past email doesn't disappear, but future ones arrive with your evidence already in hand.
Should I reply to the Amazon Flex email?+
If the email is purely informational and asks for nothing, replying rarely changes anything and exposes statements you can't back up. If instead it requests an explanation, or arrives alongside a formal warning, then reply — with concrete facts, dates, times and evidence, not generic apologies. The difference between a reply that helps and one that hurts is almost always whether you have records that support what you're saying.
What evidence actually defends a delivery I couldn't complete?+
The kind captured in the moment and carrying metadata: the exact time you were at the address, your GPS coordinates there, and a photo of whatever prevented the delivery — the locked gate, the blocked access, the address that doesn't match. Text written days later proves nothing; a photo with the timestamp and coordinates of the moment you were there does. That's the record that becomes your defense.
Does Amazon Flex penalize drivers for things outside their control, like traffic?+
Not directly, but the system doesn't distinguish causes on its own: it records the outcome (package not delivered), not the reason, unless documentation exists to explain it. That's the imbalance — Amazon's record is generated automatically and the driver's almost never exists. Documenting is how the real cause also ends up on the record.
How do I document problem deliveries without losing time on the route?+
It has to take seconds or you won't do it with a route running. FlexDash handles it in one tap: it saves the timestamp, GPS coordinates and a photo in a single record, then exports them as a PDF report organized by date and platform. That report is what you send to support if a warning arrives or if you have to appeal.
The bottom line
An unattempted deliveries email isn't an emergency, but it isn't nothing either. It's Amazon putting on record something that usually wasn't your fault, in a file where you're writing nothing at all.
Every delivery counts? Then document every one. A driver who walks into a review with timestamps, GPS and photos of every delivery they couldn't complete is in a completely different conversation from one who only has their word. That difference gets built in seconds, on the route, on the day it happens.
FlexDash is the only mileage tracker built specifically for Amazon Flex drivers — including the only correctly-implemented 40-hour cap tracker in the App Store.
Try FlexDash free for 30 days →