By Artem Korsakov ·
Hypothetical example. On Monday a client emails: 8 pallets from Tula to Kazan, 4.2 tonnes, pickup on Wednesday. On Tuesday the delivery address is changed by phone; on Wednesday morning a messenger message requests adding 4 more pallets. A logistics manager assigned a vehicle based on the first email. The five-ton truck arrives for 8 pallets, but 12 pallets and over six tonnes need to be loaded. All changes occurred across three different channels, but none are reflected in the request card.
A freight request register answers three questions: what the client requested, what the company confirmed, and what is currently happening.
An incoming request is not yet a confirmed shipment
In this article, a request refers to an operational card within the system. It does not replace contractual or transportation documents. Within a company, it is useful to distinguish between a calculation inquiry, a confirmed shipment, and actual execution. A person should see the basis for which a card transitions from one state to another.
ATI.SU (a Russian freight exchange)'s order model provides for separate stages of confirmation and execution. This is how a specific service operates; your order may differ. For your own register, first describe who has the authority to confirm an order and what conditions must be verified by that point.
A request without a precise address is permissible during the preliminary calculation stage. However, assigning an executor to such a card without explicit warning is dangerous. Checks should depend on the stage: the absence of a field may not always prevent saving a draft, but it can block transferring the task to work.
Which Fields Are Actually Needed
Do not start with a multi-screen questionnaire. Take real incoming inquiries and identify the information without which no subsequent decision can be made. For a simple road freight scenario, it is usually worth discussing the following set:
- client number, source, and time of request receipt;
- customer, payer, shipper, and consignee as separate participants;
- route points, contacts, and loading or unloading windows;
- cargo description, number of items, mass, volume, and units of measurement;
- vehicle requirements, loading conditions, temperature control, and additional services;
- responsible party, response deadline, confirmed conditions, and confirming source.
The structure is provided for discussion. For containers, hazardous goods, or oversized cargo, different information and separate professional verification are required. The first version should be limited to the type of transportation the team knows well.
Keep the original email or file next to the card. When an employee is unsure about a value, they open the source and do not search for the message among colleagues. A phone conversation is recorded as a note with the author and time, while significant changes undergo company-established confirmation.
Do Not Mix Client Orders with Shipments
Hypothetical example: a client ordered the shipment of ten pallets. Six went out today, four are scheduled for tomorrow. If a single line contains only one vehicle and the status is "in transit," the register will not explain which part has already moved and what remains to be organized.
Proposed solution: a parent order stores the total volume and conditions, while linked shipments show actual parts. The final status is calculated from them or confirmed by the responsible party according to a clear rule. Remaining cargo must remain visible until the next shipment is assigned.
Reverse case: one vehicle transports orders from multiple clients. In the CARGO.RUN (a Russian logistics platform) guide, this option is considered separately as work with consolidated requests. Do not mechanically transfer the logic of a single direct transportation to all operations. If consolidated shipments are not part of the pilot, the system should explicitly route them for manual processing.
Changes Must Have Versions
Address, mass, rate, time window, and executor may change after the first calculation. Save previous values, author, and reason for change. For fields affecting cost or execution, separately define the need for re-confirmation.
The "edit" button must not erase the fact that a logistics manager has already passed other conditions to the carrier. The list needs an indication of "confirmation of changes required," and a corresponding action appears for the responsible party. A notification is considered processed only when a decision is accepted. Sending an email alone is insufficient.
Closed periods and archive records should be protected from unnoticed editing. Corrections made after completion are executed with a reason and leave a trace. Specific rules for storing and correcting contractual documents are discussed separately with responsible specialists.
How to Handle Duplicates and Cancellations
An identical email subject does not necessarily mean a duplicate: a client may be ordering regular transportation on the same route. Conversely, resending the same request must not create a second order. For finding matches, use a combination of client number, route, dates, and other agreed-upon attributes.
Ambiguous matches should be sent for verification. A person chooses: new request, addition to an existing one, or duplicate. When merging, both sources are preserved. Batch loading from a spreadsheet first shows a preview of errors and only then creates records.
Cancellation is not equal to deletion. It must have an initiator, reason, and time. If confirmation has already been sent to the executor, a separate action is required to modify agreements. The register records the execution of this action but does not determine legal consequences independently.
How to Link the Register with Existing Systems
If an order is already tracked in ATI.SU or a TMS, store its identifier and do not create a second independent status without a synchronization rule. ATI.SU documents order operations via API. The availability of necessary actions and connection conditions are verified in the company account.
The first link can be simple: email → AI draft → logistics confirmation → existing accounting. If work is currently done in Excel, the original spreadsheet can be used as a confirmed source for a pilot. Import requires format validation, duplicate row checks, and change history verification. If the current product already has a convenient register and incoming processing, configure them first; a separate add-on is needed only for specific inconveniences.
What a Logistics Manager Should See in the Morning
The main screen should be built around queues of decisions. "No responsible party," "calculation needed," "vehicle not confirmed," "conditions changed," and "unloading confirmation missing" are more useful than a general list of all time. Each queue must have a responsible party and an exit rule.
A manager needs an overview of workload and stuck cards; a bookkeeper needs their own selection by documents and calculations. Driver contacts and purchase prices should not automatically be displayed to all participants. Permissions are checked both in the interface and when opening a direct link to a record or attachment.
If the register is linked to another program, show the time of the last successful exchange. A transfer error must not be masked by a "saved" status. The user must understand whether information remains only in the register or has already reached the main system.
A general list shows the number of inquiries but hides the reason for waiting. In a sample slice of 25 requests distributed by age and next action, two are in the queue for more than a day: one has no owner, while the other awaits a client. They cannot be corrected with identical notifications. A manager assigns responsibility for the first and checks the last request for the second. Age here is counted from the start of the current wait; the order creation date plays no role. Hours and thresholds are chosen for illustration; working rules are set by the company. AI can suggest a reason based on correspondence with a link to the message. A logistics manager confirms it, while the system calculates time and number of cards based on saved events.
Подпись: A sample slice of 25 requests. Rows show the reason for waiting, columns show how long it has lasted. Two requests have been waiting for more than a day, and their reasons differ.
AI as an Assistant in Creating Cards
A transportation tracking program can use a neural network to parse one incoming email and an attached spreadsheet. The output should include separate fields and a link to the fragment from which the value was taken. A match with an existing request is noted by the assistant as a hypothesis. The decision to merge is made by the logistics manager.
Hypothetical input: "Need to pick up 8 pallets from Tula, 4.2 t, deliver to Kazan. Address and date will be sent separately." Proposed result: eight pallets, mass 4.2 tonnes, cities Tula and Kazan; exact addresses and dates are missing. The card receives the state "clarify data," and an employee sees a list of questions. The service does not turn a city into a fictional warehouse, nor does it treat the inquiry as a confirmed shipment.
After verification, a logistics manager saves a draft or links an email to an existing order. Next, standard rules assign responsibility and the deadline for the next action. For such an assistant, separately check for mixed-up units, multiple routes in one email, corrections in a chain, and files with poor recognition. In case of doubt, the original message remains available for manual processing.
Подпись: Hypothetical example. Everything present in the email is transferred to fields by AI. Addresses and dates remain empty, and the card receives the state "clarify data".
Shift Handover Without Retelling All Orders
Besides status, a card has the next action: who is waiting for an answer, from whom, by what time, and what to do after. Otherwise, a new logistics manager will see dozens of requests "in progress" and start calling colleagues. When handing over a shift, the register shows incomplete actions and critical changes since the last viewing.
Suppose a vehicle is assigned, but the client changed the loading window. The card remains linked to the executor, while a separate task appears nearby to confirm the new window. It can be closed by recording the result and confirmation source. Changing the responsible party does not remove this wait or reset the deadline. Thus, order history works as team memory, which an archive of comments cannot do.
First Version and Checking Utility
For a start, one input method, list, card, filters, mandatory checks, and change log are sufficient. Mass integrations, complex vehicle distribution, and automated tariffs can be discussed after verifying the basic process.
Before launch, measure how much time is spent creating and clarifying a card. After launch, account for correction time as well. Additionally compare the number of requests without an owner, repeated entries, and lost changes. Counting only entry speed is insufficient: a quickly created erroneous request will increase subsequent work.
Next Step
Collect anonymized examples of a standard request, modification, and partial shipment. These can be used to test the register prototype before integrations and understand which fields help work, while others only complicate entry.
Sources
- ATI.SU: API for working with orders, state structure and order operation; verified 18 October 2026.
- CARGO.RUN: platform operation manual, consolidated requests; verified 18 October 2026.
Related reading: AI in logistics: how to turn emails into request drafts; Transport company personal portal: requests, statuses, and documents.
Частые вопросы ### Will a regular table work?
Yes, if there are few users and the workflow remains unchanged. A separate service becomes useful when roles, change history, linked shipments, and different queues are needed. First check which of these requirements actually arise.
Can you automatically fetch all messages from messengers?
This depends on the channel, access permissions, and allowed integration methods. For a first version, it is safer to choose one working source, while adding other inquiries via a form. One cannot promise to connect any personal correspondence without verifying access.