Courier Mobile App: Where Delivery Breaks
A delivery failure rarely looks like a server outage. More often it is a courier at a closed entrance calling the dispatcher and dictating the apartment number: in the courier mobile app, the address collapsed into a short string without entrance, floor, or intercom code. Each such call means minutes of downtime, and over a shift it adds up to about an hour.
A separate story is working without connectivity. An underground parking garage, an elevator shaft, a warehouse made of metal panels: the app loses the network along with the open order.
The courier cannot confirm delivery, the status remains the same, the order stays “in transit,” and the customer calls support. Without storing state on the device and sending it when the network is restored, it is not the mark that is lost, but the fact of delivery itself.
Manual statuses break the picture even earlier: the courier marks “delivered” at the end of the shift, from memory or from a piece of paper.
The dispatcher does not know until evening whether the order was delivered—hence repeat trips to the same address, disputes with the customer, and a discrepancy between actual deliveries and the report.
Courier address navigation relies on details that are usually not transferred to the app: entrance number, floor, intercom code, landmark near the yard. If they are missing, the courier asks again every time—this is slower than routing by a saved entry point.
Order closure breaks in the same place: a photo of the waybill, payment confirmation, and status change are spread across different screens, and the courier closes the request formally, then sends proof later.
Each such gap means minutes of downtime, extra kilometers, and calls that should not happen. We analyze how this is closed.
Measurable Effect: Shift Time and Address Accuracy
We record metrics before the start, otherwise there is nothing to confirm the effect with.
The baseline is taken on the current setup over two to three weeks: for each shift we calculate courier shift time—from the first switch to “on shift” status to closing the last order, excluding downtime caused by the warehouse. We then compare the same interval one-to-one.
We separate repeat trips from initial ones: this is an address the courier returned to because of incomplete recipient data, an unavailable phone, or the customer not being present.
Each such trip means double mileage and a shift of the other stops in the route, so we calculate their share of the total number of deliveries per shift, not the absolute number.
Calls to the dispatcher per hundred orders are an indirect indicator of dispatcher workload.
We take them from the call log and correlate them with shifts: it is visible how many requests are caused by address clarification and how many by technical app failures, and these are different categories that are addressed differently.
The successful delivery rate is calculated from app events with timestamps and geolocation—that is, deliveries with delivery confirmation, not a formally closed status.
The denominator includes all orders assigned to the courier, including canceled and returned to the warehouse, otherwise the metric flatters and is unsuitable for comparison.
To make the comparison fair, we keep the shift composition, zones, and typical routes the same, and account for seasonal spikes with an adjustment.
These metrics then go to the monitoring dashboard and update automatically—the deviation is visible within the day, not at the end of the quarter.
Options for Delivering Orders to the Courier Device
The choice is determined by how much your delivery process differs from the typical one and how quickly couriers need orders in the field.
Below are four options that are actually chosen between: they differ not by “quality,” but by how much work they take on and what they leave to you.
| Option | When suitable | Limitations |
|---|---|---|
| Ready-made solution for a delivery service | Routes and statuses are close to typical, need a quick launch without development | Status logic imposed by the vendor, poorly adapts to your tariff and order distribution rules |
| Courier web dashboard | Few couriers, simple orders, any courier device | No background geolocation, notification arrives only when the tab is open, the interface “freezes” on a weak network |
| Own app | Non-standard scenarios: partial refusal, return, offline work, own roles and permissions | Longer launch, two platforms, publishing in app stores and updates on the device |
| Modification of the accounting system | Accounting is already in place, important not to lose order history and reporting | Depends on whether the system has open data exchange; some tasks will have to be solved on the accounting vendor side |
The hybrid occurs more often than it seems: the courier works in the app, while the dispatcher distributes orders in the web dashboard.
We start with process review and choose the minimal option that supports your logic without rework—and leave a path for expansion when volume grows.
Project Stages: Audit, Scheme, Build, Validation, Handover
The delivery process audit starts not with screens but with shift observation: how the courier receives the assignment, how many times they call the dispatcher, under what conditions they close a stop, and what they do when the customer refuses.
The output is a map of current routes, time per stop measurements, and a list of places where manual actions consume working hours.
- Delivery process audit. We ride along with couriers, record assignment receipt, communication with the dispatcher, delivery confirmation, return, and shift handover. Separately we check network coverage, old devices, and work in gloves—this determines which actions can even be assigned to the screen.
- Route and status scheme. We describe order states and allowed transitions between them, rules for assembling stops into a route, behavior on refusal, delivery reschedule, and repeat delivery. The scheme is agreed with the service before the build starts so that dispatcher and app logic do not diverge.
- Build. Navigation, offline mode for basements and entrances, sending photo confirmation, data exchange with the service accounting system. The first prototype is tested on anonymized assignments from past shifts—load and routes are real, not invented.
- Pilot shift. Several couriers in a limited district, the dispatcher works in both setups simultaneously. We look at the share of assignments closed without calling the dispatcher, time per stop, and the number of discrepancies with the accounting system.
- Results review. Fixes for hot spots, a repeat run on the same group, fixation of target metric values. If the pilot does not match calculated indicators, the setup rolls back to the paper scheme—the service does not remain without a working process.
- Project handover. Deployment scheme, access, update regulations, instructions for couriers and dispatchers, training of the responsible person on the service side. Then—an agreed support and update period after changes in tariffs or delivery zones.
Handover Kit: Builds, Schemes, Regulations, Access
When the courier app goes to production, support must work without us—by documents and regulations, not by memory of chats. We hand over a kit by which your engineer independently builds a release, rolls back a failed version, and investigates an incident with a shift or address.
- Update procedure — where the version is built, what checks it passes, how it is deployed first to the pilot courier group, then to all. It states who decides on deployment and at what hours to do it, so as not to catch a wave of complaints at the peak of a shift.
- Version rollback — how to return the previous build if order intake or tracking breaks after an update, and how many minutes it takes without losing data on active deliveries.
- Access rights — role matrix: who sees orders, who changes zones and tariffs, who deploys releases; separately—the procedure for granting and revoking access upon termination.
- Action log — where to see who and when changed settings, canceled an order, or granted a role, so that incident review does not turn into a random search for someone to blame.
- Handover documentation — project structure, data schemas, integrations with maps and telephony, list of external services and responsible persons on the service side.
- Access and secrets — accounts, integration keys, and certificates reissued to the service, not to us.
Handover takes place via a recorded call: we go through each item, answer questions, and record what remains with your team. Then support is handled by your engineers or us under a separate agreement—but no longer with the situation where only the authors know the app structure.
Case: Delivery Service Cut Shift Time by a Third
Delivery service Skorokhod—several hundred couriers, paper route sheets, and radio: the dispatcher called each one to close an address or reassign an order.
The pilot implementation was launched on a group of 40 couriers; the second group remained the control—metrics before and after were calculated on the same order flow and the same seasonality.
Pre-pilot measurement: a shift lasted an average of 9 hours 40 minutes with a route norm of 7 hours. 46% of orders were closed without calling the dispatcher—the courier could not mark the status if the address was unavailable or the customer asked to reschedule delivery.
Repeat trips accounted for 11%: the address on the sheet differed from the actual one, and the correction was made through the dispatcher only by the next day.
What Changed in the App
Couriers received an offline operation queue: status, confirmation photo, and failure reason can be recorded without a network; data goes to the server when the connection appears.
The route updates in the background, order reassignment arrives in a targeted way, and disputed addresses are marked directly on the map. The dispatcher sees shift progress as a list, rather than gathering it through a series of calls.
What Happened to the Metrics
The shift shortened to 7 hours 15 minutes—a third less with the same number of orders per courier. The share of orders without calling the dispatcher grew from 46% to 89%, repeat trips fell from 11% to 3%: address corrections are made at delivery time, not the next day.
After the pilot, the entire fleet was moved to the app, and the control group switched to it without modifications.
What to Do If the Service Already Works in a Ready-Made Delivery Service?
A service that grew inside a ready-made delivery service hits a ceiling: order distribution rules are set by the platform, statuses and courier payouts live by its logic, and the connection with your accounting goes only through exports.
We migrate from a third-party service without stopping operations: the platform remains the source of orders, while order intake, route, statuses, and payouts gradually move to your setup.
Order history migration starts with an export: orders, addresses, timestamps for each status, assignee, cancellation reason.
We bring the data to a single schema and load it into our database—history is needed not for reporting, but for calculating tariffs, reviewing disputed deliveries, and testing new distribution rules on past shifts.
Parallel operation of the two setups relies on the order source: each request has an external number, duplicate protection works by it, and the courier sees a single task list regardless of where the order came from.
We maintain this mode for 2-6 weeks—until delivery time and the share of completed orders on your setup match the platform indicators.
Contractor training runs with a pilot group of 10-15 couriers: shifts in the new app, review of offline mode and disputed addresses, fixes for each screen. Then we migrate the rest by teams, so that there is always a group working under the old scheme available.
Rollback is simple: your setup stores data as the source of truth, so return is switching the order source, not restoring history. Describe how your service is structured—we will come back with an estimate and migration plan.
Common Technical Doubts Before Project Start
The courier works in a basement, in an elevator, in an industrial zone outside the city—the connection drops for minutes, and the shift does not stop.
Below are the questions most often asked before the start: the answers determine the app architecture, not the interface cosmetics.
What happens to the shift if the network is lost for 20 minutes?
Order statuses and delivery marks are written to a local queue on the device and go to the server as soon as the connection returns.
Operations are idempotent by order ID, so resending does not double the delivery: the dispatcher sees the current picture with a delay, not loses it.
How to update the app if the courier is already on shift?
Mandatory versions are deployed in the window between orders: the app checks for an update when returning to the main screen and does not allow taking a new order on an outdated build. Active orders are completed—the update does not knock the courier out of the shift mid-delivery.
How does the app integrate with the customer's accounting system?
Through an API: our layer handles synchronization of orders, statuses, and payouts, while your accounting system remains the source of truth. If a ready interface is absent, we set up scheduled file exchange—slower, but it launches without modifications on your side.
What courier and customer data is available to the dispatcher?
The dispatcher sees geolocation within the shift and order statuses, but not personal messages or device contents. The customer's phone is masked, the full number is revealed only on an active order, action logs are anonymized, and data on the device is stored in secure storage.
Let's Discuss the Task and Come Back with an Estimate and Plan
The accuracy of a courier app estimate depends not on the number of screens, but on the completeness of the current process description: how orders are distributed, who changes statuses, how payouts are calculated.
If this data is available at the start, we immediately see the scope of integrations and do not rework logic mid-project.
To come back with an estimate and plan, not general words, it is enough to send what is already used in daily work:
- Route scheme: who assigns orders and by what criterion, how many addresses per shift, whether there are zones and priorities.
- List of order statuses—from intake to delivery, with refusals, reschedules, and repeat trips.
- Payout calculation rules: per stop or per shift, bonuses, deductions, and the source of initial figures.
- Current order accounting: spreadsheets, accounting system, exports, who closes the shift and reconciles discrepancies.
- Examples of real shifts with failures: failed delivery, cancellation at the address, wrong address, lost connection.
- Roles and access: what the courier, dispatcher, and accounting see, who can change what.
- Where couriers work without a network and what must reach the server after it appears.
This is enough to discuss the task substantively and come back with an estimate and plan: scope of work, order of stages, and project start date. Data preparation on the customer side usually runs in parallel with design and does not delay the start.