Courier delivery automation: where to start your rollout

What you actually automate in a courier service

Automating delivery doesn't mean “buy software and hand the couriers phones”. It means making every repeated action stop depending on one person's memory. In a courier service there are five such actions, and together they form a single chain.

• Order intake. Orders come in from the online store, by email, through messengers and from the accounting system. As long as they're pulled into a spreadsheet by hand, some get lost and some get duplicated.
• Assignment to field staff. Who goes, in what order, and whether it all fits into a shift — a decision the dispatcher makes dozens of times a day, and almost always by eye.
• The courier's work at the address. What exactly needs to be done, what to pick up, how to confirm completion — that belongs on the field employee's phone, not in a verbal agreement.
• Keeping the customer informed. The “where is my order” question eats more dispatcher time than it seems, and a status in the customer portal closes it entirely.
• Collecting facts for reporting. Arrival time, visit outcome, photo report — data that is either captured at the moment it happens or doesn't exist at all.

Route planning deserves a separate mention: it's the one stage where manual work isn't merely slower, it's systematically worse. A person sorts addresses by district and intuition; an algorithm computes the visiting order with delivery windows and constraints in mind. The difference shows up right away — in how many stops a field employee gets through in a shift.

Signs that manual dispatching already costs more than software

Not every service needs a system right now. But there is a set of symptoms, and each one stands for real money rather than mere inconvenience.

• The morning goes into planning. If the dispatcher spends an hour and a half or two laying out orders, that's a full salary dissolved into spreadsheets.
• You learn the status of a visit by calling. Every call costs a minute of the dispatcher's time, a minute of the courier's, and a delay out on the route.
• The day's results are gathered in the evening. Which means that during the day the service isn't being managed at all — it's only recording consequences.
• Disputes are settled verbally. “Nobody answered”, “left it with security”, “the client refused” — without a photo and a visit time that's not evidence, neither for the customer nor for an internal review.
• One person is the only holder of the knowledge. When the dispatcher takes a holiday, the service runs worse. That's not about loyalty, it's about there being no rules inside the system.
• Order growth runs straight into headcount. Plus 30% of volume demands plus one dispatcher — which means the process doesn't scale.
• Repeat visits aren't counted. The share of second attempts is unknown, and it feeds directly into your unit cost.

If at least three of these match, this isn't a “someday we'll roll something out” conversation — it's about losses you are taking regularly right now. And the entry barrier is lower than people assume: platforms in this class are built for teams of 5 to 100 field staff, so automation has stopped being a story about large national carriers only.

Where to start: an order of steps that works

The main mistake is trying to switch everything on at once. The order that works follows the life of an order itself: from the moment it appears to a confirmed result. Each next step rests on data produced by the previous one.

• Step 1. A single intake point. Every order lands in one place, whatever channel it came from. While there are several sources, any reporting downstream will be incomplete.
• Step 2. Assignment to field staff. An order gets an owner and a deadline. At this stage the real workload is already visible: whose shift is overloaded and who is sitting idle.
• Step 3. A mobile interface for the field employee. The courier sees the list of addresses, comments and a checklist, marks the outcome and attaches a photo. This is the key step: without it the system stays a pretty picture on the dispatcher's screen and never receives any facts from the route.
• Step 4. Real-time statuses. Routes on a map and the current state of each order remove most of the “where are you” calls.
• Step 5. A customer portal. The client checks the status themselves, and the load on the dispatcher drops another notch.
• Step 6. Route optimization. Once addresses, windows and constraints are already in the system, the visiting-order calculation kicks in — and it runs on sound data rather than on garbage.
• Step 7. Integrations with accounting systems. Exchange with 1C, AmoCRM, Bitrix24 or Excel comes last, so that orders and results aren't retyped by hand.

The first three steps deliver most of the effect and are the fastest to start. In practice a working loop comes together in a week: launch takes 7 days and requires no long-term contracts, so you can test the idea on a single area without rebuilding the whole service.

