How drivers handle a device outage
Delpack Logistics
October 26, 2026
11 min read
Preserve the last confirmed route state, use an authorized outage log and reconcile every parcel after a scanner fails mid-route.
A delivery scanner stops working after the fourth stop on a ten-stop route. The screen will not open the next assignment, and several scans entered shortly before the failure may still be waiting to upload. The driver has six physical parcels and a partial memory of what the device last showed. How drivers handle a device outage depends on preserving the last known route state, calling the designated support channel, and using only the fallback that the employer authorizes. The record must eventually explain what happened to each parcel while the device was unavailable.
This guide addresses an actual device outage during a route. An isolated missed scan with an otherwise working scanner needs a narrower correction. Weak coverage with a functioning device may call for an offline-capable workflow. A blank or failed scanner creates a larger problem: the driver may have no dependable view of stops, prior events, customer instructions, or pending uploads. The first decision is whether the route can continue safely and truthfully under a documented backup procedure.
Capture the last synchronized state
The last synchronized state is the latest route information known to have reached the employer's system. It may be earlier than the last button the driver pressed. Before changing devices, restarting an app, or entering more events, note the time the scanner failed, the last stop whose completion was confirmed, and any deliveries or exceptions that appeared to be pending. If the screen still responds enough to show a queue or status, capture that information through the employer's approved method. Do not assume an event uploaded because it briefly appeared on the local screen.
Microsoft's documentation for its Dynamics 365 Field Service mobile app provides a useful product-specific example: offline work can create pending changes that synchronize later, and conflicts can require attention. It does not describe Delpack's actual route software. The general lesson for a driver is narrower: distinguish an event entered locally from an event confirmed by the central system. The employer's device and support instructions determine which indicator counts as a confirmed sync.
Write down the current physical count before moving on. A ten-stop route may have ten assigned parcels, but one stop can contain several parcels and one parcel can require a special handoff. Reconcile parcel IDs on the van with the most recent authorized manifest or route printout. If the only route list lived on the failed device, dispatch may need to supply a current copy through an approved channel. Memory is a poor substitute for a route identity when addresses or packages look similar.
Preserve any information already visible about customer instructions without copying private details into a personal app or notebook. If the employer allows a controlled paper log, use that log and protect it as route information. If no approved way exists to access the needed delivery instructions, pause the affected stop and ask dispatch what can be done. A driver should never invent a signature, recipient name, or delivery location to make an unavailable screen appear complete.
Get the employer-authorized fallback before continuing
An employer-authorized fallback may involve a spare device, a dispatch-issued route sheet, a controlled paper event log, a support ticket, or a combination. The exact method depends on the operation, customer commitments, and what the technology supports. Tell support the device identity, route ID, current location, failure time, last confirmed stop, number of parcels still under custody, and any events that might be unsynced. Ask which events should be recorded offline and which stops must wait for a working device.
Support should identify a person who owns the outage and a case or incident reference if the process provides one. That reference ties the driver's temporary notes to the eventual route correction. A verbal instruction to "keep going" is too thin when the driver cannot later distinguish delivered parcels from parcels still in the van. Repeat back the approved record fields and the point at which dispatch wants another update. If the fallback changes, record who authorized the change and when.
Do a basic, permitted device check before concluding that the hardware is unusable. Follow the employer's troubleshooting sequence for power, accessories, and app status. Avoid clearing app data, signing into someone else's account, or factory-resetting the device on personal initiative; those actions can remove pending evidence. If support tells the driver to restart, ask whether unsynced entries could be lost and what to capture first. A support-directed restart is a documented action, not a substitute for reconciling the route afterward.
A spare device can restore the route view, but it may not immediately contain the failed device's pending events. Confirm the account, route, parcel list, and last central status before making new scans. The same stop must not be recorded twice simply because the replacement device displays an older state. If dispatch reassigns the remaining stops, the physical parcels and the electronic assignments need to move together. The driver should know which device now owns new events.
Some deliveries require a live signature, identity check, photo, age verification, or other proof. Whether any alternate proof is acceptable is a policy question for the employer and the relevant service. The driver cannot choose a paper substitute simply because a device failed. If the required proof cannot be collected through an approved method, dispatch should decide whether to defer or reattempt that stop. The route may still have ordinary stops that can proceed under the authorized fallback.
Record custody and events in an outage custody log
An outage custody log should identify each parcel by its actual ID, the stop it belongs to, and what physically happened. For a completed delivery, record the time, location, approved recipient or placement description, and the person who captured the information. For an attempted delivery, record the factual reason and whether the parcel returned to the van. For an untouched stop, leave it untouched in the log. Use the employer's required fields; a personal shorthand that only the driver understands will be hard to reconcile later.
Separate physical custody from electronic status. A parcel can be delivered while its electronic event remains pending, or the central system can show a delivery event that still needs investigation if the physical parcel is in the van. At every handoff during the outage, the driver needs a record of where the parcel went. Do not mark a parcel delivered just because its stop was visited. Do not leave it with an unauthorized person because proof capture is inconvenient.
Keep entries in event order. If stop five was attempted at 11:04 and stop six completed at 11:22, those times should remain distinct even if the driver enters them into a replacement system later. A later entry time is not necessarily the event time. The employer's correction procedure may have separate fields for both. Preserve the original outage notes so the reviewer can see what the driver knew before a backfill was made.
Protect customer data during the fallback. A phone photo of a shipping label or a route list may be convenient, but only use devices and storage that the employer permits. Avoid sending addresses and recipient names through a personal text thread. A controlled paper sheet should remain with the driver or designated handoff owner and be returned or disposed of according to policy after reconciliation. The outage does not remove the normal duty to protect customer information.
Check the van after each stop. Without a working scanner to flag a mismatch, a parcel can be left at the wrong address or carried past its stop. Compare the parcel ID and address through the approved fallback before the handoff, then update the custody log immediately. If two nearby stops have similar names, stop and confirm the mapping with dispatch. An uncertain identity is a reason to pause that parcel, even if the rest of the route can continue.
If a customer reports that an expected delivery is missing while the system is down, give support the parcel ID and the driver's recorded physical state. Do not promise a delivery time based on a stale route screen. Dispatch can compare the central record with the driver's log and determine the next customer update. The driver's responsibility is a precise account of the parcel, not an improvised system status.
Work through the ten-stop outage
Suppose the scanner fails after stop four. Stops one through three show confirmed central completion. The driver entered a delivery event at stop four, but cannot tell whether it uploaded. The van contains parcels for stops five through ten. The driver calls dispatch with the route and device IDs, time of failure, the uncertain stop-four event, and the six remaining parcel IDs. Dispatch opens an outage case and directs a controlled paper log while a spare device is prepared.
The driver records the actual stop-four handoff from memory while it is fresh, marking its sync status as unknown. This is a factual note for later comparison, not a second delivery event. Before stop five, the driver confirms the parcel and address from the dispatch-issued list. Stop five is completed under the approved fallback; stop six requires a proof method the paper log cannot satisfy, so dispatch holds that parcel for a later attempt. The driver records the attempted visit and keeps the parcel in the van.
At stop seven, a replacement device becomes available. The driver and dispatch compare its central view with the outage log. If stop four is already recorded centrally, they do not enter it again. If it is absent, they follow the employer's correction method, using the original event time and the available proof. Stops five and six also need individual review: one parcel was delivered under the approved fallback, and one remains under driver custody. The device's route view must reflect those different outcomes before new events are added.
The driver then completes stops eight through ten on the replacement device if the assignments, addresses, and proof requirements match the physical load. At return, dispatch checks the paper log against central events and the remaining parcel. Stop six goes through the authorized return or reattempt path. The outage case stays open until the uncertain stop-four event and the fallback delivery at stop five have an accurate, single history. Ten assigned stops do not require ten "delivered" statuses; they require ten truthful outcomes.
Complete post-outage reconciliation when the device recovers
Post-outage reconciliation compares three records: what the driver physically did, what the temporary outage log says, and what the central route system shows. Work parcel by parcel, including undelivered items. Check event type, parcel ID, stop, event time, proof, and current custody. An apparent duplicate may be the same local event uploaded late, while a missing event may need an authorized correction. Do not delete or overwrite an event solely to make totals match.
Microsoft's offline synchronization guidance describes delayed uploads and conflict handling within its own product. That example reinforces why a repaired device should be allowed to sync under support direction before a person manually recreates every missing-looking event. Delpack or another delivery operation may use different software and rules. The practical check is the same: identify what has actually reached the destination system before entering a correction.
Escalate contradictions that cannot be resolved from the log. If the system says "delivered" but the parcel is physically in the van, the record needs investigation. If the driver says a parcel was handed over but there is no required proof, the supervisor must apply the service's exception process. If a replacement device created a second event for one handoff, preserve both event identities for review instead of guessing which one can be removed. The aim is an auditable account, not a cosmetically clean screen.
At route close, count the parcels still in the van and match them to return, hold, or reattempt statuses. Confirm that a driver or dispatch owner has signed off on the temporary log under the employer's process. The failed device may need to be kept for technical review if unsynced records remain on it. Hand it to the designated support owner rather than wiping or discarding its local state. Keep the outage case reference with the route correction.
Decide when a route can continue
How drivers handle a device outage includes a stop-or-continue judgment that the employer must own. The driver can continue a particular stop only when the parcel identity, destination, required instructions, proof method, and custody record are available through an approved fallback. If any of those are uncertain, hold that stop and ask dispatch for a decision. A working navigation app does not replace the delivery record, and a route list does not replace required proof.
Support may decide to split the route, send a spare device, return the remaining parcels, or continue selected stops on a controlled log. Record which choice was made and the exact parcel set it covers. A route-wide instruction may still leave individual stops blocked by proof requirements or customer directions. Review those exceptions before arriving at the address, where pressure to finish a delivery can lead to an unsupported handoff.
Once the outage is resolved, the team can inspect the failed device and the timing of pending uploads to prevent a repeat. That technical review should not change the driver's factual account of the ten stops. The guide's narrow rule is to preserve a reliable before-state, use an authorized fallback during the gap, and reconcile every parcel after the system returns. Readers can find related route guidance in the driver guide hub and career information on 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.