Delivery management systems: what types exist and how they differ

What counts as a delivery management system

The label covers fairly different products on the market, so it's worth agreeing on the boundaries first. A delivery management system owns the operational loop — everything that happens between an order appearing and its completion being confirmed out in the field. The typical set of jobs looks like this:

• taking orders in and assigning them to field staff;
• live routes on a map;
• a field mobile app with photo reports and checklists;
• a customer portal with statuses;
• route optimization that accounts for delivery windows and constraints;
• on-site proof that the work was done.

That is what sets it apart from an accounting system or a CRM: those handle money, documents, clients and deals — not where the courier is right now and why they missed the agreed window. In practice the boundaries blur: some of these functions turn up in accounting systems and in standalone mobile services too. So it makes sense to compare solutions not by the category label, but by how much of the order cycle they actually close.

It also helps to understand where the demand for such a product usually comes from. Almost nobody shops for one "for the future" — the trigger is a specific breakdown. The dispatcher stops being able to remember which field employee is where. The client calls before the company even learns the visit has been pushed back. Shift results are pulled together by hand in the evening, and the discrepancies surface the next day. If you know which breakdown you are fixing, the market survey shrinks several times over: most options are eliminated by the very first question about your bottleneck.

Five classes of solutions and the limit of each

Almost every tool used to run delivery today falls into one of five classes. What separates them is not the number of features, but the scale at which the solution stops coping.

• Spreadsheets and messengers. Excel plus a work chat: costs nothing and everyone knows it. The ceiling arrives fast — statuses exist only in the conversation, dispatching is manual, history gets lost, and there is nothing to settle a "delivered or not" dispute with.
• Navigation apps and maps. Good at plotting the drive between stops, but they do not manage orders: they do not assign them to field staff, do not account for windows and constraints, do not record completion and give you no reporting.
• A delivery module in an accounting system or CRM. The data sits right next to the orders, and that is a plus. The weak spot is the field side: comfortable work from a smartphone, photo reports and checklists are usually covered only superficially by such modules.
• Custom in-house development. An exact fit for your process, but you pay for it in timelines, dependence on specific developers and the cost of support every time the process changes.
• Dedicated platforms for managing couriers and field employees. The whole loop — from taking an order to on-site confirmation — lives in one window and connects to your data sources.

itlogist belongs to the last class: it is a management system for couriers and field employees built for teams of 5 to 100 field staff — itlogist features are gathered into a single dispatch loop, including order dispatch, map routes, the field employee's mobile work and statuses for the customer.

Most often, at the start of the search a company is not running one class but a hybrid: orders arrive in the CRM, the order of stops is sketched out in a navigation app, the shift report is assembled in a spreadsheet, and chat messages hold it all together. That setup survives for a long time and even looks free — until you start counting the cost in dispatcher hours and repeat visits. The point of moving to the dedicated class is not to get more features, but to remove the manual seams between tools: the seams are exactly where data gets lost.

Axes of comparison: what to check instead of what to believe

Once the class is chosen, comparison within it comes down to a handful of axes. They hold up well: you can test any product against them at a demo without relying on marketing wording.

• Cycle coverage. Either the system carries an order from intake through to proof of completion, or it closes a single stage and the rest is assembled from several services.
• The field side and the barrier to entry. How easily a field employee can get started. In itlogist that is a mobile web interface with no mandatory app install: the courier opens a link and sees their orders and route.
• Routing. There is a real difference between sorting addresses and genuine optimization. itlogist runs an OR-Tools-based engine that accounts for delivery windows and constraints.
• Integrations. Orders need to reach the system from your usual source: 1C, AmoCRM, Bitrix24 and Excel are supported.
• Transparency for the customer. A portal with statuses takes the flood of "where's my order" calls off the dispatcher.
• Terms of the start. Live in 7 days and no long-term contracts means you can test the system on your own orders instead of running a months-long rollout project.

A tip from practice: compare along these axes using your own orders. A demo data set always looks tidy — your real addresses, windows and reschedules show a system far more honestly.

The axes do not carry equal weight, and the weight is set by your bottleneck. If your time goes on spreading orders across field staff, dispatching and routing are decisive. If most of your friction is disputes over "done or not", the field side with photo reports and checklists moves to the front. If managers are retyping data from one program into another, integrations and the return flow of statuses matter most. Rank the axes by your own priorities in advance — otherwise the comparison drifts into interface details that make no difference to how a shift ends.

