By Artem Korsakov ·
Theoretical example. The owner of a freight forwarding company with 12 logistics managers wants to "automate everything." A one-week breakdown reveals three main time losses: copying requests from email into 1C, collecting documents from carriers via phone calls (Russian), and clients asking for status updates 30 times a day. These are three different products. If you combine them into the promise of "all logistics in one program," the first result will be difficult to verify.
First, determine which business you are automating
For a carrier with its own fleet, key factors are vehicle and driver assignment, transport availability, trip progress, and costs. For a forwarder using subcontractors, the process center may involve confirming the executor, two-sided payments, and a complete set of documents from the carrier. A company with a mixed model must distinguish these scenarios in the order card.
This separation is necessary for design; legally, it does not classify contracts. Before development, ask the manager to analyze two recent shipments: a standard one and a problematic one. Who promised a deadline to the client? Who confirmed the vehicle? Who changed the address? Whose final price approval remains? These answers determine the future interface.
Automating logistics without such an analysis risks creating another place for rewriting data. The manager will receive a beautiful list, but the logistics manager will continue to search for shipment terms in correspondence.
Separate requests, execution, and settlements
The proposed model consists of a client order, specific transportation stages, and financial-document closure. A direct shipment may fit into one stage. With transshipment or multiple executors, more stages will be required. It is not necessary to implement all options immediately, but you cannot lose the connection between them.
Industry products also separate states. In ATI.SU (a Russian freight exchange) documentation, order status and shipment status are described separately. Therefore, marking an "order confirmed" does not mean the vehicle has already loaded. For your system, it is useful to separately define commercial confirmation, physical movement, and document readiness.
Shipment accounting should not be reduced to a single green checkmark. Delivery is complete, but documents are still being checked. The client paid an advance, but settlement with the contractor is not finished. Each of these facts requires its own indicator and source of confirmation.
Choose the first task based on observations
Collect requests and shipments for one standard work cycle. Do not limit yourself to the loudest failures: a task that repeats daily may be more profitable than a rare complex problem. For each candidate, record the volume, manual work time, error consequences, and availability of source data.
Good candidates for a small first version:
- a single registry of incoming requests with a responsible person and response deadline;
- confirmation control for loading and unloading;
- a queue of missing documents for completed shipments;
- a portal for repeat requests from regular clients;
- notifications about changes requiring the logistics manager's decision.
If the main problem is fleet planning, telematics, or calculating the cost of complex routes, study an off-the-shelf TMS (Transportation Management System). A small portal can be connected to it later. Developing an analogue of a large platform for the sake of one inconvenient screen is irrational.
The matrix helps separate a frequent task with ready-made sources from an attractive idea to which there is nothing yet to connect. The position of each process is determined by the team based on its own observations. Analyzing standard requests can become the first product if emails are available and the result is verified by a logistics manager. Frequent document collection with unknown sources first requires an agreement on data. Rare non-standard calculations may remain manual, even if sources are available. The distribution is educational. For your matrix, take specific requests for a work period, mark frequency, source access, and result owner. AI is added where free text needs to be read; statuses and assignments are executed by rules.
Подпись: Educational matrix for team discussion. Process positions are conditional.
Example of pilot boundaries
Hypothetical example: a forwarder receives requests from regular clients via email. The first version collects them into a queue, stores the original message, displays mandatory fields, and reminds about an unconfirmed response deadline. The logistics manager checks the card and manually confirms readiness to work with the request.
The pilot does not include carrier search, reliability checks, legal signing, routing, or automatic price sending to the client. These processes remain where the company currently performs them. The boundary allows testing one hypothesis: is it easier to break down the incoming flow, and are there fewer requests without an owner?
Before launch, agree on one type of shipment, one channel, and one work group. Participants must understand where to turn in case of an error and who can return the card for clarification. Define separately what to do with a request that does not fit the selected scenario.
Add-on over an existing system
If the company already works in a TMS, start with its configuration. For example, "1C: Transportation Logistics, Forwarding and Fleet Management CORP" provides order, trip, and settlement management. These are features of a specific product; another installed "1C" may not have them.
A practical pilot link: email → AI draft and logistics manager check → confirmed card in existing accounting. If write access is not yet available, start with a verified export or manual transfer. Exchange support in your configuration is checked before promising integration. An add-on is justified by a gap at the entry; it should not repeat TMS functions that the company already uses.
Describe exceptions before development
Testing is insufficient with just the standard path "created, assigned, delivered." Add date shifts, vehicle replacement, client refusal, repeated letters, and partial shipments. After a change, the previous version of conditions must be preserved, and it must be clear whether new confirmation is required.
Groupage shipments require special attention: client orders and vehicle movement are linked differently than with direct trips. CARGO.RUN (a Russian logistics platform) guidelines separately consider groupage requests. For your own first version, it is reasonable to either explicitly support such a scenario or honestly exclude it from the pilot and provide a manual route.
An unprocessed exception cannot be silently marked as completed. It must go into the manager's or responsible logistics manager's queue with a reason and next action.
Accesses and data transfer
The dispatcher needs information to execute the shipment. The accountant needs payment agreements and documents. The client needs only permitted information about their orders. If the company works through contractors, the purchase rate and another client's contacts must not accidentally appear in an external portal.
Define the main system for each field. If payments are handled in accounting software, the portal receives a confirmed status from there or shows the responsible person's mark with a date. Free editing of identical data in two places quickly creates discrepancies.
Data exchange requires an error log, protection against duplicate record creation, and a clear manual retry. Check the export separately: the business must be able to obtain its requests and attachments when switching solutions.
Where neural networks help in the first product
For the selected pilot, you can add an assistant for analyzing requests. The input is a new email and the associated card. The model extracts the route, deadlines, and conditions, compares them with current values, and returns a list of proposed changes. Standard rules check mandatory fields and permissible units, and the logistics manager accepts or rejects each change.
Hypothetical input example: "Regarding our request 417, move loading to Friday, everything else unchanged." The assistant's result: number 417, date change proposed, exact date requires clarification, other fields unchanged. If there is no unambiguous date or time zone in the correspondence, the assistant does not substitute them by guesswork.
Подпись: Illustrative example. AI proposes a change and shows an email fragment. The logistics manager clarifies the exact date; the system saves the new version of conditions.
The screen shows an email fragment next to the proposal. After employee confirmation, the service saves the new version and assigns a task for re-confirmation if required by your process. A letter to the counterparty goes out only according to an accepted rule and after the specified confirmation. Such AI application is verified on a specific set of requests: how many fields were proposed correctly, how many corrected, and how much time verification took.
When development is not yet needed
If requests are lost due to the absence of a duty officer, first assign a responsible person and shift handover rules. If necessary fields already exist in the TMS but no one fills them, find out why: inconvenient screen, extra steps, or lack of next action. A new program will reproduce the problem if the workflow remains unchanged.
A short card is useful for a pilot decision: what action repeats, where the data are located, who confirms the result, and how it enters the working system. If at least one point is unknown, start with process analysis. If all four are clear, you can show a prototype on your requests and evaluate the specific volume of work.
How to verify results without promises of payback
Before launch, measure the processing time for comparable requests, the number of re-entries, and requests without a responsible person. After launch, repeat the measurement on a similar work composition. Additionally account for time to correct cards, training, and support.
Average time is useful supplemented by median and analysis of the longest cases: several exceptions can hide the usual picture. Fix the continuation criteria in advance. For example, the team uses a queue without a parallel mandatory list, data is saved correctly, and total processing time decreased. The numerical threshold is chosen by the company according to its own economics.
When there are not enough vehicles
In a historical Russian-market example from late August 2026, the ATI.SU rate index updated the record: 2,281 points, plus 33% from the beginning of the year and 7.4% for the last week. The ATI.SU balance indicator of cargo and vehicles showed +73, close to the annual maximum: there is a shortage of vehicles. For a forwarder working in that market, this meant finding a vehicle took more time, and the carrier's rate changes over several days.
In such a situation, automation is useful for speed of response to the client and rate control. AI can collect from correspondence the reasons why requests did not reach shipment: vehicle not found, client did not accept rate, data not clarified. The logistics manager checks the formulations, and the system counts time and shares by events. Specific improvements are chosen based on this data. General words about a crisis do not justify implementation.
The pilot should be evaluated in both calm and tense modes: replacing an executor, urgent recalculation, absence of an employee. There must be clear manual processing and a responsible person for exceptions. If the new tool requires a constant separate operator, this must be included in the assessment of its benefit and costs.
What to prepare for discussion
Show several anonymized requests, a standard and problematic shipment, the current table, and the list of systems. This is enough to discuss a small digital product for your process and define a verifiable first version.
Sources
- ATI.SU: API for working with orders, active documentation, verified 18 October 2026.
- CARGO.RUN: platform operating instructions, description of groupage requests; verified 18 October 2026.
- 1C: features of an industry transport solution, verified 18 October 2026.
- ATI.SU: freight rates updated the record, 31 August 2026; verified 19 October 2026.
Related reading: Freight request accounting: email, messages, and tables in one place; International shipment budget: expense and margin forecast en route.
Частые вопросы ### Can I start if I already have 1C or CRM?
Yes. First, find a specific gap between the existing system and people's work. Perhaps it is enough to configure its capabilities. A separate service is justified when a different interface or scenario is needed, and data transfer can be reliably organized.
Is it necessary to implement AI immediately?
For responsible parties, statuses, and reminders, standard verifiable logic is used. Neural networks add value at unstructured inputs: they parse emails and extract changes. In the pilot, these parts work together, and the result is confirmed by an employee.