What actually goes wrong, and when
Almost nobody regrets one of these purchases because of a missing feature. They regret it about eighteen months in, and usually for one of the reasons below. They are listed in the order that matters, which is not the order most evaluations spend their time in.
The system never became the place work happens
The most common failure, and it is behavioural rather than technical. The software goes live, the history does not come with it, one team keeps a spreadsheet for the awkward part, and within a year the spreadsheet is authoritative while the system is where things get typed afterwards. Nothing in a demo predicts this. What predicts it is who migrates the old data, how much work the first ninety days ask of the people entering it, and whether they get anything back for the effort.
The record is structured around the wrong thing
Whether the atomic record is the vehicle or the consignment decides what you can answer later. If fifteen cars share one record, a hold on three of them, a dent on one, and a margin question about any of them all become manual work. This is the hardest thing to change after purchase, because everything else is built on top of it.
Every change now costs money and waiting
Your business will add a lane, a customer whose paperwork works differently, and a charge type that did not exist when you signed. If each of those is a vendor quote and a release date, the distance between what you do and what the system does widens from go-live, and the gap gets covered outside the system.
The data never really flowed between the parties
A demo shows one company's screens. Your operation is a trucker, a terminal, a carrier, an agent and a customer touching the same vehicle. If those facts arrive by email and get retyped, the retyping is both a headcount cost and a source of errors on documents that release cars.
Below those sit four more worth explicit questions rather than assumptions: who is accountable for each fact when several parties can change it; what happens at renewal if the supplier is small or changes hands; whether you could get your data out in a usable form; and whether access control, backups and recovery match the fact that this system will hold titles, photographs and billing data.
You are buying a record structure you cannot easily change, and a change process you will use every month for a decade. Evaluate those two first. A product can be strong at both and still lose a feature comparison, and the reverse is more common.
Score what you see, not what you are told
Feature matrices mislead because they record a yes without recording what kind of yes it was. Use one scale for every claim, from every vendor, and write the level beside it. Anything below configurable carries a cost, a delay or a risk that belongs in the comparison.
| Level | What it means | What it costs you |
|---|---|---|
| Native | You watched it work on your data | Nothing |
| Configurable | Your administrator can set it up and it survives upgrades | Time |
| Integrated | Works through a named third party, already in production somewhere | A second supplier and a second failure point |
| Custom | The vendor will build it for a fee | Money, a date, and re-testing at every upgrade |
| Manual | A person does it outside the system | Headcount, and it will drift |
| Promised | On the roadmap, not built | Uncertainty. Treat as absent unless contracted |
| Unsupported | It does not do this | Only matters if you need it |
Then set your gates before you see anything, because it is much harder to be honest afterwards. Decide which failures eliminate a vendor, which you would accept if the contract fixed a date and a price, and which you can live with. Most teams find they have only two or three real disqualifiers, and learning that early is worth more than any scoring spreadsheet.
The four stages, cheapest first
Stage 1: Test the record structure before you agree to a demo
These can be answered on a call, and they eliminate more candidates than anything later.
The unit-of-record test
Ask to see the screen for a single vehicle rather than for a booking. If there is no such screen, or it is a line on a consignment, you have your answer about what the system is a record of.
The state test
Pick a condition that changes how a vehicle is handled and priced. A car that will not start is the usual example, because it needs a winch, a reachable slot and a carrier who accepts it. Ask what the system does with that fact and who it reaches. A note field is not a state, because nothing downstream can act on it.
The per-unit money test
Ask which vehicles on last month's largest consignment made money. If answering needs an export and a spreadsheet, cost and revenue hang off the shipment rather than the unit, and margin questions stay manual.
The correction test
Ask what happens when a fact recorded last week was wrong: an invoice already issued, a VIN entered against the wrong booking. Whether the system corrects with a trail, overwrites silently, or cannot, tells you more about its data model than any feature page.
Stage 2: Run your own worst week, not their demo
Demos are built on clean data, and in this trade the cost sits in the exceptions. Supply your scenarios in advance and ask for them in one sitting: a vehicle damaged at the third of four custodians, a consignment split across two sailings, a unit rolled to the next vessel, an invoice corrected after issue, and a used car whose title arrived late. At the end, ask for the outputs you would really have needed, which is usually a bill of lading naming every vehicle, an invoice, and the evidence you would send if a customer disputed the damage.
Measure two things while you watch. Count the times someone types a fact the system already holds, because that number is your rekeying cost and it does not shrink after go-live. And note every time the answer is a process rather than a screen, because "we would handle that by..." scores as manual on the scale above.
A vendor asking for setup time on your scenarios is being reasonable. If they steer back to their own script, ask directly whether the scenario is unsupported or simply not configured in the demo tenant. Those are different answers and only one of them should count against them.
Stage 3: The questions that decide year two
The stage most evaluations skip, and where the money is. Ask for these in writing.
The change-order test
What did the last three change requests from a customer of our size cost, and how long did they take from request to production? Then: which of the changes we expect, a new charge type, a new lane, a new document layout, can our own administrator make?
The migration plan
Who cleans and maps the historical data, and who signs off that it is right? What happens to jobs open on cutover weekend? What does the first ninety days measure, and what does the person entering data get back for the effort?
Production integrations, named
Not "is there an API". Which of our actual counterparties do you exchange data with in production today, and may we speak to a customer using that link? Include the export filing route, the carriers you book with, and your accounting system.
The exit test
If we leave in year six, what comes out, in what format, and does it include documents and photographs as well as rows? Is that right written into the contract, or does it depend on goodwill at the moment you have least of it?
Alongside those, build a rough cost over your whole hold period rather than comparing annual licence fees: implementation, the licence as headcount grows, integrations, support, the custom work you already know you need, the administrative time to run it, and what renewal looks like. Ask what happens to pricing if the supplier is acquired.
Stage 4: References, scripted to the same tests
Ask for a customer of similar size and mix, then ask them what the vendor cannot answer on their behalf: what still runs in a spreadsheet beside the system and why, what their last change request cost and how long it took, how the migration actually went, and what they would evaluate differently if they were choosing again.
If you take one thing from this guide, take the sequence rather than the questions. Stage 1 is a phone call and stage 3 is an email, and both eliminate candidates more cheaply than the demo most evaluations start with.
Weighting: which of these matters most for you
The order above is a default, not a law. Adjust it to your operation.
- Heavy on used vehicles and exports: compliance evidence, correction trails and per-unit records carry more weight, because the paperwork is per vehicle and arrives late more often.
- New vehicles on contract flows: integration reality and document automation dominate, because volume is high, exceptions are rarer, and the counterparty sets the data standard.
- Running your own compound or yard: the physical model matters more, meaning how the system represents where a unit is standing, what has been done to it, and how someone walking the lot with a scanner finds it.
- Vehicles are one part of a mixed book: weight lifecycle cost and supplier risk above vehicle-specific capability, and read the next section closely.
When a general freight platform is the better buy
This is the part vendor material leaves out, so it is worth being direct, including about the cases that are uncomfortable for a specialist.
Palletised stock is most of your warehouse work
If your storage labour is racks and bins, with put-away, picking, replenishment and a dimensioner measuring cartons, a warehouse system is built for that and a vehicle system is not. Vehicle yards model spots, not shelves. Buy for where the labour is.
US import brokerage is a core service
Customs entry on the import side is a different discipline from export filing, with its own infrastructure and licensing. If you file entries for importers as a service, that should drive the choice and vehicle handling should be evaluated second.
The general platform already exchanges data with your counterparties
A system that models vehicles well but has no production link to the carriers and systems you actually use can cost more in rekeying than it saves in fit. Integration coverage that already exists is worth more than integration that is possible.
Lifecycle cost or supplier risk points the other way
Vendors in a narrow vertical are usually smaller companies. If total cost over your hold period is lower elsewhere, or you are not comfortable depending on a small supplier for a decade, that is a legitimate reason to choose the broader product and accept some workaround.
A configurable general platform passes your own tests
If a general system can be configured, without custom work, to hold a per-vehicle record with the states and evidence your exception scenarios demand, it has passed. The category label is not the criterion. The tests are.
Vehicles are a genuine side line
If cars are a small share of a mixed book and the awkward parts of your week are elsewhere, a second system will cost more than the fit saves. Revisit when custody changes or claims start taking real time.
US export paperwork, and what it does not decide
If you export used vehicles from the United States, two obligations land on the same clock and both are worth confirming a system can support. Under 19 CFR 192.2(c)(1) the vehicle and its documentation must be presented to Customs and Border Protection at least 72 hours before export by vessel. Under 15 CFR 30.4(b)(4) the export filing citation is due to CBP on that same 72-hour clock, which is stricter than the general 24-hour vessel cargo deadline that applies separately to the carrier.
Be careful how much these decide for you. They create obligations about timing and about evidencing what you did. They do not say which system holds the title number, the issuing state or the returned filing number, and they do not require any particular validation behaviour. You can meet them with an operations system that carries the data, or with document management alongside one that does not. Those are design choices with real differences in effort and error rate, worth evaluating on that basis rather than treating one shape as legally required. The fair question to a vendor is narrower: given our volumes, what does your system do to make a missing title visible before the 72-hour mark, and can the filing result be seen per vehicle rather than per consignment?
Regulatory readings here were verified against the raw text of 19 CFR 192.2, 15 CFR 30.4 and 46 CFR part 532 on 29 August 2026. This is guidance on what to ask a vendor, not legal or customs advice, and it does not cover every case. Confirm your own obligations with your customs counsel.
Reaching a decision someone else could reproduce
At the end you should be able to hand a colleague your notes and have them arrive at the same answer. For each candidate that means: the level from the scale beside every claim that mattered, which gates it passed or failed, what stage two showed rather than what was said, written answers on change cost, migration and exit, and a cost over the hold period rather than a licence fee.
If you cannot produce that, the evaluation is not finished, however good the demo was. And if two candidates finish close, choose on stage three rather than stage one, because feature gaps narrow over a decade and the cost of changing a system does not.