What comparison tables never show

"Feature versus feature" tables are handy, but several important things almost never make it into them. And those are what later decide whether the system takes root or becomes a second window nobody opens.

• The return flow of data. Getting an order into the system is easy — the question is whether the result comes back into your accounting: the fact and time of completion, the status, the confirmations. Without a return flow, the manager keeps entering everything by hand.
• Data-entry discipline. The data is entered by the field employee out on site. The more actions the interface demands of them, the poorer and later the data you end up relying on.
• Who owns the reference data. If clients and addresses are created in two places, duplicates will start appearing — the rule has to be set at the start.
• Behaviour on errors. What happens to an order when the address is empty or the client is not found: does it vanish silently or land in a queue for review?
• Promised savings percentages. You cannot compare on those: the effect depends on stop density, the length of the windows and the discipline of your field staff. Test it on your own routes in a pilot.

A practical test at a demo takes five minutes: ask them to run one of your real orders end to end — from the source into the system, onto a field employee, into the mobile interface and back with a status. If the path runs without manual copying, the integration works.

One more line item invisible in tables is the cost of ownership. The license or subscription is only part of the total: on top come configuration for your process, training for dispatchers and field staff, and support every time the rules of work change. Custom development is the trickiest of all here — the build looks like a one-off investment, while support turns out to be permanent and tied to specific people. So in a comparison it is fairer to weigh not the monthly price, but the answer to one question: how long from the decision until an entire shift runs inside the system with no props.

What fits your segment

Requirements diverge noticeably depending on what your people actually do in the field. The same product can cover courier delivery beautifully and miss the mark on field service work.

• Courier delivery. What matters is fast dispatching of a stream of orders, live map routes, statuses and delivery confirmation. Stop density is high, and the priority is processing speed and transparency for the recipient.
• Field service — installation, repair, surveys, maintenance. The visit is long and substantive: checklists, photo reports and on-site proof of completed work count for more than an "arrived" marker.
• Distribution and sales reps. Here you need regular routes across retail outlets, visit monitoring and data collection right there in the field.

Hence a simple rule for shortlisting: if a system was built for one scenario from the outset, it will cover the neighbouring ones only at a stretch. Platforms like itlogist cover all three segments with a single loop — handy when a company runs delivery, field work and field sales at once and does not want to keep three disconnected tools.

Look at the make-up of the team as well. A mixed roster, where some staff are employed and others join for the peak season, brings a requirement of its own: a newcomer has to start working on day one, with nothing to install or configure on their phone. Seasonality adds a second — the ability to run comfortably with five field staff in the off-season and several dozen at peak, without rebuilding the process. The range of 5 to 100 field staff is exactly about teams like these: the system should not break at either the lower or the upper end.

A short algorithm for choosing

Let's fold the overview into a sequence of steps that takes you to a decision without extra rounds of comparison.

• Describe the bottleneck. What exactly eats time right now: manual dispatching, calling field staff round, lost orders or disputed visit results.
• Rule out the wrong class. If you need proof of completion and mobile work in the field, spreadsheets and navigation apps drop out immediately — they do not cover that layer.
• Check the integration with your order source. 1C, a CRM or Excel — orders must reach the system without manual transfer.
• Run a pilot on your own data. One or two real shifts end to end show more than any presentation.
• Assess the terms of entry. A short launch and the absence of long contracts mean the cost of a mistake is low.

The conclusion is simple: you do not pick the "most functional" system, you pick the one where the dispatcher and the field staff work faster than they would with spreadsheets and phone calls — and where data about completed work reaches your accounting by itself.

It is worth setting success criteria for the pilot in advance — otherwise the discussion ends in matters of taste. A reasonable minimum: the dispatcher assembled the shift without calling anyone; the field staff closed their stops with photo proof; the customer could see statuses themselves; the shift result landed in accounting without manual transfer; reschedules and refusals were recorded with a reason instead of staying in the chat. If four of those five hold up in the first week, the class and the product are the right ones. If not, the mistake is almost always in the class of solution rather than in the settings, and you should go back to step one.