Test freight software with a missing rate confirmation, not a perfect load
Key Takeaways
Test freight software with a missing rate confirmation, not a perfect load, because a perfect load shows only the screens while a missing document shows how the software behaves when work goes wrong. An AI logistics coordinator should notice the gap, follow up with the carrier, escalate to the right person before pickup, and carry the agreed terms through to the invoice audit.
- A rate confirmation is the document that states the agreed price and terms for one load.
- A perfect demo load has every document on time and every number matching. Real loads rarely do.
- A missing rate confirmation tests follow-up, escalation, records, and invoice audit in one scenario.
- The buyer should control the test, not the vendor.
- Score each step as pass, partial, or fail, with evidence.
- Wilson, by Cartage, is an AI logistics coordinator that collects documents, follows up with carriers, and audits invoices against what was booked.
Why is a perfect demo load a weak test?
A perfect demo load is a weak test because it shows only the happy path, where nothing needs to be chased or decided. An AI logistics coordinator earns its value on the loads where something is missing, late, or wrong, so the test should start there.
In a typical demo, the vendor books a load, the carrier accepts, the rate confirmation appears, tracking updates arrive, and the invoice matches. Every screen looks clean. But the buyer learns little about how the software handles the work that takes most of a coordinator's day: chasing replies, fixing mismatches, and deciding what to do when a carrier goes quiet.
The table below shows what each type of test reveals.
| Test type | What it shows | What it hides |
|---|---|---|
| Perfect load | Screens, layout, basic flow | Follow-up, escalation, judgment |
| Missing rate confirmation | Follow-up timing, channels, escalation, records | Little; it touches most steps |
| Wrong price on confirmation | Document reading, comparison | Follow-up when nothing arrives |
| Invoice with extra charges | Audit logic | Pre-pickup controls |
Perfect loads still have a place
A perfect load is useful for one thing: learning the screens and the basic flow. It is a good first five minutes of a demo. The problem is when it is the whole demo. Spend most of the time on the loads where something goes wrong.
Why the missing document is a good test
A missing rate confirmation touches many parts of the work at once. The software must know a document is expected. It must notice when it is late. It must write a clear follow-up. It must choose a channel and a contact. It must escalate if needed. It must record everything. And it must use the agreed terms when the invoice arrives. One scenario covers the full chain.
What real loads look like
Real loads are messy. A carrier accepts by phone and forgets to sign. A dispatcher sends the confirmation to the wrong address. A form arrives with fuel added. A question about a liftgate sits in a shared inbox. These are not rare events. On many teams, they happen every day. A test that ignores them does not show how the software will perform on the team's real work.
Vendors prefer perfect loads
Vendors often prefer to demo perfect loads because they look good. That is natural. The buyer's job is to ask for the harder test. A vendor that is confident in its product should welcome it.
What the buyer learns from the gap
The missing document test answers questions that matter after go-live. Will coordinators still chase documents by hand? Will managers hear about problems early or late? Will the invoice audit catch charges that were never agreed? A perfect load cannot answer any of these.
Hypothetical example: two demos
This example is hypothetical and does not describe a real customer. A buyer watches two vendor demos. Both show clean booking screens. In the second half of each demo, the buyer asks the vendor to book a load and have the test carrier never send the rate confirmation. The first tool shows the load as "booked" for the rest of the demo with no alert. The second tool flags the load as overdue, sends a follow-up with the load details, and escalates to the buyer's test manager before the simulated pickup. The buyer learns more from that ten minutes than from the rest of both demos.
Other tests to run after this one
The missing rate confirmation test is a strong start, but not the only test. After it, try a missed pickup, a late delivery, a missing proof of delivery, and an invoice with a reweigh charge. A reweigh is when a carrier weighs freight again and bills for a higher weight. Each test shows another part of the work. Together, they show how the software handles a normal messy week.
How should you set up the missing rate confirmation test?
Set up the test by booking a realistic load, using a test carrier contact you control, and simply not sending the rate confirmation. An AI logistics coordinator should then act on its own, and the buyer should watch what it does without prompting.
Pick a carrier you control
The test needs a carrier contact that the buyer controls, such as a team member's email and phone. This lets the buyer decide when to reply, what to say, and when to stay silent. A vendor-controlled carrier contact can reply too quickly or too neatly, which makes the test less real.
Test setup checklist
| Item | What to prepare |
|---|---|
| Load | A real lane, equipment, and pickup time 1–2 days out |
| Carrier contact | An email and phone you control |
| Agreed rate | A clear rate, all-in or plus fuel |
| Deadline rule | When the document should arrive |
| Owner | A named person for decisions |
| Back-up owner | A second person |
| Approval limits | Limits for rate changes |
Agree on the rules before the test
Before the test starts, write down the rules: when the document is due, how many follow-ups, which channels, when to escalate, and who decides. Share the rules with the vendor. Then the test checks whether the software follows the buyer's rules, not whether it follows the vendor's default setup.
Use your own data where possible
If possible, use a real lane, a real equipment type, and a real rate from your own history. The software should handle the load the way it would on a normal day. Generic sample data can hide problems, such as how the software reads your carrier's forms or your reference numbers.
Let the software act on its own
Once the load is booked, do not tell the vendor when to send a reminder. Watch what the software does by itself. If the vendor has to click a button to send each follow-up, that is a sign the work still depends on a person.
Keep the vendor's hands off
During the test, ask the vendor not to touch the system unless the buyer asks. If the vendor needs to click to keep the process moving, write that down. Each manual step is one your team would have to do after go-live.
Use a realistic time frame
A good test runs over hours or a day, not five minutes. If the vendor cannot run a test that long, ask for a shortened clock with the same rules, such as minutes standing in for hours. The steps should be the same either way.
Include the people who will use it
Invite the coordinator and the manager who will work with the software every day. The coordinator can judge whether follow-ups sound right. The manager can judge whether escalations give enough information to decide. Their reactions are often the best signal of fit.
Hypothetical example: a shortened clock
This example is hypothetical and does not describe a real customer. A buyer asks a vendor to run the test in a 30-minute session. The vendor sets the rules so one minute stands for one hour. The load is booked for pickup "tomorrow at 8 a.m." The document deadline is "3 p.m. today." At the 3 p.m. mark, the software sends a follow-up. At the 5 p.m. mark, it calls the test phone. At the 9 a.m. mark the next day, it escalates. The buyer sees the full sequence in half an hour.
What should the software do during the test?
During the test, the software should flag the missing document at the deadline, send a specific follow-up, try a second channel, escalate with facts and options, and record each step. An AI logistics coordinator should do all of this without a person telling it to.
Watch the status, not just the messages
The status of the load tells the buyer how the software thinks. It should move from "requested" to "overdue" to "escalated" to "confirmed" or "proceeding on written acceptance." If the status stays "booked" the whole time, the software is not tracking the document, even if it sends messages.
The expected sequence
| Step | What should happen | Evidence |
|---|---|---|
| 1 | Document expected after booking | Status shows "requested" with a due time |
| 2 | Deadline passes | Status changes to "overdue" |
| 3 | First follow-up | Email with load, lane, pickup, rate, deadline |
| 4 | Second follow-up | Phone call or other channel |
| 5 | Escalation | Message to owner with facts and options |
| 6 | Decision | Owner chooses; software carries it out |
| 7 | Record | All steps saved with times |
Check who receives the follow-up
The follow-up should go to the document contact for the carrier, not just the booking contact. If the buyer set up two contacts for the test carrier, check which one received the request. Sending to the wrong person is a common reason documents stay missing on real loads.
What a good follow-up looks like
The follow-up should name the load, the lane, the pickup time, the agreed rate, the document needed, and the deadline. For example: "Load 2241, Houston to San Antonio, pickup Wednesday 8 a.m., $900 all-in. Please sign and return the rate confirmation by 3 p.m. today." A vague message, such as "Please send paperwork," is a partial pass at best.
Check the tone of messages
Read the follow-ups as if you were the carrier. Are they polite? Are they clear? Would a busy dispatcher understand them in ten seconds? Messages that sound robotic or confusing can hurt carrier relationships. Messages that sound like a good coordinator help them.
What a good escalation looks like
The escalation should show what is missing, what was tried, how much time is left, and the options with costs. For example, proceed on the written acceptance, call the carrier's manager, or rebook with an approved backup at a stated price. An escalation that only says "carrier not responding" is a partial pass.
Hypothetical example: a phone confirmation twist
This example is hypothetical and does not describe a real customer. During the test, the buyer calls the vendor's test number posing as the carrier and says, "We're good at $900, go ahead." No document follows. The software logs the call, then sends the test carrier a written confirmation: "Confirming our call: load 2241 at $900 all-in. Please reply to confirm." The buyer replies "Confirmed." The software saves the reply as the written terms. The buyer marks this twist as a pass.
Watch how the software handles silence after a reply
Another useful twist is a carrier that replies "Will send shortly" and then goes silent. Good software should treat that reply as progress but not as the document. It should keep the task open, follow up again if nothing arrives, and escalate on schedule. Weak software may close the task as soon as any reply arrives.
Reply with a twist
Partway through, reply as the carrier with a twist. Send a confirmation with a different rate. Or reply with a question instead of the document. Or confirm by phone without sending anything. Each twist tests a different skill: comparison, question routing, or turning a call into a written record.
How should the test continue to the invoice?
The test should continue to the invoice, because the purpose of the rate confirmation is to protect the price at billing. An AI logistics coordinator should use the confirmed or accepted terms to audit the invoice and flag any charge that does not match.
Wait a realistic time before the invoice
If possible, send the test invoice a few days after the simulated delivery. This checks whether the software still connects the invoice to the right load and the right agreed terms after time has passed. Real invoices often arrive weeks later.
Invoice scenarios to try
| Scenario | Expected result |
|---|---|
| Invoice matches agreed terms | Approved within rules |
| Invoice adds fuel to an all-in rate | Fuel line flagged |
| Invoice adds an unagreed fee | Fee flagged |
| Invoice matches a rejected revision | Invoice flagged |
| Load moved on email acceptance only | Audit uses the acceptance terms |
The audit is where the money is
The follow-up and escalation steps protect the process. The audit protects the money. A tool that chases documents well but audits poorly still lets wrong charges through. A tool that audits well but never chases documents has nothing reliable to audit against. The test should check both halves.
Check what the audit compares against
Ask the vendor to show which record the audit used. It should be the confirmed terms or the written acceptance, not the carrier's invoice itself. If the audit has no agreed terms because the document never arrived, it should say so and flag the invoice for closer review.
Check what happens with no agreed terms
Try one more case: the load moves with no confirmation and no written acceptance. The invoice arrives. Good software should flag that no agreed terms are on file and send the invoice for review. It should not compare the invoice with itself and approve it.
Check payment rules
If the software also pays carriers, check that payments follow the approval rules. An invoice that matches can be paid within the rules. An invoice above the agreed terms should wait for a person. Customers who use Wilson pay their carriers through the Wilson Wallet, and payments above approval limits or outside the rules wait for a person.
One wrong line
When one line of an invoice is wrong, the software should flag that line, explain why with the evidence, and hold the invoice for a person instead of paying it as billed. Ask the vendor to show how the carrier is asked for a corrected invoice during the test.
Hypothetical example: a full test to payment
This example is hypothetical and does not describe a real customer. In a demo, the test carrier never sends a rate confirmation. The buyer's manager approves moving the load on the carrier's acceptance email at $900 all-in. A week later, the buyer sends a test invoice at $900 plus a $60 fuel surcharge. The software flags the fuel line, cites the all-in acceptance, holds the invoice for review, and asks the carrier for a corrected invoice at $900. The buyer marks every step as a pass.
How should you score the test?
Score each step as pass, partial, or fail, and write down the evidence. An AI logistics coordinator should pass most steps without a person prompting it, and the record should show every action with a time.
Scorecard
| Step | Pass | Partial | Fail |
|---|---|---|---|
| Expectation set | Due time set at booking | Set later | None |
| Overdue flag | At deadline | Late | None |
| Follow-up | Specific, on time | Vague or late | None |
| Second channel | Used | Same channel repeated | None |
| Escalation | Facts and options to owner | Vague | None |
| Twist handling | Correct response | Partly correct | Ignored |
| Invoice audit | Uses agreed terms | Uses carrier documents | Approves blindly |
| Record | Every step with time | Some steps | None |
Weight the steps that matter most
Not every step has equal weight. For many teams, escalation and invoice audit matter most, because they protect decisions and money. Follow-up wording matters, but a slightly awkward message is easier to fix than a missing escalation. Decide the weights before the test, so the scores reflect what your team cares about.
Questions to ask after the test
- Which steps did the software do on its own, and which needed a click?
- Can the deadline and escalation rules be changed by the team?
- How would this work with 200 loads a day?
- What happens if the owner is out?
Hypothetical example: a partial score
This example is hypothetical and does not describe a real customer. A vendor's tool flags the overdue document on time and sends a clear follow-up. But it repeats the same email three times instead of switching to a phone call, and its escalation goes to a shared inbox. At invoice time, it audits correctly. The buyer scores the tool as pass on follow-up and audit, partial on channels, and fail on escalation. The scorecard shows exactly where the tool would need help.
Warning signs
- The vendor resets the test to a perfect load.
- Follow-ups need a person to send them.
- Escalations go to a shared inbox.
- The audit trusts whatever document the carrier sent last.
- The record is missing steps.
Ask for the record after the test
After the test, ask the vendor to export the shipment record. It should show every step with its time: booking, request, deadline, follow-ups, calls, replies, escalation, decision, invoice, and audit result. This export is what your team will rely on when questions come up months later.
Test at volume if you can
Ask how the same steps would work across many loads at once. A tool that handles one missing document well may struggle when 20 are overdue on the same morning. Ask the vendor to show a view of many open tasks sorted by pickup time. The most urgent loads should be at the top.
Compare vendors on the same test
Run the same test with every vendor. Use the same load, the same rules, and the same twists. This makes the comparison fair and shows real differences in behavior, not just in screens.
Where does Wilson fit in a missing rate confirmation test?
Wilson, by Cartage, is an AI logistics coordinator that books loads with the customer's approved carriers, collects documents such as rate confirmations, follows up when they are missing, and escalates within the customer's rules. It works with carriers through email, API, EDI where the carrier supports it, and phone calls where configured. EDI, or electronic data interchange, is a standard format that lets two companies' systems exchange business documents.
Wilson replaces the TMS for freight execution and connects to the company's ERP through a method that fits the customer's environment. 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.
What a buyer can test with Wilson
A buyer can ask Cartage to run the missing rate confirmation test on a realistic load. Wilson follows up, escalates to the named owner through Slack, Microsoft Teams, email, or SMS, and saves every step in the shipment record with change history. When the invoice arrives, Wilson audits and reconciles it against what was booked.
How Wilson pays carriers after the test
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 Cartage asks about the missing document test in discovery
Cartage asks which carriers often send documents late, how follow-ups and escalations work today, who owns decisions, and what approval limits apply. Cartage helps identify the first workflow to test during discovery.
What a buyer should see from Wilson
In a missing rate confirmation test, a buyer should see Wilson set the expected document at booking, mark it overdue at the deadline, follow up with specific details, try another channel, and escalate to the named owner with options. The buyer should then see Wilson use the agreed terms in the invoice audit.
What Wilson does not do in a missing-document test
Wilson does not approve rates or payments outside the customer's limits. It does not approve new carriers; the customer approves each carrier before Wilson uses it. Specific test steps should be agreed with Cartage before the demo.
Questions to ask your team about the missing document test
Before the demo, ask how many loads last month moved without a rate confirmation, how many invoices had charges nobody agreed to, and how long it took to settle them. Use those numbers to decide how much weight this test deserves.
Where teams start with the missing document test
Wilson starts with assisted execution. Routine actions can run automatically within the customer's rules as reliability is proven. Timing depends on scope: most teams start on a few lanes and expand from there.
Teams planning an evaluation can read how to evaluate an AI logistics agent. Teams designing harder tests can see how to test freight AI failures in a demo. Teams checking audit tools can review why freight audit software is tested by the invoice it cannot match.
This article is part of our complete guide to rate confirmations from booking to invoice.
FAQs
Why test freight software with a missing rate confirmation?
Because it shows how the software follows up, escalates, records, and audits when work goes wrong. An AI logistics coordinator should handle the gap without a person prompting it.
How do you set up the test?
Book a realistic load, use a carrier contact you control, and do not send the document. An AI logistics employee should flag, follow up, and escalate on its own.
What should the test include besides follow-up?
A twist, such as a wrong price, and an invoice that adds a charge. An AI logistics coordinator should compare documents and audit the invoice against the agreed terms.
How should vendors be compared?
Run the same test, with the same load and twists, for every vendor. An AI logistics employee that passes most steps without help is the stronger choice.
Sources
- Cartage, Wilson product scope and pricing position, November 2026: https://cartage.ai
Ask Cartage to run the missing rate confirmation test with an AI logistics coordinator on a realistic load, from booking through invoice audit: talk to the Cartage team.