The Operating System for the Carrier: Turning a Fragmented Transport Business into One Coherent System

There is a particular moment in the life of almost every growing carrier.

At first, everything is simple.

The owner has a few trucks. He knows the drivers personally. He knows where the vehicles are. He knows which customer is waiting for a load. He knows roughly how much fuel costs and when a particular truck needs service.

Then the business grows.

There are ten trucks.

Then thirty.

Then fifty.

Suddenly the owner no longer sees the business itself. He sees fragments of it. Loads are in one place. Vehicles are in another. Documents are somewhere else. Fuel is recorded separately. Maintenance has its own history. Tires have their own story. Leasing payments sit in accounting. GPS produces another stream of information.

And at the end of the month there is a familiar question:

We moved millions of rubles through the company. But how much did we actually earn?

This is the problem we are addressing.

We are building an operating platform for the carrier — a system that brings the commercial, operational, fleet and economic sides of the transport business into one coherent model.

Its purpose is not simply to automate individual tasks.

It is to help the carrier understand and operate the business as a whole.

The carrier is one business, not ten software modules

Today, a carrier may use one system for finding loads, another for GPS, another for electronic documents, accounting software for money, spreadsheets for fleet costs and messaging applications for everyday coordination.

Each tool may work perfectly well.

The problem appears between them.

A load becomes a trip.

The trip uses a particular truck.

The truck consumes fuel.

The driver performs the trip.

The vehicle accumulates kilometers.

The kilometers create wear.

Wear creates maintenance.

Maintenance creates costs and downtime.

The trip creates revenue.

Revenue and costs together create margin.

The customer eventually pays.

All of these events belong to one economic story.

The carrier, however, often experiences them as separate pieces of information.

Our approach starts from a different principle:

The software should represent the business first, and the individual functions second.

This is the application of our broader enterprise-design approach to transportation.

Instead of asking:

“What modules does a transport company need?”

we ask:

“What actually exists in the business, how are these things connected, and how does the business create economic value?”

The answer gives us the structure of the product.

Start with the reality of the enterprise

A carrier has:

• an enterprise;
• people;
• roles;
• vehicles;
• trailers;
• customers;
• suppliers;
• loads;
• orders;
• routes;
• trips;
• drivers;
• facilities;
• documents;
• fuel;
• tires;
• maintenance;
• insurance;
• financing;
• expenses;
• revenue;
• payments;
• operational events;
• risks;
• capacity.

These are not merely database tables.

They are the actual objects that make up the business.

And they are connected.

A company owns vehicles.

A company employs people.

A driver operates a vehicle.

A customer creates an order.

An order concerns a load.

An order becomes a trip.

A trip uses a vehicle and a driver.

A trip follows a route.

A trip creates kilometers.

Kilometers create operating costs.

The trip creates revenue.

Revenue minus cost produces economic result.

Once these relationships are represented explicitly, something important happens. The system stops being a collection of screens.

It becomes a model of the carrier's business.

The central object: the trip

There are many important things in transportation.

But operationally, they come together in one place:

the trip.

A trip connects:

Order → Cargo → Vehicle → Driver → Route → Documents → Execution → Costs → Revenue → Margin

Before the trip begins, we have a plan.

During the trip, we collect facts.

After the trip, we know the result.

This gives the platform a natural operational lifecycle:

Opportunity → Load discovered → Order created → Order accepted → Trip planned → Vehicle assigned → Driver assigned → Documents prepared → Loading → In transit → Delivery → Documents completed → Trip closed → Settlement → Payment

But this operational lifecycle has another one running alongside it:

Planned economics → Actual kilometers → Actual fuel → Actual expenses → Actual cost → Revenue → Margin → Deviation from plan → Learning

That second lifecycle is what makes the system fundamentally different.

The platform does not only know what happened.

It knows what happened economically.

The vehicle has a life of its own

A carrier does not simply operate trips.

It operates assets.

And those assets consume enormous amounts of money.

A truck has:

• acquisition or leasing costs;
• fuel;
• tires;
• maintenance;
• repairs;
• spare parts;
• insurance;
• depreciation;
• downtime;
• driver costs.

Therefore fleet management cannot be treated as a separate GPS function.

We want to connect fleet management directly to the economics of transportation.

A truck has a history.

It accumulates kilometers.

It consumes fuel.

It wears tires.

