How to choose management software for a small transport company

In brief

For a small transport company, the best management software is not the one with the most functions. It is the one that is used every day, reduces manual steps and remains understandable when the owner is not at the computer.

A wrong choice can fail in two ways:

1. software that is too simple and, after a few months, ends up being used alongside Excel and WhatsApp again;
2. software that is too complex and requires so much configuration that operators reject it.

Selection should therefore be a small operational project, not a decision made after a one-hour sales demo.

Start with problems, not functions

Before looking for suppliers, describe the five problems that waste the most time or generate the most risk.

Examples:

• orders arrive through three channels;
• the plan exists only on one person’s PC;
• a change communicated to the driver is not recorded in the file;
• the same address is typed again every day;
• the POD arrives days later and is not linked to the order;
• it is not known which orders are still open;
• it is difficult to understand how much work has been done for each customer.

For each problem, define a simple measure:

“Today we copy each order three times. Objective: enter it only once.”

This sentence is worth more than “we want to digitalise”.

Write 10 requirements before seeing demos

Requirements must be described as activities, not as buzzwords.

Example list

1. Create an order in under two minutes.
2. Reuse customers and locations already entered.
3. See all unplanned orders.
4. Assign truck and driver from the same screen.
5. Move an activity without creating it again.
6. Let the driver see the updated version.
7. Keep a record of who changed the data, where available.
8. Search history by customer/date/reference.
9. Export orders in a readable format.
10. Manage separate accounts for the people who use it.

Then add company-specific requirements: multiple collections, groupage, swap bodies, articulated lorries, customer constraints, documents, Excel import, API, etc.

Test the software with real orders

Do not use only the dataset prepared by the vendor. Take five real cases, removing personal or confidential data that are not needed for the test.

Test:

Case 1 — standard order

One collection, one delivery, one driver, one truck.

Case 2 — change

After assignment, the customer changes the time or address. Check where the change appears and whether the previous version remains reconstructible.

Case 3 — exception

Driver unavailable: how easy is reassignment?

Case 4 — multiple activities

One trip with multiple collections or deliveries, if this is part of actual operations.

Case 5 — closing

Delivery completed, status updated, any document linked, order searchable after one month.

Time the steps. If a function constantly requires the consultant’s intervention to demonstrate it, ask whether the day-to-day operator will be able to use it.

Assess ease of use and adoption

Software is not chosen only for the owner. Involve at least one person who plans and, if there is a driver component, one or two drivers.

Observe:

• do they understand where to start without continual explanations?
• can errors be corrected?
• do field names match the language used in the company?
• does the daily screen show what is actually needed?
• is essential information readable on a phone?
• are too many clicks needed for an activity repeated dozens of times?

A technically powerful feature that no one uses has zero operational value.

Check data ownership, export and portability

One of the most important questions is often overlooked:

If I change software in three years, how do I take my data with me?

Ask in writing:

• which data can be exported;
• in which formats;
• whether export is self-service or requires support;
• whether extraction costs apply;
• whether attachments/documents can be exported;
• how links between the order and attachments are maintained;
• how long data remain available after termination;
• how final deletion takes place.

CSV/XLSX may be sufficient for much tabular data; for more complex systems, API or structured exports may be important.

Avoid a dependency where the company can view the data but cannot retrieve them reasonably.

GDPR: what to ask the supplier

Transport management software may contain names, contact details, driver data, documents and operational information relating to natural persons. The privacy role depends on the service and the actual processing, but in ordinary SaaS services the supplier may act, for various activities, as a processor on behalf of the customer company.

Article 28 of the GDPR governs the relationship between controller and processor and requires processing to be regulated by a contract or other legal act containing the elements required by the regulation.

Before signing, ask for:

• a DPA/data processing agreement;
• a list of, or information mechanism for, sub-processors;
• where data are processed/stored;
• declared security measures;
• management of personal data breaches;
• support for access/deletion requests where applicable;
• rules for return/deletion at the end of the contract;
• retention and backup periods;
• any international transfers and their legal bases.

A page saying “GDPR compliant” is not enough: the information must be consistent with the actual service.

Security, backups and continuity

For a small company, a day without a trip plan can be more serious than many missing functions. Ask how the supplier manages reliability.

Accounts

• individual users;
• password policy;
• MFA where available;
• access revocation;
• roles and permissions.

Backups

• are there backups?
• how often?
• how long are they retained?
• are restoration procedures tested?

Continuity

• is there a status page or channel for incidents?
• what service levels are contractually provided, if any?
• how does work continue if the internet or service is unavailable?

Logs

For important operations, knowing who changed data can reduce disputes and reconstruction time.

An SME does not necessarily have to demand a bank’s architecture, but it must understand whether its operational plan depends on a system without adequate measures.

Read the contract and hidden costs

Check at least:

• minimum term;
• automatic renewal;
• cancellation terms;
• price review arrangements;
• number of users/vehicles included;
• module costs;
• API costs;
• onboarding costs;
• included support;
• SLA, where relevant;
• liability and limitations;
• data export;
• access period after termination;
• conditions for customisation;
• ownership of any bespoke developments.

The question “how much does it cost per month?” is not enough.

Avoid premature customisation

During a demo it is easy to say: “we do it differently; make this change for us”. Ten customisations later, the project becomes costly and difficult to update.

Before requesting bespoke development, distinguish:

Legal/contractual requirement. It must be handled correctly.

Essential operational requirement. Without it, the process does not work.

Habit. “We have always done it this way” is not necessarily a requirement.

Preference. It can be sacrificed if the new process is simpler.

Try the standard product first. Customise only what creates a real advantage or prevents a concrete problem.

Migration plan

A small company should not automatically transfer ten years of messy files.

A simple plan can be:

Phase 1 — clean-up

Remove duplicates and standardise at least customers, locations, drivers and vehicles.

Phase 2 — import

Load master data and, if needed, a limited period of historical orders.

Phase 3 — short parallel trial

Use the new system with a limited group or for a few days, avoiding months of double work.

Phase 4 — cutover date

Set: “from Monday, all new orders start here”.

Phase 5 — archive

Keep the old material in accordance with applicable obligations, but no longer use it as the current plan.

Scorecard for comparing 3 software products

Use a score of 1-5 and assign a weight.

Weights should be adapted. The value of the table is that it prevents a spectacular demo of a secondary function from dominating the choice.

Final checklist

• Did we write down the problems before seeing the products?
• Are there 10 verifiable requirements?
• Did we test real orders?
• Has the person who plans tested the software?
• Have drivers tested the part that concerns them?
• Did we measure the number of steps?
• Can we export data and attachments?
• Have we read the DPA/privacy information and sub-processors?
• Are backups and continuity clear?
• Have we calculated the three-year cost?
• Does the contract explain exit and cancellation?
• Can we start without extensive customisations?
• Is there a concrete migration plan?