Management software for 10 trucks: what changes compared with Excel

In brief

With around ten trucks, the issue is not simply having more rows in the file. At the same time, the following increase:

• orders;
• drivers;
• vehicles;
• phone calls;
• changes;
• documents;
• people who need to know the same status;
• the risk that two decisions overlap.

Excel can remain an excellent tool for analysis and support. It becomes fragile when it is asked to be, at the same time, a database, operational plan, multi-user system, history, communication tool and archive.

Ten trucks are not ‘twice’ five

Assume three average activities per vehicle:

• 5 trucks → around 15 activities;
• 10 trucks → around 30 activities.

But the rise in complexity is not linear. With more vehicles, the following grow:

• intersections between availability;
• substitutions;
• time windows;
• communications;
• opportunities for errors;
• people involved.

If two operators change the plan, the business needs to know which piece of information is the current one.

Excel’s main limitation: operational concurrency

A modern shared spreadsheet can be edited by several people. So the problem is not simply that ‘Excel is not multi-user’. The point is that a generic grid does not automatically manage the meaning of the process.

Example:

• Luca changes the driver on row 38;
• Marta moves the time of the same order;
• the driver receives the change on WhatsApp;
• the customer calls a third colleague;
• someone duplicates the row so as not to lose the old version.

The file may contain everything, but it does not necessarily apply rules about:

• order identity;
• status;
• roles;
• assignments;
• version;
• notifications;
• relationships between entities.

Management software creates structure around the data.

The plan must become a shared state

With ten trucks, the plan cannot be only a graphical representation. It must result from structured objects.

An order should know:

• who the customer is;
• where collection takes place;
• where delivery takes place;
• when;
• which vehicle is assigned;
• which driver is assigned;
• what status it is in;
• which operational changes have occurred;
• which documents are linked, if the system handles them.

The daily plan displays these relationships. It should not be the only place where they exist.

Roles and responsibilities

With a small fleet, everyone may know each other and speak directly. But as work grows, it is useful to define who can do what.

Minimum example:

Operator

• creates/edits orders;
• plans;
• updates operational statuses.

Administration

• consults closed orders;
• retrieves required references and documents;
• does not necessarily change the day’s plan.

Driver

• sees their own activities;
• updates the expected statuses;
• does not see the complete plan or other people’s data unless necessary.

Owner/manager

• sees the overall picture;
• checks indicators;
• manages users/permissions according to the product.

Roles reduce errors and also help respect the principle of access to data according to need.

Managing exceptions without losing the official version

With ten trucks, exceptions are normal:

• loading delay;
• customer closed;
• driver unavailable;
• vehicle in the workshop;
• urgent order;
• change of destination;
• cancellation;
• missing document.

The process must distinguish conversation from decision.

Example:

‘The customer may move it to 17:00’ is a conversation.

‘Unloading at 17:00 confirmed’ is operational data to record in the official source.

If both remain only in a chat, whoever starts the next shift must reconstruct the context by reading messages.

Communication with drivers

More trucks mean more one-to-one communications. A driver system or structured channel can reduce repetitive phone calls.

Useful information:

• sequence of activities;
• addresses;
• contacts;
• times;
• operational notes;
• changes;
• activity status.

The objective is not to eliminate the phone. A complex problem will always require a conversation. The objective is not to use the phone call as a database.

If the app processes personal data or geolocation, GDPR, data-minimisation principles and, where relevant, employment rules on remote monitoring must be assessed. These assessments do not depend on the number of trucks.

Data and reporting that become useful

With ten vehicles, patterns that are difficult to see from memory begin to emerge.

Simple indicators:

Orders by customer

Helps understand commercial dependencies and volumes.

Orders by day/week

Shows peaks and organisational capacity.

Rescheduled activities

If too many activities are moved every day, there may be a problem with initial data, capacity or process.

Exceptions

Classifying a few reasons helps understand whether recurring problems are ‘customer waiting time’, ‘vehicle’, ‘incomplete order’, ‘customer change’, and so on.

Missing documents

If the workflow includes POD/attachments, knowing what is missing avoids searches at the end of the month.

This data does not replace accounting, cost control or regulatory checks, but it improves operational management.

Operational continuity and dependence on people

A very useful question:

If the person who manages the file does not come to work tomorrow, can a colleague understand the day in 10 minutes?

If the answer is no, the company has an organisational risk.

Digitalisation should reduce knowledge that exists ‘only in someone’s head’ through:

• shared master data;
• simple rules;
• shared statuses;
• history;
• individual access;
• minimally documented procedures.

There is no need to create bureaucracy. A few repeatable rules are enough.

When Excel can still remain

Moving to management software does not mean banning Excel.

Excel remains excellent for:

• ad hoc analysis;
• budgets;
• simulations;
• temporary tables;
• reconciliations;
• exports and checks;
• customised reports.

The useful distinction is:

Management software: current operational source. Excel: analysis/support tool.

The problem returns when a manually edited export again becomes the ‘real version’ of the plan.

A 4-week transition plan

Week 1 — mapping and clean-up

• list the processes;
• choose the necessary fields;
• clean up customers and locations;
• clean up drivers and vehicles;
• define a few statuses.

Week 2 — configuration and trial

• import master data;
• create real test orders;
• test changes and cancellations;
• test users and permissions;
• check exports.

Week 3 — pilot group

• 2–3 trucks or part of the operation;
• gather issues;
• correct procedures;
• avoid non-essential customisation.

Week 4 — cutover date

• all new orders enter the new system;
• the old file becomes a temporary operational archive/backup, not a competing source;
• a short daily check for one week.

The timings are illustrative: complexity, integrations and data quality can require much more time.

Checklist: have 10 trucks outgrown Excel?

• Do several people change the plan?
• Are there competing versions?
• Are assignments written as free text?
• Do changes for drivers remain in chats?
• Is it difficult to know which orders are open?
• Is the owner the only person who understands the file?
• Do drivers have to be called for every detail?
• Are roles and permissions missing?
• Does reconstructing history take hours?
• Is there no consistent export/archive by customer?
• Are recurring exceptions not measured?

If many answers are ‘yes’, the problem is not the number 10 itself: complexity has outgrown the structure of the spreadsheet.