It enters service.

It leaves service.

It experiences failures.

It spends time idle.

It performs profitable and unprofitable trips.

Its economic performance changes over time.

The platform should preserve this entire history.

That means the fleet manager can ask not simply:

“Where is truck 184?”

but:

“What does truck 184 cost me per kilometer, why does it cost that much, and is its current operation economically healthy?”

That is a much more powerful question.

The kilometer becomes the bridge between operations and economics

This is where our approach leads to a particularly important idea.

The truck is a production asset.

The trip is a production operation.

But the kilometer is a fundamental economic unit of movement.

Every kilometer carries some combination of:

• fuel cost;
• tire cost;
• maintenance cost;
• financing cost;
• depreciation;
• driver cost;
• insurance;
• road costs;
• overhead;
• other operating expenses.

So the platform must be able to construct the real cost of movement.

Not just:

Fuel: 34,000 ₽

but:

What did the 820 kilometers of this trip actually cost the company?

And not just for one trip.

For the vehicle.

For the route.

For the customer.

For the type of cargo.

For the month.

For the entire fleet.

This transforms the platform from a transport management tool into an economic management system for the carrier.

The system follows the money and the machine at the same time

Imagine a carrier receives a Moscow–St Petersburg order.

The system creates a trip.

A suitable vehicle is assigned.

A driver is assigned.

The route is planned.

The expected mileage is calculated.

The expected fuel consumption is estimated.

The current vehicle condition is considered.

The expected cost is calculated.

The expected revenue is already known.

So before the truck moves, the carrier can see an economic picture.

Then the trip begins.

Actual mileage arrives.

Fuel transactions arrive.

GPS provides movement data.

Documents are completed.

Additional expenses appear.

Perhaps there is waiting time.

Perhaps the vehicle takes a detour.

Perhaps the return trip is empty.

Perhaps the truck requires an unexpected repair afterward.

The system records these facts against the same business object.

When the trip closes, the carrier does not receive a collection of unrelated reports.

He receives the economic history of the trip.

Plan versus fact.

And that difference becomes valuable knowledge.

What happened to the kilometer?

This is one of the questions we want the platform to answer continuously.

Suppose two trucks completed the same route.

Their revenue was almost identical.

But one generated significantly more margin.

Why?

Perhaps it consumed less fuel.

Perhaps its tires had better economics.

Perhaps it had lower maintenance costs.

Perhaps it had fewer empty kilometers.

Perhaps it spent less time waiting.

Perhaps its financing burden was lower.

Perhaps the driver operated differently.

Perhaps the vehicle was simply better suited to that route.

The system should not force the manager to discover this manually by opening five different reports.

The relationships should already exist.

That is the practical value of the underlying model.

The platform creates one economic history

One of the most important ideas in the system is that information should not disappear into departmental silos.

A fuel transaction should be connected to a vehicle.

The vehicle should be connected to its trips.

The trips should be connected to their kilometers.

The kilometers should be connected to revenue and costs.

A maintenance event should be connected to the vehicle.

The vehicle's downtime should affect its operational availability.

Its availability should affect its ability to perform trips.

The trips should affect the company's revenue.

The revenue should ultimately meet the costs.

The platform therefore creates a continuous chain:

Enterprise → Fleet → Vehicle → Trip → Kilometer → Cost → Revenue → Margin

This chain is the economic backbone of the system.

Maintenance becomes part of business management

Consider a simple example.

A truck has a maintenance event costing 85,000 ₽.

Traditional fleet software records the event.

Our system should go further.

It knows:

• which vehicle received the service;
• what was repaired;
• how many kilometers the vehicle had travelled;
• which components were replaced;
• how much downtime occurred;
• what trips were affected;
• what the vehicle's cost per kilometer was before the event;
• what it became afterward.

Over time, the company develops its own operational knowledge.

It may discover that a particular vehicle has unusually high maintenance costs.

Or that a particular component fails earlier than expected.

Or that preventive maintenance costs less than repeated emergency repairs.

Or that a particular vehicle becomes economically unattractive after a certain mileage.

The platform does not need to prescribe the answer.

It makes the relationship visible.

Tires become economics

The same principle applies to tires.

A tire is not just an inventory item.

It has:

purchase price → installation → mileage → wear → replacement → cost per kilometer

That is a complete economic lifecycle.

