What to look for in a TMS demo before you buy
A practical guide to judging a transport software demo for UK haulage: jobs, POD, invoicing, container work, setup and day-to-day use.
If you are sitting through a transport software demo, do not judge it by the polish of the presenter. Judge it by whether it matches the jobs that actually land on your desk at six in the morning. A good TMS demo should show how the system deals with late changes, missing POD, waiting time, driver calls, container deadlines, and the gap between a job being done and the invoice going out. If it cannot show that clearly, it is not ready for a UK haulage or container operation.
The easiest way to test a demo is simple. Ask them to run one real-world job from start to finish, then push it off the happy path. Add a late collection, a missed slot, a backload, a subcontractor, or demurrage. Ask what the driver sees. Ask how the invoice gets raised. Ask what you have to set up before any of that works. That tells you far more than a slide deck ever will.
Start with your own working day, not the sales script, how to judge a demo against the actual problems a UK haulage or container operator deals with each day
Most demos are built around the cleanest possible version of the job. A booking arrives in a tidy format. The planner has complete information. The driver follows the plan. The POD comes back instantly. The invoice goes out without a chase. That is not the working day in most haulage firms.
A better way to judge a transport software demo is to start with your own routine. Think about the jobs and interruptions that actually cost you time.
For many operators, that means things like:
- jobs arriving by phone, email and WhatsApp
- collection references missing from the booking
- a driver asking for the address again because it was buried in a message thread
- POD stuck in the cab or unreadable in a photo
- an invoice waiting because nobody knows whether the customer will accept a charge for waiting time
- container work where the box status changes twice before lunch
- a subcontractor doing the job, but the customer still expecting updates from your office
- jobs that are finished operationally, but not finished administratively
So in the demo, ask to see how a job is entered when the information is incomplete. Ask what happens when details are updated after the job is already allocated. Ask how the office sees what is still missing before invoicing. Ask what the system does to reduce phone calls, not just record them afterwards.
This is where a proper TMS should be practical. It should help the planner and traffic office get a job into the system quickly, update it without creating a mess, brief the driver clearly, and keep the commercial side moving while the operation is still busy. If the demo spends twenty minutes on dashboard colours and two minutes on POD and invoicing, it is focused on the wrong problem.
For UK operators, also pay attention to whether the system reflects our paperwork and compliance reality. You are not just running loads, you are running a business under an O-licence. That means records matter. It also means the office often needs simple answers quickly, such as which jobs were done, which are still waiting for POD, which are ready to bill, and which were covered by a subcontractor. A demo should make those answers easy to find.
If you want a clearer view of what that looks like in daily use, our page on transport management for haulage and container operators shows the operational side we focus on.
See one job run from booking through to invoice, what a proper demo should show across planning, driver briefing, POD capture and getting the invoice out
The single best test of any transport software demo is to ask for one complete job journey.
Not a list of features. Not separate screens explained in isolation. One job, from the first booking to the final invoice.
That demo should include at least these stages.
First, the booking goes in. You should see how quickly the office can create the job, what fields are required, what can be added later, and how the traffic office avoids retyping the same information. If the process is slow in the demo, it will be slower on a busy morning.
Second, the job is planned. The presenter should show how the planner allocates the work, changes the allocation, and sees the status of the day. If you run mixed work, ask them to show a normal delivery and then a timed job or a collection with a strict slot. You want to know whether the plan can be changed without losing control of the detail.
Third, the driver is briefed. This matters more than many demos admit. A lot of avoidable phone calls happen because the office and driver are not looking at the same job information. In a proper demo, you should see exactly what the driver receives, including addresses, references, notes, timings, and any special instructions. If that part is vague, the demo is hiding a weakness.
Fourth, the job is completed and the POD comes back. This is where many firms lose time and cash. The software should show how the driver returns ePOD, how the office checks it, and how the job moves from done in the yard to ready to invoice in the office. If the system still leaves somebody chasing images from a phone gallery at the end of the week, it has not solved the problem.
Fifth, the invoice is raised. Do not accept a hand-wave here. Ask them to show the exact step from completed job to invoice-ready status. Ask what stops the invoice going out. Ask how extra charges are added. Ask whether finance has to wait for somebody in traffic to confirm that all documents are present. This is often the point where software either saves time or simply moves the delay to a different screen.
We built Logivo around that gap between the job finishing and the invoice going out. If that is one of the problems you are trying to fix, our articles on transport software that stops jobs waiting for invoices and haulage software that stops PODs holding up invoices go into that part in more detail.
A proper demo should also show exceptions. Ask what happens if the POD is missing. Ask what happens if the driver records waiting time. Ask what happens if the customer rate changes after the job is already in the system. If the answer is that somebody exports it and fixes it elsewhere, you need to know that before you buy.
Check how it handles container work and awkward jobs, whether the system can cope with demurrage, container turnaround, waiting time, backload and subcontractor jobs
Container work exposes weak software very quickly.
A general haulage demo can look convincing until you ask about import collections, export bookings, box numbers, quay references, changing slots, and charges that only become clear after the movement. If you do container work, your transport software demo should cover container jobs specifically, not as an afterthought.
Start with the basics. Ask how the system records the container number, booking references, collection and delivery points, and relevant notes for the driver. Then ask how it handles changes. In container transport, details often move during the life of the job. If a demo only works when everything is fixed from the start, it is not reflecting reality.
Then move to the awkward bits that affect margin.
Ask how demurrage is recorded and charged. Ask whether container turnaround can be tracked clearly enough for the office to know which jobs need attention. Ask how waiting time is captured and approved for billing. Ask how a backload is linked to the same vehicle movement, rather than treated as an unrelated job with no operational context.
These are not edge cases. They are normal commercial details that decide whether the week was profitable.
The same applies to subcontractor work. Many operators need to pass jobs out at busy times, for distance, or because a vehicle is tied up elsewhere. In the demo, ask how a subcontractor job is created, tracked, costed and invoiced. Ask whether the customer-facing side stays under your control. Ask whether the system distinguishes clearly between your own fleet work and outsourced work when you come to review margin.
A good demo should show awkward jobs without becoming awkward itself. If the presenter needs to explain that container jobs are possible with a workaround, or that waiting time is handled in notes, or that subcontractor costs are dealt with later in accounts, that is a warning sign. Workarounds are exactly what most operators are trying to escape.
For firms that do container transport regularly, we have set out the main operational requirements on our page about software for container transport operations.
Ask what the driver actually sees and does, how drivers receive work, return ePOD and update the office without adding more phone calls
A lot of software is bought by the office and then judged by the driver. If the driver side is clumsy, the office pays for it in calls, missed updates and missing POD.
So during a transport software demo, ask to see the driver workflow properly. Not a screenshot. Not a promise that there is an app. Ask them to show what happens when the office allocates a job and what the driver actually receives.
The driver should be able to see the work clearly. That means job details, addresses, references, notes and any special instructions in one place. If the office still has to send separate WhatsApp messages to explain the real job, the software has not replaced the old process.
Then ask how the driver updates the job. Can they mark progress simply? Can they return ePOD without extra steps? Can they add notes about waiting time or issues on site? Can they do that while the office sees the update quickly enough to act on it?
This matters because every missing update turns into a phone call. The office rings the driver to ask if the collection is done. The customer rings the office to ask for an ETA. The office rings again to ask for the POD. None of that is unusual, but software should reduce it.
You should also ask what happens when signal is poor, when the driver is busy, or when the office needs to correct something after allocation. The best driver workflow is not the one with the most buttons. It is the one that gets the essential information in and out with the least friction.
In practice, that means the demo should show:
- how a driver receives a newly assigned job
- how changes are pushed out
- how proof is captured as ePOD
- how notes and status updates are returned
- how the office sees that information without chasing
If the driver side looks like an afterthought, it will become your office's problem immediately after go-live.
Test the setup, training and first week in the office, whether a small operator can start using the system without an implementation project, consultant or large admin burden
For a small or mid-size operator, the buying decision is not only about features. It is also about whether the software can be up and running without turning into a project of its own.
This is where many firms get stuck. The demo looks fine, the system may even be capable, but the path to using it involves an implementation fee, workshops, data mapping, a long setup period, and too much admin before the first live job goes through it. If you are running three vehicles or thirty, that can be enough to kill the idea.
So ask direct questions about the first week.
How is the system set up? What information do you need to load before using it? Can you start with live jobs and build from there? Who in your office needs training? How long before a planner or owner-operator can use it confidently? What has to be configured by a consultant, and what can you do yourself?
A proper answer should be concrete. It should not sound like a software procurement exercise from a much larger fleet.
For most small UK operators, the realistic test is this. Could the traffic office start using the system without stopping the business for a week? Could the person who plans jobs and also answers the phone learn it without formal project management? Could you get value before every customer and every rate card is perfect in the system?
That matters because most firms in this bracket do not have spare admin capacity. The owner may still drive some weeks. The transport manager may also handle customers, rates, and workshop bookings. If software only works once everything is pristine, it will never feel lighter than the spreadsheet and phone calls it was meant to replace.
At Logivo, we have been deliberate about this. We do not require an implementation project, a consultant, or a minimum fleet size. We built it for operators who need to get jobs planned, drivers briefed, POD captured and invoices moving, without taking on another layer of overhead just to start.
You should also ask about the handover into finance. If invoicing is one of your pain points, the first week should include a clear way to get completed jobs billed promptly. If you use QuickBooks, it is worth understanding that link early, not after the operation is already live. Our guide to QuickBooks integration for transport management software covers what to check there.
The best demo is the one that leaves you thinking, "Yes, we could actually use this on Monday." Not "Yes, this looks powerful if we can spare the time for a rollout."
When you watch a transport software demo, do not buy the promise of a better future in general terms. Buy the evidence that your office will have fewer loose ends next week. One job should go in cleanly, get planned properly, reach the driver clearly, come back with POD, and become an invoice without a fortnight of chasing. If the demo can show that on an ordinary UK haulage or container job, and still cope when the job gets messy, then you are looking at something worth taking seriously.
What should a transport software demo include?
It should show a real job from entry to invoice: planning, driver briefing, status updates, POD or ePOD return, and how the office closes the job without retyping everything.
How long should a TMS demo take?
Long enough to run through your own work properly. If it only shows dashboards and reports, it is too short. You need to see the daily office routine, not just the polished bits.
What should a container operator ask in a demo?
Ask how it records collection and return times, tracks container turnaround, flags demurrage risk, and handles jobs that change during the day.
Should I ask about AI in the demo?
Yes, but ask what it actually does. It should be tied to practical office work, not vague claims. If they cannot show the behaviour on screen, it is not worth much.
Can a small haulage firm use a TMS without a big setup project?
Some can. Ask what has to be configured before your first live job, who does it, and whether you need outside consultants or a long implementation period.