Why a courier service mobile app stalls in the field
A courier accepts an order in a basement or outside the city: the app shows “accepted,” but the dispatcher’s screen has no order.
The weak channel interrupted the send, the local queue did not retain the record, retry was not provided for — and the client waits for a courier who has already left for another address.
Formally the order is accepted — for the system it does not exist; this is what lost orders look like under weak connectivity.
Delivery statuses hang until the end of the shift. The courier’s offline mode works only for reading: the latest data can be shown, but a new state cannot be sent.
The marks “delivered,” “refusal,” “reschedule” are written over the previous state without a queue and retry, so when switching between networks some events are lost, and when connectivity returns they arrive as duplicates.
The dispatcher sees “in transit” where the order was closed an hour ago and calls couriers to reconstruct the day’s picture.
The third source of failures is manual address entry. The courier types the street and building as text, a one-digit error turns into going to the wrong place and a repeat delivery.
Support drowns in clarifying calls: during peak hours they come in a stream and crowd out handling real failures, while the dispatcher’s load grows with the number of couriers on the line.
The cost of these defects is lost orders, unreliable statuses, and a dispatcher who manually stitches data together from calls. Let’s break down how this is addressed.
What changes in a courier’s shift: four measurable effects
The effect is visible in the shift, not in reviews: how many addresses a courier closes per hour, how many orders go to support, and what happens when connectivity drops. Each item below has a metric that can be measured before and after implementation.
Order closing speed
Delivery is marked with one tap, the status goes to the dispatcher immediately — without a call or evening reconciliation of waybills.
The gap between the actual handover of the order and its closing in the system shrinks from hours to seconds, and the freed-up time goes to additional addresses.
Offline synchronization: connectivity is lost, the shift continues
Basement, elevator, country plot — marks, photos, and signatures go into a local queue, and work is not interrupted.
When the network appears, the queue goes to the server in order, without duplicates or lost statuses, so after a connectivity failure there is no need for manual shift reconciliation.
Delivery status control without support requests
Each transition — “in transit,” “on site,” “delivered” — is recorded with time and position, and the dispatcher and client see the courier’s movement on the map in Yandex Maps.
The question “where is my order” is answered by the tracking screen, and the share of orders without support calls grows multiple times.
Fewer manual operations, no input errors
The address and order contents are pulled from the waybill, delivery is confirmed by scanning instead of retyping the number. Discrepancies are caught by the system at entry, not during end-of-day reconciliation — the class of manual input errors disappears entirely.
Development options: ready-made platform, app builder, custom build
At the start, all four paths look similar: map, order statuses, notification of courier assignment. The difference shows up in order volume, when the courier payment scheme changes, and when a proprietary dispatch environment needs to be connected to the app.
How to choose by fleet size and order logic
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made delivery platform | Fleet up to 50 couriers, standard orders, launch in tight deadlines | Routes and tariffs are set by the vendor; custom rules only through the shared improvement queue |
| App builder | Need fast release and a simple order showcase | Screens are assembled from third-party blocks; a non-standard checkout step requires an external module |
| Custom development | Own order distribution logic, exchange with the accounting system, growing fleet | Longer onboarding, need your own release pipeline and ongoing support |
| Enhancement of the current solution | The app works but hits a functional ceiling | Dependence on the previous contractor’s code; first an audit and build transfer |
Where they hit a wall in year two
For a platform, the ceiling comes when a second courier type or a zone with different rules appears — the core is not rebuilt for them. An app builder starts to slow down on the number of screens and connections, and third-party module updates follow someone else’s schedule.
A custom build requires maintaining compatibility with current system versions and testing operation under weak connectivity and on old devices. Enhancing someone else’s code without an audit almost always leads to a second round of rework.
Implementation stages: from process review to project handover
While the app is not built, delivery processes live in the dispatcher’s head and in chats. That is why we start not with code but with a review of the order route: which statuses change, where paper appears, where the courier calls the office to clarify the address.
- Delivery process review — we go into a shift and record the real order path: acceptance, distribution, handover, confirmation, return. We note places where data is entered twice.
- Data exchange scheme — we describe the entities of order, address, delivery interval, status, and recipient signature, synchronization directions, and app behavior without network.
- Roles and rights — courier, dispatcher, logistician, administrator: what each sees and changes, which actions require confirmation.
- Build and connection to the accounting system — interfaces for one-handed work, a queue of unsent marks, an action log.
- Field testing on real shifts — weak connectivity, old devices, evening addresses.
- Handover and training — instructions, failure review regulations, accesses, update procedure.
Pilot on one shift
We launch on one crew and one shift with a limited number of orders. We measure the time to mark a status, see where synchronization breaks, and how often the courier calls the dispatcher. This way a raw build does not go out to the entire fleet.
Acceptance criteria
Acceptance is based on measurable indicators: the share of orders closed without a call to the office, time per delivery, the share of marks that reached the system without manual correction, and the number of refusals per shift. Until the results match, the stage is not closed.
Project artifacts: app builds, schemes, regulations
The project is handed over not as a folder with source code but as a set that allows the app to be developed without us. Everything created during the work remains in the customer’s repositories and accounting systems along with a description of how to use it.
- ready builds for app stores — signed, with a description of the version that can be rolled out again;
- data exchange scheme with the accounting system: which entities are synchronized, how often, and what happens when connectivity is interrupted;
- role and rights matrix: courier, dispatcher, logistician, administrator — what each sees and changes;
- support regulations: request channels, response time by failure classes, escalation procedure;
- courier instructions: installation, login, working with an order, actions when network is lost;
- update release procedure: who approves, how the build is tested, how rollback is performed;
- build and environment description — so the release can be reproduced on a clean machine without us.
Access rights and role matrix
The matrix defines not only visible screens but also access to data: the courier sees only their own orders and does not edit the waybill, the logistician distributes and reassigns, the administrator maintains reference data. Restrictions by handover point and territory are described separately.
Update release procedure
The build first goes to a test environment and is checked against real route scenarios, then is rolled out gradually — first to a group of couriers, then to everyone.
Rollback is described step by step: how to return to the previous version if the share of errors grows during a shift.
Case study: how lost orders during peak hours were reduced
A courier service with a fleet of several hundred contractors came with a problem during the evening peak hour: some orders remained without a courier.
The order hung in the queue, the client called support, and the contractor declined the offer without understanding the real workload.
Metrics before and after on an active fleet
We measured not daily averages but the two peak hours separately — that is where orders were lost. Measurements were taken before launch and one month after operation on the same fleet, without dedicated “reference” couriers:
- share of lost orders during peak hours — 11% → 2%;
- address closing time — 8.5 → 5 minutes;
- support requests about order status — reduced threefold;
- orders per contractor during peak hours — 20% more.
What was changed in processes, not only in the app
The app was not the only point of change: the distribution rules were rewritten — priority to the nearest courier taking into account address closing time, not the order’s sequence number.
A clear status model was introduced so the dispatcher could see a stuck order before the client called, and the shift was trained to work with it. The arrival time forecast was recalculated using data from the mapping service Yandex.Maps with traffic taken into account.
The implementation result rests on these two layers: the interface removes unnecessary actions, and the distribution rules prevent an order from remaining without a contractor.
Six months after launch, the share of lost orders during peak hours remained at 2-3% with increased volume.
How enhancing a ready-made solution differs from building from scratch
Enhancing a ready-made solution preserves the working environment: reference data, order history, courier accounts, and configured exchanges with the accounting environment 1C.
Data migration here is a predictable operation: export, field mapping, loading into the new scheme takes days, not months.
Logic, however, is rarely transferred — extensions written around the core live by their own rules and often have no connection point in someone else’s build.
The limits of a ready-made platform begin where a requirement diverges from the built-in model.
Courier offline operation, background geolocation transfer, a non-standard order distribution queue, granular rights for substitution and shift handover — if this is closed inside a module, enhancement turns into a superstructure over someone else’s code. It holds only until the first major update.
Version compatibility is the second limiter. A core update changes contracts, and every extension undergoes re-testing. Two or three releases in a row with broken enhancements is a signal that the cost of ownership is growing faster than the product.
Building from scratch wins when more than a third of key scenarios run into closed modules or the relaunch timeline is shorter than the path of sequential enhancements.
Then we fix the set of data for migration, design the scheme for real shift scenarios, and release the first working version earlier than a superstructure over the platform would reach the same scope.
Describe your situation — we will come back with an estimate and a plan showing exactly where the turning point is.
Common concerns: connectivity, battery, accounting system
The concerns here are not about the interface but about the shift as a whole: connectivity in stairwells and basements, battery charge by evening, old devices in the fleet, and an already working accounting system. Below is how these areas are addressed architecturally, not with promises.
What happens to the work order during connectivity interruptions?
The courier works in a local queue: statuses, delivery marks, and photos are written to the device and are sent when the network appears. Each operation has its own identifier key, so re-sending does not create a duplicate work order.
Will the app run on a budget device?
The work orders screen is a lightweight list without a heavy map, background activity is limited, and data arrives in portions. On devices from previous years, a shift runs without freezing even with a large order history.
How much battery is used per shift?
Coordinates are sent in packets with adaptive frequency: more often while moving, less often when parked; there is no background server polling — events arrive as notifications. A typical smartphone lasts a shift without an external battery.
How does the app connect to the accounting system?
The app does not write to the accounting system directly: operations go through an integration layer according to the described rules. This provides status reconciliation, retry on failure, and discrepancy review if the accounting system is unavailable.
Will an update stop the shift?
No: versions are rolled out in stages, installation is postponed until the end of the shift, and the previous client works with the server until the forced threshold. The courier is not left without a work order because of an update release.
Starting work: shift composition, exchange scheme, evaluation procedure
To come back with an estimate and a stage-by-stage plan rather than a broad range, we need a minimal but concrete set of input data.
A courier app lives at the junction of field devices and the office accounting system — almost all effort is determined by how thoroughly this junction is described.
- Composition of roles and shifts: courier, dispatcher, sorter, shift supervisor — and how orders are handed over between shifts, including night windows.
- Examples of exchange with the accounting system: 3–5 real exports — order, status, cancellation, work order closing. They show the required fields and behavior when the service is unavailable.
- Device constraints: models and operating system versions in the fleet, whether offline mode is needed and for how many hours, whether scanners and label printers are present.
- Data handling rules: where recipients’ personal data is stored, whether delivery confirmation by photo and signature is required.
- Control points and approval procedure: which stages you accept personally — exchange scheme, prototype, build, test environment, release; for each point — an acceptance criterion.
- Decision-making setup: who on the customer side answers questions and within what timeframe — this affects the plan no less than the scope of work.
From this we assemble a stage-by-stage plan with an estimate of effort and explicit assumptions: it is clear what is done at each step and where you accept the result.