How I changed the way 28,000 companies manage rail freight

My core idea was to stop treating documents, tracking, payments and services as separate destinations. The customer’s goal was not to fill in a document or check a status; it was to move a shipment from origin to destination. I introduced Shipment as the central product entity and connected everything needed to complete that job around it.

Each shipment held the route, cargo, wagons and containers, documents, services, money and a timestamped event feed, so users could move through a process without memorising how the railway structured it.

I also cut the status model down to what customers needed. Technical states stayed available for the people who used them; the main interface showed plain names, timestamps and the next action.

With the shipment as the main object, documents, tracking and payments shared one structure, and that model became the standard across the platform.

Clients used to plan routes from their own experience, tips from colleagues and unofficial tariff calculators. I brought route, station and tariff data into one view, so they could compare realistic options side by side.

I labelled the useful trade-offs, such as fastest and cheapest. The bigger change was extra services. They used to sit in catalogues and separate processes, so a customer had to know they existed. I moved them into route planning, where the system knew the origin, destination, cargo and special requirements and could offer the options that fit, such as warehouse pickup or the road leg to the railway. Use of additional services grew by 5%.

The rail charge had one more catch: RZD fixed the final amount after the shipment arrived and the last documents went through. So I showed a calculated price, its breakdown and the costs that could still change, and labelled the whole figure an estimate.

The estimate sat next to the company’s settlement account. If the shipment pushed the company past its allowed debt limit, the product asked the client to contact their RZD manager first.

For complex freight operations, many customers had no practical alternative to a professional legacy system. It was powerful, and it demanded long training and deep domain knowledge. We were building that alternative.

The consignment note showed the gap best. It could hold up to 278 fields across hundreds of scenarios: dangerous goods, export, containers, mixed cargo, extra parties such as insurers or private-track owners, and many rare exceptions.

I regrouped fields by meaning and then by role, showed a conditional section once an answer called for it, and pushed for autofill from every source we could trust. Pick timber, and the system knew the cargo fell outside dangerous goods and dropped that branch. Ship a container inside a wagon, and the flow opened the nested fields at that moment.

Checks ran as early as they could, so nobody went far down an invalid branch. Before signing, users saw a short summary, the check results and a PDF preview. Colleagues could share drafts within the company’s permissions.

The work took almost a year, because rare cases mattered. We launched the waybill once we trusted that it covered the full decision tree.

Many companies shipped the same cargo along the same routes, using almost the same document set each time. With cloning, a recurring shipment meant checking what had changed and signing it.

91% of regular shipments used clone/reuse.

Bulk wagon work followed the same idea. A shipment could involve 1 to 50 wagons, and a company might run hundreds or thousands. Customers could paste a list from their own systems, fix invalid or repeated rows, apply shared values and correct individual exceptions without starting over.

The system knew about a hundred parameters for many wagons and containers. I surfaced single values where they mattered, such as a wagon due for maintenance or an export requirement.