Courier mobile app: features, requirements and rollout

Why couriers need an app — and dispatchers need its data

As long as the job lives on a printed route sheet and contact with the field runs on phone calls and chat messages, the dispatcher has not a single reliable data point about how the day is going. They know they handed out twenty addresses in the morning, and they hear the outcome in the evening — as a retelling. Everything that happened in between gets reconstructed from memory: what time the courier arrived, why they were late, who exactly signed for the order.

A mobile interface for field staff closes precisely that gap, and it solves two different problems at once. For the courier it is a working tool: the day's addresses in the right order, navigation, the recipient's contact details, order contents, amount due and payment method, plus a clear way to record the outcome. For the dispatcher and the manager it is a source of facts: when the shift started, where the person is right now, which addresses are closed, what went wrong and what backs that up.

Hence the first rule of rollout: a tool that only suits the office will never stick in the field. If every delivery takes six taps and three mandatory fields, couriers will start closing jobs in batches at the end of the shift — and you will end up with tidy reports full of unreliable timestamps. You will have data, but no trust in it. Value appears at the point where recording a fact is faster and easier than calling the dispatcher.

The bare minimum of features on the route

Feature lists differ from system to system, but there is a minimum below which the tool will not replace paper and a phone call.

• The shift's jobs in visiting order. Not just a list of addresses, but a sequence with estimated arrival times: the courier should not have to decide for themselves where to go after the third stop.
• A complete order card. Address down to the building and entrance, access notes ("intercom broken, call from the street"), the recipient's phone number, contents, amount and payment method. Every missing field is another call to the office.
• One-tap navigation. A jump into the courier's usual map app straight from the order card, with no copying addresses by hand.
• Clear statuses. On the way, on site, completed, failed with a reason. It is the reasons that give you something to analyse, rather than a bare record that something happened.
• Proof of completion. A photo, the recipient's signature, a comment — whatever settles a delivery dispute before it starts.
• Checklists. A short list of mandatory steps per order type: check the packaging is intact, count the items, collect the return.
• A line to the dispatcher. The ability to flag a problem inside the job itself, not in a private chat where the message gets lost.
• Changes accepted during the day. A new urgent order, a cancellation, a reschedule — the courier should see it immediately, without a round of phone calls.

Worth calling out separately: automatic capture of the time and geotag at the moment a status is set. This is not surveillance for its own sake — without an objective link to place and time, any analysis of delivery times rests on the assumption that staff pressed the buttons diligently, and it falls apart the first time a case is disputed.

Photo proof, signatures and checklists instead of a tick-box

A formal "delivered" mark is worth exactly as much as your trust in that particular courier. Proof works when it cannot be produced without actually being on site, and when a month later you can still reconstruct what happened from it.

What is worth capturing in the field:

• A shot of the handover or the location. The goods at the door, the building entrance, a meter reading or the installed equipment — depending on which disputes actually come up in your business.
• The recipient's signature on screen — wherever you need proof that a specific person took delivery.
• The reason for a failed job. No answer, refused, address not found, recipient absent, rescheduled at the customer's request. Keep the list closed; free text is an addition, never the main answer.
• A record of a return or exchange, if those scenarios exist in your flow.

A checklist solves a different problem — not proof, but error prevention. It turns an experienced employee's tacit knowledge into a short list of steps that is the same for the newcomer and the veteran. The rule is simple: a checklist should only contain items whose omission leads to a repeat visit or a complaint. Everything else is extra taps, and extra taps are why people start ticking the list without reading it.

One point that people remember too late: photos and signatures must be tied to the order and available in the office straight away, not sitting in the phone's gallery until the end of the shift. Otherwise handling a complaint turns into hunting for the right photo among hundreds of others — and the customer simply has to take your word for it.

Installed app or mobile web interface

Technically there are two ways to deliver a tool to field staff, and the choice affects how fast you can launch far more than the feature list does.

A standalone app from the store gives you full access to the device's capabilities and keeps working on a poor connection, but it requires installation, permissions and updates on every single phone. Where some of your couriers are contractors or part-timers and turnover is noticeable, installation becomes a permanent chore: every new person has to be walked through the app store, the login and the setup.

A mobile web interface opens from a link in the phone's browser. The barrier to entry is lower, there is no divergent behaviour across app versions, and updates reach everyone at once. In exchange you have to pay closer attention to what happens without a connection, and to making sure the tab does not get lost between shifts.

A practical rule of thumb: if you have a mixed team, seasonal peaks and frequent rotation, how quickly you can onboard a new courier matters more than the maximum feature set. In itlogist, field staff work in a mobile web interface with photo reports and checklists, with no app installation required, while the dispatcher sees routes on a live map and assigns jobs to people from a single screen — there is more on this on the Courier management page.

Personal phones are a separate question. If staff work from their own devices, agree up front what data is collected, when location tracking is active and what happens to access after someone leaves. That removes half of the objections at the start.

What to test before rollout: connectivity, battery, speed

On a large screen in the office, any interface looks convenient. Conditions in the field are different, and that is exactly where the system has to be tested.

• Behaviour on a poor connection. What happens in an underground car park or a basement: do the records queue up and sync once there is signal, or vanish along with the photo?
• Battery drain. A shift is eight to twelve hours with navigation and the camera running. If the phone dies by lunchtime, the rest of the day comes back to you with no data at all.
• Number of actions per order. Count the taps from opening the order card to marking it complete. Across seventy addresses a week, the difference between three actions and eight stops being a detail.
• One-handed use. A box in one hand, freezing rain outside: large controls and a minimum of mandatory typing are worth more than a rich feature set.
• Photo file size. Images should be compressed on the device, otherwise data usage and upload time become a problem of their own.
• What the customer sees. A status in the client portal removes some of the calls to the dispatch desk — that is time saved in the office, directly.

The test takes a day: give the system to two couriers on a real route and ask them to note every point where they had to call the dispatcher or work around the interface. That list is more honest than any sales demo.

How to roll it out so the tool actually gets used

Pushback at the start almost never comes from the technology — it comes from the feeling that now "everything is visible". You do not talk people out of that; you deal with it by making sure the tool gives the courier something in return: no calls needed to confirm an address, the visiting order already worked out, a disputed delivery backed by a photo rather than the customer's word.

A rollout sequence that works:

• Record your baseline. How many addresses per person per day, what share is delivered on time, how many jobs fail and for which reasons. Without those numbers, "things got better" stays a feeling.
• Clean up your data. Normalised addresses, access notes, current recipient phone numbers: half of the trouble in the field starts with a bad address, not a bad app.
• Launch on part of the flow. One team or one city, two weeks, a short daily feedback round with the couriers.
• Remove the duplication. As soon as records go into the system, the paper route sheet and the chat report have to be cancelled. Two systems of record are worse than one, even when the second one is just a habit.
• Connect your back office. itlogist works with 1C, AmoCRM, Bitrix24 and Excel, so orders come in from the sources you already use without being retyped by hand.

What changes as a result: jobs are assigned to people from a single screen, the visiting order is calculated by an optimisation engine built on OR-Tools that accounts for delivery windows and constraints, completion is confirmed on the spot, and the customer sees statuses in the client portal. Launch takes 7 days with no long-term contract, and the platform is designed for teams of 5 to 100 field staff — so you can test the approach on your live order flow and compare it with your recorded baseline a month later.