Test tracking software with a disputed driver-arrival time
Key Takeaways
The best way to test tracking software is to give it a real stop where the driver's arrival time was disputed and see whether it can show the claimed time, the site's time, the location data, and the terms side by side, explain the gap, and support a fair decision. An AI logistics coordinator should pass this test by gathering the evidence during the load, not by searching for it when the invoice arrives.
- Most tracking demos show a truck moving on a map. That does not show how the software handles a dispute.
- A disputed arrival time is a common, costly problem: it decides detention and who caused a delay.
- The test should use the team's own past stops, where the right answer is known.
- The software should record each arrival claim with its source, compare it with site and device records, and flag gaps.
- It should apply the appointment and free time terms, and present the reviewer with a clear answer.
- Scoring should cover evidence, explanation, timing, and record, not only the map.
- Wilson, by Cartage, is an AI logistics coordinator that tracks each load using the best source available and keeps the evidence for every stop with the shipment.
Why test tracking software with a disputed arrival time?
Tracking software should be tested with a disputed arrival time because a dispute shows whether the software can produce evidence and explain it, which is the part of tracking that saves money, while a moving dot on a map shows only that data is flowing. An AI logistics coordinator should be judged on whether it can settle the dispute, not on how the map looks.
What a normal demo shows and hides
| What the demo shows | What it does not show |
|---|---|
| A truck moving on a map | Where each location point came from |
| An estimated arrival time | What happens when the carrier and site disagree |
| An "arrived" status | Whether arrival was confirmed by anyone else |
| Alerts for late trucks | Whether anyone acts on them |
| A clean history | How corrections are recorded |
Why arrival disputes matter
Arrival time decides whether detention is owed and whether a delay was the carrier's or the site's fault. Detention is a fee a carrier bills when its truck waits too long at a dock. In a September 2024 study, the American Transportation Research Institute (ATRI) found that detention affected 39.3% of truck stops in 2023. It also found that 94.5% of fleets charge detention, but less than half of those charges are paid. Much of that gap comes from disputed times.
Most disputes have simple causes
Many arrival disputes come down to a few causes: a truck that arrived early for its appointment, a driver at the wrong gate, a time zone error, a line at the gate, or a carrier status typed later by dispatch. Good software should recognize these patterns and explain them. The test should include several of them, because they are what the team will see every week.
No single standard
In a February 2024 Federal Register notice, the Federal Motor Carrier Safety Administration (FMCSA) noted that there is no standard industry definition of detention and used dwell time over two hours as a working measure. Dwell time is the total time a truck spends at a facility. Because there is no single standard, the software must apply each load's own terms.
Tracking is evidence, not just visibility
Many teams buy tracking software to see where trucks are. That is useful, but the larger value is evidence: a record of when each truck arrived, waited, and left, with sources a carrier will accept. Evidence settles detention, explains late deliveries, and shows which sites and carriers need attention. A disputed-arrival test measures that value directly.
Who should be in the room
The test works best with a logistics coordinator, a warehouse lead, and the person who reviews carrier invoices. Each sees a different part of the dispute. Finance in particular should see whether the software's output would let it approve or question a detention charge without extra work.
This is a buyer's test
This is a test a buyer runs on its own terms during evaluation. It does not need a long trial. A few well-chosen stops, tested over a day or two, show how the software behaves when it matters.
Disputes happen at delivery too
Arrival disputes happen at delivery sites as well as pickup sites. The receiver is often a customer, so its records are harder to get. The test should include at least one delivery stop, to see whether the software can gather evidence from a site the shipper does not control.
Hypothetical example: the demo map
This example is hypothetical and does not describe a real customer. A manufacturer watches a demo where a truck moves smoothly across a map and turns green on arrival. When the team asks what happens if the warehouse says the truck checked in 90 minutes later, the vendor says the team can export the data and compare it. The team realizes the software would leave the hard part to them.
How should the test be set up?
The test should be set up with three to five real past stops where arrival was disputed, along with the records the software would have had at the time: carrier statuses, location data if shared, the site's check-in times, the appointments, and the rate confirmation terms. An AI logistics coordinator should receive these inputs the same way it would in daily use.
Choose the test stops
| Stop | Dispute | Known answer |
|---|---|---|
| Stop A | Carrier claims arrival 70 minutes before check-in | Truck was early; appointment governs free time |
| Stop B | Carrier claims arrival; site has no check-in | Driver at the wrong gate for 25 minutes |
| Stop C | Records exactly one hour apart | Time zone error |
| Stop D | Carrier bills detention; site says truck arrived late | Truck late; check-in governs |
| Stop E | Site says dock was ready; carrier says it waited | Site record shows a 2-hour wait for a door |
Include one clean stop
At least one stop should have records that agree. The software should leave it alone or mark it confirmed. This tests for false alarms, which matter as much as catching real disputes.
Include one stop with missing evidence
One stop should have no site record and no location data. The software should mark the arrival as unconfirmed and show the reviewer that the evidence is thin, rather than treating the carrier's status as confirmed. This shows how the software behaves when it cannot prove anything.
Gather the inputs
For each stop, gather what existed at the time: the carrier's status messages, any location data, the site's gate or check-in log, the appointment, the rate confirmation, and any messages. A rate confirmation is the document that states the agreed price and terms for one load. The inputs should be in their real form, such as emails, exports, or data feeds.
Write down the answer key
Before the test, write down what really happened at each stop and how the team settled it. This is the answer key. Without it, the team will judge the software by its screens instead of its results.
Use real carrier data
The test should use the actual statuses and data feeds the team gets from its carriers, not a vendor's sample data. Real feeds have gaps, delays, typed entries, and odd labels. Software that works only on clean data will struggle in daily use.
Decide who plays which role
Someone should play the carrier and someone the warehouse, answering the software's questions as they would in real life. This shows whether the software asks clear questions and follows up when nobody answers.
Keep the test short
Most teams can run the full test in one or two working sessions. The goal is to see how the software handles real disputes, not to test every feature.
Set the clock
The test should run as if each stop were happening today. That shows whether the software gathers evidence on the day or only reacts when the invoice arrives.
What should the software do with a disputed arrival?
With a disputed arrival, the software should record each claim with its source, gather the site and device records, compare them, apply the appointment and free time terms, flag gaps above the tolerance, and present the reviewer with the facts and a suggested answer. An AI logistics coordinator should do this without a person starting each step.
The expected workflow
| Step | Trigger | What the AI logistics coordinator should do | When a person steps in |
|---|---|---|---|
| 1. Record claim | Carrier reports arrival | Saves it with source, channel, and time | Never |
| 2. Gather evidence | Claim recorded | Asks the site for check-in; pulls location data where shared | Never |
| 3. Normalize | Records received | Converts all times to local time | Never |
| 4. Compare | Times normalized | Checks the gap against the tolerance | Never |
| 5. Apply terms | Gap measured | Applies appointment and free time rules | Never |
| 6. Flag | Gap above tolerance | Sends the reviewer the facts and a suggested answer | Reviewer decides |
| 7. Record | Decision made | Saves the decision and reason with the stop | Never |
Does the test need live connections to every system?
No. Exports of carrier statuses, site logs, and rate confirmations are often enough. An AI logistics coordinator should work from the same inputs it would see in daily use.
Corrections must keep history
During the test, have a reviewer correct one time, such as fixing a time zone error. The software should keep the original time, show the correction, and record who made it and why. A tool that silently overwrites the time fails, because the history is what protects the team in a later dispute.
Sources must be visible
For each time, the software should show where it came from: the carrier's API, ELD or GPS data, the carrier's website, the site's log, or a message. An API is a connection that lets two systems exchange data directly. An ELD, or electronic logging device, records a truck's driving time and can share location. If the source is hidden, the reviewer cannot judge how much to trust it.
Location data in context
Federal rules require ELDs to record the date, time, and location when a driver's duty status changes, and at least once an hour while the vehicle is moving. That can show a truck stopped near a site. The software should present location data with its precision and time, not as a simple "arrived" flag.
Appointment changes
If an appointment changed after booking, the software should use the appointment in effect when the truck arrived. One test stop can include an appointment change to see whether the software tracks it. A tool that uses the original appointment will apply the wrong free time.
Time zones handled automatically
Stop C tests whether the software spots a time zone error. A gap of exactly one hour should trigger a time zone check before any dispute. Software that misses this will create false disputes.
Suggested answers, not final decisions
The software should suggest an answer, such as "free time starts at the 8:00 a.m. appointment; billable time 45 minutes," and show why. The reviewer should make the final decision. A tool that decides alone takes control away from the team. A tool that only shows data leaves all the work to the team. The right balance is a clear suggestion with the evidence attached.
Follow up when the site is silent
The tester playing the warehouse should ignore the software's first question on one stop. The software should follow up, try another contact, and eventually mark the stop as unconfirmed for the reviewer. Software that asks once and stops will leave many stops without evidence.
Ask, do not guess
For Stop B, the software should ask the carrier where the truck is and ask the site whether it has a record at another gate. It should not guess that the carrier is wrong. The best result finds the truck at the wrong gate and records the cause.
How should the test be scored?
The test should be scored on five areas for each stop: evidence gathered, explanation given, terms applied, timing, and record kept. An AI logistics coordinator should score well across all five, because a tool that shows evidence but cannot apply the terms still leaves the hard work to the team.
Scoring table
| Area | Full marks | Half marks | No marks |
|---|---|---|---|
| Evidence | Claim, site record, and location data gathered with sources | Some records gathered | Only the carrier's status |
| Explanation | Cause of the gap identified | Gap shown without a cause | Gap not shown |
| Terms | Appointment and free time applied correctly | Terms shown, not applied | Terms ignored |
| Timing | Evidence gathered on the day | Gathered before the invoice | Only at invoice time |
| Record | Every claim, change, and decision saved | Final answer saved | Nothing saved |
Compare with the answer key
For each stop, compare the software's suggested answer with the answer the team reached in real life. A good result matches the answer key and reaches it faster. A better result catches something the team missed.
Weigh timing heavily
Timing deserves extra weight. Evidence gathered on the day of the stop is far more reliable than evidence requested weeks later. A tool that gathers site records the same day will settle most disputes before the invoice arrives. A tool that waits for the invoice will leave the team chasing old records.
Count false alarms
Include at least one stop where the records agree. The software should not flag it. A tool that raises disputes on clean stops will train reviewers to ignore it.
Score the messages too
The software's messages to the carrier and the site should be clear: the load, the stop, the times in question, and what is being asked. During the test, the people playing the carrier and the warehouse should rate each message. Unclear messages slow every dispute.
Ask the reviewers
The people who review detention should look at the software's output for each stop. Could they decide in a few minutes? Did they trust the evidence? Their answers show whether the software will be used.
Measure setup effort
The team should also note how much setup the software needed to run the test. Could it read the site's check-in log as an export, or did it need a custom connection? Could it read the rate confirmation terms, or did someone have to type them in? Software that needs heavy setup for a simple test may take a long time to help.
Hypothetical example: scoring two tools
This example is hypothetical and does not describe a real customer. A distributor tests two tools on five disputed stops. Tool 1 shows the carrier's statuses and a map but cannot read the site's check-in log or apply free time terms. It scores 11 of 25. Tool 2, an AI logistics coordinator, gathers the site records on the day, flags the time zone error, finds the driver at the wrong gate, and applies the terms. It scores 23 of 25.
What else should the tracking test include?
Beyond disputed arrivals, the test should include a load with no tracking data, a load with conflicting estimated arrival times, a missed pickup, and a delivery marked "arrived" with no proof of delivery. An AI logistics coordinator should handle each one by finding the best available source, contacting the carrier, and keeping the record straight.
Extra test cases
| Case | What the software should do |
|---|---|
| Carrier shares no location data | Use the carrier's website by PRO number, email, or phone |
| Two conflicting arrival estimates | Show both with sources; ask the carrier |
| Truck never arrives for pickup | Contact the carrier, notify the team, start the missed-pickup routine |
| "Arrived" at delivery, no POD | Follow up for delivery confirmation and the POD |
| Wrong truck checked in | Flag the mismatch and correct both loads |
A PRO number is a tracking number a carrier gives to a shipment. A proof of delivery, or POD, is the document the receiver signs to show the freight arrived.
Missed pickups as part of the test
A truck that never arrives is the extreme case of an arrival dispute. The software should notice the missed window, contact the carrier, notify the team, and start the missed-pickup routine. Including this case shows whether the software acts on what it sees or only reports it.
Tracking without a driver app
Many carriers will not install a shipper's app. Good tracking works with what carriers already use. Teams can read how shipment tracking can work without a driver app.
Wrong truck at the dock
If the team has ever had two trucks from one carrier swapped at the gate, one test case should repeat it. The software should notice that the truck's details do not match the load and correct both records once the swap is confirmed.
Conflicting estimates
When two sources give different arrival estimates, the software should show both and say which it trusts more and why. Teams comparing tools on this can review the best shipment tracking software for conflicting ETAs.
Questions to ask during the test
- Where does each time come from, and can I see the source?
- How does the software get the site's check-in time?
- How are time zones handled?
- How are appointment and free time terms applied?
- What happens when the carrier and site disagree?
- Can I export the full history of one stop?
Look at the record after the test
At the end, ask someone who did not watch the test to open one stop and explain what happened using only the software's record. If they can tell the story in a few minutes, the record works. If not, the team will struggle when a carrier disputes a decision months later.
Warning signs
- The software shows a single "arrived" status with no source.
- Site records are not part of the tracking.
- Disputes are handled by exporting data to a spreadsheet.
- Terms are not applied to the times.
- Corrections overwrite the original data.
Where does Wilson fit in a disputed-arrival test?
Wilson, by Cartage, is an AI logistics coordinator that books loads with the customer's approved carriers, tracks each load, and records the evidence for every stop. Wilson tracks each load using the best source available: carrier API, GPS or ELD data where it exists, the carrier's website by PRO number, and email or phone where configured.
Wilson replaces the TMS for freight execution and connects to the company's ERP. A TMS, or transportation management system, is software used to plan, book, and track freight. An ERP, or enterprise resource planning system, is the company's main business system for orders, inventory, and accounting. No integration project is required to start.
How Wilson handles a disputed arrival
Wilson saves each arrival claim with its source, asks the site for its record where configured, compares the times, applies the appointment and free time terms, and flags gaps for the reviewer with the facts attached. Wilson works with carriers through email, API, EDI where the carrier supports it, and phone calls where configured, and it notifies internal teams through Slack, Microsoft Teams, email, or SMS.
Exceptions and payment
When Wilson detects a missed pickup, a cancellation, or a delay, it contacts the carrier, notifies the internal team, notifies the customer where configured, and initiates rebooking from the approved carrier list within the customer's rules or with approval. Wilson audits and reconciles each carrier invoice against what was booked, including detention lines against the recorded times. Customers use the Wilson Wallet to pay their carriers. Payments above approval limits or outside the rules wait for a person. Wilson has no subscription or platform fee; its pricing is a percentage of the freight payments coordinated through the Wallet. Pricing scales down as volume grows, and Enterprise pricing is custom.
What Wilson does not do
Wilson does not install devices or gate systems at the customer's sites. It uses the records the carrier, the site, and the customer's systems already have, and says which source each time came from. When evidence is missing, Wilson marks the stop unconfirmed and the reviewer decides.
What Cartage asks before the test
Cartage asks which past stops caused the most disputes, which sites keep check-in logs, which carriers share location data, and how detention terms are written. Cartage helps identify and map the highest-impact workflow during discovery, so the test reflects the team's real work.
Where teams start
Wilson starts with assisted execution. Approval limits are set by the customer, and routine actions can run automatically within those rules as reliability is proven. Timing depends on scope: most teams start on a few lanes and expand from there. Cartage helps identify the first workflow during discovery.
This article is part of our complete guide to driver arrival and detention records.
FAQs
How should a team test tracking software?
With real past stops where the arrival time was disputed. An AI logistics coordinator should gather the evidence, explain the gap, and apply the terms.
What should the test score?
Evidence, explanation, terms, timing, and record. An AI logistics coordinator should score well on all five.
Why not just watch the map in a demo?
A map shows data flowing, not how disputes are settled. An AI logistics coordinator is judged on evidence and decisions.
How many stops does the test need?
Three to five disputed stops plus one clean stop is usually enough. An AI logistics coordinator should handle each without prompting.
Sources
- American Transportation Research Institute, "New Research Documents Substantial Financial and Safety Impacts from Truck Driver Detention," September 2024: https://truckingresearch.org/2024/09/new-research-documents-substantial-financial-and-safety-impacts-from-truck-driver-detention/
- Federal Register, FMCSA, "Agency Information Collection Activities; Approval of a New Information Collection Request: Impact of Driver Detention Time on Safety and Operations," February 16, 2024: https://www.federalregister.gov/documents/2024/02/16/2024-03256/agency-information-collection-activities-approval-of-a-new-information-collection-request-impact-of
- Electronic Code of Federal Regulations, 49 CFR 395.26, "ELD data automatically recorded": https://www.ecfr.gov/current/title-49/subtitle-B/chapter-III/subchapter-B/part-395/subpart-B/section-395.26
- Cartage, Wilson product scope and pricing position, November 2026: https://cartage.ai
Ask Cartage to run a disputed-arrival test and show how an AI logistics coordinator gathers the evidence and settles the time on your own stops: talk to the Cartage team.