By Artem Korsakov ·
Theoretical example. A transport company has 40 regular clients. Every day, managers receive 70–80 calls and messages: "Where is the truck?", "Send me the closing documents", "When is unloading happening?". The manager searches for the answer in 1C (a Russian accounting and ERP platform) and email or asks a dispatcher. The client waits an hour, even though the cargo status was already in the accounting system.
A customer portal eliminates such questions if there is something to show: verified stages and documents. An empty screen with the message "in progress" only adds more calls.
What questions should the account solve?
Start with inquiries from regular clients during a typical working week. Separate requests that require human intervention from those seeking existing information. The question "What stage is my cargo at?" differs from the request "Can I change the recipient?". In the first case, access to verified events is needed; in the second, a decision-making process is required.
Market participants are already combining such functions into customer services. PEC (a Russian freight carrier) describes creating requests, viewing statuses, and obtaining documents. This is a confirmed example of features from a specific carrier. For a small company, it is not necessary to reproduce the entire set: choose those inquiries that are repeated by your clients.
A logistics customer account should be evaluated based on completed actions. Did the user find the current stage, download the necessary file, or submit missing data? The number of open pages and the beauty of a map do not show value on their own.
Where does shipping status come from?
Create a list of events that the company actually records. For example: request received, conditions confirmed, cargo accepted, shipment occurred, arrival confirmed, cargo issued. Each event must have a source, time, and allowable update delay.
If a dispatcher enters an event manually after a call, honestly show "confirmed by dispatcher" and the time. If data comes from a partner system, save its identifier and reception time. Geolocation of the vehicle, if access is available, can be a separate source, but a point on the map itself does not prove cargo handover to the recipient.
It is useful to separate the actual date, plan, and forecast. "Planned delivery October 21" differs from "cargo issued on October 21 at 14:20". In the absence of fresh data, the account shows the last confirmed information and a way to clarify. One cannot create an illusion of continuous monitoring if such a source does not exist.
Partial delivery and multiple executors
Hypothetical example: out of ten items, eight have been delivered, two await the next shipment. For the client, a single status of "delivered" would be incorrect. The model needs shipment parts, their quantity, and separate stages, with a clear summary of the entire order on the screen.
During overload, it is useful to store the link between the original order and stages and executors. However, the client does not necessarily need to see purchase terms or internal contacts. The composition of visible information is determined by the service and agreements. It does not automatically copy from an internal card.
Before development, go through three more cases: partial order cancellation, damage with a separate request, and return. If the first version does not support an operation, the user must see a clear way to transfer it to a manager. Such a transition preserves the order number and the content of the question.
Подпись: Illustrative example. One cell corresponds to one cargo unit; the color shows the confirmed status. The shipment date for the remaining two units is not confirmed.
AI summary of order events
A practical neural network scenario: answer the client's question based only on authorized events and documents of their order. The input is the order number, confirmed history, and question. The model returns a short summary, links to grounds, and a note about missing information. It does not receive arbitrary access to all company shipments.
Hypothetical example. The client asks: "Has everything been delivered?". The data indicates: eight items issued, two are at the terminal, no confirmed date for further shipment. Draft answer: "Eight out of ten items have been issued. Two remain at the terminal. The date for further shipment is not yet confirmed". Events on which the text is based are shown nearby.
Подпись: Illustrative example. The answer is compiled solely from confirmed events of this order. A date not present in the data is not named by the assistant.
In a pilot, an employee checks the summary before sending. After confirmation, the answer is saved in the inquiry and becomes available to the client. Automatic issuance of answers can be discussed separately after verifying accuracy, limiting it to simple questions. Changing the recipient, cancellation, and compensation promises require a different approval route.
Such an assistant should not calculate the arrival date based on general knowledge about routes. If the business needs a forecast, a verifiable calculation source must first be created, and the model explains its result. In case of conflicting sources, the question goes to the responsible person with an indication of the discrepancy.
Requests and documents without extra manual work
For repeat shipments, a "create based on" function is useful. It transfers authorized details, but asks to re-check dates, addresses, and special conditions. An old template should not automatically confirm a new price or vehicle availability.
Files must be linked to a specific order and document type. For the client, name, date, version, and authorized action are shown. An uploaded scan should not be presented as a legally significant electronic exchange completed. Signing and exchanging transport documents are organized through the appropriate electronic document exchange service and operator, and the account can show an available confirmed result.
For a missing document, it is better to provide a request button and the expected next action. A repeated request goes into an existing inquiry and does not create identical tasks for different managers.
Access rights must be checked against complex cases
One user may work on behalf of multiple organizations, and within one organization, there may be different roles. Do not combine them by similar name or single email domain. The company must determine how authority is confirmed, who invites employees, and who revokes access.
The minimum set of checks before launch:
- the user sees only authorized companies and orders;
- direct links to another's card and file do not open;
- a client employee without a financial role does not see closed amounts;
- a former employee loses access, including active sessions;
- the AI summary does not receive documents outside the user's rights.
Checking one interface is not enough. Rights must operate during downloading, searching, exporting, and the assistant's access to data. For sensitive actions, history is saved: who changed the information, when, and on what basis.
Account over existing accounting system?
Check your TMS's ready-made customer service. In the industry transport solution 1C, the customer account is listed among the features. If it solves the task, it makes sense to configure it. A custom add-on is justified by a special interface or an AI scenario that is missing.
Possible integration: authorized events from TMS → account and AI summary → manager check → answer to client. For companies shipping via PEC, there is separately PEC customer account API documentation: it describes obtaining statuses and documents. Connecting any account does not guarantee documentation: rights, access conditions, and required methods must be verified before development. Recording changes requires a separate approved scenario.
What to do if the client sees outdated data?
Separate event time and account update time. If a shipment was unloaded in the morning, but information arrived in the evening, both timestamps are needed for analysis. If exchange stops, show the last successful upload and a button to inquire about the order. An outdated plan cannot be automatically converted into a promise of a new date.
Think through the conflict: the client reports receiving cargo, but in TMS it is still "in transit". The inquiry is linked to the order, the manager checks confirmation and updates the main system. The account should not independently overwrite it based on an external user's words. This is a small but important acceptance scenario: the client received an answer, the discrepancy was closed, and history was preserved.
How to launch and measure benefits?
Start with a small group of regular clients and one type of shipment. The first version may receive data from an approved export or a single integration. Clients must know how often information is updated and where to go in case of discrepancies.
Before launch, count inquiries about status and documents for a comparable number of orders. After launch, measure independent completed actions, repeated inquiries after viewing the account, and manager time on clarifications. For AI, separately record accepted summaries, corrections, and unconfirmed statements.
Reducing calls should not be achieved by making it more difficult for the client to contact the company. Therefore, along with statistics, look at the reasons for repeated questions and complaints about incorrect statuses. These data determine which functions to add next.
Where to start the discussion?
Collect ten typical client questions and show where answers currently reside. On this basis, you can design a small account and assistant based on your data, without promising capabilities for which there is no reliable source yet.
Sources
- PEC: customer account capabilities, description of their own customer service; verified 18 October 2026.
- 1C: industry transport solution capabilities, verified 18 October 2026.
- PEC: customer account API documentation, verified 18 October 2026.
Related reading: International logistics automation: milestones and deviations; Freight document control: completeness, signatures, and payment (Russian).
Частые вопросы ### Is a vehicle map necessary in the first version?
Only if the company has a legal and technically accessible source of coordinates and a clear client task. For many scenarios, reliable stages and documents are more useful. The possibility of connecting a specific source is checked separately.
Can the AI independently change a shipment upon client request?
In the first version, it can analyze the request and prepare a change. An authorized employee checks authority, terms, and consequences. Only after confirmation does the service perform the allowed action and save history.