The platform can therefore answer questions such as:

• Which tires provide the lowest cost per kilometer?
• Which vehicles consume tires faster?
• How does route type affect tire life?
• How much did tires contribute to vehicle cost this year?
• Which maintenance practices extend tire life?

The important thing is not the individual report.

It is the connection between the events.

Fuel becomes intelligence

Fuel follows the same logic.

The system knows:

• vehicle;
• date;
• location;
• fuel quantity;
• price;
• mileage;
• route;
• load;
• driver;
• operating conditions.

Over time, this creates a real operational picture.

The carrier can compare actual consumption with expected consumption.

And more importantly, fuel becomes part of the complete cost-per-kilometer calculation.

The question is no longer simply:

“How much did we spend on fuel?”

It becomes:

“How did fuel affect the economics of our transportation?”

The system also understands fixed costs

Leasing is another example.

A monthly leasing payment does not disappear when a truck stands still.

Therefore utilization matters.

If a vehicle runs too few economically useful kilometers, fixed costs are distributed over a smaller production volume.

This is why the platform needs to connect:

leasing → vehicle → availability → mileage → trips → revenue → cost per kilometer

The same principle applies to insurance and other fixed or semi-fixed expenses.

The result is a much more realistic picture of the economics of the asset.

The carrier can finally see the whole machine

When these relationships are combined, the owner can begin asking questions that were previously difficult to answer.

Which truck is actually profitable?

Which one only produces revenue?

Which route gives us good margins?

Which customer looks attractive by revenue but is poor economically?

How much does empty mileage cost us?

What is the effect of downtime?

How much does maintenance contribute to the cost of a kilometer?

How many kilometers should this vehicle economically run each month?

Which vehicles should receive investment?

Which should be replaced?

Which loads should we accept?

Which ones should we reject?

The platform turns these questions into normal management questions.

This is where our approach becomes visible in the product

The application of our enterprise-design methodology is not something the customer needs to see.

They do not need to know that we started by designing an ontology.

They simply experience the consequences.

They see one business.

They see one operational history.

They see consistent relationships.

They enter information once.

They find it where it logically belongs.

They can move from:

Customer → Order → Trip → Vehicle → Cost → Margin

without losing context.

They can move from:

Vehicle → Maintenance → Mileage → Cost

without reconstructing the history manually.

They can move from:

Expense → Vehicle → Trip → Customer

and understand where the money went.

That coherence is the product.

From modules to a system

Traditional software design often begins with modules:

Fleet.

Orders.

Accounting.

GPS.

Maintenance.

Documents.

Analytics.

Each module then develops its own data and workflows.

Our approach begins from the enterprise.

The modules emerge around the relationships.

This produces a different architecture.

The same vehicle is not “a fleet object” in one place and “an accounting object” somewhere else.

It is the same vehicle.

The same trip is not one object in dispatch and another in finance.

It is the same trip.

The same expense is not merely a financial transaction.

It is a fact about the operation of the enterprise.

This sounds like a technical distinction.

In practice, it creates something much more important:

one version of reality.

One carrier. One model.

A carrier with three trucks and a carrier with seven hundred do not need fundamentally different business models.

They have different scale.

The three-truck company may have one person performing five roles.

The seven-hundred-truck company may have hundreds of employees performing specialized roles.

But underneath, the same objects exist.

The same relationships exist.

The same economic logic exists.

This is why our system can grow with the carrier.

At three trucks, the owner may use it himself.

At thirty, dispatchers and mechanics become separate users.

At three hundred, departments and regional structures emerge.

At seven hundred, management needs consolidated analytics.

But the underlying model remains intact.

The system should make complexity manageable, not hide it

Transportation is inherently complex.

There are too many variables to eliminate.

The goal is not to pretend that the business is simple.

The goal is to organize its complexity.

That is why we distinguish between:

Operate

Run the company.

Manage customers, loads, orders, vehicles, drivers, trips, documents and payments.

Maintain

Keep the production assets healthy.

Manage fuel, tires, maintenance, repairs, insurance, leasing and availability.

Understand

See what is happening.

Understand costs, margins, mileage, utilization, downtime, customers and routes.

Decide

Choose what to do next.

Which load to accept.

Which vehicle to assign.

When to service.

Where to look for a return load.

Where the business is losing money.

Learn

Use the history.

Compare plan and fact.

