How drivers record an undeliverable item
Delpack Logistics
October 26, 2026
10 min read
Choose the exception reason that matches a failed delivery attempt, attach required evidence, and keep the undelivered parcel in accountable custody.
A driver reaches a gated building, enters the access code supplied for the stop, and the gate rejects it. No one answers the approved contact channel, and the driver cannot reach the delivery point. The parcel remains in the vehicle. When the app asks why the item is undeliverable, "customer not home" may be the first convenient option on the screen. It would describe a different event. How drivers record an undeliverable item depends on the barrier the driver actually observed, the evidence the employer requires, and the parcel's continuing custody.
A failed delivery can result from many conditions: no access, an incomplete address, an unavailable required recipient, an unsafe handoff location, or another route-specific reason. These are not interchangeable labels. They can shape what the customer sees and what the operation does next. The United States Postal Service, for example, describes "No Access to Delivery Location" separately from a notice that no authorized recipient was available. That is a USPS status distinction, not a Delpack code list. The general lesson for a driver is to choose a reason that matches the observed event in the employer's own system.
Describe the observed barrier
The observed barrier is the fact that prevented this attempt from reaching an authorized handoff. In the gate example, the driver could not enter the property because the provided code did not work and no approved alternative access was available. The driver did not reach the recipient's door. There is no basis for saying the recipient was absent. A status choice should not claim knowledge the driver could not obtain.
Write the sequence in plain terms before picking a category if the app permits a note. Include the package or stop identifier, arrival or attempt time, where the driver could safely reach, what access method was tried, and the result. "Gate keypad rejected the listed code; no response through approved contact; parcel retained" is more useful than "couldn't deliver." It tells the next owner what needs correction and shows that no recipient interaction occurred.
Do not add details merely because they fit a common failure pattern. A closed lobby is not proof that the business is permanently closed. A silent intercom is not proof that no one was home. A parcel still in the van has not been refused by the recipient. If the driver cannot determine the cause, describe what was observed and ask the assigned support owner which category applies. A truthful "unknown pending review" path, where the system offers one, is better than a confident but unsupported reason.
How drivers record an undeliverable item starts after the driver has followed the applicable safe access and contact steps. This article addresses the entry that closes the failed attempt; a separate guide addresses how to handle an inaccessible site while the driver is still trying to reach it. The distinction matters because a status record should describe the outcome of the attempt, not replace the work needed to make the attempt.
Select the supported exception reason
A supported exception reason is the employer's status whose definition fits the attempt facts. Read the label and any help text. If the options include an access barrier and a recipient-unavailable option, choose between them based on where the driver got and what was observed. At a gate that never opened, the access problem is established; recipient availability is not. At a signature-required door where the driver reached the location and no authorized signer appeared, a recipient-related option may fit, subject to the employer's policy.
The app's wording may differ from a public carrier's tracking vocabulary. Do not copy a USPS or UPS status into another company's system because it sounds familiar. The employer may distinguish locked building, unsafe access, no secure location, or unable to contact recipient. The driver needs the current local definitions. If two labels appear to fit equally well, report the facts to dispatch rather than guess which one produces a faster route closure.
Some options carry consequences beyond the driver screen. A choice can trigger a customer notice, a redelivery task, a return workflow, or a quality review. The driver may not see those downstream actions. That is a reason to preserve accuracy, not to overthink every ordinary selection. Use the definition tied to what happened. If the system lacks a fitting choice, use its approved escalation or free-text path and obtain an instruction. Do not select "delivered" to make the parcel disappear from the active list.
This is an individual entry decision, not a proposal to rewrite the organization's code set. A separate operations topic concerns whether categories need clearer definitions across many drivers and stops. Here the driver has one failed attempt in front of them. They need a defensible status for that package now, with an evidence trail that allows later correction if support finds new facts.
Attach the required attempt evidence
The attempt evidence should support the reason selected without exposing more customer information than the employer allows. The app may require a time-stamped attempt scan, a location confirmation, a photo of a public-facing gate or notice, a contact attempt, or a short note. Requirements vary by service and system. Use the assigned workflow; do not invent a universal photo rule from a general delivery article.
For the rejected-code scenario, the useful evidence is that the driver reached the access point, the code supplied for the stop failed, and the approved contact method did not yield another route in. A photo may show the gate or keypad area if the employer permits it, but a photo alone may not prove which code was tried. A concise note can provide that context without recording the actual access code in an unapproved field. Keep security credentials out of customer-visible status text.
If the driver leaves a notice, its placement and wording must follow the employer's rules. Do not place a notice in a location the driver could not lawfully or safely reach. Do not claim a notice was left when it was not. A system prompt may assume a notice on certain exceptions, so check the workflow before confirming it. Evidence should describe a completed action, not an action the driver intended to take.
If service is weak and the device stores events locally, distinguish a saved attempt from a confirmed upload. Preserve the local event and check synchronization when service returns. A delayed upload should not become a new invented attempt time. The record should connect the actual stop event to the later system transfer. If the app fails to save the attempt at all, use the authorized device or support fallback; do not repeatedly tap an uncertain control until several contradictory records appear.
Keep parcel custody aligned with the status
The parcel custody record must agree with the exception entry. If the driver could not reach the delivery point, the item remains with the driver or moves to another authorized holder. Do not mark it as left at the property or with a receptionist who never accepted it. Secure it in the vehicle according to the normal load rules, with the identifier available for a later scan or receiving check.
The next action may be a retry, a depot return, an approved hold, or another instruction. The driver should not assume that selecting "undeliverable" automatically transfers the parcel out of their custody. Confirm what the route app expects at the end of the shift and who must receive the item. A physical return without a receiving event can leave the package showing on the driver's route; a status entry without a physical return leaves a parcel still on the van. Both sides of the handoff need to match.
If the package is later handed to another driver or station worker, record the actual transfer through the employer's process. The first exception reason remains a historical account of why the delivery failed at that stop. A later successful delivery does not make the failed attempt false. Nor should the driver erase the initial event to make the tracking timeline look simpler. Each event should tell the truth about its own time and custody state.
A wrong status may create a second problem. A "delivered" scan for a parcel still in the van can send a recipient searching for an item that never left the vehicle. A "recipient refused" entry can attribute a decision to a person the driver never met. If a mistaken reason was submitted, report it promptly with the original event ID and the actual facts. Let the authorized correction owner amend the record rather than silently replacing it with another unsupported status.
Work the invalid entry code example
Consider an illustrative stop for parcel G18 at a gated apartment building. The route information includes a gate code. At 14:10 the driver reaches the public entrance and tries that code once under the approved procedure. The keypad rejects it. The driver uses the app's approved contact option, receives no response, and has no safe authorized way inside. G18 has not reached the recipient's door and remains in the vehicle.
At this point, the driver has enough information to describe an access barrier, but not enough to say the recipient was absent. The driver records the package and stop ID, actual attempt time, gate rejection, contact result, and continuing custody. They select the employer's fitting access-related reason if that option and definition exist. If the app presents only ambiguous categories, the driver contacts dispatch and follows its instruction. They do not choose "no one home" solely because it is first in the list.
Suppose the app requires a supporting photo and permits a photo of the public gate. The driver takes the required image without capturing a person or revealing the entry code. If no photo is required, the driver does not need to create a personal record. They then keep G18 in the van, continue the authorized route, and return it or hold it as instructed. The receiving handoff at the depot is recorded separately from the failed attempt.
Now suppose a later support call reaches the resident, who says they were home. That fact does not change the driver's earlier observation: the driver could not get past the gate. It further shows why "recipient absent" would have been misleading. The operation may provide a corrected code for a later attempt, but that later event belongs in a new record. Do not backdate it into the first attempt.
The example is deliberately narrow. It does not prescribe how long a driver must wait, how many times to try a code, or whether to call a customer directly. Those are employer and service decisions. The article's decision is which reason and evidence accurately describe the failed attempt after the permitted access steps have ended.
Use a status review before closing the stop
A brief status review can catch a wrong option before submission. Read the reason back as a sentence: "This parcel could not be delivered because..." Does the selected category complete that sentence with an observed fact? Check the package ID, stop, time, and required note or evidence. Confirm that the app shows the parcel as undelivered and still under the correct custody path. Then submit according to the employer's workflow.
If a choice is irreversible from the driver account, slow down at the selection screen. If the app allows edits, preserve the original event and use the documented correction method; do not assume an edit leaves no audit trail. If the screen freezes or the result is uncertain, check for the submitted event before trying again. Two conflicting exception entries can make it harder for support to know what happened.
Before ending the route, compare undeliverable items still in the vehicle with the recorded exceptions and any return handoffs. Every parcel should have a physical location and a truthful status. An item that appears closed on the screen but remains in the van needs attention. An item marked for return should reach the required receiving point. The driver should report any unresolved mismatch rather than leave it for the next shift to discover without context.
How drivers record an undeliverable item is a small decision with a long record. Select the reason the evidence supports, document the attempt the driver actually made, and keep the parcel's custody visible until the next authorized handoff. More delivery scenarios are in the driver guide hub . Drivers exploring local work can use the Fort Wayne driver careers page .
Continue with Delpack
Review the Fort Wayne career overview or contact Delpack with a question about the company.
Topics
Browse Topics
All Guides
346
Job Search, Applications & Offers
79
Role Types & Job Fit
83
Schedules, Policies & Work-Life
40
Route Operations & Performance
91
Logistics & Warehouse Operations
53
Delpack Logistics Delpack Logistics is an Amazon Delivery Service Partner and last-mile logistics company serving the Fort Wayne market. Explore Welcome Meet Delpack Fort Wayne Delivery Driver Careers Driver Resources Contact Delpack Delpack News Legal Terms of Service Privacy Policy SMS status Contact info@delpacklogistics.com 260-306-5806 View market and mailing address © 2026 Delpack Logistics . All rights reserved.