Mistakes that keep a rollout from sticking

Projects usually fall apart on organization, not on technology. The typical scenarios repeat from one service to the next.

• Double bookkeeping. The system is live, but the spreadsheet keeps going “just to be safe”. A month later the two disagree and neither is trusted. Old record-keeping has to be switched off on the day of the transition, not “once everyone gets used to it”.
• Field staff weren't prepared. The courier was handed access with no explanation of what's in it for them. If the app feels like surveillance instead of a tool, the data will be filled in for show. A simple argument helps: a recorded photo report protects the courier in a dispute.
• Rules that are too complex at the start. Fifteen order statuses and ten mandatory fields guarantee they'll be filled in every other time. Start with the minimum that genuinely gets used.
• Demanding the app be installed on a personal phone. A common point of resistance, especially with piece-rate work. A mobile web interface for field staff takes the question off the table: there's nothing to install.
• Nobody owns the process. A rollout without an owner turns into an optional initiative and fades away in week two.
• Integrations on day one. Wiring up exchange with the accounting system before catalogues and statuses have settled is a reliable way to multiply errors automatically.
• No baseline numbers. If you don't record your current metrics before the start, the argument about the effect will be fought with impressions.

A useful rule: before launch, write down three or four “as is” metrics — stops per shift, share of second attempts, planning time, number of inbound calls about statuses. A month later the comparison takes five minutes.

How to choose a system for your own service

Vendors' feature lists all look alike, so it's better to compare by what happens in your own daily scenario. A few questions worth asking before you sign anything.

• Does the system cover the whole chain? Order intake and dispatch, the field employee's work at the address, statuses for the customer, reporting — if part of it stays in spreadsheets, the gap stays with it.
• What does the courier see and do? List of addresses, checklist, photo report, on-site proof of completion — this screen sets the quality of every piece of data further up the chain.
• Is the route optimization real? Sorting addresses by district and computing a visiting order with delivery windows and constraints in mind are fundamentally different things.
• How does exchange with your systems work? 1C, AmoCRM, Bitrix24, Excel — what matters isn't a logo on the website but which objects travel in which direction.
• How long is the launch, and what are you risking? A week to get started with no long-term contract and a multi-month project with prepayment are very different levels of risk behind identical promises.
• Does the scale fit? Solutions built for hundreds of vehicles are overkill for a service with ten couriers, and the other way round.

All of this is easier to check on your own data than in a presentation: take a typical day, load real addresses and see what comes out. The set of features such a test is assembled from in itlogist — order intake and dispatch, live map routes, a field mobile app with photo reports and checklists, a customer portal with statuses and on-site proof of completed work — is laid out on the Courier management page.

What should change in the first month

The effect of automation shows up in a handful of metrics, not in impressions. If they haven't moved after a month, some of the steps were done for show.

• Planning time. Laying out the day's orders stops being a morning ritual and takes minutes.
• Stops per shift. The main money metric: fixed costs are spread across more completed orders, and the price of each one falls.
• Share of first-attempt visits. It grows on the back of correct windows, address comments and a heads-up to the customer.
• Inbound calls about statuses. They move into the customer portal and real-time statuses.
• How fast disputes are closed. A photo, a visit time and an outcome for every order turn a review into a simple fact check.
• Independence from one particular dispatcher. Assignment rules and order history live in the system, not in somebody's head.

One important nuance: look at the metrics by segment — city and suburbs, large and small orders, different field staff. A single average across the whole flow hides both the failures and the wins. And don't expect a smooth chart in the first two weeks: while people get used to the new routine the data is noisy, and the real picture emerges in weeks three and four.

The practical takeaway is simple: start not with the hardest part but with the place where the data is born — order intake and the field employee's screen. Everything else, including route calculation and exchange with the accounting system, is built on top and works exactly as well as the data underneath it is honest.