Management software for 5 trucks: which functions are really needed

In brief

With five trucks, a small company can still seem ‘manageable from memory’. In reality, five vehicles, five drivers, around twenty orders, two customers changing times and one absence are enough to generate dozens of operational combinations in a single day.

The right management software must not turn the business into a multinational. It must ensure six things:

1. each order exists only once;
2. everyone can see which version is up to date;
3. truck and driver are linked to the activity;
4. a change does not remain confined to a chat;
5. the activity can be closed and found again;
6. the company can retrieve its own data.

If these six conditions work well, for a fleet of five trucks this is already a huge step forward compared with Excel + phone + WhatsApp.

Why 5 trucks are already enough to lose control

Imagine a simple day:

• 5 trucks;
• 5 drivers;
• 3 average activities per vehicle;
• 15 activities in total;
• 2 changed addresses;
• 1 late customer;
• 1 driver finishing later than expected;
• 1 urgent order added at 11:00.

The issue is no longer ‘remembering 15 deliveries’. It is keeping all the relationships consistent:

order ↔ customer ↔ address ↔ time ↔ truck ↔ driver ↔ status ↔ document

If each one lives in a different place, the company depends on the dispatcher’s memory.

The fleet’s minimum operating system

For a fleet of around five trucks, it is useful to think of the software as a shared operational board, not as an ERP.

The minimum areas are:

• customers and locations;
• orders;
• drivers;
• vehicles;
• the day’s plan;
• activity status;
• any attachments;
• history search.

Everything else comes later.

1. Reusable master data

Re-entering the same data every day is a source of errors.

The system should make it possible to save at least:

Customer

• legal business name;
• operational contacts;
• any internal codes;
• genuinely necessary permanent notes.

Collection/delivery location

• full address;
• operational contact if needed;
• recurring time slots/times;
• useful access notes;
• any customer references.

Driver

• name;
• operational contact;
• availability;
• information needed for assignment.

Vehicle

• licence plate or identifier;
• type;
• features needed for planning;
• availability.

However, do not turn master data into an indiscriminate store of personal data. Collect what the process needs and manage separately data/documents that require different protections or purposes.

2. Structured orders

Every transport should have an identifiable record.

Practical fields:

• customer;
• order reference;
• date;
• collection;
• delivery;
• time windows;
• goods/quantity in the necessary information;
• operational instructions;
• any consideration, if the system manages it;
• status;
• relevant notes and attachments.

The record must distinguish permanent information from temporary notes. If ‘unload at gate 3’ always applies to that location, it may be master data. If it applies only today, it belongs to the order.

3. Daily plan

With five trucks, the plan must be readable in a few seconds.

A useful view answers straight away:

• what is still to be assigned?
• what will each truck do?
• who is driving?
• what is the sequence?
• which activities have critical times?
• which ones have changed?
• which ones are completed?

The plan must not try to replace obligations concerning driving times, rest, working time or other regulatory constraints. It must help the operator organise work and make visible the constraints that the company chooses to manage in the process.

4. Linked drivers and vehicles

Writing ‘Mario / 123AB’ in a note is different from actually assigning a driver entity and a vehicle entity.

A structured link makes it possible to:

• see all of a driver’s activities;
• see all of a truck’s activities;
• avoid obvious duplicate assignments;
• change a resource without rewriting the order;
• create a consistent history;
• create useful statistics.

For regulatory checks, however, the company must continue to use the data and systems required by the applicable rules, including the tachograph where required.

5. Communicating changes

The real value appears when something changes.

If the customer moves delivery from 14:00 to 16:00, the ideal process is:

1. the office updates the order;
2. the plan reflects the new information;
3. the driver receives/sees the update in the intended operational channel;
4. the change remains reconstructible if the system keeps history/audit data;
5. two competing versions do not exist.

WhatsApp can still be used for conversations and urgent matters, but it should not be the only archive of the operational decision.

6. Activity status and closure

An SME should define a small number of clear statuses.

Example:

to be planned → planned → assigned → in progress → completed

Add statuses only if they have real operational consequences, such as ‘issue’ or ‘cancelled’.

Too many statuses create confusion. Too few make it impossible to understand what is missing.

The rule is: every status must answer the question ‘what needs to happen next?’.

7. Documents and attachments

Linking a document to the order can avoid endless folders and searches. But it is necessary to distinguish between:

• an operational attachment in the management system;
• a document relevant for tax/legal purposes;
• any digital preservation obligation under the applicable rules.

The fact that a PDF is uploaded to the cloud does not automatically mean that any preservation requirements for that document have been met. For documents subject to specific obligations, the correct process must be checked with advisers and official sources.

What is not necessarily needed at the start

For five trucks, it is not compulsory to start with:

• an advanced optimisation engine;
• carrier tendering;
• a data warehouse;
• complex business intelligence;
• proprietary telematics;
• full accounting;
• dozens of integrations;
• AI-based automation;
• enterprise approval workflows.

If one of these functions solves a real problem, it can make sense. The point is not to buy it because it ‘looks professional’.

A digitised typical day

07:00 — opening

The dispatcher opens the plan and sees:

• 12 activities already planned;
• 2 to assign;
• 1 truck unavailable;
• the day’s operational notes.

08:15 — new order

An email arrives. The operator creates an order using the customer and location already on file.

09:00 — driver change

A driver cannot continue. The activity is reassigned. Everyone sees the new combination.

11:30 — time change

The customer moves the delivery time. The order is updated and the driver receives the new information.

16:30 — closure

Completed activities move to the correct status. Any documents are linked to the trip according to the company process.

End of day

Tomorrow’s plan starts from data that are already structured, not from reconstructing chats.

What data to measure with five trucks

Fifty KPIs are not needed. The following may be enough:

• orders per day/week;
• completed vs open activities;
• orders per customer;
• number of changes/exceptions;
• orders entered manually vs imported;
• missing documents, if managed;
• number of activities per vehicle/driver as operational data, not as a substitute for driving/working-time checks.

If an indicator does not lead to a decision, it can be removed.

Checklist: is the management system proportionate to 5 trucks?

• Can I create an order quickly?
• Are customer and location reusable?
• Can I immediately see unplanned orders?
• Can I assign truck and driver without duplicating data?
• Does a change appear to the person who must carry it out?
• Can I search old orders?
• Can I export the data?
• Do different users have separate accounts?
• Does the system keep a useful history of changes?
• Can documents be linked without confusing archiving with regulatory preservation?
• Can I work without buying unnecessary modules?
• Can staff use it after reasonable training?