Understand patterns.

Improve future decisions.

These are not separate products.

They are different levels of the same operating system.

And eventually the system can begin to think with the carrier

Once the company has a structured history, AI becomes much more useful.

The AI is no longer looking at a blank conversation.

It understands the enterprise.

It knows the vehicles.

It knows their history.

It knows the routes.

It knows the costs.

It knows the customers.

It knows the completed trips.

It knows the current operational state.

Then the conversation can become practical.

“Should I take this Moscow–St Petersburg load?”

The system might answer:

Revenue is 180,000 ₽.

Estimated total mileage is 820 km.

Expected empty mileage is 120 km.

Vehicle 24 has above-average fuel consumption on this route.

Its next scheduled service is due in 1,200 km.

Expected trip cost is 112,000 ₽.

Expected margin is 68,000 ₽.

Two alternative vehicles have lower historical cost per kilometer.

Now AI is not generating generic advice.

It is reasoning over the carrier's actual operating model.

But intelligence comes after discipline

We deliberately do not begin with the AI.

We begin with reality.

First:

What exists?

Then:

How is it connected?

Then:

What happens?

Then:

What does it cost?

Then:

What happened in reality?

Then:

What can we learn?

And only then:

What should we do next?

This order matters.

Good intelligence requires good memory.

Good memory requires structured operations.

Structured operations require a coherent model of the enterprise.

The first product is therefore much simpler than the final vision

We do not need to solve the entire transportation market on day one.

The first version can do something very valuable.

A carrier creates its company.

Adds its fleet.

Adds drivers.

Connects its sources of loads.

Creates and manages orders.

Turns orders into trips.

Plans and executes trips.

Manages documents.

Records fuel and expenses.

Tracks maintenance and tires.

Records revenue and payments.

And at the end:

sees the real economics of the business.

Especially the economics of the vehicle.

Especially the economics of the kilometer.

That is enough to create the foundation.

From one carrier to a network

The long-term opportunity begins after the individual carrier is organized.

Imagine thousands of independent carriers, each operating independently, but each producing structured operational data.

The platform can eventually see patterns that no individual carrier can see alone.

Where capacity is available.

Where empty kilometers accumulate.

Which routes are becoming expensive.

Where demand is growing.

How actual costs are changing.

Which lanes are consistently attractive.

Where delays occur.

Where capacity is structurally insufficient.

This does not require centralizing the carriers.

Quite the opposite.

The carriers remain independent.

But the industry gains a digital layer through which its distributed activity becomes more visible.

From software to industrial infrastructure

That is ultimately what we are building.

Not another application for dispatchers.

Not another GPS system.

Not simply another TMS.

Not another marketplace.

We are building an operating layer for the carrier enterprise.

A layer that connects:

market → commercial opportunity → order → trip → vehicle → driver → route → documents → kilometers → fuel → tires → maintenance → financing → cost → revenue → margin → decision → learning

This is the carrier as a coherent system.

The bigger idea

There is something larger behind this product.

Small carriers already possess the trucks.

They already possess the drivers.

They already possess the experience.

They already possess customer relationships.

They already possess enormous amounts of operational knowledge.

What many of them lack is a system that brings these resources together into a clear operating model.

We want to provide that model.

So that a company with three trucks can operate with the discipline and visibility of a much larger organization.

So that a company with thirty trucks can scale without losing control.

So that a company with seven hundred trucks can manage complexity without fragmenting its operational knowledge.

And so that, over time, the accumulated operational history of many independent carriers can create a new layer of intelligence for the industry.

The promise

The promise is not:

“We will give you more software.”

It is:

We will help you see and manage your transport business as one system.

You will know where your vehicles are.

What they are doing.

What they cost.

What they earn.

What each trip produces.

What each kilometer costs.

Where money is being lost.

Where money is being made.

And, increasingly, what decision should come next.

Because in the end, the carrier's business is not about moving trucks around a map.

It is about transforming:

vehicles + people + kilometers + capital + fuel + time

into:

reliable transportation and sustainable economic value.

That is the system we are building.

And the idea at its center is remarkably simple:

A carrier wins when it can consistently produce transportation at a cost that leaves room for a healthy margin.

Our job is to make that economics visible, manageable and increasingly intelligent.

Three trucks or seven hundred.
One enterprise.
One operating model.
One economic history.
One system.