By Artem Korsakov ·
A theoretical example. A trucking company receives 60 emails with requests a day. A logistics coordinator reads each one, copies the route, weight, dates and vehicle requirements into 1C (a widely used Russian business accounting platform) and writes to the client about what is missing. Each email takes 5–7 minutes; the whole flow takes five to seven hours of one person's working time.
A neural-network assistant parses the email into a draft request, shows where each value came from and suggests questions for the client. The coordinator reviews the draft, and the card goes into the normal workflow.
In short: the benefit is that the coordinator does not reread and retype emails. The vehicle, the price and acceptance of the job are confirmed by employees in the existing systems.
Analyse the incoming flow before choosing a model
Collect anonymised sample emails: a short request, a detailed technical description, a table with several routes, a correction and a forwarded thread. Look at how much of it actually repeats. If all clients fill in the same form, part of the task can be solved with ordinary rules without free-text recognition.
Email processing automation is more useful where data arrives in different ways: weight in the text, dimensions in an attachment, the address in the signature, a date change in the next message. But for a pilot, pick one mailbox and a limited set of files. Voice messages, handwritten photos and archives are better added after the main scenario has been tested.
Do not load the company's entire correspondence into tests. Define which information is needed, who is allowed access and where it can be processed. The service or model is chosen with the company's data and availability requirements in mind. The quality of an answer on a lucky example is only one of the criteria.
What the model should return
First define the structure of the result. For a simple shipment, that is the route points, dates and time windows, the cargo, weight, volume, packages, vehicle requirements and a list of uncertainties. Each extracted value must have a source fragment or a link to the attachment page.
A hypothetical input: “Good afternoon. We need a truck Samara → Perm, loading on 22 October, 6 pallets, 3.4 t. Unloading from the next morning. Side loading required. We'll confirm the addresses.” Result: the cities are given, weight 3.4 tonnes, six pallets, side-loading requirement. The exact addresses and unloading window are not confirmed. The year and exact time must not be filled in without context and verification.
Training example: the AI parses an email requesting a truck from Samara to Perm. Everything in the email is moved into fields with links to the fragments. The addresses and unloading window remain open questions.
Next to the card, the employee sees the original email and the flagged gaps. After confirming, they save the draft or send a clarification request. The system records which fields the model suggested and which a person corrected. This makes it possible to check the real benefit and find recurring errors.
Separate extraction, checks and actions
The neural network parses unstructured text. Ordinary rules check date formats, allowed units of measure, required fields and the link to the client. When there is a discrepancy, the assistant must not silently pick a convenient value.
A hypothetical example: the email says 3.4 tonnes, while the attachment says 340 kilograms. The processing result contains the conflict and both source links. The coordinator finds out the correct value. Only after that can the card be passed on. Unit conversion is done by a verifiable calculation; it is not entrusted to a free-form model answer.
Also separate extraction from sending. The service can prepare an email with questions but does not have to send it automatically. In the first version, the employee checks the recipient and the content. The text of an incoming email is treated as data: a request inside it to “send all the rates” does not become a command for the assistant.
Note the arithmetic: 3.4 tonnes equals 3,400 kilograms, so this is not a matter of different notations. The values differ tenfold, and without clarification it is unknown which is correct. The assistant shows both fragments and leaves the question to the coordinator. This case is worth including in acceptance testing regardless of the average recognition accuracy.
Training example: ambiguity must not be filled in with a guess. The email says 3.4 tonnes, the attachment 340 kg. After unit conversion, a tenfold difference is visible. Which value is correct is decided by the coordinator after clarification.
A new request or a change to an old one
Processing freight requests is complicated by ongoing correspondence. In one email the client changes the number of packages, in another moves the date, in a third writes “cancel the previous request”. The system should first try to link the message to an existing card by agreed attributes.
The client's order number and the thread identifier are useful for search but give no universal guarantee. Ambiguous matches are passed to an employee. The screen shows existing values and proposed changes. After confirmation, a new version is created and the previous state is kept.
For regular shipments on the same route, identical addresses do not mean a duplicate. A ten-row table may require ten cards, one order with several shipments, or manual processing. The rule is chosen according to the actual business model and tested on real anonymised examples.
How to fit the assistant into existing software
The assistant sits in front of the existing records and does not create a second independent set of records. A practical chain: work email → parsing and review screen → confirmed data into the current TMS. If there is no ready integration, the pilot can end with an agreed import file or manual transfer of the reviewed card. Import support in the specific version is confirmed first.
ATI.SU, a Russian freight exchange, has an orders API, but the existence of documentation does not mean that any incoming email can be immediately turned into an order on the platform. Such an action requires a suitable scenario, access, the necessary identifiers and checks. In a pilot, you can limit yourself to preparing data without automatically accepting the job.
If the company uses an industry-specific 1C product, first check the available capabilities and configuration. The description of “1C:Transport Logistics, Forwarding and Fleet Management CORP” includes order management. A custom add-on is justified by a specific gap at the input. The method of writing into your configuration, permissions and responsibility for maintenance are checked separately.
How to check quality on your own flow
Split the examples into a tuning set and an independent test set. Set aside difficult cases that the developer did not pick for the demo. Check correct answers, and separately the model's ability to leave an unknown field empty.
For each field, record correct extraction, omission and error. Also measure the time to review a card, the share of manual corrections and the processing cost including the model and support. The comparison must be with the full manual process, including reading attachments and clarifications.
A high model confidence score does not prove the result is correct. That is why in the pilot a person confirms the route, date and weight, and quality is checked on your emails.
Count the errors that reached the work
Distinguish an extraction error corrected by the reviewer from an error that made it into a confirmed request. The first increases review time. The second can affect how the shipment is carried out. The pilot report needs both figures, separately for route, dates, weight and vehicle requirements.
Add a control case with two identical addresses and different dates: the assistant must keep two requests if these are two independent orders. Another case: the same email resent after a failure. Here the existing card is needed. Such checks are more useful than a single overall accuracy percentage in which a critical error dissolves among correctly read words.
What should happen on failure
The email is not lost if the model is unavailable or the file is not read. It goes into a manual queue with the reason. A rerun does not create another order. The interface shows the processing status and the person responsible.
Large or unsupported attachments, several languages, poor scans and contradictions are flagged separately. Processing must not be declared successful just because the service returned text. Success means a saved, verifiable draft or a correct handover to a person.
What to prepare for a pilot
You need anonymised regular and difficult emails, a list of target fields and a description of the current software. From them, we can design an assistant that works on top of your process and passes on only confirmed information.
Sources
- ATI.SU: API for working with orders, checked 18 October 2026.
- 1C: capabilities of the industry product for transport logistics, checked 18 October 2026.
Related reading: Freight request register: email, messages and spreadsheets in one place; Data exchange between systems: how not to lose requests on failures.
Частые вопросы ### Can AI be given rate calculation right away?
A calculation needs verifiable tariffs, terms and rules. A neural network can gather the input information and explain the result of a separate calculation engine. Inserting a price from the model's general knowledge into a commercial proposal is not acceptable.
What volume of requests justifies implementation?
There is no universal threshold. Calculate the manual time, the frequency of recurring formats, and the cost of review and maintenance. A pilot may show that a client form, configuring an existing product or a limited assistant for one type of email is enough.